You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by "Simon Kitching (JIRA)" <de...@myfaces.apache.org> on 2008/09/03 22:33:44 UTC
[jira] Created: (TOMAHAWK-1323) Tomahawk extensions code should not
parse web.xml
Tomahawk extensions code should not parse web.xml
-------------------------------------------------
Key: TOMAHAWK-1323
URL: https://issues.apache.org/jira/browse/TOMAHAWK-1323
Project: MyFaces Tomahawk
Issue Type: Task
Reporter: Simon Kitching
Priority: Blocker
In earlier Tomahawk releases, the ExtensionsFilter class provides a number of features, including resource-serving and file-upload support. It does need some config parameters, and these were simply defined as filter-specific init params.
However a custom TomahawkFacesContextFactory now allows this functionality to be available without configuring a servlet filter at all. Therefore there needs to be some way for this new code to get the needed init params.
The current code parses the web.xml and looks for filter-specific init params, but this is complex and not intuitive for users.
It seems that the most sensible way is simply to use
ServletContext.getInitParameter -- for servlet config
PortletContext.getInitParameter -- for portlet config
This does require some kind of reflection trickery, as having the portlet api in the classpath is optional.
Note that if a user does configure a filter, then things work as they always did - config params are read from the filter config. Being able to use "extensions" functionality without configuring the filter is a brand new feature, so there is no backwards-compatibility issue with using a different configuration approach.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (TOMAHAWK-1323) Tomahawk extensions code should
not parse web.xml
Posted by "Hazem Saleh (JIRA)" <de...@myfaces.apache.org>.
[ https://issues.apache.org/jira/browse/TOMAHAWK-1323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12628235#action_12628235 ]
Hazem Saleh commented on TOMAHAWK-1323:
---------------------------------------
Leonardo,
Thanks for these very nice review comments.
I will apply now ;).
> Tomahawk extensions code should not parse web.xml
> -------------------------------------------------
>
> Key: TOMAHAWK-1323
> URL: https://issues.apache.org/jira/browse/TOMAHAWK-1323
> Project: MyFaces Tomahawk
> Issue Type: Task
> Reporter: Simon Kitching
> Assignee: Hazem Saleh
> Priority: Blocker
> Fix For: 1.1.7
>
>
> In earlier Tomahawk releases, the ExtensionsFilter class provides a number of features, including resource-serving and file-upload support. It does need some config parameters, and these were simply defined as filter-specific init params.
> However a custom TomahawkFacesContextFactory now allows this functionality to be available without configuring a servlet filter at all. Therefore there needs to be some way for this new code to get the needed init params.
> The current code parses the web.xml and looks for filter-specific init params, but this is complex and not intuitive for users.
> It seems that the most sensible way is simply to use
> ServletContext.getInitParameter -- for servlet config
> PortletContext.getInitParameter -- for portlet config
> This does require some kind of reflection trickery, as having the portlet api in the classpath is optional.
> Note that if a user does configure a filter, then things work as they always did - config params are read from the filter config. Being able to use "extensions" functionality without configuring the filter is a brand new feature, so there is no backwards-compatibility issue with using a different configuration approach.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Reopened: (TOMAHAWK-1323) Tomahawk extensions code should
not parse web.xml
Posted by "Leonardo Uribe (JIRA)" <de...@myfaces.apache.org>.
[ https://issues.apache.org/jira/browse/TOMAHAWK-1323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Leonardo Uribe reopened TOMAHAWK-1323:
--------------------------------------
I have some observations about MultipartRequestWrapperConfig:
1. It should be saved on application map, and do not be created on each request (since this values does not change in the application life). One useful class that works as a guide for do this is.
org.apache.myfaces.shared_tomahawk.config.MyfacesConfig
This class is not the right place to put this params because the discussed feature and related code belongs to tomahawk (not to shared). So a new class to get the is the right way to do this.
2. According to the code, when it is configured it should be like this
<context-param>
<param-name>uploadMaxFileSize</param-name>
<param-value>100m</param-value>
</context-param>
It could be better to have something like this:
<context-param>
<param-name>org.apache.myfaces.UPLOAD_MAX_FILE_SIZE</param-name>
<param-value>100m</param-value>
</context-param>
> Tomahawk extensions code should not parse web.xml
> -------------------------------------------------
>
> Key: TOMAHAWK-1323
> URL: https://issues.apache.org/jira/browse/TOMAHAWK-1323
> Project: MyFaces Tomahawk
> Issue Type: Task
> Reporter: Simon Kitching
> Assignee: Hazem Saleh
> Priority: Blocker
> Fix For: 1.1.7
>
>
> In earlier Tomahawk releases, the ExtensionsFilter class provides a number of features, including resource-serving and file-upload support. It does need some config parameters, and these were simply defined as filter-specific init params.
> However a custom TomahawkFacesContextFactory now allows this functionality to be available without configuring a servlet filter at all. Therefore there needs to be some way for this new code to get the needed init params.
> The current code parses the web.xml and looks for filter-specific init params, but this is complex and not intuitive for users.
> It seems that the most sensible way is simply to use
> ServletContext.getInitParameter -- for servlet config
> PortletContext.getInitParameter -- for portlet config
> This does require some kind of reflection trickery, as having the portlet api in the classpath is optional.
> Note that if a user does configure a filter, then things work as they always did - config params are read from the filter config. Being able to use "extensions" functionality without configuring the filter is a brand new feature, so there is no backwards-compatibility issue with using a different configuration approach.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (TOMAHAWK-1323) Tomahawk extensions code should
not parse web.xml
Posted by "Hazem Saleh (JIRA)" <de...@myfaces.apache.org>.
[ https://issues.apache.org/jira/browse/TOMAHAWK-1323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Hazem Saleh resolved TOMAHAWK-1323.
-----------------------------------
Resolution: Fixed
Doneeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee :).
> Tomahawk extensions code should not parse web.xml
> -------------------------------------------------
>
> Key: TOMAHAWK-1323
> URL: https://issues.apache.org/jira/browse/TOMAHAWK-1323
> Project: MyFaces Tomahawk
> Issue Type: Task
> Reporter: Simon Kitching
> Assignee: Hazem Saleh
> Priority: Blocker
> Fix For: 1.1.7
>
>
> In earlier Tomahawk releases, the ExtensionsFilter class provides a number of features, including resource-serving and file-upload support. It does need some config parameters, and these were simply defined as filter-specific init params.
> However a custom TomahawkFacesContextFactory now allows this functionality to be available without configuring a servlet filter at all. Therefore there needs to be some way for this new code to get the needed init params.
> The current code parses the web.xml and looks for filter-specific init params, but this is complex and not intuitive for users.
> It seems that the most sensible way is simply to use
> ServletContext.getInitParameter -- for servlet config
> PortletContext.getInitParameter -- for portlet config
> This does require some kind of reflection trickery, as having the portlet api in the classpath is optional.
> Note that if a user does configure a filter, then things work as they always did - config params are read from the filter config. Being able to use "extensions" functionality without configuring the filter is a brand new feature, so there is no backwards-compatibility issue with using a different configuration approach.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (TOMAHAWK-1323) Tomahawk extensions code should
not parse web.xml
Posted by "Hazem Saleh (JIRA)" <de...@myfaces.apache.org>.
[ https://issues.apache.org/jira/browse/TOMAHAWK-1323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Hazem Saleh resolved TOMAHAWK-1323.
-----------------------------------
Resolution: Fixed
Resolved!!!
1. No more parse to (web.xml).
2. In case of using (TomahawkFacesContextWrapper) + Servlet World:
The parameters of the (MultipartRequestWrapper) are read using Servlet API.
3. In case of using (TomahawkFacesContextWrapper) + Portlet World:
The <t:inputFile/> portlet enablement is not implemented yet MYFACES-434 (should be in the next release).
> Tomahawk extensions code should not parse web.xml
> -------------------------------------------------
>
> Key: TOMAHAWK-1323
> URL: https://issues.apache.org/jira/browse/TOMAHAWK-1323
> Project: MyFaces Tomahawk
> Issue Type: Task
> Reporter: Simon Kitching
> Assignee: Hazem Saleh
> Priority: Blocker
>
> In earlier Tomahawk releases, the ExtensionsFilter class provides a number of features, including resource-serving and file-upload support. It does need some config parameters, and these were simply defined as filter-specific init params.
> However a custom TomahawkFacesContextFactory now allows this functionality to be available without configuring a servlet filter at all. Therefore there needs to be some way for this new code to get the needed init params.
> The current code parses the web.xml and looks for filter-specific init params, but this is complex and not intuitive for users.
> It seems that the most sensible way is simply to use
> ServletContext.getInitParameter -- for servlet config
> PortletContext.getInitParameter -- for portlet config
> This does require some kind of reflection trickery, as having the portlet api in the classpath is optional.
> Note that if a user does configure a filter, then things work as they always did - config params are read from the filter config. Being able to use "extensions" functionality without configuring the filter is a brand new feature, so there is no backwards-compatibility issue with using a different configuration approach.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.