Re: ** WARNING ** node-impl2 can cause hard to diagnose errors with OSGi

[ant elder <an...@gmail.com>]

On Sun, May 10, 2009 at 11:24 AM, Mike Edwards <
mike.edwards.inglenook@gmail.com> 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

Re: ** WARNING ** node-impl2 can cause hard to diagnose errors with OSGi

[Mike Edwards <mi...@gmail.com>]

ant elder wrote:
> 
> 
> On Sun, May 10, 2009 at 11:24 AM, Mike Edwards 
> <mike.edwards.inglenook@gmail.com 
> <ma...@gmail.com>> 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
> 
Ant,

It's going to be a bit more involved than that.

There is also the running of OSGi stuff when in development mode under Eclipse.  Then it DOES seem 
to make sense to use the materials in the target\classes directories, since you want the code to 
pick up what you're working on without the need for a full build.  This is what happens today and 
for me, it works well.

But THEN - you will have to remember to remove node-impl2 from your installation (which I what I 
ended up doing), since you get it if you do a full checkout.  Having to remember something like this 
is tedious.

Yours,  Mike.