[Building Sakai] Unable to upload large file/resource, but still smaller than content.upload.max?

[Charles Hedrick]

Is that a full fix? The backtrace that caused me to make my initial comment seemed to be in a normal resource tool. I haven't trace it yet, but conjecture that the problem is the way the new API is defined. If you define both getcontent and getcontentstream, getcontent wins. That is you use the stream only if the source isn't able to produce the byte array. I conjecture that some sources define both. I will track down what's really going on, but at the moment I wonder if it wouldn't be better for code to first check whether there's a stream available and use the array only if it's not.

On Nov 17, 2009, at 6:38:03 PM, Seth Theriault wrote:

> Steve Swinsburg wrote:
> 
>> As for adding content via an InputStream rather than byte[], looks like
>> http://jira.sakaiproject.org/browse/KNL-325 is the one and the fix version
>> is in Kernel trunk v1.1.0-beta04 (not 2.6.x):
> 
> This JIRA is on the candidate list for inclusion in 2.6.2 (would
> require a new K1 release) and 2.5.6:
> 
> http://confluence.sakaiproject.org/display/REL/Sakai+2.6.2+and+2.5.6+Jira+Candidates
> 
> Seth
> _______________________________________________
> 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: 2421 bytes
Desc: not available
Url : http://collab.sakaiproject.org/pipermail/sakai-dev/attachments/20091118/eeba1903/attachment.bin