[
https://issues.apache.org/jira/browse/TUSCANY-4073?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebastian Millies updated TUSCANY-4073:
---------------------------------------
Attachment: example-code.zip
Example class loader, class loader provider, extension point and services files
> 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, example-code.zip
>
>
> 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.8090...@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
