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 13:05:11 GMT
Millies, Sebastian wrote:
>> -----Ursprüngliche Nachricht-----
>> Von: Simon Nash [mailto:nash@apache.org]
>> Gesendet: Mittwoch, 28. November 2012 12:37
>> An: user@tuscany.apache.org
>> Betreff: Re: Tuscany class loading (was: Re: Using EMF with Tuscany
>> 1.6)
>>
>> 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:
>>>
> 
> [snip]
> 
>>>     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:
>>>
> 
> [snip]
> 
>>>       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.initInvocationChai
>> ns(RuntimeWireImpl.java:220)
>>      at
>> org.apache.tuscany.sca.core.assembly.RuntimeWireImpl.getInvocationChain
>> s(RuntimeWireImpl.java:118)
>>      at
>> org.apache.tuscany.sca.core.assembly.RuntimeWireImpl.getInvocationChain
>> (RuntimeWireImpl.java:146)
>>      at
>> org.apache.tuscany.sca.core.assembly.RuntimeComponentServiceImpl.getInv
>> ocationChain(RuntimeComponentServiceImpl.java:125)
>>      at
>> org.apache.tuscany.sca.binding.sca.impl.RuntimeSCAReferenceBindingProvi
>> der.getInvoker(RuntimeSCAReferenceBindingProvider.java:200)
>>      at
>> org.apache.tuscany.sca.binding.sca.impl.RuntimeSCAReferenceBindingProvi
>> der.createInvoker(RuntimeSCAReferenceBindingProvider.java:213)
>>      at
>> org.apache.tuscany.sca.core.assembly.RuntimeWireImpl.addReferenceBindin
>> gInterceptor(RuntimeWireImpl.java:329)
>>      at
>> org.apache.tuscany.sca.core.assembly.RuntimeWireImpl.initInvocationChai
>> ns(RuntimeWireImpl.java:208)
>>      at
>> org.apache.tuscany.sca.core.assembly.RuntimeWireImpl.getInvocationChain
>> s(RuntimeWireImpl.java:118)
>>      at
>> org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.getInvocati
>> onChain(JDKInvocationHandler.java:298)
>>      at
>> org.apache.tuscany.sca.core.invocation.JDKInvocationHandler.invoke(JDKI
>> nvocationHandler.java:188)
>>      at $Proxy9.sayRmiHello(Unknown Source)
>>      at
>> org.apache.tuscany.sca.binding.rmi.BindingTestCase.testRmiService(Bindi
>> ngTestCase.java:43)
>>      at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>      at
>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.ja
>> va:39)
>>      at
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccesso
>> rImpl.java:25)
>>      at java.lang.reflect.Method.invoke(Method.java:597)
>>      at
>> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMe
>> thod.java:44)
>>      at
>> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCalla
>> ble.java:15)
>>      at
>> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMeth
>> od.java:41)
>>      at
>> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMetho
>> d.java:20)
>>      at
>> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.ja
>> va:28)
>>      at
>> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java
>> :31)
>>      at
>> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunne
>> r.java:73)
>>      at
>> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunne
>> r.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.ja
>> va: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.ja
>> va:62)
>>      at
>> org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestS
>> et(AbstractDirectoryTestSuite.java:138)
>>      at
>> org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(Abst
>> ractDirectoryTestSuite.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.ja
>> va:39)
>>      at
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccesso
>> rImpl.java:25)
>>      at java.lang.reflect.Method.invoke(Method.java:597)
>>      at
>> org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(Sure
>> fireBooter.java:308)
>>      at
>> org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.jav
>> a:879)
> 
> [snip
> 
>>>    ...ant
>>>
> 
> [snip]
>>    Simon
>>
> 
> I especially wonder about that failure, because I have deployed the
> change in my environment (I can build the modules, although I cannot
> get all the tests to run) and saw no such problem, although I use
> RMI bindings almost exclusively between my components.
> 
> So I rather expect that test to be based on wrong assumptions.
> 
> For one thing, I notice the test uses
> SCANodeFactory.newInstance().createSCANodeFromClassLoader("RMIBindingTest.composite",
BindingTestCase.class.getClassLoader());
> Perhaps the assumption that this class loader should be able to find the composite is
> now wrong? Although that really shouldn't be the case.
> 
> But if the classes are now loaded by a different classloader (the contribution loader
instead of
> the parent loader), perhaps it is some RMI specific stuff in the test that only worked
by accident
> while everything  was in the same classloader. For example, when my app launches a node
that makes
> components  available via RMI, it sets the java.rmi.server.codebase system property.
And when it launches
> a component that consumes RMI services I set an appropriate  SecurityManager that allows
the  client to
> download classes remotely from that remote URL. Otherwise, I too get ClassCastExceptions
and operation
> lookup failures. That's just how RMI works.
> 
> I have no ideas about the failures in the other modules, though.
> 
It's possible that this could be the reason for the failure.  To make
further progress with this classloading change, someone would need to
investigate all the failing tests (I haven't yet tried itest, vtest
and tutorials) and make the necessary changes to remove any wrong
assumptions.  This would be quite a large piece of work.

   Simon

> -- Sebastian
> 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
> 


Mime
View raw message