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. -- </Mattias> _______________________________________________ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
