Re: [core] performance: ELResolvers filtering

2011-04-04 Thread Leonardo Uribe 
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-nameorg.apache.myfaces.EL_RESOLVER_PREDICATE/param-name
param-valueorg.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

Re: [core] performance: ELResolvers filtering

2011-04-04 Thread Martin Koci 
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-nameorg.apache.myfaces.EL_RESOLVER_PREDICATE/param-name
   param-valueorg.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

Re: [core] performance: ELResolvers filtering

2011-04-04 Thread Leonardo Uribe 
Hi

Yes, no problem. Right now I'm running the necessary steps to release
myfaces core 2.0.5 (and after that tomahawk 1.1.11), so this patch will not
be on 2.0.5 (but it will on 2.0.6). I want to take a look carefully to this
problem and I require some time to do it. Thanks for your patch.

regards,

Leonardo Uribe

2011/4/4 Martin Koci martin.kocicak.k...@gmail.com

 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-nameorg.apache.myfaces.EL_RESOLVER_PREDICATE/param-name
   param-valueorg.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

Re: [core] performance: ELResolvers filtering

2011-03-17 Thread Martin Koci 

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-nameorg.apache.myfaces.EL_RESOLVER_PREDICATE/param-name
   param-valueorg.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

[core] performance: ELResolvers filtering

2011-03-16 Thread Martin Koci 
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-nameorg.apache.myfaces.EL_RESOLVER_PREDICATE/param-name
  param-valueorg.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

Re: [core] performance: ELResolvers filtering

2011-03-16 Thread Mark Struberg 
h hot ;)

fat +1 

Lets allow to switch off all that stuff which no one needs if running on a 
modern stack with facelets and CDI.

LieGrue,
strub

--- On Wed, 3/16/11, Martin Koci martin.kocicak.k...@gmail.com wrote:

 From: Martin Koci martin.kocicak.k...@gmail.com
 Subject: [core] performance: ELResolvers filtering
 To: dev@myfaces.apache.org
 Date: Wednesday, March 16, 2011, 10:29 AM
 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-nameorg.apache.myfaces.EL_RESOLVER_PREDICATE/param-name
  
 param-valueorg.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

Re: [core] performance: ELResolvers filtering

2011-03-16 Thread Martin Koci 

Hi, 

see https://issues.apache.org/jira/browse/MYFACES-3075 for first version
of patch.


@Mark, 
CDI/OWB manage scopes on their own, they don't use
externalContext.getSessionMap(), applicationMap, .. is it true? If yes,
then should be possible to disable
org.apache.myfaces.el.unified.resolver.ScopedAttributeResolver ? This
one is not in filtered list, because of code in:

org.apache.myfaces.el.unified.ResolverBuilderForFaces.build(CompositeELResolver)

// the ScopedAttributeResolver has to be the last one in every
// case, because it always sets propertyResolved to true (per the spec)
compositeElResolver.add(new ScopedAttributeResolver());


Regards,

Kočičák


Mark Struberg píše v St 16. 03. 2011 v 12:10 +:
 h hot ;)
 
 fat +1 
 
 Lets allow to switch off all that stuff which no one needs if running on a 
 modern stack with facelets and CDI.
 
 LieGrue,
 strub
 
 --- On Wed, 3/16/11, Martin Koci martin.kocicak.k...@gmail.com wrote:
 
  From: Martin Koci martin.kocicak.k...@gmail.com
  Subject: [core] performance: ELResolvers filtering
  To: dev@myfaces.apache.org
  Date: Wednesday, March 16, 2011, 10:29 AM
  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-nameorg.apache.myfaces.EL_RESOLVER_PREDICATE/param-name
   
  param-valueorg.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

Re: [core] performance: ELResolvers filtering

2011-03-16 Thread Jakob Korherr 
big +1 from my side too :)

Great idea, Martin!

Regards,
Jakob

2011/3/16 Mark Struberg strub...@yahoo.de:
 h hot ;)

 fat +1

 Lets allow to switch off all that stuff which no one needs if running on a 
 modern stack with facelets and CDI.

 LieGrue,
 strub

 --- On Wed, 3/16/11, Martin Koci martin.kocicak.k...@gmail.com wrote:

 From: Martin Koci martin.kocicak.k...@gmail.com
 Subject: [core] performance: ELResolvers filtering
 To: dev@myfaces.apache.org
 Date: Wednesday, March 16, 2011, 10:29 AM
 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-nameorg.apache.myfaces.EL_RESOLVER_PREDICATE/param-name

 param-valueorg.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









-- 
Jakob Korherr

blog: http://www.jakobk.com
twitter: http://twitter.com/jakobkorherr
work: http://www.irian.at

Re: [core] performance: ELResolvers filtering

2011-03-16 Thread Mark Struberg 
Hi!

We use the ViewMap for @ViewScoped, but nothing else currently.

LieGrue,
strub

--- On Wed, 3/16/11, Martin Koci martin.kocicak.k...@gmail.com wrote:

 From: Martin Koci martin.kocicak.k...@gmail.com
 Subject: Re: [core] performance: ELResolvers filtering
 To: MyFaces Development dev@myfaces.apache.org
 Date: Wednesday, March 16, 2011, 2:53 PM
 
 Hi, 
 
 see https://issues.apache.org/jira/browse/MYFACES-3075 for
 first version
 of patch.
 
 
 @Mark, 
 CDI/OWB manage scopes on their own, they don't use
 externalContext.getSessionMap(), applicationMap, .. is it
 true? If yes,
 then should be possible to disable
 org.apache.myfaces.el.unified.resolver.ScopedAttributeResolver
 ? This
 one is not in filtered list, because of code in:
 
 org.apache.myfaces.el.unified.ResolverBuilderForFaces.build(CompositeELResolver)
 
 // the ScopedAttributeResolver has to be the last one in
 every
 // case, because it always sets propertyResolved to true
 (per the spec)
 compositeElResolver.add(new ScopedAttributeResolver());
 
 
 Regards,
 
 Kočičák
 
 
 Mark Struberg píše v St 16. 03. 2011 v 12:10 +:
  h hot ;)
  
  fat +1 
  
  Lets allow to switch off all that stuff which no one
 needs if running on a modern stack with facelets and CDI.
  
  LieGrue,
  strub
  
  --- On Wed, 3/16/11, Martin Koci martin.kocicak.k...@gmail.com
 wrote:
  
   From: Martin Koci martin.kocicak.k...@gmail.com
   Subject: [core] performance: ELResolvers
 filtering
   To: dev@myfaces.apache.org
   Date: Wednesday, March 16, 2011, 10:29 AM
   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-nameorg.apache.myfaces.EL_RESOLVER_PREDICATE/param-name
    
  
 param-valueorg.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