You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by "Sebastian Millies (JIRA)" <de...@tuscany.apache.org> on 2012/11/27 18:43:58 UTC
[jira] [Commented] (TUSCANY-4073) Change classloader to use
different versions of third-party libraries than the Tuscany runtime
[ https://issues.apache.org/jira/browse/TUSCANY-4073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13504791#comment-13504791 ]
Sebastian Millies commented on TUSCANY-4073:
--------------------------------------------
I hereby give permission to the Apache Software Foundation use the attached patch for any purpose whatsoever. -- Sebastian Millies
> 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
>
> Attachments: classloader.patch
>
>
> 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