[jira] Closed: (TUSCANY-262) The packaging scheme for Tuscany runtime and dependency jars is problematic against the Tomcat class loading hierarchy

["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