tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject [Bug 56580] el-api.jar memory leak
Date Mon, 02 Jun 2014 07:06:53 GMT
https://issues.apache.org/bugzilla/show_bug.cgi?id=56580

--- Comment #2 from costin@prodinf.ro ---
There is no Class in ELUtils  but there is BeanELResolver(in el-api.jar).

The ELUtils is in (JSF MOjarra
https://github.com/bleathem/mojarra/blob/master/jsf-ri/src/main/java/com/sun/faces/el/ELUtils.java
). The problem is that Jsf jars  and el-api jar are stored in tomcat_dir\lib
directory (shared classloader) and 
after a while BeanELResolver stores classes for the war classloader and never
unloads them on war redeploy.

The issue is in line 142 from ELUtils.java .The guys from mojarra are saying
that the BeanELResolver must be reimplemented so that after redeploy no
references to the classes from the war classloader must be holded.

I have analyzed this source code
(http://svn.apache.org/repos/asf/tomcat/tc7.0.x/trunk/java/javax/el/BeanELResolver.java)
and I think that if the member cache will hold SoftReferences everything will
be unloaded . In my perspective I think that it will be ok if you redesign the
inner class ConcurrentCache from ELResolver.

They say that this issue was fixed in Glassfish in their el-api implementation.

If you like we could talk by Skype and give you more information

-- 
You are receiving this mail because:
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


Mime
View raw message