[WG: Sakai QA] [Building Sakai] KNL-155/SAK-16036/SAK-800: Resources archive filehandling issues
Anthony Whyte
arwhyte at umich.edu
Fri Apr 17 16:58:22 PDT 2009
The property fix as implemented:
/config.../*.sakai.properties (demo, default, sample)
. . .
# KNL-155/SAK-16036/SAK-800 Hack; enable/disable archive file handling
# [WARN] archive file handling (e.g., compress/expand) is buggy; see
KNL-155/SAK-16036 for details.
# Default=false
resource.zip.enable=false
. . .
kernel-impl/src/main/java/org/sakaiproject/content/types/
FolderType.java
. . .
// KNL-155/SAK-800 Hack; archive file handling is buggy; enable by
property setting only
if (ServerConfigurationService.getBoolean
(RESOURCES_ZIP_ENABLE,false)) {
actions.put(ResourceToolAction.COMPRESS_ZIP_FOLDER, new
FolderCompressAction());
}
. . .
FolderUploadType.java
. . .
// KNL-155/SAK-800 Hack; archive file handling is buggy; enable by
property setting only
if (ServerConfigurationService.getBoolean
(RESOURCES_ZIP_ENABLE,false)) {
actions.put(ResourceToolAction.EXPAND_ZIP_ARCHIVE, new
FileUploadExpandAction());
}
. . .
Using properties to mask or otherwise hide incomplete or problematic
code (see SAK-800) is not ideal. However, given that at least one
institution, Oxford, is comfortable using the code as is, renders
problematic the simple and straightforward expedient of commenting
out the functionality and forcing them into hack mode when
implementing 2.6.0 or 2.6.x.
The archive action options are now hidden by default in the resource
tool action dropdown. Local implementers have the option of
explicitly overriding the config's default.sakai.properties as has
been requested by Oxford. There is a warning message in
*.sakai.properties regarding enabling archive file handling and we
can provide a warning in the release notes as well.
Cheers,
Anth
On Apr 17, 2009, at 5:26 PM, Matthew Jones wrote:
> I'm also on the side of commenting it rather than providing a
> property. It seems like this could be done by 2.6.1 but not by the
> first 2.6.0. The stack trace in dropbox, the permissions issue and the
> stack dumps that should throw error messages to logs with no response
> to the user were 3 functional ones. Beyond that since it isn't
> performance tested and it has large delays in certain conditions we'd
> probably still need a property that could limit its availability.
>
> Something like
> #Turn off the option
> resources.option.zip=false
> #Everyone can use the option
> resources.option.zip=true
> #Only people with maintain role can use the option
> resources.option.zip=maintain
>
> Since we are pushing for a release soon, this idea wouldn't be
> resolved in the very near term if I were working on it.
>
> I'm +1 for commenting it now, and I'm also +1 for improving it and
> adding it as an property eventually (as I also patch it in
> occasionally, but only on a development server)
>
> Since it looks like you've decided to property it, I'd still make this
> clear in sakai.properties (if you decide to even put it in there and
> make it public) that this feature does have known bugs and we
> recommend that it be left disabled at present time.
>
> -Matthew
>
> On Thu, Apr 16, 2009 at 1:59 PM, Adam Marshall
> <adam.marshall at oucs.ox.ac.uk> wrote:
>> We use SAK-800 in production and whereas the zipping up is a bit
>> flaky, the
>> unzipping seems to work fine.
>>
>> As we have to apply the SAK-800 patch for each build, we'd like to
>> see it in
>> the code base protected by a property that by default disables the
>> functionality.
>>
>> Perhaps if it is available in the download, some kind soul may fix
>> the
>> outstanding problems (and add an option to save the ZIP file on
>> one's local
>> machine!)
>>
>> Adam
>>
>> | -----Original Message-----
>> | From: sakai-dev-bounces at collab.sakaiproject.org [mailto:sakai-dev-
>> | bounces at collab.sakaiproject.org] On Behalf Of Anthony Whyte
>> | Sent: 16 April 2009 18:16
>> | To: Sakai-Dev Developers
>> | Cc: Sakai QA
>> | Subject: [Building Sakai] KNL-155/SAK-16036/SAK-800: Resources
>> archive
>> | filehandling issues
>> |
>> | In April 2008 code was merged into trunk /content (r 45419, 45421)
>> | and the API and service modifications were later repackaged in the
>> | kernel (K1) in order to provide the ability to create/extract from
>> | archive file types (e.g., .zip, .tar, .tgz). The most recent
>> | comments in SAK-800 combined with recent testing by Matt Jones of
>> | UMich (as reported in KNL-155) indicates that this feature still
>> has
>> | a number of problems associated with it (Matt's comments are
>> below).
>> |
>> | Given these concerns and the short time frame that now exists with
>> | respect to the upcoming 2.6.0 release Matt has suggested the
>> | following options in lieu of fixing it:
>> |
>> | 1) remove it
>> | 2) comment it out
>> | 3) wrap it in a property setting (enable/disable) and add the new
>> | property (e.g., resources.zip.experimental = false) to /config
>> | default.sakai.properties. Default = disabled.
>> |
>> | I'd appreciate your opinion on the matter.
>> |
>> | Cheers,
>> |
>> | Anth
>> |
>> |
>> | Further reading:
>> |
>> | http://bugs.sakaiproject.org/jira/browse/KNL-155
>> | http://bugs.sakaiproject.org/jira/browse/SAK-16036
>> | http://bugs.sakaiproject.org/jira/browse/SAK-15995
>> | http://bugs.sakaiproject.org/jira/browse/SAK-800
>> |
>> | KNL-155/SAK-16036. Matt Jones comments:
>> |
>> | "Since there were still so many issues with SAK-800, it's status
>> was
>> | recently brought up by Stephen on the QA mailing listlist,
>> Because of
>> | followup concerns and based on the comments for on the jira for
>> | SAK-800, I believe that it shouldn't be released in the final
>> build.
>> | This contributed patch was merged into trunk in an unfinished state
>> | and made it into the 2.6 release. Ideally the issues in this patch
>> | should be resolved but this will unlikely happen before the release
>> | and it should not hold it up.
>> |
>> | Here were my comments on the QA list:
>> |
>> | - There is no feedback to the user when anything goes bad, as the
>> | link appears on resources that you don't have permission to (this
>> | could be checked for permission first in FolderCompressAction) and
>> | there was an NPE as indicated on the jira.
>> | - No solution for extracting files that already exist in resources
>> | - If the zip file or number of contained files is large, the
>> | extraction/compression might take a long time and the UI will block
>> | interaction rather than threading it. An alternative would be to
>> have
>> | it check sizes in advance. I think I even tested a zip file
>> | containing 0K small files and it took almost 5 minutes to
>> uncompress.
>> | - I wasn't sure if compressing large files/directories ran into
>> | memory errors or not, some of these edge cases should be tested.
>> | - I don't think I tested what happens operated on really isn't a
>> zip
>> | file, just has a .zip extension There's no error messages shown by
>> | the tool, so
>> | - More errors in general need to be show to the user.
>> |
>> | This should be able to be easily disabled in the UI, you'd just
>> have
>> | to wrap up
>> | the actions in FileUploadType/FolderType
>> | actions.put(ResourceToolAction.EXPAND_ZIP_ARCHIVE, new
>> | FileUploadExpandAction());
>> |
>> | I don't know if we'd want to wrap these up with a user settable
>> | sakai.properties value, comment it out of the code or unmerge this
>> | patch. It would be nice to eventually see it working. I would
>> | probably vote to disable via property just to give someone interest
>> | on possibly working on it again. Like resources.zip.experimental =
>> | false."
>>
>> _______________________________________________
>> sakai-dev mailing list
>> sakai-dev at collab.sakaiproject.org
>> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>>
>> TO UNSUBSCRIBE: send email to sakai-dev-
>> unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"
>>
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2417 bytes
Desc: not available
Url : http://collab.sakaiproject.org/pipermail/sakai-qa/attachments/20090417/239f294f/attachment-0001.bin
More information about the sakai-qa
mailing list