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.
Regards, Simon
