On Sun, May 10, 2009 at 9:40 PM, Raymond Feng <[email protected]> wrote: > node-impl2 has conflicts with node-impl from the OSGi perspective because > both of them export "overlapping" packages. In Eclipse, all the PDE projects > in the workspace contributes to the OSGi bundle resolution (requiredPlugins > classpath container). This is so called "split packages" in OSGi and that's > probably root cause of the problem. You should either load node-impl or > node-impl2 but not both in your workspace. We should remove node-impl2 from > the main buid if it is there to avoid further confusions. > > Thanks, > Raymond > -------------------------------------------------- > From: "Mike Edwards" <[email protected]> > Sent: Sunday, May 10, 2009 3:24 AM > To: "tuscany-dev" <[email protected]> > Subject: ** WARNING ** node-impl2 can cause hard to diagnose errors with > OSGi > >> Folks, >> >> A warning - after I chased my tail for a day with a bug that was very hard >> to pin down. >> >> Turned up running NodeLauncherTestCase in node-launcher-equinox after I >> had made a change in a completely different module - Assembly. >> >> What I started getting were NoClassDefFound errors for ContributionScanner >> when trying to load the ContributionContentProcessor from NodeImpl in the >> startup phase. The worst aspect was that these errors were intermittent - >> they happened often, but not every time - and trying to use the debugger in >> Eclipse usually made the code work - but not always. >> >> Eventually, I managed to get the ClassLoader code to stop at the point >> where it was throwing the exception and discovered to my surprise that the >> Bundle doing the loading was not node-impl but rather node-impl2. Removing >> the node-impl2 module from my system solved the problem. >> >> Now, node-impl2 isn't part of the mainline build so you'd expect it not to >> get used. And in general this is true. However, the class loading under >> OSGi is different - and if node-impl2 is there in your modules directory, it >> is fair game for loading under OSGi for some configurations. And for >> whatever reason, it screws up the classloading. >> >> >> Yours, Mike > >
Would someone be able to articulate what different behaviours are now in place for loading the correct modules in order to run SCA contributions in the various different environments we support, e.g. command line, Eclipse dev, Eclipse plugin, mvn, ant, webapp, embedded. This was a topic of much discussion some months ago when we debated the merits of various different launcher approaches. Where are we now? Yes, I could look at the code but if someone happens to know it would save some time. I'd like to get a launcher page up to date, e.g. [1], for how we expect people to use the runtime. Simon [1] http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Tuscany+Runtime+Launching
