Hello Mario, Comments inline.
On 9/6/07, Mario Ivankovits <[EMAIL PROTECTED]> wrote: > > Hi! > > I found the problem. > > I requested the "to-be-decorated" application within my constructor > which failed as with an JSF 1.1. compiled class the FacesContext is > required to find the JSF 1.2 default application implementation. > > JSF 1.2 will then dispatch the new methods to the default implementation > automatically - _instead to the decorated one_. > > Which means, if you have a JSF 1.1. Application in the chain, > inheritance do not work as expected as JSF 1.2 methods are not > dispatched to the decorated application but to the default implementation. > > In MyFaces I can't find such a behavior at all, isn't it defined by the > spec? I thought it was... but it seems to not apply to the factory classes... Here's the detail: When providing a replacement for the default PropertyResolver, VariableResolver, ActionListener, NavigationHandler, ViewHandler, or StateManager, the decorator design pattern is leveraged, so that if you provide a constructor that takes a single argument of the appropriate type, the custom implementation receives a referenc to the implementation that was previously fulfilling the role. In this way, the custom implementation is able to override just a subset of the functionality (or provide only some additional functionality) and delegate the rest to the existing implementation. That's kind of fishy... I guess you could use a ServletContextListener to extract the default factory from FactoryFinder and then set your own instance passing it the default implementation, but that would work only if JSF's own ServletContextListener is executed before, and I'm not aware of the listener priority when placed in a tld. I event can't use the proxy based solution as the Application isn't an > interface and using AOP fails as the > com.sun.faces.application.ApplicationAssociate checks that it hasn't > been instantiated twice. (via ASSOCIATE_KEY in the application map) > > > It's odd. > > Ciao, > Mario > >
