[ 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

Reply via email to