> From: Simon Nash [mailto:[email protected]] > Sent: Thursday, August 23, 2012 10:08 PM > To: [email protected] > Subject: Re: Using EMF with Tuscany 1.6 > > Millies, Sebastian wrote: > > Hello Simon, > > > > thanks for the pointer. The thing is, I can't get this to work. > > The NodeLauncher.createNode() does not seem to be aware of the > > Tuscany dependencies (i. e. the jars that come in the lib/* > > directory). For example, when launching a certain node I get > > > > java.lang.NoClassDefFoundError: > org/apache/commons/lang/exception/NestableException > > [snip]
> Can you post the full stack trace for this error? This may provide > some > clues to why NodeLauncher isn't loading this class from the lib > directory. > > Simon 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. 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: 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? 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. 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. -- 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
