issues with 1) forking surefire and 2) Surefire's IsolatedClassloader class

[Andy Glick <an...@acm.org>]

I've been working on adding forking to the surefire plugin, really into the 
surefire package, in order to allow clover to work and to allow our 
implementation to offer features similar to those provided by the JUnit Ant 
task

I've run into a number of problems:

1) on windows using both plexus.util.cli and runtime.exec I haven't been 
able to construct classpaths containing embedded spaces - my repo is 
located at c:\documents and settings\user\.m2\repository and so the 1st 
reference to a jar in the repo is causing the exec to fail - it doesn't 
matter if i wrap the classpath specification in double quotes or not

does anybody have any experience setting classpath as an environment 
variable on runtime.exec()? if that would work it might  be a work around 
for setting classpath in the args list in CommandLine or runtime.exec()

2) the Surefire class uses a custom classLoader IsolatedClassLoader, which 
lives in the surefire-booter subproject, In the method instantiateReports 
the interface org.codehaus.surefire.report.Reporter is used as a cast for 
the concrete implementation classes which implement the Reporter interface. 
They are explicitly loaded with the custom classloader and the cast is 
causing a ClassCastException because the Reporter class is declared in the 
Surefire class and it is being loaded by the application class loader. 
Since the classes are loaded by different ClassLoaders they are not 
related. This strange behavior is a function of Java's class loading 
strategy which actually creates sets of namespaces which are distinguished 
by class/classloader pairs.

Given the previous explanation, does the following seem workable?  Using 
the classes ThreadedExecutor, ThreadFactory, FutureResult and Callable from 
Doug Lea's concurrency package construct a mechanism for Surefire so that 
it can run in a thread whose contextClassLoader is an IsolatedClassLoader 
and which can produce a result object or throw an exception.

I'd appreciate feedback.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: issues with 1) forking surefire and 2) Surefire's IsolatedClassloader class

[Kenney Westerhof <ke...@apache.org>]

On Sat, 1 Oct 2005, Andy Glick wrote:

Hi Andy,

> I've been working on adding forking to the surefire plugin, really into the
> surefire package, in order to allow clover to work and to allow our
> implementation to offer features similar to those provided by the JUnit Ant
> task
>
> I've run into a number of problems:
>
> 1) on windows using both plexus.util.cli and runtime.exec I haven't been
> able to construct classpaths containing embedded spaces - my repo is
> located at c:\documents and settings\user\.m2\repository and so the 1st
> reference to a jar in the repo is causing the exec to fail - it doesn't
> matter if i wrap the classpath specification in double quotes or not
>
> does anybody have any experience setting classpath as an environment
> variable on runtime.exec()? if that would work it might  be a work around
> for setting classpath in the args list in CommandLine or runtime.exec()

The CommandLine should be fixed; can you file a JIRA?

How do you call runtime.exec? Afaik it should support separate arguments
which should be escaped properly. If not, that's a bug in the JDK. Maybe
you can escape the characters like "\"C:\Documents and Settings\...\"" ?

> 2) the Surefire class uses a custom classLoader IsolatedClassLoader, which
> lives in the surefire-booter subproject, In the method instantiateReports
> the interface org.codehaus.surefire.report.Reporter is used as a cast for
> the concrete implementation classes which implement the Reporter interface.
> They are explicitly loaded with the custom classloader and the cast is
> causing a ClassCastException because the Reporter class is declared in the
> Surefire class and it is being loaded by the application class loader.
> Since the classes are loaded by different ClassLoaders they are not
> related. This strange behavior is a function of Java's class loading
> strategy which actually creates sets of namespaces which are distinguished
> by class/classloader pairs.
>
> Given the previous explanation, does the following seem workable?  Using
> the classes ThreadedExecutor, ThreadFactory, FutureResult and Callable from
> Doug Lea's concurrency package construct a mechanism for Surefire so that
> it can run in a thread whose contextClassLoader is an IsolatedClassLoader
> and which can produce a result object or throw an exception.

Not sure if a workaround like this is needed - I'm not sure what you're
talking about, really :) Classworlds should be able to deal with this.

Can you file a JIRA and attach a test project that fails? Maybe we can
work something out in surefire itself, or perhaps maven2.
Did this bug occur after the fixes in maven-core that set the
contextClassloader correctly?

-- Kenney

> I'd appreciate feedback.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>

--
Kenney Westerhof
http://www.neonics.com
GPG public key: http://www.gods.nl/~forge/kenneyw.key

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org