[ http://issues.apache.org/jira/browse/TUSCANY-262?page=comments#action_12377675 ]
Raymond Feng commented on TUSCANY-262: -------------------------------------- Hi, Jeremy. I agree with you on the isolation part. I understand if the container wants to access application resources, it should use TCCL. I'm not sure if you cover the following situation. The javax.xml.stream.XMLInputFactory.newInstance() API tries to use the TCCL to resolve the factory provider. So if you don't explicitly reset the TCCL to the classloder from XMLInputFactory.class.getClassLoader(), it will fail since the "META-INF/services/javax.xml.stream.XMLInputFactory" from the wstx-asl.jar cannot be found from the TCCL chain. Thanks, Raymond > The packaging scheme for Tuscany runtime and dependency jars is problematic > against the Tomcat class loading hierarchy > ---------------------------------------------------------------------------------------------------------------------- > > Key: TUSCANY-262 > URL: http://issues.apache.org/jira/browse/TUSCANY-262 > Project: Tuscany > Type: Bug > Components: Java SCA Tomcat Integration > Reporter: Raymond Feng > Assignee: Jeremy Boynes > Priority: Critical > > As a result from the investigation on JIRA issue Tuscany-258, I found the > following problem. > Right now, most of the Tuscany and dependency jars are copied to > $CATALINA_HOME/server/lib. Is it by design? I think it's problematic and it's > the root cause of the problem > described by 258. > Here's a quote from the Tomcat 5.0 document @ > http://tomcat.apache.org/tomcat-5.0-doc/class-loader-howto.html: > "Catalina - This class loader is initialized to include all classes and > resources required to implement Tomcat 5 itself. These classes and resources > are TOTALLY invisible to web applications. All unpacked classes and resources > in $CATALINA_HOME/server/classes, as well as classes and resources in JAR > files under $CATALINA_HOME/server/lib, are made visible through this class > loader. " > It leads to a very messy classloading story. The classloader for the Tuscany > runtime classes/interfaces is NOT part of the web application's classloader > chain. Some classes in the runtime (including Tuscany and Axis2) uses Thread > context classloader as the starting point to resolve resources/classes and > it'll fail without the hacky classloader switching all over the place. > I did some experiement and found out the following should be the correct > packaging scheme: > 1) Only tuscany-tomcat-SNAPSHOT.jar should be copied to > $CATALINA_HOME/server/lib since it contains a class > "org.apache.tuscany.tomcat.TuscanyHost" extending > "org.apache.catalina.core.StandardHost" which is packaged in catalina.jar > under $CATALINA_HOME/server/lib. > 2) All the other Tuscany jars should be copied to $CATALINA_HOME/common/lib > With the new strategy, we can remove the classloader switching hacks in the > code base. > I can upload the patch if you guys agree with me. The patch includes the > changes against the build.xml (testing/tomcat), TuscanyContextListener.java > (sca/tomcat) and the rollbacks of the workaround committed by Ant under 258. > Thanks, > Raymond -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
