It's been over 2 years since I looked into this in detail and put
together the list of gudelines in [1], so I don't recall 100% of the
detail of how this works. See inline below for my impressions of
what may be happening.
Simon
Millies, Sebastian wrote:
(cut)
I think I have found the cause of the problem:
My contribution had a dependency on Apache Commons Configuration, since one
of the contribution classes uses
org.apache.commons.configuration.ConfigurationException,
through which I get an indirect reference to
org.apache.commons.lang.exception.NestableException
from Apache Commons Lang.
I did not detect that at compile time, because when I restricted the launcher
classpath from all of Tuscany to the two jars tuscany-sca-api.jar and
tuscany-node-kauncher.jar,
I did not adjust the compile time contribution libraries accordingly. So
commons-lang.jar,
although available at compile time from $TUSCANY_HOME/lib, was not found at run
time.
Thanks for the help. In the rest of this post, I'll just ramble on about what
testing I did.
It will be of little value for those who are not especially interested in
classlaoding problems.
Here goes. Referring again to [1] (see below): I read that post as implying
that I should put commons-lang.jar on the runtime classpath. And that this
would not interfere with
whatever version of commons-lang Tuscany requires, because the NodeLauncher
will use a separate classloader
for its dependencies. I tried that, and lo and behold, the component starts,
and using -verbose:class
shows Tuscany classes being loaded from $TUSCANY_HOME/lib and Tuscany/modules.
Yes, that's correct.
By extension the same approach should work with classes like
common.sdo.DataObject (which occur in
my service methods) etc. So I tried that as well. Now the situation is as
follows:
Do you mean that this appears in your service method interfaces, or in
your service method implementations? The Tuscany runtime needs to load
and introspect classes in your service method interfaces, but not classes
that are used only by your service method implementations.
1) When I do NOT include tuscany-sdo-api-r2.1-1.1.1.jar on the application
classpath, the class
commonj.sdo.DataObject and its dependencies will be loaded from the jars
located in $TUSCANY_HOME/lib.
This confuses me: Why would the contribution classloader be able to find
classes belonging to
the Tuscany dependencies, when in theory according to [1] these should be
loaded only through the
NodeLauncher, the contribution classloader being restricted to the application
classpath?
My guess is that the Tuscany runtime is loading these classes for its
own purposes based on your usage of SDO in your application.
2) When I DO inlude that jar on the runtime classpath, the class will be loaded
from that jar,
provided of course I also load all the dependencies, which include:
codegen-ecore-2.2.3.jar
common-2.2.3.jar
commons-configuration-1.6.jar
commons-lang-2.3.jar
ecore-2.2.3.jar
ecore-change-2.2.3.jar
ecore-xmi-2.2.3.jar
tuscany-sdo-api-r2.1-1.1.1.jar
tuscany-sdo-impl-1.1.1.jar
tuscany-sdo-lib-1.1.1.jar
tuscany-sdo-tools-1.1.1.jar
xsd-2.2.3.jar
This list was difficult to put together, basically only through trial and
error. And according
to point 6. in [1], the classpath MUST NOT contain these Tuscany jars anyway.
I'll have to test
later, if this interferes with anything in my app.
I think the term "Tuscany jars" was intended to refer to those jars
in the 'modules' directory, not all jars whose name starts with 'tuscany'.
I don't understand why you're putting tuscany-sdo-api-r2.1-1.1.1.jar on
your runtime classpath. The mechanisms described in [1] for runtime jar
replacement can't be used to replace any Tuscany APIs by different
versions. I thought you wanted to use this mechanism to have a different
level of EMF in your application than the level used by the Tuscany runtime.
Taken together, these results make me mistrust the recommendation in [1].
Perhaps it would
really be better to try the opposite approach of including any different
versions of components used
by Tuscany in nested jars in the contribution itself, given that according to
today's post by ant this
nesting of jars should work. I'll try that next.
I'll be interested to hear how you get on with that.
Simon
-- Sebastian
I will have to test at a later time
From: Simon Nash [mailto:[email protected]]
Sent: Tuesday, August 21, 2012 9:55 PM
To: [email protected]
Subject: Re: Using EMF with Tuscany 1.6
[snip]
Please see [1].
Simon
[1]
http://mail-archives.apache.org/mod_mbox/tuscany-user/201006.mbox/%[email protected]%3E
[snip]
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
