[WG: Sakai QA] [Building Sakai] KNL-155/SAK-16036/SAK-800: Resources archive file handling issues

John Leasia jleasia at umich.edu
Thu Apr 16 10:35:04 PDT 2009

Seems like the safest at this date - least impact/risk on the code - is 
comment the couple lines that put up the menu item.


Anthony Whyte wrote:

>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.
>Further reading:
>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  
>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 =  
>sakai-dev mailing list
>sakai-dev at collab.sakaiproject.org
>TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai-qa/attachments/20090416/d0144c87/attachment-0001.html 

More information about the sakai-qa mailing list