On Thu, 18 Jul 2013 09:42:23 -0700 Scott wrote:
> On 7/18/13 2:32 AM, Mattias Jiderhamn wrote:
> > It seems that a classloader leak in the JSF API as of
> > https://java.net/jira/browse/JAVASERVERFACES-2746 is triggered much 
> more
> > easily by the Caucho EL implementation than with the Sun/Glassfish one.
> > At least from my point of view the bug still is with JSF and not Resin,
> > but somene might find this information useful.
> Hmm. I'm not sure why Resin's EL would make a difference. From that 
> description, it's a JSF bug.
> Do you happen to know what classes are being held?

Yes. The bug is triggered when there are additional attributes added to 
the cached PropertyDescriptors, that implies a strong reference to the 
classloader. The cases I've seen involves having the 
javax.el.ELResolver.TYPE (="type") attribute having a class loaded 
within the webapp as it's value (i.e. a custom JSF component with a 
custom attribute). Resin adds this attribute in BeanELResolver.java line 
520 (Resin 4.0.33), reached from the 
javax.el.BeanELResolver.BeanProperty constructors in turn called from 
the javax.el.BeanELResolver.BeanProperties constructor which in the 
Resin case is used in all five BeanELResolver methods mentioned in my 
latest comment.

In the case of Sun/Glasfish EL, this attribute is (AFAI can see) only 
added by getFeatureDescriptors().

Nevertheless, I agree that it is JSF that needs fixing, not Resin.



resin-interest mailing list

Reply via email to