tuscany-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Nash <n...@apache.org>
Subject Re: Tuscany class loading (was: Re: Using EMF with Tuscany 1.6)
Date Wed, 28 Nov 2012 11:36:34 GMT
ant elder wrote:
> On Wed, Nov 28, 2012 at 10:12 AM, Simon Nash <nash@apache.org 
> <mailto:nash@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
>     <http://apache.tuscany.sca.binding.ws>.__axis2.itests.mtom.__FileTransferMTOMTestCase)
>     testSourceFileTransfer(org.__apache.tuscany.sca.binding.ws
>     <http://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
>     <http://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?
Here's the first one:

org.osoa.sca.ServiceRuntimeException: No matching operation for sayRmiHi is found in service
     at org.apache.tuscany.sca.core.assembly.RuntimeWireImpl.initInvocationChains(RuntimeWireImpl.java:220)
     at org.apache.tuscany.sca.core.assembly.RuntimeWireImpl.getInvocationChains(RuntimeWireImpl.java:118)
     at org.apache.tuscany.sca.core.assembly.RuntimeWireImpl.getInvocationChain(RuntimeWireImpl.java:146)
     at org.apache.tuscany.sca.core.assembly.RuntimeComponentServiceImpl.getInvocationChain(RuntimeComponentServiceImpl.java:125)
     at org.apache.tuscany.sca.binding.sca.impl.RuntimeSCAReferenceBindingProvider.getInvoker(RuntimeSCAReferenceBindingProvider.java:200)
     at org.apache.tuscany.sca.binding.sca.impl.RuntimeSCAReferenceBindingProvider.createInvoker(RuntimeSCAReferenceBindingProvider.java:213)
     at org.apache.tuscany.sca.core.assembly.RuntimeWireImpl.addReferenceBindingInterceptor(RuntimeWireImpl.java:329)
     at org.apache.tuscany.sca.core.assembly.RuntimeWireImpl.initInvocationChains(RuntimeWireImpl.java:208)
     at org.apache.tuscany.sca.core.assembly.RuntimeWireImpl.getInvocationChains(RuntimeWireImpl.java:118)
     at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.getInvocationChain(JDKInvocationHandler.java:298)
     at org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKInvocationHandler.java:188)
     at $Proxy9.sayRmiHello(Unknown Source)
     at org.apache.tuscany.sca.binding.rmi.BindingTestCase.testRmiService(BindingTestCase.java:43)
     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
     at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
     at java.lang.reflect.Method.invoke(Method.java:597)
     at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
     at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
     at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
     at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
     at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
     at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31)
     at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:73)
     at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:46)
     at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:180)
     at org.junit.runners.ParentRunner.access$000(ParentRunner.java:41)
     at org.junit.runners.ParentRunner$1.evaluate(ParentRunner.java:173)
     at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
     at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31)
     at org.junit.runners.ParentRunner.run(ParentRunner.java:220)
     at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62)
     at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:138)
     at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:125)
     at org.apache.maven.surefire.Surefire.run(Surefire.java:132)
     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
     at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
     at java.lang.reflect.Method.invoke(Method.java:597)
     at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:308)
     at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:879)

> 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  
I've always thought that switch was a nasty hack....

Did you have in mind a global switch to change the classloader behaviour,
or something that could be applied on a per-contribution basis?


View raw message