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 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.
Gotcha. I can make that initialization lazy. That will only initialize the reference for getFeatureDescriptors(). -- Scott > _______________________________________________ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
