geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jacek Laskowski" <>
Subject [M2] Failing *one* test in the kernel module
Date Mon, 20 Feb 2006 10:32:59 GMT

Over the weekend I tried to convert a module to execute M2 from within
M1, i.e. usig the concept of exec'ing M2 in maven.xml. It works fine,
but there's one caveat (well, there might be more than one, but that's
the most irritating).

In revision 379071 I've just committed, you can execute M2 commands
over a single module. This is done using the M2 concept of profiles
where you can tweak how the commands are executed, etc. This is
defined in the main pom.xml in the root of Geronimo's sources.
Whenever you run any M2 command from within the root of the sources
with the module property set, the singlemodule profile is activated
and only the module pointed out by the property is taken into account.
Without the property all modules are processed. As an example run:

  mvn -Dmodule=kernel test

That's the command that took my whole weekend away and I'm still stuck
with no idea how to work it out :( It seems that I chose one of the
worst modules to convert (as it was with the class I used in my tests
right after Dave wiped it out ;)).

Before I leave it out and move on to another module, I'll describe
what I found out so far wrt the failing
org.apache.geronimo.gbean.GBeanNameTest test of the kernel module.

Here's the snippet of the test report:

$ more modules/kernel/target/surefire-reports/org.apache.geronimo.gbean.GBeanNameTest.txt
... no protocol: and
        at sun.rmi.server.LoaderHandler.pathToURLs(
        at sun.rmi.server.LoaderHandler.loadClass(
        at java.rmi.server.RMIClassLoader$2.loadClass(
        at java.rmi.server.RMIClassLoader.loadClass(
        at sun.rmi.server.MarshalInputStream.resolveClass(
        at java.rmi.MarshalledObject.get(
        at org.apache.geronimo.gbean.GBeanNameTest.testSerialization(

Chances are it won't happen on operating systems (MacOS, *nix) that
their user home directories, thus Maven repo, have on paths without
spaces. That's where the 'and' comes from - on Windows it's
c:/Documents and Settings/account/.m2.

The question is why it fails on M2, but M1 works fine. It is because
the test machinery changed a little in M2 and now surefire is used. I
think it's a brand new test solution in Maven2, but it might be that
it's based on M1 test plugin somehow. Anyway, the following commands
let you step over and see yourself what's going on behind the scenes.

For Maven2 (run it off the top directory):

-Xrunjdwp:transport=dt_socket,server=y,address=8000" mvn -o
-Dmodule=kernel clean test

For Maven1 (run it off the module/kernel directory):

-Xrunjdwp:transport=dt_socket,server=y,address=8000" maven -o clean

According to,
during the serialization (MarshalledObject.get) an object is annotated
with information that's necessary for deserialization. Upon closer
look, during debugging session, I've noticed that
java.rmi.server.RMIClassLoader is provided with the value of null for
codebase parameter in Maven1 while codebase is set to the entire test
classpath in M2. Since it contains entires separated with spaces, any
directory with spaces is divided inappropriately leading to the above

Is there anyone who could lend me a hand and sort it out? Should I
find for help in the user@maven mailing list? Brett, Jason, Vincent -
could you help with it?

Jacek (utterly frustrated by not achieving at least a partial success
with M2 after the *whole* weekend)

Jacek Laskowski

View raw message