On Wed, Nov 28, 2012 at 10:12 AM, Simon Nash <n...@apache.org> wrote:
> Simon Nash wrote: > >> Millies, Sebastian 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) >>> >>> I can run these tests on the Tuscany 1.x trunk tomorrow. >> >> Simon >> >> I tried this and got the following failures in modules and samples: > > modules/binding-rmi-runtime: > testRmiService(org.apache.**tuscany.sca.binding.rmi.**BindingTestCase) > > modules/binding-ws-axis2: > testEchoFoo(org.apache.**tuscany.sca.binding.ws.axis2.**itests.** > HelloWorldNoWSDLTestCase) > testImageFileTransfer(org.**apache.tuscany.sca.binding.ws.** > axis2.itests.mtom.**FileTransferMTOMTestCase) > testSourceFileTransfer(org.**apache.tuscany.sca.binding.ws.** > axis2.itests.mtom.**FileTransferMTOMTestCase) > testDataHandlerFileTransfer(**org.apache.tuscany.sca.** > binding.ws.axis2.itests.mtom.**FileTransferMTOMTestCase) > testOMElementFileTransfer(org.**apache.tuscany.sca.binding.ws.** > axis2.itests.mtom.**FileTransferMTOMTestCase) > > samples/callbacks-jms: > testOderClient(callbacks.**CallbacksTestCase) > > samples/helloworld-ws-**reference-lean: > testWSClient(helloworld.**HelloWorldClientTestCase) > > samples/helloworld-ws-sdo: > testWSClient(helloworld.**HelloWorldClientTestCase) > > samples/implementation-**composite: > test(composite.**CompositeTestCase) > > samples/quote-xquery: > testQuoteJoin(xquery.quote.**XQueryQuoteClientTestCase) > > samples/simple-bigbank: > test(bigbank.BigBankTestCase) > > samples/spring-bigbank-**stockquote: > testServer(bigbank.stockquote.**StockQuoteServiceTestCase) > > samples/simple-callback: > test(simplecallback.**SimpleCallbackTestCase) > > samples/simple-callback-ws: > test(simplecallback.**SimpleCallbackTestCase) > > I didn't go any further, as the above errors seem to indicate there > are serious issues with this change. > > > Simon > > Could you show a stacktrace of one of those fails to see if that helps identify the issue? It seems like a reasonable idea for a function to support to me. In 2.0 the OASIS specs do define the class searching so its not going to be spec compliant but that doesn't matter so much in 1.x and it should probably have some type of switch to control it, something like the parent classloader first/last switch that many Java EE appservers have. ...ant
