> -----Original Message-----
> From: Nathaniel Alfred [mailto:[EMAIL PROTECTED]]
> Sent: Monday, October 14, 2002 4:58 PM
> To: [EMAIL PROTECTED]
> Subject: RE: [VOLUNTEER] Re: DO NOT REPLY [Bug 13541] New: -
> SAVE_UPLOAD_FILES_TO_DISK should be configurable
>
</snip>
> 3.) Refactor MultipartRequestFactoryImpl and friends.
>
> How should MultipartRequestFactoryImpl be refactored?
>
> The FilePartArray stuff works fine. The only problem is that for
> duration
> of a request it has provide buffer space for the whole request body.
> With
> a few large uploads running in parallel it can easily exhaust all JVM
> memory.
>
> Rather than choosing in the configuration either/or
> array/file a hybrid
> approach should be used. Small upload request (configurable limit
> ~100k)
> are kept in memory.
>
> Larger uploads are written to a *temporary* file created with a random
> name
> in tempdir and automatically removed by CocoonServlet at the
> end of the
> request.
>
I'd like to have the means to handle the uploaded file in my own code.
If the code that handles the file will be separated from the HTTP request handling,
into a new component, it will be easier to build custom implementations that handle
the file upload, according to the logic of the application.
An implementation that always store the file to the file system, when it is obvious it
should be then copied to another place (since it will be deleted when the request
ends) reduces performance.
> The samples/xsp/upload.xsp is then made working again by
> reading out the
> upload content from the request and storing it as permanent file.
>
> <xsp:logic>
> FilePart filePart = (FilePart)request.get("uploaded_file");
> InputStream contentStream = filePart.getInputStream();
> File uploadFile = new File(filePart.getSafeFilePath(uploadDir));
> // copy contentStream to uploadFile
> ...
> </xsp:logic
>
> This could actually be turned into an FileUploadAction with
> configuration
> parameters:
>
> <map:act type="upload" src="path/to/inbox">
> <map:parameter name="overwrite" value="deny|allow|rename"/>
> <map:parameter name="maxsize" value="10000000"/>
> ... Thank you for your file
> </map:act>
> ... Sorry, your file could not be stored
>
> SimpleRequestFactoryImpl should become the fallback request factory in
> CocoonServlet, unless web.xml (or cocoon.xconf) says otherwise.
> The request factory in the example configuration should be
> MultipartRequestFactoryImpl with a reasonable limits for array/file
> sizes.
>
> The RequestFactory should be extended to allow registering different
> request wrappers depending on the method ("POST") and content type
> ("multipart/form-data"). That can come handy if more special request
> decoding is required (WEBDAV?, SOAP?).
>
> CocoonServlet.init():
>
> MultipartRequestFactoryImpl.setMaxBufferSize(maxBufferSize);
> MultipartRequestFactoryImpl.setMaxUploadSize(maxUploadSize);
>
> RequestFactory.register("POST",
> "application/x-www-form-urlencoded",
>
> "org.apache.cocoon.component.request.SimpleRequestFactoryImpl");
>
> RequestFactory.register("POST", "multipart/form-data",
>
> "org.apache.cocoon.component.request.MultipartRequestFactoryImpl");
>
> RequestFactory.register("...", "...",
>
> "org.apache.cocoon.component.request.MySpecialRequestFactoryImpl");
>
Why put this configuration in the code, and not in cocoon.xconf ?
Is there a way to configure this differently for different sitemaps/pipelines, so for
example, only a specific pipeline allows the use of multipart/form-data, while other
pipelines block such requests ?
Thanks,
Amir
>
> CocoonServlet.service():
>
> RequestFactory factory =
> RequestFactory.getRequestFactory(req.getMethod(),
>
> req.getContentType());
> HttpServletRequest request = factory.getServletRequest(req);
>
>
</snip>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
