On Tue, Nov 27, 2012 at 2:30 AM, Millies, Sebastian < sebastian.mill...@softwareag.com> wrote:
> Hello there, > > I've never been back to talk about this, so here goes. > > To re-iterate the problem: 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 contributionget 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 > > [2] https://cwiki.apache.org/TUSCANYWIKI/classloading.html > > -----Ursprüngliche Nachricht----- > Von: Simon Nash [mailto:n...@apache.org] > Gesendet: Samstag, 25. August 2012 09:17 > An: user@tuscany.apache.org > Betreff: Re: Using EMF with Tuscany 1.6 > > It's been over 2 years since I looked into this in detail and put together > the list of gudelines in [1], so I don't recall 100% of the detail of how > this works. See inline below for my impressions of what may be happening. > > [cut] > > I'll be interested to hear how you get on with that. > > Simon > > > -- Sebastian > > > >> > >> [1] > >> http://mail-archives.apache.org/mod_mbox/tuscany-user/201006.mbox/%3C > >> 4c164dd3.8090...@apache.org%3E > >> > IDS Scheer Consulting GmbH > Geschäftsführer/Managing Directors: Michael Rehm, Ivo Totev > Sitz/Registered office: Altenkesseler Straße 17, 66115 Saarbrücken, > Germany - Registergericht/Commercial register: Saarbrücken HRB 19681 > http://www.ids-scheer-consulting.com > > Thanks for the detailed explanation and patch. Could you please create a JIRA and attach the patch there (making sure you give permission to use it in the available checkbox). Thanks -- Luciano Resende http://people.apache.org/~lresende http://twitter.com/lresende1975 http://lresende.blogspot.com/
