after extensive analysis I come to the concllusion that.. it really is jaxen which is the evil one here. RootLoader does not follow completely the constrains that a classloader should follow and because of that not all things are working that would work when using only normal classloaders. As far as I can tell jaxen includes the UserDataHandler for compatibility with 1.4, in java5 jaxen duplicates this class. As long as the same loader which is loading the xml stuff is also loading the jaxen.jar, there is no problem. But in our case RootLoader loads the jaxen jar and the system loader loads the xml stuff. Because of the special construction of the RootLoader we get the problem above... As a result the jaxen classes will use the jaxen UserDataHandler and the XML classes in rt.jar will use the UserDataHandler class from rt.jar. And that is not working.
I see several possible workarounds, but they all don't sound very good...
one would be to enforce the loading of UserDataHandler through the system loader. For this RootLoader would have to not to include the jaxen.jar yet, and gets it added later. That's something a gant script could do.
Another way would be to remove the UserDataHandler class from the jaxen.jar. You could still have it loaded for java1.4 when you say you set a property "java.v4.compatibility.path" for example and a line like this to the conf file:
of course that means, that this should be in a directory that is normally not loaded. This directory would then for example contain a jar with the UserDataHandler class, while the normal jaxen.jar (without that class) would be in the standard lib directory.
And the last way would be to not to add jaxen.jar to the paths RootLoader handles, but to add jaxen.jar to the classpath the system classloader gets. Of course any xml stuff would have to be in this classpath as well.
And the last workaround would be to define a custom system classloader, by setting java.system.class.loader. That ClassLoader would have to extend RootLoader and would need to configure itself. Such a loader could prefer the classes in the conf file.. but for this the startup process of Groovy would need adaption. So it is no solution you can do quickly