On Thu, 18 Jul 2013 10:51:52 -0700 Scott wrote:
> On 7/18/13 10:29 AM, Mattias Jiderhamn wrote:
> > 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
> >>> At least from my point of view the bug still is with JSF and not
> >>> 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
> > 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.
> I can make that initialization lazy. That will only initialize the
> reference for getFeatureDescriptors().
The leak is already taken care of by my classloader leak prevention
library  for any EL implementation, so there is no need on our part,
but it might help someone else that don't understand the crashes or is
unable to find this discussion.
resin-interest mailing list