You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@tuscany.apache.org by ed...@apache.org on 2009/04/22 11:18:00 UTC
svn commit: r767428 - in
/tuscany/java/sca/modules/node-launcher-equinox/src/main/java/org/apache/tuscany/sca/node/equinox/launcher:
EquinoxHost.java NodeLauncherUtil.java
Author: edwardsmj
Date: Wed Apr 22 09:17:59 2009
New Revision: 767428
URL: http://svn.apache.org/viewvc?rev=767428&view=rev
Log:
Improvements to the handling of OSGi bundles when running in development mode
Modified:
tuscany/java/sca/modules/node-launcher-equinox/src/main/java/org/apache/tuscany/sca/node/equinox/launcher/EquinoxHost.java
tuscany/java/sca/modules/node-launcher-equinox/src/main/java/org/apache/tuscany/sca/node/equinox/launcher/NodeLauncherUtil.java
Modified: tuscany/java/sca/modules/node-launcher-equinox/src/main/java/org/apache/tuscany/sca/node/equinox/launcher/EquinoxHost.java
URL: http://svn.apache.org/viewvc/tuscany/java/sca/modules/node-launcher-equinox/src/main/java/org/apache/tuscany/sca/node/equinox/launcher/EquinoxHost.java?rev=767428&r1=767427&r2=767428&view=diff
==============================================================================
--- tuscany/java/sca/modules/node-launcher-equinox/src/main/java/org/apache/tuscany/sca/node/equinox/launcher/EquinoxHost.java (original)
+++ tuscany/java/sca/modules/node-launcher-equinox/src/main/java/org/apache/tuscany/sca/node/equinox/launcher/EquinoxHost.java Wed Apr 22 09:17:59 2009
@@ -314,31 +314,41 @@
}
// Start all our bundles for now to help diagnose any class loading issues
- // for (Bundle bundle: bundleContext.getBundles()) {
- // if (bundle.getSymbolicName().startsWith("org.apache.tuscany.sca")) {
- // if ((bundle.getState() & Bundle.ACTIVE) == 0) {
- // if (logger.isLoggable(Level.FINE)) {
- // logger.fine("Starting bundle: " + string(bundle, false));
- // }
- // try {
- // //bundle.start();
- // } catch (Exception e) {
- // logger.log(Level.SEVERE, e.getMessage(), e);
- // // throw e;
- // }
- // if (logger.isLoggable(Level.FINE)) {
- // logger.fine("Bundle: " + string(bundle, false));
- // }
- // }
- // }
- // }
- // logger.fine("Tuscany bundles are started in " + (System.currentTimeMillis() - activateStart) + " ms.");
+ // startBundles( bundleContext );
return bundleContext;
} catch (Exception e) {
throw new IllegalStateException(e);
}
}
+
+ /**
+ * Start all the bundles as a check for class loading issues
+ * @param bundleContext - the bundle context
+ */
+ private void startBundles( BundleContext bundleContext ) {
+
+ for (Bundle bundle: bundleContext.getBundles()) {
+ // if (bundle.getSymbolicName().startsWith("org.apache.tuscany.sca")) {
+ if ((bundle.getState() & Bundle.ACTIVE) == 0) {
+ if (logger.isLoggable(Level.FINE)) {
+ logger.fine("Starting bundle: " + string(bundle, false));
+ } // end if
+ try {
+ bundle.start();
+ } catch (Exception e) {
+ logger.log(Level.SEVERE, e.getMessage(), e);
+ // throw e;
+ } // end try
+ if (logger.isLoggable(Level.FINE)) {
+ logger.fine("Bundle: " + string(bundle, false));
+ } // end if
+ } // end if
+ // } // end if
+ } // end for
+ logger.fine("Tuscany bundles are started.");
+ return;
+ } // end startBundles
public Bundle installAsBundle(Collection<URL> jarFiles, String libraryBundleName) throws IOException,
BundleException {
@@ -398,9 +408,16 @@
logger.fine("Installing third-party jar as bundle: " + jarFile);
}
InputStream is = thirdPartyLibraryBundle(Collections.singleton(jarFile), symbolicName, version);
+ // try/catch and output message added 10/04/2009 Mike Edwards
+ try {
bundle = bundleContext.installBundle(symbolicName, is);
allBundles.put(symbolicName, bundle);
installedBundles.add(bundle);
+ } catch (BundleException e) {
+ System.out.println("EquinoxHost:installAsBundle - BundleException raised when dealing with jar " + symbolicName);
+ throw (e);
+ } // end try
+ // end of addition
}
return bundle;
}
@@ -416,7 +433,11 @@
// Use classpath entries from a distribution if there is one and the classpath
// entries on the current application's classloader
- bundleLocations = runtimeClasspathEntries(true, true, false);
+ // *** Changed by Mike Edwards, 9th April 2009 ***
+ // -- this place is reached when starting from within Eclipse so why use the classpath??
+ // bundleLocations = runtimeClasspathEntries(true, true, false);
+ // Instead search the modules directory
+ bundleLocations = runtimeClasspathEntries(true, true, true);
}
}
return bundleLocations;
Modified: tuscany/java/sca/modules/node-launcher-equinox/src/main/java/org/apache/tuscany/sca/node/equinox/launcher/NodeLauncherUtil.java
URL: http://svn.apache.org/viewvc/tuscany/java/sca/modules/node-launcher-equinox/src/main/java/org/apache/tuscany/sca/node/equinox/launcher/NodeLauncherUtil.java?rev=767428&r1=767427&r2=767428&view=diff
==============================================================================
--- tuscany/java/sca/modules/node-launcher-equinox/src/main/java/org/apache/tuscany/sca/node/equinox/launcher/NodeLauncherUtil.java (original)
+++ tuscany/java/sca/modules/node-launcher-equinox/src/main/java/org/apache/tuscany/sca/node/equinox/launcher/NodeLauncherUtil.java Wed Apr 22 09:17:59 2009
@@ -48,6 +48,7 @@
import java.util.Collection;
import java.util.HashSet;
import java.util.List;
+import java.util.Map;
import java.util.Set;
import java.util.StringTokenizer;
import java.util.jar.Attributes;
@@ -240,7 +241,14 @@
* starting with -, then some digits, then . or - or _, then some digits again
*
*/
- private static Pattern pattern = Pattern.compile("-(\\d)+((\\.|-|_)(\\d)+)*");
+ // Mike Edwards 13/04/2009 - this original pattern allows for any number of repeated
+ // groups of digits, so that 1.2.3.4 is legal, for example. The problem with this is
+ // that OSGi only deals with a maximum of 3 groups of digits...
+ // private static Pattern pattern = Pattern.compile("-(\\d)+((\\.|-|_)(\\d)+)*");
+ //
+ // This updated version restricts the allowed patterns to a maximum of 3 groups of
+ // digits so that "1", "1.2" and "1.2.3" are allowed but not "1.2.3.4" etc
+ private static Pattern pattern = Pattern.compile("-(\\d)+((\\.|-|_)(\\d)+){0,2}");
/**
* Returns the version number to use for the given JAR file.
@@ -265,7 +273,12 @@
String version = "0.0.0";
if (matcher.find()) {
version = matcher.group();
+ // Remove the leading "-" character
version = version.substring(1);
+ // The Pattern above allows the version string to contain "-" and "_" as digit separators.
+ // OSGi only allows for "." as a separator thus any "-" and "_" characters in the version string must be replaced by "."
+ version = version.replace('-', '.');
+ version = version.replace('_', '.');
}
return version;
}
@@ -367,6 +380,31 @@
}
}
}
+
+ /**
+ * Finds the OSGi manifest file for a JAR file, where the manifest file is held in a META-INF directory
+ * alongside the JAR
+ * @param jarURL - The URL of the JAR file
+ * @return - a Manifest object corresponding to the manifest file, or NULL if there is no OSGi manifest
+ */
+ static private Manifest findOSGiManifest( URL jarURL ) {
+ try{
+ File jarFile = new File( jarURL.toURI() );
+ File theManifestFile = new File(jarFile.getParent(), "META-INF/MANIFEST.MF");
+ if( theManifestFile.exists() ) {
+ // Create manifest object by reading the manifest file
+ Manifest manifest = new Manifest( new FileInputStream(theManifestFile) );
+ // Check that this manifest file has the necessary OSGi metadata
+ String bundleName = manifest.getMainAttributes().getValue(BUNDLE_SYMBOLICNAME);
+ if( bundleName != null ) {
+ return manifest;
+ } // end if
+ } // end if
+ } catch ( Exception e ) {
+ // Could not read the manifest - continue
+ }
+ return null;
+ } // end findOSGiManifest
/**
* Generate a manifest from a list of third-party JAR files.
@@ -381,7 +419,17 @@
String bundleSymbolicName,
String bundleVersion) throws IllegalStateException {
try {
-
+ // Added by Mike Edwards, 12/04/2009 - to handle the third party JAR files in the distribution that
+ // have separate OSGi manifest files provided alongside them
+ // In some cases a single JAR file is already accompanied by a MANIFEST.MF file, sitting in
+ // a META-INF directory alongside the JAR
+ //if( jarFiles.size() == 1 ){
+ // URL theJar = jarFiles.iterator().next();
+ // Manifest theManifest = findOSGiManifest( theJar );
+ // if( theManifest != null ) return theManifest;
+ //} // end if
+ // End of addition
+
// List exported packages and bundle classpath entries
StringBuffer classpath = new StringBuffer();
StringBuffer exports = new StringBuffer();
@@ -825,7 +873,10 @@
jarDirectoryURLs,
jarURLs,
new StandAloneDevelopmentClassesFileNameFilter());
- }
+ // Added Mike Edwards, 09/04/2009
+ // Get hold of the Libraries that are used by the Tuscany modules
+ collectDevelopmentLibraryEntries( modulesDirectory, jarDirectoryURLs, jarURLs );
+ } // end if
}
}
}
@@ -1053,6 +1104,29 @@
}
/**
+ * A file name filter used to filter the libraries in the \java\sca\distribution\all\target\modules
+ * directory
+ */
+ private static class DistributionLibsFileNameFilter implements FilenameFilter {
+
+ public boolean accept(File dir, String name) {
+ name = name.toLowerCase();
+
+ // Include subdirectories
+ if (new File(dir, name).isDirectory()) { return true; }
+
+ // Filter out the Tuscany jars - since the development versions of these are used
+ // from the \target\classes directories...
+ if (name.startsWith("tuscany")) { return false; }
+
+ // Include JAR and MAR files
+ if (name.endsWith(".jar")) { return true; }
+ if (name.endsWith(".mar")) { return true; }
+ return false;
+ } // end accept
+ } // end DistributionLibsFileNameFilter
+
+ /**
* Returns the File object representing the given URL.
*
* @param url
@@ -1108,6 +1182,34 @@
collectTargetClassesClasspathEntries(directoryFile, jarURLs, filter);
}
- }
+ } // end collectDevelopmentClasspathEntries
+
+ /**
+ * Collect the dependent Library JAR files for the development use of Tuscany
+ * It is assumed that these live in the \java\sca\distribution\all\target\modules
+ * directory, where the development modules live in \java\sca\modules, but that
+ * same directory also contains prebuilt versions of the Tuscany JARs, which must be
+ * filtered out so as not to clash with the development versions of the code
+ *
+ * @param directory - the \java\sca\modules directory
+ * @param jarDirectoryURLs
+ * @param jarURLs
+ * @throws MalformedURLException
+ */
+ private static void collectDevelopmentLibraryEntries(File modulesDirectory,
+ Set<URL> jarDirectoryURLs,
+ Set<URL> jarURLs) throws MalformedURLException {
+ // Get the \java\sca directory
+ File rootDirectory = modulesDirectory.getParentFile();
+ // Get the \java\sca\distribution\all\target\modules
+ String sep = File.separator;
+ File libsDirectory = new File(rootDirectory, "distribution" + sep + "all" + sep + "target" + sep + "modules");
+ URL libsURL = libsDirectory.toURI().toURL();
+ if (!jarDirectoryURLs.contains(libsURL) && libsDirectory.exists()) {
+ // Collect files under the libs module directory
+ jarDirectoryURLs.add(libsURL);
+ collectClasspathEntries(libsDirectory, jarURLs, new DistributionLibsFileNameFilter(), true);
+ } // end if
+ } // end collectDevelopmentLibraryEntries
}
Re: svn commit: r767428 - in /tuscany/java/sca/modules/node-launcher-equinox/src/main/java/org/apache/tuscany/sca/node/equinox/launcher:
EquinoxHost.java NodeLauncherUtil.java
Posted by Mike Edwards <mi...@gmail.com>.
ant elder wrote:
>
>
> The actual error cause was:
>
> Caused by: java.lang.ClassNotFoundException:
> org.apache.tuscany.sca.assembly.builder.ComponentPreProcessor
> at
> org.eclipse.osgi.framework.internal.core.BundleLoader.findClassInternal(BundleLoader.java:481)
>
> but I guess thats just caused by the spring modules not being finished,
> I saw you committed some updates to the spring manifests last night so
> i've tried again now it it works ok fine today.
>
> What was unexpected (to me anyway at the time) was that the
> node-launcher-equinox tests were failing because it was discovering a
> module that i didn't even have included in the build just happened to be
> within the modules/ directory, so thats the bit i was asking if that was
> the expected behaviour. I'm not saying its a problem, now that i know
> this is whats going on i guess it wont be unexpected if it happens again.
>
> ...ant
>
Ant,
Thanks for the post.
The error you were getting was the one I was working on, so that's good - and yes, I fixed it. It
was due to an incomplete adjustment of the code and the manifest files to permit clean running under
OSGi - the code was working fine outside of OSGi.
The problem here is perhaps one we should worry about - code that you have no intention of using
gets "touched" and eagerly loaded. So you have no Spring stuff in your Tuscany app, but simply
because the Spring implementation module is there, declaring that it supports
<implementation.spring/>, it gets initialized by the core runtime.
I would like us to consider moving to a lazy loading scheme, where the code is only loaded and
initialized when it is found to be required.
Thoughts??
Yours, Mike.
Re: svn commit: r767428 - in /tuscany/java/sca/modules/node-launcher-equinox/src/main/java/org/apache/tuscany/sca/node/equinox/launcher:
EquinoxHost.java NodeLauncherUtil.java
Posted by ant elder <an...@gmail.com>.
On Thu, Apr 23, 2009 at 8:16 PM, Mike Edwards <
mike.edwards.inglenook@gmail.com> wrote:
> ant elder wrote:
>
>>
>>
>>
>> After some digging i've found the cause. I happen to have built the new
>> implementation-spring* modules that are in the 2.x svn checkout but those
>> modules are not yet in the main build as they're still being brought up in
>> 2.x so most others and continuum wont have these built. With this change in
>> r767428 the node launcher OSGi runtime finds and uses those tuscany-spring*
>> jars because they're there in the modules/ directory hierarchy. Doing a "mvn
>> clean" in the tuscany spring modules and the problem goes away and
>> everything works fine. Is this the expected behaviour?
>>
>> ...ant
>>
>> Ant,
>
> Can you tell me more about the actual failure you're getting.
>
> I'm working on fixing the Spring modules, but it was not an expectation
> that the new code in the Equinox launcher would have worked this way when
> doing a build.
>
>
> Yours, Mike.
The actual error cause was:
Caused by: java.lang.ClassNotFoundException:
org.apache.tuscany.sca.assembly.builder.ComponentPreProcessor
at
org.eclipse.osgi.framework.internal.core.BundleLoader.findClassInternal(BundleLoader.java:481)
but I guess thats just caused by the spring modules not being finished, I
saw you committed some updates to the spring manifests last night so i've
tried again now it it works ok fine today.
What was unexpected (to me anyway at the time) was that the
node-launcher-equinox tests were failing because it was discovering a module
that i didn't even have included in the build just happened to be within the
modules/ directory, so thats the bit i was asking if that was the expected
behaviour. I'm not saying its a problem, now that i know this is whats going
on i guess it wont be unexpected if it happens again.
...ant
Re: svn commit: r767428 - in /tuscany/java/sca/modules/node-launcher-equinox/src/main/java/org/apache/tuscany/sca/node/equinox/launcher:
EquinoxHost.java NodeLauncherUtil.java
Posted by Mike Edwards <mi...@gmail.com>.
ant elder wrote:
>
>
>
> After some digging i've found the cause. I happen to have built the new
> implementation-spring* modules that are in the 2.x svn checkout but
> those modules are not yet in the main build as they're still being
> brought up in 2.x so most others and continuum wont have these built.
> With this change in r767428 the node launcher OSGi runtime finds and
> uses those tuscany-spring* jars because they're there in the modules/
> directory hierarchy. Doing a "mvn clean" in the tuscany spring modules
> and the problem goes away and everything works fine. Is this the
> expected behaviour?
>
> ...ant
>
Ant,
Can you tell me more about the actual failure you're getting.
I'm working on fixing the Spring modules, but it was not an expectation that the new code in the
Equinox launcher would have worked this way when doing a build.
Yours, Mike.
Re: svn commit: r767428 - in /tuscany/java/sca/modules/node-launcher-equinox/src/main/java/org/apache/tuscany/sca/node/equinox/launcher:
EquinoxHost.java NodeLauncherUtil.java
Posted by ant elder <an...@apache.org>.
On Thu, Apr 23, 2009 at 5:44 PM, ant elder <an...@apache.org> wrote:
>
>
> On Thu, Apr 23, 2009 at 5:20 PM, Luciano Resende <lu...@gmail.com>wrote:
>
>> On Thu, Apr 23, 2009 at 8:43 AM, ant elder <an...@gmail.com> wrote:
>> >
>> > I'm getting the build error below when building node-launcher-equinox
>> which
>> > i think is caused by this change. The continuum build is working ok so
>> it
>> > must be soemthing in my environment, anyone have any ideas on what the
>> > problem is?
>> >
>> > ...ant
>> >
>>
>> I just did an update and tried to build 2.x code with 'mvn clean
>> install' and it worked ok...
>>
>> How are you trying to build ? And from which level (full build versus
>> modules only)
>>
>>
> Just a regular mvn clean install with Sun JDK6 from top or within the
> node-launcher-equinox. Always fails with that error with r767428, works fine
> if i revert the change to EquinoxHost.java
>
> ...ant
>
>
After some digging i've found the cause. I happen to have built the new
implementation-spring* modules that are in the 2.x svn checkout but those
modules are not yet in the main build as they're still being brought up in
2.x so most others and continuum wont have these built. With this change in
r767428 the node launcher OSGi runtime finds and uses those tuscany-spring*
jars because they're there in the modules/ directory hierarchy. Doing a "mvn
clean" in the tuscany spring modules and the problem goes away and
everything works fine. Is this the expected behaviour?
...ant
Re: svn commit: r767428 - in /tuscany/java/sca/modules/node-launcher-equinox/src/main/java/org/apache/tuscany/sca/node/equinox/launcher:
EquinoxHost.java NodeLauncherUtil.java
Posted by ant elder <an...@apache.org>.
On Thu, Apr 23, 2009 at 5:20 PM, Luciano Resende <lu...@gmail.com>wrote:
> On Thu, Apr 23, 2009 at 8:43 AM, ant elder <an...@gmail.com> wrote:
> >
> > I'm getting the build error below when building node-launcher-equinox
> which
> > i think is caused by this change. The continuum build is working ok so it
> > must be soemthing in my environment, anyone have any ideas on what the
> > problem is?
> >
> > ...ant
> >
>
> I just did an update and tried to build 2.x code with 'mvn clean
> install' and it worked ok...
>
> How are you trying to build ? And from which level (full build versus
> modules only)
>
>
Just a regular mvn clean install with Sun JDK6 from top or within the
node-launcher-equinox. Always fails with that error with r767428, works fine
if i revert the change to EquinoxHost.java
...ant
Re: svn commit: r767428 - in /tuscany/java/sca/modules/node-launcher-equinox/src/main/java/org/apache/tuscany/sca/node/equinox/launcher:
EquinoxHost.java NodeLauncherUtil.java
Posted by Luciano Resende <lu...@gmail.com>.
On Thu, Apr 23, 2009 at 8:43 AM, ant elder <an...@gmail.com> wrote:
>
> I'm getting the build error below when building node-launcher-equinox which
> i think is caused by this change. The continuum build is working ok so it
> must be soemthing in my environment, anyone have any ideas on what the
> problem is?
>
> ...ant
>
I just did an update and tried to build 2.x code with 'mvn clean
install' and it worked ok...
How are you trying to build ? And from which level (full build versus
modules only)
--
Luciano Resende
Apache Tuscany, Apache PhotArk
http://people.apache.org/~lresende
http://lresende.blogspot.com/
Re: svn commit: r767428 - in /tuscany/java/sca/modules/node-launcher-equinox/src/main/java/org/apache/tuscany/sca/node/equinox/launcher:
EquinoxHost.java NodeLauncherUtil.java
Posted by ant elder <an...@gmail.com>.
On Wed, Apr 22, 2009 at 10:18 AM, <ed...@apache.org> wrote:
> Author: edwardsmj
> Date: Wed Apr 22 09:17:59 2009
> New Revision: 767428
>
> URL: http://svn.apache.org/viewvc?rev=767428&view=rev
> Log:
> Improvements to the handling of OSGi bundles when running in development
mode
>
> Modified:
>
tuscany/java/sca/modules/node-launcher-equinox/src/main/java/org/apache/tuscany/sca/node/equinox/launcher/EquinoxHost.java
>
tuscany/java/sca/modules/node-launcher-equinox/src/main/java/org/apache/tuscany/sca/node/equinox/launcher/NodeLauncherUtil.java
>
I'm getting the build error below when building node-launcher-equinox which
i think is caused by this change. The continuum build is working ok so it
must be soemthing in my environment, anyone have any ideas on what the
problem is?
...ant
<testcase time="3.625"
classname="org.apache.tuscany.sca.node.equinox.launcher.NodeLauncherTestCase"
name="testLaunch">
<error message="java.lang.reflect.InvocationTargetException"
type="org.apache.tuscany.sca.node.equinox.launcher.LauncherException">org.apache.tuscany.sca.node.equinox.launcher.LauncherException:
java.lang.reflect.InvocationTargetException
at
org.apache.tuscany.sca.node.equinox.launcher.NodeLauncherUtil.node(NodeLauncherUtil.java:181)
at
org.apache.tuscany.sca.node.equinox.launcher.NodeLauncher.createNode(NodeLauncher.java:101)
at
org.apache.tuscany.sca.node.equinox.launcher.NodeLauncherTestCase.testLaunch(NodeLauncherTestCase.java:56)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:73)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:46)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:180)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:41)
at org.junit.runners.ParentRunner$1.evaluate(ParentRunner.java:173)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31)
at org.junit.runners.ParentRunner.run(ParentRunner.java:220)
at
org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62)
at
org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:140)
at
org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:127)
at org.apache.maven.surefire.Surefire.run(Surefire.java:177)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:345)
at
org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:1009)
Caused by: java.lang.reflect.InvocationTargetException
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
at
org.apache.tuscany.sca.node.equinox.launcher.NodeLauncherUtil.node(NodeLauncherUtil.java:162)
... 30 more
Caused by: java.lang.NoClassDefFoundError:
org/apache/tuscany/sca/assembly/builder/ComponentPreProcessor
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:621)
at
org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.defineClass(DefaultClassLoader.java:165)
at
org.eclipse.osgi.baseadaptor.loader.ClasspathManager.defineClass(ClasspathManager.java:554)
at
org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findClassImpl(ClasspathManager.java:524)
at
org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClassImpl(ClasspathManager.java:455)
at
org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClass_LockClassLoader(ClasspathManager.java:443)
at
org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClass(ClasspathManager.java:423)
at
org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.findLocalClass(DefaultClassLoader.java:193)
at
org.eclipse.osgi.framework.internal.core.BundleLoader.findLocalClass(BundleLoader.java:368)
at
org.eclipse.osgi.framework.internal.core.SingleSourcePackage.loadClass(SingleSourcePackage.java:33)
at
org.eclipse.osgi.framework.internal.core.BundleLoader.findClassInternal(BundleLoader.java:432)
at
org.eclipse.osgi.framework.internal.core.BundleLoader.findClass(BundleLoader.java:397)
at
org.eclipse.osgi.framework.internal.core.BundleLoader.findClass(BundleLoader.java:385)
at
org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(DefaultClassLoader.java:87)
at java.lang.ClassLoader.loadClass(ClassLoader.java:252)
at
org.eclipse.osgi.framework.internal.core.BundleLoader.loadClass(BundleLoader.java:313)
at
org.eclipse.osgi.framework.internal.core.BundleHost.loadClass(BundleHost.java:227)
at
org.eclipse.osgi.framework.internal.core.AbstractBundle.loadClass(AbstractBundle.java:1274)
at
org.apache.tuscany.sca.extensibility.equinox.EquinoxServiceDiscoverer$ServiceDeclarationImpl.loadClass(EquinoxServiceDiscoverer.java:96)
at
org.apache.tuscany.sca.contribution.processor.DefaultStAXArtifactProcessorExtensionPoint$LazyStAXArtifactProcessor.getModelType(DefaultStAXArtifactProcessorExtensionPoint.java:404)
at
org.apache.tuscany.sca.contribution.processor.DefaultStAXArtifactProcessorExtensionPoint.addArtifactProcessor(DefaultStAXArtifactProcessorExtensionPoint.java:105)
at
org.apache.tuscany.sca.contribution.processor.DefaultStAXArtifactProcessorExtensionPoint.loadArtifactProcessors(DefaultStAXArtifactProcessorExtensionPoint.java:194)
at
org.apache.tuscany.sca.contribution.processor.DefaultStAXArtifactProcessorExtensionPoint.getProcessor(DefaultStAXArtifactProcessorExtensionPoint.java:121)
at org.apache.tuscany.sca.node.impl.NodeImpl.init(NodeImpl.java:372)
at org.apache.tuscany.sca.node.impl.NodeImpl.<init>(NodeImpl.java:240)
at
org.apache.tuscany.sca.node.impl.NodeFactoryImpl.createNode(NodeFactoryImpl.java:42)
at
org.apache.tuscany.sca.implementation.node.launcher.NodeImplementationLauncherBootstrap.<init>(NodeImplementationLauncherBootstrap.java:119)
... 35 more
Caused by: java.lang.ClassNotFoundException:
org.apache.tuscany.sca.assembly.builder.ComponentPreProcessor
at
org.eclipse.osgi.framework.internal.core.BundleLoader.findClassInternal(BundleLoader.java:481)
at
org.eclipse.osgi.framework.internal.core.BundleLoader.findClass(BundleLoader.java:397)
at
org.eclipse.osgi.framework.internal.core.BundleLoader.findClass(BundleLoader.java:385)
at
org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(DefaultClassLoader.java:87)
at java.lang.ClassLoader.loadClass(ClassLoader.java:252)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:320)
... 63 more
</error>