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
