You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by "Raymond Feng (JIRA)" <tu...@ws.apache.org> on 2006/05/03 22:34:46 UTC
[jira] Created: (TUSCANY-262) The packaging scheme for Tuscany
runtime and dependency jars is problematic against the Tomcat class loading
hierarchy
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
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
[jira] Closed: (TUSCANY-262) The packaging scheme for Tuscany
runtime and dependency jars is problematic against the Tomcat class loading
hierarchy
Posted by "Jeremy Boynes (JIRA)" <tu...@ws.apache.org>.
[ http://issues.apache.org/jira/browse/TUSCANY-262?page=all ]
Jeremy Boynes closed TUSCANY-262:
---------------------------------
Resolution: Invalid
Assign To: Jeremy Boynes
Closing as invalid as we need to handle classloaders in an appropriate manner.
> 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
[jira] Commented: (TUSCANY-262) The packaging scheme for Tuscany
runtime and dependency jars is problematic against the Tomcat class loading
hierarchy
Posted by "Jeremy Boynes (JIRA)" <tu...@ws.apache.org>.
[ http://issues.apache.org/jira/browse/TUSCANY-262?page=comments#action_12377639 ]
Jeremy Boynes commented on TUSCANY-262:
---------------------------------------
In short, yes this is by design, at least of Tomcat and the integration code for it.
Tomcat does this to create isolation between the classes and libraries it itself uses and those that the applications that it is running might use. This prevents classes from the container leaking in to an application's classpath and overriding versions that the application may want. It also prevents security problems caused by exposing the container's internals to applications or potential conflicts when static fields are used.
The integration code follows Tomcat's classloading model and places the Tuscany implementation code in the container's classloading scope. The only classes that should be shared are the standard org.osoa interfaces (which are currently located in the common classloader just like the servlet API classes).
One of the complexities of this scheme is that the container code does not have access to application classes using its own classloader. To address this, the J2EE programming model makes use of the Thread context classloader (TCCL) which allows the container to associate the application classloader with the currently running Thread before a request is handed over to application code. When the application calls back into the container, the container code can retrieve the application classloader from the Thread whenever it needs to access the application code. Application code should not need to access this classloader as it has access to its own using getClass().getClassLoader(); in fact, in a strict security environment, it will not even be able to access the TCCL (unless it happens to be the application classloader itself).
Many of the problems we are seeing are because code is not making this separation between container and application classloaders a top level concept. For example, the SDO implementation always keys its type system off the TCCL which means that any time the container needs to interact with SDO it needs to ensure the TCCL is set to the application classloader. Moreover, due to the use of static initializers, it must set the TCCL every time it does anything that may touch an application class.
The real solution here is for the libraries to provide mechanisms that allow operations to be performed by the container on behalf of the application using an explicitly provided classloader. Work has start on this with SDO, I am not sure what the situation is with Axis2.
Placing all the Tuscany implementation on the application classpath by moving the jars to common will only cause greater problems in the long run and is not something that should be done.
> 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
> 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
[jira] Commented: (TUSCANY-262) The packaging scheme for Tuscany
runtime and dependency jars is problematic against the Tomcat class loading
hierarchy
Posted by "Raymond Feng (JIRA)" <tu...@ws.apache.org>.
[ 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