Hi Simon,

Catching up on mail to this list. The assessment for the isolated classloader sounds correct, so a patch would be good. I think the bootstrap classloader needs to be changed to be the same as the surefire one, as its the latter that has evolved. I'm not sure the bootstrap even needs it, to be honest.

While this all sounds useful, I'd suggest its still a workaround. There should be a better way to get things into the system/bootclassloader (which would also require that you use the fork directive), and I think that feature request is open on surefire already.

- Brett

On 1/08/2006 5:16 PM, Simon Kitching wrote:
Hi,

The IsolatedClassLoader class in the surefire module has the following
line of code:

    private ClassLoader parent = ClassLoader.getSystemClassLoader();

I believe this is causing a recursive loop when I try to explicitly use
this class as the system classloader. Its only purpose is a very minor
optimisation in the loadClass method, so I was hoping this could be
removed, and replaced with a call to getParent() in the loadClass method
instead.


Why am I trying to use this class as the system classloader? Well, I
have tests that need to load a few classes explicitly via the system
classloader rather than the one that surefire sets up. In my case, it's
because java.util.logging.LogManager *requires* that LogHandler classes
be loaded from the system classpath. There might be other situations
where this kind of thing is necessary (though it's never going to be
common).

In order to force a class to be loaded in the system classloader, I want
to ensure the system classloader is one that has an addURL method so the
test can itself add classes into the system classloader. As it happens,
org.apache.maven.surefire.booter.IsolatedClassLoader provides exactly
that method.

Forcing the system classloader can be done with:
<argLine>
-Djava.system.class.loader=org.apache.maven.surefire.booter.IsolatedClassLoader
</argLine>

Unfortunately, however, the member declaration shown above attempts to
fetch the system classloader while the VM is trying to install that same
instance as the system classloader, thus causing the recursive loop.

This member is really rather odd anyway; there are two constructors that
take a parent reference as a parameter, but the existing code completely
ignores this and always uses the system classloader as the parent
regardless of the constructor params. This is currently harmless as
surefire is the only user of this class, and it always does pass the
system classloader as the constructor parameter. Still not elegant
though. And the member is not declared final, but is never assigned to
except in its initializer expression.

If people are ok with this, I will provide a patch to remove this member
and just call getParent() inline.

By the way, there is another class
org.apache.maven.bootstrap.util.IsolatedClassLoader that is almost but
not quite identical (doesn't support the child-first parameter). For
some reason this class keeps a parent reference internally, and does NOT
propagate the parent parameter in the constructor to the superclass.
This means that all inherited methods think an instance is a child of
the system classloader regardless of the parent parameter to the
classloader, while overloaded methods that do use the local parent
reference behave differently. Maybe there is a reason for that, but it
looks odd to me.


BTW, I've looked into other ways to tackle the problem of configuring
custom java.util.logging.Handler classes. However surefire just doesn't
support loading the test classes via anything other than the special
IsolatedClassLoader instance it creates.

Regards,


Simon


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



--
Apache Maven - http://maven.apache.org/
Better Builds with Maven - http://library.mergere.com/

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to