You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by ant elder <an...@gmail.com> on 2009/04/23 17:43:33 UTC
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
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>
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/