You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomee.apache.org by Alex A <al...@hotmail.com> on 2014/11/24 16:08:21 UTC
TomEE+ 1.7.1 Classloader gets replaced by CxfContainerClassLoader
which causes ClassNotFoundException in Rhino/Nashorn ScriptEngine
Hello,
We are migrating our stack from TomEE+ 1.5.2 to TomEE+
1.7.1, and are seeing the following regression: most of our javascripts (based
on Rhino ScriptEngine, but tried & got same issue with Nashorn) which load
classes from our webapp do not work anymore.
Simple javascript test (CloudUtils.jar containing CloudUtils
class is deployed in /mywebapp):
com.mycompany.infra.cloud.cloudutils.CloudUtils.nowStr()
TomEE+ 1.5.2 and JDK 1.7.0_72 (Rhino):
2014/11/24
15:06:37.976 +0100
(expected result)
TomEE+ 1.7.1 and JDK 1.7.0_72 (Rhino):
sun.org.mozilla.javascript.internal.EcmaError:
TypeError: Cannot call property nowStr in object [JavaPackage com.
mycompany.infra.cloud.cloudutils.CloudUtils]. It is not a function, it is
"object".
TomEE+ 1.7.1 and JDK 1.8.0_25 (Nashorn):
java.lang.ClassNotFoundException:
com.mycompany.infra.cloud.cloudutils.CloudUtils.nowStr()
In JDK we know that the ScriptEngineManager is initialized
as follows:
public ScriptEngineManager() {
ClassLoader ctxtLoader = Thread.currentThread().getContextClassLoader();
init(ctxtLoader);
}
After debugging, we found out that until TomEE+ 1.5.2 the Thread.currentThread().getContextClassLoader(),
as expected, was:
LazyStopWebappClassLoader
context: /mywebapp
delegate: false
repositories:
/WEB-INF/classes/
---------->
Parent Classloader:
org.apache.catalina.loader.StandardClassLoader@70f4d063
But in TomEE+ 1.7.1, it is now replaced by:
org.apache.openejb.server.cxf.transport.util.CxfContainerClassLoader@1d56ce6a
Actually, it seems this new CxfContainerClassLoader class
was introduced back in 1.6 and is found in openejb-cxf-transport JAR:
http://grepcode.com/file/repo1.maven.org/maven2/org.apache.openejb/openejb-cxf-transport/4.6.0/org/apache/openejb/server/cxf/transport/util/CxfUtil.java?av=f
I guess this classloader does not have the intelligence to
find the JARs in “/mywebapp” like catalina’s does.
Why is catalina’s classloader replaced by
CxfContainerClassLoader? Is it expected? Is there any way to avoid this?
Your help is much appreciated!
Alexandre
Re: TomEE+ 1.7.1 Classloader gets replaced by CxfContainerClassLoader
which causes ClassNotFoundException in Rhino/Nashorn ScriptEngine
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Hi
are you able to reproduce and share a sample (github project if possible) to us?
CxfContainerClassLoader doesn't replace tomcat classloader and we
didnt loose the webapp classloading logic snice actually
CxfContainerClassLoader just contextually delegates to the webapp
classloader.
Without a sample i'm not sure but what I could see as issue is the
scriptengine keeps CxfContainerClassLoader instead of
WebAppClassLoader cause it is created during a cxf webservice request
then executed when the request is already done. Is that the case? Is
so using an EJB to execute the js should work
Romain Manni-Bucau
@rmannibucau
http://www.tomitribe.com
http://rmannibucau.wordpress.com
https://github.com/rmannibucau
2014-11-24 16:08 GMT+01:00 Alex A <al...@hotmail.com>:
> Hello,
>
>
>
> We are migrating our stack from TomEE+ 1.5.2 to TomEE+
> 1.7.1, and are seeing the following regression: most of our javascripts (based
> on Rhino ScriptEngine, but tried & got same issue with Nashorn) which load
> classes from our webapp do not work anymore.
>
>
>
> Simple javascript test (CloudUtils.jar containing CloudUtils
> class is deployed in /mywebapp):
>
> com.mycompany.infra.cloud.cloudutils.CloudUtils.nowStr()
>
>
>
> TomEE+ 1.5.2 and JDK 1.7.0_72 (Rhino):
>
> 2014/11/24
> 15:06:37.976 +0100
> (expected result)
>
>
>
> TomEE+ 1.7.1 and JDK 1.7.0_72 (Rhino):
>
> sun.org.mozilla.javascript.internal.EcmaError:
> TypeError: Cannot call property nowStr in object [JavaPackage com.
> mycompany.infra.cloud.cloudutils.CloudUtils]. It is not a function, it is
> "object".
>
>
>
> TomEE+ 1.7.1 and JDK 1.8.0_25 (Nashorn):
>
> java.lang.ClassNotFoundException:
> com.mycompany.infra.cloud.cloudutils.CloudUtils.nowStr()
>
>
>
> In JDK we know that the ScriptEngineManager is initialized
> as follows:
>
>
> public ScriptEngineManager() {
>
>
> ClassLoader ctxtLoader = Thread.currentThread().getContextClassLoader();
>
>
> init(ctxtLoader);
>
> }
>
>
>
> After debugging, we found out that until TomEE+ 1.5.2 the Thread.currentThread().getContextClassLoader(),
> as expected, was:
>
> LazyStopWebappClassLoader
>
>
> context: /mywebapp
>
>
> delegate: false
>
>
> repositories:
>
>
> /WEB-INF/classes/
>
> ---------->
> Parent Classloader:
>
> org.apache.catalina.loader.StandardClassLoader@70f4d063
>
>
>
> But in TomEE+ 1.7.1, it is now replaced by:
>
> org.apache.openejb.server.cxf.transport.util.CxfContainerClassLoader@1d56ce6a
>
>
>
> Actually, it seems this new CxfContainerClassLoader class
> was introduced back in 1.6 and is found in openejb-cxf-transport JAR:
>
> http://grepcode.com/file/repo1.maven.org/maven2/org.apache.openejb/openejb-cxf-transport/4.6.0/org/apache/openejb/server/cxf/transport/util/CxfUtil.java?av=f
>
>
>
> I guess this classloader does not have the intelligence to
> find the JARs in “/mywebapp” like catalina’s does.
>
> Why is catalina’s classloader replaced by
> CxfContainerClassLoader? Is it expected? Is there any way to avoid this?
>
>
>
> Your help is much appreciated!
> Alexandre
>
>
>
>
>