You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by Blake Sullivan <bl...@oracle.com> on 2009/05/06 18:27:53 UTC
Re: [jira] Commented: (TRINIDAD-1464) max upload size cannot be
reconfigured after app is deployed
Matthias Wessendorf said the following On 5/5/2009 10:01 PM PT:
> Hi Blake,
>
> the idea is to change the upload-config during runtime.
> Not sure how moving it to trinidad-config helps to change it
> via an Java API.
>
> -Matthias
>
My thinking was that the application EL binds the trinidad-config
attribute. Since we reread the EL-bound attributes on each request, the
application is free to use any scheme it wants to determine the maximum
size, including doing so on a per-user or per-user-per-request basis.
-- Blake Sullivan
> On Fri, May 1, 2009 at 7:18 PM, Blake Sullivan
> <bl...@oracle.com> wrote:
>
>> Matthias,
>>
>> Would things be improved if we moved the configuration to
>> trinidad-config.xml and allowed the configuration to be retrieved on a
>> per-request basis?
>>
>> -- Blake Sullivan
>>
>> Matthias Weßendorf (JIRA) said the following On 5/1/2009 4:25 AM PT:
>>
>> [
>> https://issues.apache.org/jira/browse/TRINIDAD-1464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12704962#action_12704962
>> ]
>>
>> Matthias Weßendorf commented on TRINIDAD-1464:
>> ----------------------------------------------
>>
>> One possible approach:
>> *create a new abstract class in the Trinidad API "FileUploadConfig"
>> and define abstract get/set methods for "maxMemory", "maxDiskSpace"
>> and "tempDir".
>>
>> *every implementation of the UploadedFileProcessor that wants to change
>> the configuration during runtime should not only implement the actual
>> UploadedFileProcessor interface, it also has to implement the abstract
>> "FileUploadConfig" class. The UploadFileProcessorImpl (default) would
>> do that too.
>>
>> *since the FileUploadConfig implementation is shared over all sessions
>> (application scoped), the implementor (e.g. the UploadFileProcessorImpl)
>> needs to be aware of writing thread-safety code, when *setting* the new
>> value...
>>
>> possible usage in an action-method:
>> ...
>> FileUploadConfig fuc = null;
>> UploadedFileProcessor ufp = requestCtx.getUploadedFileProcessor();
>> if(ufp instanceof FileUploadConfig)
>> {
>> fuc = (FileUploadConfig) ufp;
>> fuc.setMax.....(....);
>> }
>> ...
>>
>>
>>
>> max upload size cannot be reconfigured after app is deployed
>> ------------------------------------------------------------
>>
>> Key: TRINIDAD-1464
>> URL: https://issues.apache.org/jira/browse/TRINIDAD-1464
>> Project: MyFaces Trinidad
>> Issue Type: New Feature
>> Affects Versions: 1.2.11-core
>> Reporter: Matthias Weßendorf
>> Assignee: Matthias Weßendorf
>>
>> Currently the only way to configure the max upload size it to set context
>> parameters in web.xml. Some container do not provide any support for
>> changing
>> web.xml during or after deployment...
>> Applications needs to be able to change the max upload size after
>> deployment.
>> This could be done by providing an implementation of
>> org.apache.myfaces.trinidad.webapp.UploadedFileProcessor. However that
>> would be a relatively simple variation on
>> org.apache.myfaces.trinidadinternal.config.upload.UploadedFileProcessorImpl
>> We need to find a good way to dynamically change those configuration
>> settings
>>
>>
>>
>>
>>
>
>
>
>
Re: [jira] Commented: (TRINIDAD-1464) max upload size cannot be
reconfigured after app is deployed
Posted by Matthias Wessendorf <ma...@apache.org>.
follow up on the suggested EL scheme approach:
Using EL scheme inside the trinidad config:
By that the application EL binds the trinidad-config (new) attributes.
On each request the (current) implementation of the UploadProcessor
rereads the EL-bound attributes. Therefore the application is free to
use any scheme it wants to determine the maximum size, including doing
so on a per-user or per-user-per-request basis.
Notes on the implementation:
For that we change/enhance the trinidad-config (and its XSD) to allow
something like this:
<trinidad-config...>
...
<uploaded-file-processor-settings>
<upload-max-memory>#{bean.blah}</upload-max-memory>
<upload-max-disc-space>#{bean.blub}</upload-max-disc-space>
<upload-temp-dir>#{bean.fooDir}</upload-temp-dir>
</uploaded-file-processor-settings>
...
</trinidad-config>
The problem here is that the actual upload is done in front of JSF
lifecycle and the Configurator implementation as no access to the
ELContext (only to an ExternalContext impl)...
However, we still can use the EL approach, by using a work around:
-We evaluate the EL at the end of the request and stuff it into the session
-On the actual upload we just read the value from the session (inside
of the upload processor implementation)
Because of backward compatibility we still need to support the web.xml
based settings, however when trinidad-config is used we prefer
that....
-Matthias
On Wed, May 6, 2009 at 7:20 PM, Matthias Wessendorf <ma...@apache.org> wrote:
>> My thinking was that the application EL binds the trinidad-config
>> attribute. Since we reread the EL-bound attributes on each request, the
>> application is free to use any scheme it wants to determine the maximum
>> size, including doing so on a per-user or per-user-per-request basis.
>
> oh yeah. correct.
> Let me update the jira ticket according to that.
>
> -Matthias
>
>>
>> -- Blake Sullivan
>>
>> On Fri, May 1, 2009 at 7:18 PM, Blake Sullivan
>> <bl...@oracle.com> wrote:
>>
>>
>> Matthias,
>>
>> Would things be improved if we moved the configuration to
>> trinidad-config.xml and allowed the configuration to be retrieved on a
>> per-request basis?
>>
>> -- Blake Sullivan
>>
>> Matthias Weßendorf (JIRA) said the following On 5/1/2009 4:25 AM PT:
>>
>> [
>> https://issues.apache.org/jira/browse/TRINIDAD-1464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12704962#action_12704962
>> ]
>>
>> Matthias Weßendorf commented on TRINIDAD-1464:
>> ----------------------------------------------
>>
>> One possible approach:
>> *create a new abstract class in the Trinidad API "FileUploadConfig"
>> and define abstract get/set methods for "maxMemory", "maxDiskSpace"
>> and "tempDir".
>>
>> *every implementation of the UploadedFileProcessor that wants to change
>> the configuration during runtime should not only implement the actual
>> UploadedFileProcessor interface, it also has to implement the abstract
>> "FileUploadConfig" class. The UploadFileProcessorImpl (default) would
>> do that too.
>>
>> *since the FileUploadConfig implementation is shared over all sessions
>> (application scoped), the implementor (e.g. the UploadFileProcessorImpl)
>> needs to be aware of writing thread-safety code, when *setting* the new
>> value...
>>
>> possible usage in an action-method:
>> ...
>> FileUploadConfig fuc = null;
>> UploadedFileProcessor ufp = requestCtx.getUploadedFileProcessor();
>> if(ufp instanceof FileUploadConfig)
>> {
>> fuc = (FileUploadConfig) ufp;
>> fuc.setMax.....(....);
>> }
>> ...
>>
>>
>>
>> max upload size cannot be reconfigured after app is deployed
>> ------------------------------------------------------------
>>
>> Key: TRINIDAD-1464
>> URL: https://issues.apache.org/jira/browse/TRINIDAD-1464
>> Project: MyFaces Trinidad
>> Issue Type: New Feature
>> Affects Versions: 1.2.11-core
>> Reporter: Matthias Weßendorf
>> Assignee: Matthias Weßendorf
>>
>> Currently the only way to configure the max upload size it to set context
>> parameters in web.xml. Some container do not provide any support for
>> changing
>> web.xml during or after deployment...
>> Applications needs to be able to change the max upload size after
>> deployment.
>> This could be done by providing an implementation of
>> org.apache.myfaces.trinidad.webapp.UploadedFileProcessor. However that
>> would be a relatively simple variation on
>> org.apache.myfaces.trinidadinternal.config.upload.UploadedFileProcessorImpl
>> We need to find a good way to dynamically change those configuration
>> settings
>>
>>
>>
>>
>>
>>
>>
>>
>
>
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf
>
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
Re: [jira] Commented: (TRINIDAD-1464) max upload size cannot be
reconfigured after app is deployed
Posted by Matthias Wessendorf <ma...@apache.org>.
> My thinking was that the application EL binds the trinidad-config
> attribute. Since we reread the EL-bound attributes on each request, the
> application is free to use any scheme it wants to determine the maximum
> size, including doing so on a per-user or per-user-per-request basis.
oh yeah. correct.
Let me update the jira ticket according to that.
-Matthias
>
> -- Blake Sullivan
>
> On Fri, May 1, 2009 at 7:18 PM, Blake Sullivan
> <bl...@oracle.com> wrote:
>
>
> Matthias,
>
> Would things be improved if we moved the configuration to
> trinidad-config.xml and allowed the configuration to be retrieved on a
> per-request basis?
>
> -- Blake Sullivan
>
> Matthias Weßendorf (JIRA) said the following On 5/1/2009 4:25 AM PT:
>
> [
> https://issues.apache.org/jira/browse/TRINIDAD-1464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12704962#action_12704962
> ]
>
> Matthias Weßendorf commented on TRINIDAD-1464:
> ----------------------------------------------
>
> One possible approach:
> *create a new abstract class in the Trinidad API "FileUploadConfig"
> and define abstract get/set methods for "maxMemory", "maxDiskSpace"
> and "tempDir".
>
> *every implementation of the UploadedFileProcessor that wants to change
> the configuration during runtime should not only implement the actual
> UploadedFileProcessor interface, it also has to implement the abstract
> "FileUploadConfig" class. The UploadFileProcessorImpl (default) would
> do that too.
>
> *since the FileUploadConfig implementation is shared over all sessions
> (application scoped), the implementor (e.g. the UploadFileProcessorImpl)
> needs to be aware of writing thread-safety code, when *setting* the new
> value...
>
> possible usage in an action-method:
> ...
> FileUploadConfig fuc = null;
> UploadedFileProcessor ufp = requestCtx.getUploadedFileProcessor();
> if(ufp instanceof FileUploadConfig)
> {
> fuc = (FileUploadConfig) ufp;
> fuc.setMax.....(....);
> }
> ...
>
>
>
> max upload size cannot be reconfigured after app is deployed
> ------------------------------------------------------------
>
> Key: TRINIDAD-1464
> URL: https://issues.apache.org/jira/browse/TRINIDAD-1464
> Project: MyFaces Trinidad
> Issue Type: New Feature
> Affects Versions: 1.2.11-core
> Reporter: Matthias Weßendorf
> Assignee: Matthias Weßendorf
>
> Currently the only way to configure the max upload size it to set context
> parameters in web.xml. Some container do not provide any support for
> changing
> web.xml during or after deployment...
> Applications needs to be able to change the max upload size after
> deployment.
> This could be done by providing an implementation of
> org.apache.myfaces.trinidad.webapp.UploadedFileProcessor. However that
> would be a relatively simple variation on
> org.apache.myfaces.trinidadinternal.config.upload.UploadedFileProcessorImpl
> We need to find a good way to dynamically change those configuration
> settings
>
>
>
>
>
>
>
>
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf