Mailing-List: contact dev-help@tuscany.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@tuscany.apache.org
Date: Tue, 27 Nov 2012 17:37:58 +0000 (UTC)
From: "Sebastian Millies (JIRA)" <dev@tuscany.apache.org>
To: dev@tuscany.apache.org
Message-ID: <1458764337.28553.1354037878346.JavaMail.jiratomcat@arcas>
Subject: [jira] [Created] (TUSCANY-4073) Change classloader to use different
 versions of third-party libraries than the Tuscany runtime
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

Sebastian Millies created TUSCANY-4073:
------------------------------------------

             Summary: Change classloader to use different versions of third-party libraries than the Tuscany runtime
                 Key: TUSCANY-4073
                 URL: https://issues.apache.org/jira/browse/TUSCANY-4073
             Project: Tuscany
          Issue Type: Improvement
          Components: SCA Java Runtime
    Affects Versions: Java-SCA-1.6.2
         Environment: Java 7 on Windows 7 (64bit)
            Reporter: Sebastian Millies
             Fix For: Java-SCA-1.6.2


I want to set up my contributions, so that they can use
different versions of third-party libraries than the Tuscany runtime. My original example
was using recent versions of EMF (hence the subject line), another example is using
Tuscany with an Apache Solr 4.0 backend, which requires different Apache Http Components.

The standard recommendation is [1], but I have had great trouble to get that to work. (The
reasons have to do with the use of SDOs in the application in question.)

I have therefore decided to try the opposite approach of  including any different versions of components
used  by Tuscany in nested jars in the contribution itself. Nested jars in a zip contribution get added into
the contribution classpath.

Here I am working under the assumption that the SCA contribution classloader would work
somewhat like a webapp class loader in that it would not follow the delegation model,
but would look for classes in the following order
1) inside the contribution
2) in the imports
3) in the parent classloader

With this behavior, everything goes well. For example, I can make calls to Apache Solr through
the solr-solrj-4.0.0.jar and its dependents, including httpclient-4.1.3.jar and httpcore-4.1.4.jar,
without impacting HTTP calls made by Tuscany-generated proxies elsewhere.

Here's the snag: As it turned out, org.apache.tuscany.sca.contribution.java.impl.ContributionClassLoader DID
NOT work the way I expected, but rather looked in the parent classloader first, only then inside the contribution.
I had to change the coding (in module contribution-java) and the associated test. A patch is attached.

Would my change break anything, perhaps with respect to OSGi? Is there anything in the SCA spec that mandates a
certain class loading behavior? I do feel that the alternative behavior is more natural than the one that is currently
implemented. (There a very few resources on Tuscany classloading, and e. g. [2] does not seem to mention
this particular issue.)

Unfortunately, I cannot get all the Tuscany 1.6  tests to compile and run with maven.

Please, would anyone be willing to see if Tuscany 1.6 with my patch applied would still pass all current tests?
(unless my proposal is obviously wrong for other reasons, of course)

Best,
Sebastian

[1] http://mail-archives.apache.org/mod_mbox/tuscany-user/201006.mbox/%3C4C164DD3.8090405@apache.org%3E
[2] https://cwiki.apache.org/TUSCANYWIKI/classloading.html

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira