Hi,

suggested patch is here:
 https://issues.apache.org/jira/browse/MYFACES-3078

can you please review it and apply if is it proper?

Regards,

Kočičák

> Hi

> Add a param to disable JSP support looks like a good idea. With such >
param we could solve this issue raised recently:

> https://issues.apache.org/jira/browse/MYFACES-3104 MyFaces 2 with EL ?
> 2.2 in Websphere 7

> regards,

> Leonardo Uribe

2011/3/17 Martin Koci <martin.kocicak.k...@gmail.com>
        
        This approach cannot filter two resolvers:
        1.
        org.apache.myfaces.el.unified.resolver.FacesCompositeELResolver
        2.
        org.apache.myfaces.el.unified.resolver.ScopedAttributeResolver
        
        
        1) the first one is instance of CompositeELResolver and serves
        as
        container for sorted/filtered list of others ELResolvers.
        Currently does
        something for JSP, so I suggest to introduce:
        
        o.a.m.SUPPORT_JSP = true|false
        
        content-param as mentioned in original mail thread "performance:
        disabling "old" technologies" and if this false, myfaces will
        not
        install FacesCompositeELResolver, but plain
        javax.el.CompositeELResolver
        as parent.
        
        
        2)
        org.apache.myfaces.el.unified.resolver.ScopedAttributeResolver
        is the
        last one in chain and always calls setPropertyResolved(true);
        (JSF 2.1:
        5.6.2.9 ScopedAttribute ELResolver) and pick up anything stored
        in the
        request, viewScope,  session, or application scopes by name.
        
        In strictly CDI-based application with no direct modification of
        servlet
        scopes or view scope this resolver will never resolve a
        property.
        
        What to do with this one I don't know. Possibly we can use
        ELResolver
        transforming :) org.apache.commons.collections.Transformer and
        allow
        replace one resolver with another, for example:
        
        o.a.m.el.unified.resolver.ScopedAttributeResolver ->
        MyNotResovingResolverWhichCallsSetPropertyResolvedTrue
        
        el.ResourceBundleELResolver -> SpringMessageSourceResolver (we
        don't use
        ResourceBundle)
        
        el.BeanELResolver -> MemoryLeakFreeBeanELResolver
        
        Of course this functionality can be achieved by filtering out
        the
        unwanted resolver with predicate and adding own in faces-config
        (and
        sort it to proper position in chain)
        
        
        Regards,
        
        
        Kočičák
        
        
        Martin Koci píše v St 16. 03. 2011 v 11:29 +0100:
        
        > Hi,
        >
        >
        > after few months I have time to do some performance
        optimalization for
        > myfaces.
        >
        > This one is related to topic
        >
        http://www.mail-archive.com/dev@myfaces.apache.org/msg49177.html
        >
        >
        > Problem:
        > how to disable ELResolver smartly? Adding a context-param for
        each is an
        > overkill.
        >
        > But we have
        https://cwiki.apache.org/MYFACES/elresolver-ordering.html in
        > codebase already. I propose to add new feature "ELResolver
        filtering"
        > and new context-param:
        >
        > <context-param>
        >
        <param-name>org.apache.myfaces.EL_RESOLVER_PREDICATE</param-name>
        >   <param-value>org.foo.bazz.ELResolverPredicate</param-value>
        > </context-param>
        >
        > Filter is simple instance of
        org.apache.commons.collections.Predicate.
        >
        >
        > For application where no ManagedBean(Resolver) is used or no
        Flash, user
        > can simply return false from Predicate.evaluate and ELResolver
        won't be
        > installed.
        >
        > WDYT?
        >
        > Regards,
        >
        > Kočičák
        >
        >
        
        
        



Reply via email to