You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Kristian Rosenvold <kr...@gmail.com> on 2013/04/08 20:13:33 UTC
Simplifying surefire classloader stucture.....
Surefire currently uses this classloader architecture :
Boot<----System<-----Test<----<Provider
The "idea" is that while the test is executing, the "Test" classloader
is active, while the "provider" classloader hides all the provider
implementation details so they are invisible when the tests are run
(but provider is active before and after the test run).
The thing is that the surefire providers have over time become very
aggressive users of the maven-shade-plugin, which means that we
relocate everything
of importance to private class name spaces. This must be done no
matter what since the Provider cannot load a class that will be later
required when running the test.
Hence I'm contemplating just putting everything on the "system"
classloader when forking in surefire and just dropping the two extra
classloaders; I personally don't understand how that could change
anything ? (surefire does not claim to be a root-kit in the sense that
surefire is "undetectable"). It would also make the classpath of the
forked jvm more or less totally realistic and correct (apart from the
actual provider jar which would have to be there, unless we use
something like (the nonstandard) -Xbootclasspath to add the provider
to the boot classpath to make the system class path 100% correct)
So tell me, what would this break ? :)
(And yes, we have bugs and features related to this classloader
separation that would definitely make such a simplification
worthwhile. It´s actually a huge simplification)
Kristian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Simplifying surefire classloader stucture.....
Posted by Andreas Gudian <an...@gmail.com>.
I'd love to see this happening. We would be a big step closer to allow more
user-defined providers or extensions, which could easily be added as
plugin-dependencies, without having to worry too much on when to load what.
2013/4/8 Brett Porter <br...@apache.org>
> I looked at something similar some time back and struggled with it - but
> that was pre-shading of providers and still having to deal with the forking
> to the old booter. I suspect the combination of both will make this more
> feasible, but it's long enough ago that I can't remember anything more
> specific. Good luck :)
>
> - Brett
>
> On 08/04/2013, at 2:13 PM, Kristian Rosenvold <
> kristian.rosenvold@gmail.com> wrote:
>
> > Surefire currently uses this classloader architecture :
> >
> > Boot<----System<-----Test<----<Provider
> >
> > The "idea" is that while the test is executing, the "Test" classloader
> > is active, while the "provider" classloader hides all the provider
> > implementation details so they are invisible when the tests are run
> > (but provider is active before and after the test run).
> >
> > The thing is that the surefire providers have over time become very
> > aggressive users of the maven-shade-plugin, which means that we
> > relocate everything
> > of importance to private class name spaces. This must be done no
> > matter what since the Provider cannot load a class that will be later
> > required when running the test.
> >
> > Hence I'm contemplating just putting everything on the "system"
> > classloader when forking in surefire and just dropping the two extra
> > classloaders; I personally don't understand how that could change
> > anything ? (surefire does not claim to be a root-kit in the sense that
> > surefire is "undetectable"). It would also make the classpath of the
> > forked jvm more or less totally realistic and correct (apart from the
> > actual provider jar which would have to be there, unless we use
> > something like (the nonstandard) -Xbootclasspath to add the provider
> > to the boot classpath to make the system class path 100% correct)
> >
> > So tell me, what would this break ? :)
> >
> > (And yes, we have bugs and features related to this classloader
> > separation that would definitely make such a simplification
> > worthwhile. It´s actually a huge simplification)
> >
> > Kristian
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
>
> --
> Brett Porter
> brett@apache.org
> http://brettporter.wordpress.com/
> http://au.linkedin.com/in/brettporter
> http://twitter.com/brettporter
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Simplifying surefire classloader stucture.....
Posted by Brett Porter <br...@apache.org>.
I looked at something similar some time back and struggled with it - but that was pre-shading of providers and still having to deal with the forking to the old booter. I suspect the combination of both will make this more feasible, but it's long enough ago that I can't remember anything more specific. Good luck :)
- Brett
On 08/04/2013, at 2:13 PM, Kristian Rosenvold <kr...@gmail.com> wrote:
> Surefire currently uses this classloader architecture :
>
> Boot<----System<-----Test<----<Provider
>
> The "idea" is that while the test is executing, the "Test" classloader
> is active, while the "provider" classloader hides all the provider
> implementation details so they are invisible when the tests are run
> (but provider is active before and after the test run).
>
> The thing is that the surefire providers have over time become very
> aggressive users of the maven-shade-plugin, which means that we
> relocate everything
> of importance to private class name spaces. This must be done no
> matter what since the Provider cannot load a class that will be later
> required when running the test.
>
> Hence I'm contemplating just putting everything on the "system"
> classloader when forking in surefire and just dropping the two extra
> classloaders; I personally don't understand how that could change
> anything ? (surefire does not claim to be a root-kit in the sense that
> surefire is "undetectable"). It would also make the classpath of the
> forked jvm more or less totally realistic and correct (apart from the
> actual provider jar which would have to be there, unless we use
> something like (the nonstandard) -Xbootclasspath to add the provider
> to the boot classpath to make the system class path 100% correct)
>
> So tell me, what would this break ? :)
>
> (And yes, we have bugs and features related to this classloader
> separation that would definitely make such a simplification
> worthwhile. It´s actually a huge simplification)
>
> Kristian
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
--
Brett Porter
brett@apache.org
http://brettporter.wordpress.com/
http://au.linkedin.com/in/brettporter
http://twitter.com/brettporter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Simplifying surefire classloader stucture.....
Posted by Kristian Rosenvold <kr...@gmail.com>.
2013/4/8 John Casey <jd...@commonjava.org>:
> On 4/8/13 1:13 PM, Kristian Rosenvold wrote:
>> Surefire currently uses this classloader architecture :
>>
>> Boot<----System<-----Test<----<Provider
> Would this cause any problems with testing surefire itself?
Nope. Currently surefire shades /everything/ in the junit3 provider to
a different location to test itself.
> What about those
> things surefire depends on at runtime, if there are any (I don't remember
> off the top of my head)...
That's m-s-u and a couple of other things. All dependencies are
effectively shaded already.
The thing about the current design is that when the provider
classloader is active
before the test is being run, we can *never* load anything that can appear in
the test classloader since we could potentially load different versions.
So it all has to be shaded anyway, which IMO just shows that the current
classloader structure looks good on paper but is useless IRL.
>
> The point being that anything in the classpath to support surefire's
> execution might conflict with something in the classpath to support the test
> case itself. This is one reason shading makes a lot of sense IMO, and
> probably the classloader structure too.
Well with the new classloader structure we'd have a jar full of
surefire classes swimming
in the same classloader as the actual tests (or use endorsed jars to
put surefire
in the boot loader to get 100% correct system class path)
(the surefire jar would have everything shaded away somewhere deep
below org.apache.maven.surefire.shade -
much like today)
>
> Having said that, I'd love to see things simplified, so hopefully I'm full
> of crap on all this. ;-)
i think this is one of those areas where this mailing list has a lot of
knowledge, so discussing it is a Good Thing :)
Kristian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Simplifying surefire classloader stucture.....
Posted by John Casey <jd...@commonjava.org>.
On 4/8/13 1:13 PM, Kristian Rosenvold wrote:
> Surefire currently uses this classloader architecture :
>
> Boot<----System<-----Test<----<Provider
>
> The "idea" is that while the test is executing, the "Test" classloader
> is active, while the "provider" classloader hides all the provider
> implementation details so they are invisible when the tests are run
> (but provider is active before and after the test run).
>
> The thing is that the surefire providers have over time become very
> aggressive users of the maven-shade-plugin, which means that we
> relocate everything
> of importance to private class name spaces. This must be done no
> matter what since the Provider cannot load a class that will be later
> required when running the test.
>
> Hence I'm contemplating just putting everything on the "system"
> classloader when forking in surefire and just dropping the two extra
> classloaders; I personally don't understand how that could change
> anything ? (surefire does not claim to be a root-kit in the sense that
> surefire is "undetectable"). It would also make the classpath of the
> forked jvm more or less totally realistic and correct (apart from the
> actual provider jar which would have to be there, unless we use
> something like (the nonstandard) -Xbootclasspath to add the provider
> to the boot classpath to make the system class path 100% correct)
>
> So tell me, what would this break ? :)
Would this cause any problems with testing surefire itself? What about
those things surefire depends on at runtime, if there are any (I don't
remember off the top of my head)...
The point being that anything in the classpath to support surefire's
execution might conflict with something in the classpath to support the
test case itself. This is one reason shading makes a lot of sense IMO,
and probably the classloader structure too.
Having said that, I'd love to see things simplified, so hopefully I'm
full of crap on all this. ;-)
>
> (And yes, we have bugs and features related to this classloader
> separation that would definitely make such a simplification
> worthwhile. It´s actually a huge simplification)
>
> Kristian
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
--
John Casey
Developer, PMC Member - Apache Maven (http://maven.apache.org)
GitHub - http://github.com/jdcasey
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org