On Sun, May 10, 2009 at 11:24 AM, Mike Edwards <
[email protected]> wrote:

> 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
>

This is not specific to node-impl2 and its come up before -
http://apache.markmail.org/message/jflhtsrgwx7w4uy5

It seems like a design flaw in how node-launcher-equinox works. It doesn't
seem right that when its being run from in the maven build it just uses
anything it happens to find in the directory above where it is. If it wants
to work as part or the maven build then it needs to use the modules that are
part of that build, anything else is inevitably going to cause this type of
confusion. Working the way it is now its also including jars that are in the
build but not built until after node-launcher-equinox, so when the tests run
its testing what the previous build run did not what the current build run
is creating.

One easy way to fix this may be to remove this way of working from the
node-launcher-equinox module and move it to in the distribution itests so
its testing what we actually intend to part of the build.

As an FYI to anyone trying to understand whats doing this see
NodeLauncherUtil.runtimeClasspathEntries in the node-launcher-equinox
module.

   ...ant

Reply via email to