[
https://issues.apache.org/jira/browse/TRINIDAD-1757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12850390#action_12850390
]
Girish Kumar Balachandran edited comment on TRINIDAD-1757 at 3/26/10 10:52 PM:
-------------------------------------------------------------------------------
Here is how we propose to extend this enhancement request:
We would like to make it easy for folks to write simple, efficient and
optimized chain of multiple UploadedFileProcessor in the platform. We would
also strive to be backward compatible with the current implementations of
fully overriding UploadedFileProcessor implementations. Hence, this is how we
are going to implement:
* Introduce a new Interface called ChainedUploadFileProcessor that extends
UploadedFileProcessor. This interface is just a marker interface to distinguish
between the old fully overridden implementation versus the multiple chained
upload processors.
* clients wanting to fully override UploadedFileProcessor continue implementing
the UploadedFileProcessor and declaring it in trinidad-config.xml under the
<uploaded-file-processor> element. The UploadedFile object that gets sent in
the call UploadedFileProcessor.processFile( Object request, UploadedFile file)
will not have any buffer backing. Implementers of this interface need to take
care of buffering of the stream and passing it along to the bean. This is how
it works as of today and will continue to work.
* clients wanting to do minimal processing on the file stream (like virus
scanning on the content, profanity scanner, etc), with out worrying too much
about the buffering, can use the new interface ChainedUploadFileProcessor. The
UploadedFile parameter that gets passed for the call impl
UploadedFileProcessor.processFile( Object request, UploadedFile file) will be
actually backed by buffer. This buffer will also respect the buffer limits that
is available as of today via <uploaded-file-max-*> elements.
* If there is a need for multiple UploadedFileProcessor to process the file
content, then clients could have more than one implementation for
ChainedUploadFileProcessor and chain them up in trinidad-config.xml using space
separated character like the following example:
** <uploaded-file-processor> MyVirusScanner MyProfanityScanner MyFileSaveToDB
</uploaded-file-processor>
** the chained processors will be called in the same order as it appears inside
the <uploaded-file-processor> element.
** ChainedUploadFileProcessor.processFile( Object request, UploadedFile file)
should still return UploadedFile. This is the object that will be passed to the
next impl in the chain. This is to enable decorating the UploadedFile stream
with the previous impl in the chain. If the content was not decorated, then
just returning the UploadedFile parameter will suffice.
was (Author: girixkumar):
Here is how we propose to extend this enhancement request:
We would like to make it easy for folks to make it easy, efficient and
optimized chain of multiple UploadedFileProcessor in the platform. We would
also strive to be backward compatible with the current implementations of
fully overriding UploadedFileProcessor implementations. Hence, this is how we
are going to implement:
* Introduce a new Interface called ChainedUploadFileProcessor that extends
UploadedFileProcessor. This interface is just a marker interface to distinguish
between the old fully overridden implementation versus the multiple chained
upload processors.
* clients wanting to fully override UploadedFileProcessor continue implementing
the UploadedFileProcessor and declaring it in trinidad-config.xml under the
<uploaded-file-processor> element. The UploadedFile object that gets sent in
the call UploadedFileProcessor.processFile( Object request, UploadedFile file)
will not have any buffer backing. Implementers of this interface need to take
care of buffering of the stream and passing it along to the bean. This is how
it works as of today and will continue to work.
* clients wanting to do minimal processing on the file stream (like virus
scanning on the content, profanity scanner, etc), with out worrying too much
about the buffering, can use the new interface ChainedUploadFileProcessor. The
UploadedFile parameter that gets passed for the call impl
UploadedFileProcessor.processFile( Object request, UploadedFile file) will be
actually backed by buffer. This buffer will also respect the buffer limits that
is available as of today via <uploaded-file-max-*> elements.
* If there is a need for multiple UploadedFileProcessor to process the file
content, then clients could have more than one implementation for
ChainedUploadFileProcessor and chain them up in trinidad-config.xml using space
separated character like the following example:
** <uploaded-file-processor> MyVirusScanner MyProfanityScanner MyFileSaveToDB
</uploaded-file-processor>
** the chained processors will be called in the same order as it appears inside
the <uploaded-file-processor> element.
** ChainedUploadFileProcessor.processFile( Object request, UploadedFile file)
should still return UploadedFile. This is the object that will be passed to the
next impl in the chain. This is to enable decorating the UploadedFile stream
with the previous impl in the chain. If the content was not decorated, then
just returning the UploadedFile parameter will suffice.
> Allow (or support) decorator pattern for the UploadedFileProcessor
> ------------------------------------------------------------------
>
> Key: TRINIDAD-1757
> URL: https://issues.apache.org/jira/browse/TRINIDAD-1757
> Project: MyFaces Trinidad
> Issue Type: Improvement
> Affects Versions: 1.2.13-core , 2.0.0-alpha-2
> Reporter: Matthias Weßendorf
>
> Currently it is only possible to replace the entire UploadedFileProcessor,
> with a custom one.
> A neat improvement (crap, this should not be a bug) would be supporting the
> decorator pattern.
> The tricky part is that we need a buffer inside of the implementation of the
> file
> that get's passed into the Processor.
> currently you can call only once the "getInputStream", so we need a buffer
> here
> (that works with the impl's writeFile()/getInputStream()):
> There are some ways for that.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
