ant elder wrote:
On Sun, May 10, 2009 at 11:24 AM, Mike Edwards
<[email protected]
<mailto:[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
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.
