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? -M > > Regards, Simon > > -- Matthias Wessendorf Need JSF and Web 2.0? http://code.google.com/p/facesgoodies further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org
