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.


I can make that initialization lazy. That will only initialize the 
reference for getFeatureDescriptors().

-- Scott


resin-interest mailing list

Reply via email to