Malisetti, Ramanjaneyulu wrote:
Hi Simon,
My cheers doesn't last beyond standalone sample. When I
start using same concept in our app, I am hit by below exception. I
don't understand why there is different classloader for definitions. If
you follow below exceptions, it is not using runtimeclassloader.
com.ca.ucf.remote.sca.bind.tuscany.TuscanySCANodeLauncherFactory is our
wrapper for creating, starting and stopping SCA Node. I am creating Node
exactly what you given instructions.
How could be the reason for below stack?
I looked through this stack trace and the Tuscany runtime code and I don't
see any problem in the Tuscany runtime code that would cause the wrong
classloader to be used.
To make a wild guess, could it be that your wrapper class
com.ca.ucf.remote.sca.bind.tuscany.TuscanySCANodeLauncherFactory is on
the classpath and contains references to Tuscany runtime code (other
than code in tuscany-node-launcher.jar)? This could cause a problem
like the one you are seeing.
If this isn't the cause of the problem, please create a JIRA and attach
the source code for a complete application that produces this stack trace.
Simon
Caused by: org.apache.tuscany.sca.node.launcher.LauncherException:
java.lang.reflect.InvocationTargetException
at
org.apache.tuscany.sca.node.launcher.NodeLauncherUtil.node(NodeLauncherU
til.java:388)
at
org.apache.tuscany.sca.node.launcher.NodeLauncher.createNode(NodeLaunche
r.java:90)
at
com.ca.ucf.remote.sca.bind.tuscany.TuscanySCANodeLauncherFactory.getSCAN
odeWrapper(TuscanySCANodeLauncherFactory.java:63)
at
com.ca.ucf.remote.sca.util.SCANodeUtil.buildServiceSCANode(SCANodeUtil.j
ava:114)
... 4 more
Caused by: java.lang.reflect.InvocationTargetException
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
Method)
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorA
ccessorImpl.java:39)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingCons
tructorAccessorImpl.java:27)
at
java.lang.reflect.Constructor.newInstance(Constructor.java:513)
at
org.apache.tuscany.sca.node.launcher.NodeLauncherUtil.node(NodeLauncherU
til.java:360)
... 7 more
Caused by: java.lang.NoClassDefFoundError:
org/apache/tuscany/sca/provider/SCADefinitionsProvider
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:620)
at
java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:260)
at java.net.URLClassLoader.access$000(URLClassLoader.java:56)
at java.net.URLClassLoader$1.run(URLClassLoader.java:195)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:276)
at java.lang.ClassLoader.loadClass(ClassLoader.java:299)
at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
at
org.apache.tuscany.sca.extensibility.ClassLoaderServiceDiscoverer$Servic
eDeclarationImpl.loadClass(ClassLoaderServiceDiscoverer.java:88)
at
org.apache.tuscany.sca.extensibility.ClassLoaderServiceDiscoverer$Servic
eDeclarationImpl.loadClass(ClassLoaderServiceDiscoverer.java:82)
at
org.apache.tuscany.sca.provider.DefaultSCADefinitionsProviderExtensionPo
int.loadProviders(DefaultSCADefinitionsProviderExtensionPoint.java:74)
at
org.apache.tuscany.sca.provider.DefaultSCADefinitionsProviderExtensionPo
int.getSCADefinitionsProviders(DefaultSCADefinitionsProviderExtensionPoi
nt.java:57)
at
org.apache.tuscany.sca.node.impl.RuntimeBootStrapper.loadSCADefinitions(
RuntimeBootStrapper.java:286)
at
org.apache.tuscany.sca.node.impl.RuntimeBootStrapper.start(RuntimeBootSt
rapper.java:193)
at
org.apache.tuscany.sca.node.impl.NodeImpl.initRuntime(NodeImpl.java:473)
at
org.apache.tuscany.sca.node.impl.NodeImpl.<init>(NodeImpl.java:412)
at
org.apache.tuscany.sca.node.impl.NodeFactoryImpl.createSCANode(NodeFacto
ryImpl.java:52)
at
org.apache.tuscany.sca.implementation.node.launcher.NodeImplementationLa
uncherBootstrap.<init>(NodeImplementationLauncherBootstrap.java:137)
... 12 more
Caused by: java.lang.ClassNotFoundException:
org.apache.tuscany.sca.provider.SCADefinitionsProvider
at java.net.URLClassLoader$1.run(URLClassLoader.java:200)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:276)
at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
... 34 more
Regards
Raman
-----Original Message-----
From: Malisetti, Ramanjaneyulu
Sent: Monday, June 14, 2010 7:56 PM
To: [email protected]
Subject: RE: Does SCA 1.6 supports Axis 1.5
Simon,
It works!!!! Many many thanks for help. We are out of flux
now :-)
Regards
Raman
-----Original Message-----
From: Simon Nash [mailto:[email protected]]
Sent: Saturday, June 12, 2010 3:25 AM
To: [email protected]
Subject: Re: Does SCA 1.6 supports Axis 1.5
Simon Nash wrote:
Hi Raman,
I'd be interested to know how you get on with this. I think
everything
will be fine if the services in a node that's created using
NodeLauncher.createNode() are invoked using remote calls. If a
service
in the node is invoked locally using SCAClient.getService(), I'm not
sure
whether the classloader switching will happen correctly. I'll give
this
a try and see what happens.
Simon
I tried this and it does work if you have the classpath set up
correctly.
It isn't very easy to figure out the right combination, though.
The following rules seem to work OK:
1. The classpath MUST contain the application code.
2. If the application code uses any SCA annotations, the classpath MUST
contain the tuscany-sca-api jar.
3. The classpath MUST contain the tuscany-node-launcher jar.
4. The classpath MUST NOT contain any Tuscany jars other than the above.
Specifically, it MUST NOT contain the tuscany-node-api jar. This
means that the application code needs to use Java reflection to call
the "start", "stop" and "getService" methods on the object returned
by createNode().
Here's an example of the code that I used to do this:
package scatours;
import org.apache.tuscany.sca.node.launcher.Contribution;
import org.apache.tuscany.sca.node.launcher.NodeLauncher;
public class JumpstartLauncher {
public static void main(String[] args) throws Exception {
Contribution gvtContribution =
new Contribution("introducing-trips",
"../../contributions/introducing-trips/target/classes");
Object node = NodeLauncher.newInstance().
createNode("trips.composite", gvtContribution);
node.getClass().getMethod("start").invoke(node);
Trips tripProvider = (Trips)node.getClass().
getMethod("getService", Class.class, String.class)
.invoke(node, Trips.class, "TripProvider/Trips");
System.out.println("Trip boooking code = " +
tripProvider.checkAvailability("FS1APR4", 1));
node.getClass().getMethod("stop").invoke(node);
}
}
Simon
Malisetti, Ramanjaneyulu wrote:
Thanks a lot Simon,
Yes, I can have Tuscany and its dependent modules use different
classloader from application classloader.
Regards
Raman
-----Original Message-----
From: Simon Nash [mailto:[email protected]] Sent: Friday, June 11, 2010
3:35 PM
To: [email protected]
Subject: Re: Does SCA 1.6 supports Axis 1.5
Malisetti, Ramanjaneyulu wrote:
Thanks for the information.
We are not using Axis-1.5.1 directly. But, one of the component
that
is going to run along with the modules developed on SCA is using.
They
don't have any proper reason other than they can't change it now from
1.5.1 to 1.4.1 because that component is already shipped to
customers.
So, it is a circular dependency for us.
Do you have any suggestion to come out this flux.
This is difficult because I can imagine other users in the opposite
situation, i.e., with application modules that use Axis2 1.4 and
might
no longer work if Tuscany changed to 1.5.1.
Is it a problem if Tuscany is using Axis2 1.4 and other application
code
is using 1.5.1? This would cause problems if everything is loaded on
the
same classpath. Perhaps the best solution for these kinds of
problems
would be for Tuscany to use a separate classloader for its
dependencies
so that they don't interfere with the application's classloader and
classpath.
The NodeLauncher class in 1.x does something like this, and I'm
wondering if
using the NodeLauncher.createNode() method to create the Tuscany node
instead
of using SCANodeFactory.createSCANode() would solve the problem.
Simon
Regards
Raman
-----Original Message-----
From: Simon Laws [mailto:[email protected]] Sent: Friday,
June 11, 2010 1:13 PM
To: [email protected]
Subject: Re: Does SCA 1.6 supports Axis 1.5
On Fri, Jun 11, 2010 at 8:39 AM, Simon Nash <[email protected]> wrote:
Malisetti, Ramanjaneyulu wrote:
Hi,
We need to use Axis 1.5 along with Tuscany SCA. Did any of
you try
this combination. We tried to use but left with exceptions on
client
side.
Regards
Raman
I'm interested to know more about what is new or changed in Axis2
1.5
that means you need to use it instead of 1.4.
I haven't tried using Axis2 1.5 with Tuscany SCA 1.6. Based on
past
experience, moving to a new version of Axis2 is likely to need some
work
in Tuscany and a new Tuscany release. As part of the consideration
of
whether to do this, it would be helpful to know why this change is
important for our users.
Simon
We're based on Axis 1.5.1 in the Tuscany 2.x development in trunk.
As
Simon says moving up from 1.4 did require a few changes.
Regards
Simon
