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
> > 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
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