ant elder wrote:
On Wed, Nov 28, 2012 at 10:12 AM, Simon Nash <n...@apache.org
<mailto: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
<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 HelloWorldRmiServiceComponent#HelloWorldRmiService
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?
Simon
