Matthias Wessendorf schrieb:
Simon,

On Wed, Aug 13, 2008 at 10:53 AM, Simon Kitching <[EMAIL PROTECTED]> wrote:
Hi,

Just a reminder of the email I posted a few weeks ago: I'm still very
concerned about the recent ExtensionsFilter refactoring.

The new code now parses the web.xml to extract some configuration
information. This just feels wrong to me.
The new code also is based around a custom FacesContext wrapper. I'm worried
about possible interactions between this and other libraries that also wrap
FacesContext. And I'm worried about the portability of this code to the
upcoming JSF2.0.

I know this stuff is needed to get tomahawk useable for portlets. But it's
very important not to break existing users.

What I would like to see is:
* separate out the resource-serving stuff into a separate utilities module,
that can be called from either a filter or a FacesContext.
 And call the common code from both ExtensionsFilter and
TomahawkFacesContextWrapper.
* have the TomahawkFacesContextFactory create a FacesContext wrapper only in
the case where the filter is not configured, ie
 look in the request-scope for a flag placed there by the filter. That means
there is no chance of breaking existing setups where
 the filter is defined explicitly.
* ideally, also have some way of turning off the faces-context wrapping even
when the filter is not present.
* don't parse the web.xml at all. I know you said earlier that it is needed,
but I just don't see why. In any case, I think we *must*
 find some other solution; the current approach is really hard to maintain.

Until this is fixed, I would definitely vote -1 on any tomahawk release.
It's a major issue.

was there a jira issue for it ?
or can you point me to the svn rev?
The best thing to do is to look at these classes:
 org.apache.myfaces.webapp.filter.ExtensionsFilter
 org.apache.myfaces.webapp.filter.TomahawkFacesContextFactory
 org.apache.myfaces.webapp.filter.TomahawkFacesContextWrapper
 org.apache.myfaces.webapp.filter.ExtensionsFilterConfig [1]

The svn history of these files references MYFACES-434.
There is no specific jira issue about my concerns; it is really an architecture/design disagreement rather than a specific bug.

[1] ExtensionsFilterConfig.getExtensionsFilterConfig is invoked from TomahawkFacesContextWrapper.

Regards, Simon

Reply via email to