myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Leonardo Uribe (JIRA)" <>
Subject [jira] Reopened: (TOMAHAWK-1323) Tomahawk extensions code should not parse web.xml
Date Thu, 04 Sep 2008 02:03:44 GMT


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.


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

2. According to the code, when it is configured it should be like this


It could be better to have something like this:


> Tomahawk extensions code should not parse web.xml
> -------------------------------------------------
>                 Key: TOMAHAWK-1323
>                 URL:
>             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.

View raw message