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 <[email protected]>: > 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 > > > > >
