>-----Original Message-----
>From: Vadim Gritsenko [mailto:[EMAIL PROTECTED]]
>
>Geoff Howard wrote:
>
>>I've been working on a quick patch to provide a third autosave-uploads
>>option. Currently "true" results in a permanent file
>(FilePartFile) being
>>created in the upload-dir. "false" results in a temporary
>byte[] stored in
>>memory (FilePartArray).
>>
>>when doing work on file uploads before it occurred to me that
>it might be
>>useful to have an option to have a temporary physical file which gets
>>deleted after request processing is done. I had originally
>planned on using
>>FilePartArray for this but was concerned about situations
>where large files
>>are uploaded with respect to memory use. Using FilePart
>instead I consider
>>a potential problem since an abusive user aware of cocoon's
>system could
>>upload arbitrary files to any server running cocoon limited
>only by the
>>default 10 meg limit per request.
>>
>>i've got it working locally (though not bugzilla ready yet)
>but before I
>>spend more time on it wanted to see if
>>
>>1) does this seem like a worthwhile feature, and
>>
>>
>
>I think it makes sense to add feature like this.
>
Certainly a useful feature but rather than having to choose either/or
we should have a hybrid solution. For small upload requests use
FilePartArray
to avoid the filesystem overhead, for large one use FilePartFile to
avoid
memory exhaustion.
Just define a new config parameter <max-memory-uploads>. In
MultipartParser
read first into a buffer of that size. If buffer overflows, make an
FilePartFile,
otherwise wrap the buffer it into a FilePartArray.
autosave-uploads="false" with "max-memory-uploads="0" is then equivalent
to
your autosave-uploads="temp".
>
>>2) make sure my implementation was acceptable.
>>
>>
>>if (tempUploads) {
>> log.debug("AutoSave uploads set to temporary - examining request
>>parameters");
>> Enumeration enum=request.getParameterNames();
>> while(enum.hasMoreElements()) {
>> // use requestFactory directly so we don't have to go back through
>> // the objectModel. We already know we're in the servlet
>environment
>> Object
>obj=this.requestFactory.get(request,(String)enum.nextElement());
>> // should FilePartArrays be handled too? (nulled?)
>> if (obj instanceof FilePartFile) {
>> File tmpFile=((FilePartFile)obj).getFile();
>>
>
An extra loop over *all* parameters of *all* requests is too high a
price.
You should use instead a request attribute with a fixed name. If set,
it contains the List of FilePartFile objects to clean up.
For autosave-uploads="false", MultipartParser simple creates/adds to
that
list the FilePartFile objects it creates.
>
>>Any suggestions?
>>
>>Geoff Howard
>>
>>[1] autoSaveUploads will still need to be set to true to get
>FilePartFile -
>>I considered but rejected subclassing FilePartFile to FilePartTempFile
>>because I'd also have to modify at least the MultipartParser
>and the method
>>signature for requestFactory.getServletRequest and wasn't
>sure how that
>>would affect MaybeUpload
>>
I'd say time to dump MaybeUpload and rework the RequestFactory interface
into getServletRequest(HttpServletRequest, RequestOptions).
Cheers, Alfred.
This message is for the named person's use only. It may contain
confidential, proprietary or legally privileged information. No
confidentiality or privilege is waived or lost by any mistransmission.
If you receive this message in error, please notify the sender urgently
and then immediately delete the message and any copies of it from your
system. Please also immediately destroy any hardcopies of the message.
You must not, directly or indirectly, use, disclose, distribute, print,
or copy any part of this message if you are not the intended recipient.
The sender's company reserves the right to monitor all e-mail
communications through their networks. Any views expressed in this
message are those of the individual sender, except where the message
states otherwise and the sender is authorised to state them to be the
views of the sender's company.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
