On further reflection, the instructions I posted aren't quite right.
The classpath doesn't need to include any application code that's part
of an SCA contribution, and it's best practice for it not to include
such code because this can cause problems with import/export resolution.
Taking this into account, the guidance is as follows:
1. The classpath MUST contain any application code that isn't part of
an SCA contribution (e.g., launcher code or test client code).
2. The classpath SHOULD NOT contain any application code that is part
of an SCA contribution.
3. Application code that's part of an SCA contribution SHOULD NOT also
appear on the classpath. Most commonly this arises with Java interfaces
that are used by SCA services and also by client code to call those
SCA services. A simple solution is for the client code to use a copy
of the service interface in a different Java package.
4. If the application code uses any SCA annotations, the classpath MUST
contain the tuscany-sca-api jar.
5. The classpath MUST contain the tuscany-node-launcher jar.
6. 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().
Simon
Simon Nash wrote:
Malisetti, Ramanjaneyulu wrote:
Simon,
It works!!!! Many many thanks for help. We are out of flux
now :-)
Hi Raman,
That's great news! This should also be useful to other people who need
to use a different version of any of the components used by Tuscany.
I've changed the subject line as this might make it easier for others to
find this information.
Simon
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
