You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Romain Manni-Bucau <rm...@gmail.com> on 2014/02/18 10:21:34 UTC
new classloader parent?
Hello
seems now parent classloader used to avoid to overwrite classes is
j2seClassLoader which is extclassloader by default. This totally
breaks tomee and i guess other apps since classes which were not
overwritten in standalone (new Tomcat) are now overwritten by webapp
classloader.
Is it intended?
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: new classloader parent?
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Thanks in all case, think we can close the debate now ;)
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau
2014-02-18 17:18 GMT+01:00 Mark Thomas <ma...@apache.org>:
> On 18/02/2014 16:06, Romain Manni-Bucau wrote:
>> 2014-02-18 17:01 GMT+01:00 Mark Thomas <ma...@apache.org>:
>>> On 18/02/2014 13:05, Romain Manni-Bucau wrote:
>>>> 2014-02-18 12:09 GMT+01:00 Mark Thomas <ma...@apache.org>:
>>>
>>> <snip/>
>>>
>>>>> We can certainly make that easier. Making it non-final, using an
>>>>> over-ridable protected getter(), adding protected getter and setter etc.
>>>>> Does TomEE have a preference?
>>>>>
>>>>
>>>> not really while we can change it, we were used to protected field but
>>>> protected getter would be nice too.
>>>
>>> What do you think of
>>> http://svn.apache.org/r1569398
>>>
>>> If that is OK, I'll back-port it to 7.0.x with the one change that
>>> j2seClassLoader will be a protected rather than private field in 7.0.x.
>>>
>>
>>
>> Would be enough, thanks Mark.
>>
>> Just few notes:
>> 1) i think the behavior should be configurable even for tomcat (= use
>> system classloader)
>
> I disagree. There is a clearly defined set of classes that the web
> application should not be able to override and classes loaded by the
> system class loader are not included. I don't mind making things easier
> for TomEE but I'm not yet convinced of the need to go further.
>
>> 2) in the constructor maybe replace the init by a protected method or
>> a constructor parameter (new constructor WebappClassLoader(parent,
>> j2seClassLoader)?)
>
> I thought about that but:
> - I'd prefer to avoid having a constructor call a protected method
> - I prefer (having seen the other extreme in Commons) fewer constructors.
>
> I'll get that commit back-ported to 7.0.x.
>
> Mark
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: new classloader parent?
Posted by Mark Thomas <ma...@apache.org>.
On 18/02/2014 16:06, Romain Manni-Bucau wrote:
> 2014-02-18 17:01 GMT+01:00 Mark Thomas <ma...@apache.org>:
>> On 18/02/2014 13:05, Romain Manni-Bucau wrote:
>>> 2014-02-18 12:09 GMT+01:00 Mark Thomas <ma...@apache.org>:
>>
>> <snip/>
>>
>>>> We can certainly make that easier. Making it non-final, using an
>>>> over-ridable protected getter(), adding protected getter and setter etc.
>>>> Does TomEE have a preference?
>>>>
>>>
>>> not really while we can change it, we were used to protected field but
>>> protected getter would be nice too.
>>
>> What do you think of
>> http://svn.apache.org/r1569398
>>
>> If that is OK, I'll back-port it to 7.0.x with the one change that
>> j2seClassLoader will be a protected rather than private field in 7.0.x.
>>
>
>
> Would be enough, thanks Mark.
>
> Just few notes:
> 1) i think the behavior should be configurable even for tomcat (= use
> system classloader)
I disagree. There is a clearly defined set of classes that the web
application should not be able to override and classes loaded by the
system class loader are not included. I don't mind making things easier
for TomEE but I'm not yet convinced of the need to go further.
> 2) in the constructor maybe replace the init by a protected method or
> a constructor parameter (new constructor WebappClassLoader(parent,
> j2seClassLoader)?)
I thought about that but:
- I'd prefer to avoid having a constructor call a protected method
- I prefer (having seen the other extreme in Commons) fewer constructors.
I'll get that commit back-ported to 7.0.x.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: new classloader parent?
Posted by Romain Manni-Bucau <rm...@gmail.com>.
2014-02-18 17:01 GMT+01:00 Mark Thomas <ma...@apache.org>:
> On 18/02/2014 13:05, Romain Manni-Bucau wrote:
>> 2014-02-18 12:09 GMT+01:00 Mark Thomas <ma...@apache.org>:
>
> <snip/>
>
>>> We can certainly make that easier. Making it non-final, using an
>>> over-ridable protected getter(), adding protected getter and setter etc.
>>> Does TomEE have a preference?
>>>
>>
>> not really while we can change it, we were used to protected field but
>> protected getter would be nice too.
>
> What do you think of
> http://svn.apache.org/r1569398
>
> If that is OK, I'll back-port it to 7.0.x with the one change that
> j2seClassLoader will be a protected rather than private field in 7.0.x.
>
Would be enough, thanks Mark.
Just few notes:
1) i think the behavior should be configurable even for tomcat (= use
system classloader)
2) in the constructor maybe replace the init by a protected method or
a constructor parameter (new constructor WebappClassLoader(parent,
j2seClassLoader)?)
> Mark
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: new classloader parent?
Posted by Romain Manni-Bucau <rm...@gmail.com>.
2014-02-18 18:49 GMT+01:00 Konstantin Kolinko <kn...@gmail.com>:
> 2014-02-18 20:01 GMT+04:00 Mark Thomas <ma...@apache.org>:
>> On 18/02/2014 13:05, Romain Manni-Bucau wrote:
>>> 2014-02-18 12:09 GMT+01:00 Mark Thomas <ma...@apache.org>:
>>
>> <snip/>
>>
>>>> We can certainly make that easier. Making it non-final, using an
>>>> over-ridable protected getter(), adding protected getter and setter etc.
>>>> Does TomEE have a preference?
>>>>
>>>
>>> not really while we can change it, we were used to protected field but
>>> protected getter would be nice too.
>>
>> What do you think of
>> http://svn.apache.org/r1569398
>>
>> If that is OK, I'll back-port it to 7.0.x with the one change that
>> j2seClassLoader will be a protected rather than private field in 7.0.x.
>
> By the way, "j2se" is called "JavaSE" nowadays, starting with Java 5.
>
same for jee/j2ee and JavaEE. Think I saw some j2ee in tomcat jndi part IIRC.
> Best regards,
> Konstantin Kolinko
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: new classloader parent?
Posted by Konstantin Kolinko <kn...@gmail.com>.
2014-02-18 20:01 GMT+04:00 Mark Thomas <ma...@apache.org>:
> On 18/02/2014 13:05, Romain Manni-Bucau wrote:
>> 2014-02-18 12:09 GMT+01:00 Mark Thomas <ma...@apache.org>:
>
> <snip/>
>
>>> We can certainly make that easier. Making it non-final, using an
>>> over-ridable protected getter(), adding protected getter and setter etc.
>>> Does TomEE have a preference?
>>>
>>
>> not really while we can change it, we were used to protected field but
>> protected getter would be nice too.
>
> What do you think of
> http://svn.apache.org/r1569398
>
> If that is OK, I'll back-port it to 7.0.x with the one change that
> j2seClassLoader will be a protected rather than private field in 7.0.x.
By the way, "j2se" is called "JavaSE" nowadays, starting with Java 5.
Best regards,
Konstantin Kolinko
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: new classloader parent?
Posted by Mark Thomas <ma...@apache.org>.
On 18/02/2014 13:05, Romain Manni-Bucau wrote:
> 2014-02-18 12:09 GMT+01:00 Mark Thomas <ma...@apache.org>:
<snip/>
>> We can certainly make that easier. Making it non-final, using an
>> over-ridable protected getter(), adding protected getter and setter etc.
>> Does TomEE have a preference?
>>
>
> not really while we can change it, we were used to protected field but
> protected getter would be nice too.
What do you think of
http://svn.apache.org/r1569398
If that is OK, I'll back-port it to 7.0.x with the one change that
j2seClassLoader will be a protected rather than private field in 7.0.x.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: new classloader parent?
Posted by Romain Manni-Bucau <rm...@gmail.com>.
2014-02-18 12:09 GMT+01:00 Mark Thomas <ma...@apache.org>:
> On 18/02/2014 10:50, Romain Manni-Bucau wrote:
>> 2014-02-18 11:44 GMT+01:00 Mark Thomas <ma...@apache.org>:
>>> On 18/02/2014 10:14, Romain Manni-Bucau wrote:
>
> <snip/>
>
>>>> It was working fine before and it was convenient. By default you don't
>>>> add jars in tomcat system loader so the behavior of tomcat was fine +
>>>> in unit test of embedded mode it was convenient so I dont get the
>>>> point changing it.
>>>
>>> The point of changing it was:
>>>
>>> - fixing the reported bug
>>> - have the actual behaviour align with the documented / spec required
>>> behaviour
>>>
>>> There was nothing in either the spec or the docs that required Tomcat to
>>> prevent web applications overridding a class on the system class path.
>>>
>>
>> Nothing forces it to be done so IMO it should be configurable and not
>> the default behavior for backward compatibility (spoken of v7).
>
> That is a fair point about making it configurable for Tomcat 7. It is
> likely that making it configurable for 8 would be useful to.
>
>>> Switching to using the endorsed dir looks like the simplest solution to
>>> me and it should work for Tomcat versions before and after the BZ 55943
>>> change.
>>>
>>> Other possible solutions include:
>>> - removing the final from j2seClassLoader / always accessing it via an
>>> over-ridable getter() (I'd recommend checking that that will work for
>>> you as the other related changes may also cause problems)
>>
>>
>> I set by reflection j2seClassLoader it solved this particular issue.
>
> We can certainly make that easier. Making it non-final, using an
> over-ridable protected getter(), adding protected getter and setter etc.
> Does TomEE have a preference?
>
not really while we can change it, we were used to protected field but
protected getter would be nice too.
>>> - making it possible to add to the packages used to define the filter
>>> for container classes
>>
>> Not enough since user classes should get this bahavior too in embedded
>> case (I don't say that's good but common, convenient and done so we
>> need to leave with it).
>
> That I disagree with. Just because Tomcat is being used in embedded
> mode, that is no reason to ignore the direction of the Servlet spec on
> the topic of class loading priority.
>
Not really, if you put a class in jvm loader you don't want it to be
overrided by a webapp in general (saw it often for technical libs)
even if the lib is in the webapps so since servlet spec is not clear
on it it should just be a config. The other point I'm not sure (sorry
didnt get time to test) is doesn't it break javaagent which add libs
to system classloader and not bootstrap for classloader constraints?
> Mark
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: new classloader parent?
Posted by Mark Thomas <ma...@apache.org>.
On 18/02/2014 10:50, Romain Manni-Bucau wrote:
> 2014-02-18 11:44 GMT+01:00 Mark Thomas <ma...@apache.org>:
>> On 18/02/2014 10:14, Romain Manni-Bucau wrote:
<snip/>
>>> It was working fine before and it was convenient. By default you don't
>>> add jars in tomcat system loader so the behavior of tomcat was fine +
>>> in unit test of embedded mode it was convenient so I dont get the
>>> point changing it.
>>
>> The point of changing it was:
>>
>> - fixing the reported bug
>> - have the actual behaviour align with the documented / spec required
>> behaviour
>>
>> There was nothing in either the spec or the docs that required Tomcat to
>> prevent web applications overridding a class on the system class path.
>>
>
> Nothing forces it to be done so IMO it should be configurable and not
> the default behavior for backward compatibility (spoken of v7).
That is a fair point about making it configurable for Tomcat 7. It is
likely that making it configurable for 8 would be useful to.
>> Switching to using the endorsed dir looks like the simplest solution to
>> me and it should work for Tomcat versions before and after the BZ 55943
>> change.
>>
>> Other possible solutions include:
>> - removing the final from j2seClassLoader / always accessing it via an
>> over-ridable getter() (I'd recommend checking that that will work for
>> you as the other related changes may also cause problems)
>
>
> I set by reflection j2seClassLoader it solved this particular issue.
We can certainly make that easier. Making it non-final, using an
over-ridable protected getter(), adding protected getter and setter etc.
Does TomEE have a preference?
>> - making it possible to add to the packages used to define the filter
>> for container classes
>
> Not enough since user classes should get this bahavior too in embedded
> case (I don't say that's good but common, convenient and done so we
> need to leave with it).
That I disagree with. Just because Tomcat is being used in embedded
mode, that is no reason to ignore the direction of the Servlet spec on
the topic of class loading priority.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: new classloader parent?
Posted by Romain Manni-Bucau <rm...@gmail.com>.
2014-02-18 11:44 GMT+01:00 Mark Thomas <ma...@apache.org>:
> Again, please stop top posting.
>
> On 18/02/2014 10:14, Romain Manni-Bucau wrote:
>> let say we have an interface Foo. I deploy a war with Foo and FooImpl.
>> In the since I'm in embedded mode I can get FooImpl casting it to Foo.
>> Foo has been loaded from the Junit JVM for instance and FooImpl from
>> the webapp cause we use a framework (spring, CDI, ...). The cast will
>> fail cause FooImpl will use Foo from the webapp.
>
> In which case you need either:
>
> a) Have Foo treated as a Java SE provided class. Adding the JAR
> containing Foo to the endorsed dir rather than the class path should work.
This is a workaround, not a solution. Think to new Tomcat() in JUnit at least.
>
> b) Have Foo treated as a container provided class and filter it out via
> WebappClassLoader.filter(String)
>
Thought filtering system classes like before in filter but then there
are 2 filtering which makes performances very bad so I'd prefer to be
able to override j2seClassLoader.
>> It was working fine before and it was convenient. By default you don't
>> add jars in tomcat system loader so the behavior of tomcat was fine +
>> in unit test of embedded mode it was convenient so I dont get the
>> point changing it.
>
> The point of changing it was:
>
> - fixing the reported bug
> - have the actual behaviour align with the documented / spec required
> behaviour
>
> There was nothing in either the spec or the docs that required Tomcat to
> prevent web applications overridding a class on the system class path.
>
Nothing forces it to be done so IMO it should be configurable and not
the default behavior for backward compatibility (spoken of v7).
> Switching to using the endorsed dir looks like the simplest solution to
> me and it should work for Tomcat versions before and after the BZ 55943
> change.
>
> Other possible solutions include:
> - removing the final from j2seClassLoader / always accessing it via an
> over-ridable getter() (I'd recommend checking that that will work for
> you as the other related changes may also cause problems)
I set by reflection j2seClassLoader it solved this particular issue.
> - making it possible to add to the packages used to define the filter
> for container classes
Not enough since user classes should get this bahavior too in embedded
case (I don't say that's good but common, convenient and done so we
need to leave with it).
>
> Mark
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: new classloader parent?
Posted by Mark Thomas <ma...@apache.org>.
Again, please stop top posting.
On 18/02/2014 10:14, Romain Manni-Bucau wrote:
> let say we have an interface Foo. I deploy a war with Foo and FooImpl.
> In the since I'm in embedded mode I can get FooImpl casting it to Foo.
> Foo has been loaded from the Junit JVM for instance and FooImpl from
> the webapp cause we use a framework (spring, CDI, ...). The cast will
> fail cause FooImpl will use Foo from the webapp.
In which case you need either:
a) Have Foo treated as a Java SE provided class. Adding the JAR
containing Foo to the endorsed dir rather than the class path should work.
b) Have Foo treated as a container provided class and filter it out via
WebappClassLoader.filter(String)
> It was working fine before and it was convenient. By default you don't
> add jars in tomcat system loader so the behavior of tomcat was fine +
> in unit test of embedded mode it was convenient so I dont get the
> point changing it.
The point of changing it was:
- fixing the reported bug
- have the actual behaviour align with the documented / spec required
behaviour
There was nothing in either the spec or the docs that required Tomcat to
prevent web applications overridding a class on the system class path.
Switching to using the endorsed dir looks like the simplest solution to
me and it should work for Tomcat versions before and after the BZ 55943
change.
Other possible solutions include:
- removing the final from j2seClassLoader / always accessing it via an
over-ridable getter() (I'd recommend checking that that will work for
you as the other related changes may also cause problems)
- making it possible to add to the packages used to define the filter
for container classes
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: new classloader parent?
Posted by Romain Manni-Bucau <rm...@gmail.com>.
let say we have an interface Foo. I deploy a war with Foo and FooImpl.
In the since I'm in embedded mode I can get FooImpl casting it to Foo.
Foo has been loaded from the Junit JVM for instance and FooImpl from
the webapp cause we use a framework (spring, CDI, ...). The cast will
fail cause FooImpl will use Foo from the webapp.
It was working fine before and it was convenient. By default you don't
add jars in tomcat system loader so the behavior of tomcat was fine +
in unit test of embedded mode it was convenient so I dont get the
point changing it.
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau
2014-02-18 11:11 GMT+01:00 Mark Thomas <ma...@apache.org>:
> On 18/02/2014 10:07, Romain Manni-Bucau wrote:
>> 2014-02-18 11:04 GMT+01:00 Mark Thomas <ma...@apache.org>:
>>> On 18/02/2014 09:59, Romain Manni-Bucau wrote:
>
> <snip/>
>
>>>> it doesn't cover the embedded case at all
>>>
>>> What doesn't? Why?
>>
>> In embedded case you deploy an app with your classes in the JVM and
>> want 1/2 of times to cast both, this was working fine before because
>> tomcat was preventing system loader overriding, it is broken now now
>> since tomcat only uses ext classloader.
>
> I have no idea what you mean by "cast both" so I can't follow the point
> you are making here at all.
>
> Mark
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: new classloader parent?
Posted by Mark Thomas <ma...@apache.org>.
On 18/02/2014 10:07, Romain Manni-Bucau wrote:
> 2014-02-18 11:04 GMT+01:00 Mark Thomas <ma...@apache.org>:
>> On 18/02/2014 09:59, Romain Manni-Bucau wrote:
<snip/>
>>> it doesn't cover the embedded case at all
>>
>> What doesn't? Why?
>
> In embedded case you deploy an app with your classes in the JVM and
> want 1/2 of times to cast both, this was working fine before because
> tomcat was preventing system loader overriding, it is broken now now
> since tomcat only uses ext classloader.
I have no idea what you mean by "cast both" so I can't follow the point
you are making here at all.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: new classloader parent?
Posted by Romain Manni-Bucau <rm...@gmail.com>.
2014-02-18 11:04 GMT+01:00 Mark Thomas <ma...@apache.org>:
> Please don't top post.
>
> On 18/02/2014 09:59, Romain Manni-Bucau wrote:
>> We did it but
>
> Did what?
used filter()
>
>> it doesn't cover the embedded case at all
>
> What doesn't? Why?
In embedded case you deploy an app with your classes in the JVM and
want 1/2 of times to cast both, this was working fine before because
tomcat was preventing system loader overriding, it is broken now now
since tomcat only uses ext classloader.
>
>> since you want to use system classloader.
>
> What do you want to use that class loader for?
>
>> I know this is a case tomcat doesn't handle
>
> What case doesn't Tomcat handle?
>
>> but it breaks applications using it before (new Tomcat() too).
>
> Using what?
>
> Mark
>
>> Romain Manni-Bucau
>> Twitter: @rmannibucau
>> Blog: http://rmannibucau.wordpress.com/
>> LinkedIn: http://fr.linkedin.com/in/rmannibucau
>> Github: https://github.com/rmannibucau
>>
>>
>>
>> 2014-02-18 10:57 GMT+01:00 Mark Thomas <ma...@apache.org>:
>>> On 18/02/2014 09:21, Romain Manni-Bucau wrote:
>>>> Hello
>>>>
>>>> seems now parent classloader used to avoid to overwrite classes is
>>>> j2seClassLoader which is extclassloader by default. This totally
>>>> breaks tomee and i guess other apps since classes which were not
>>>> overwritten in standalone (new Tomcat) are now overwritten by webapp
>>>> classloader.
>>>>
>>>> Is it intended?
>>>
>>> Yes. There was a deliberate change to allow web applications to override
>>> classes on the system class path. If you had looked at the svn log for
>>> WebappClassLoader it would have led you to this bug:
>>>
>>> https://issues.apache.org/bugzilla/show_bug.cgi?id=55943
>>>
>>> The requirement from the Servlet specification (section 10.7.2) is to
>>> ensure that neither Java SE nor container classes are overridden. The
>>> j2seClassLoader check is solely for Java SE classes. I'd have preferred
>>> a reference to the bootstrap class loader but that isn't available in an
>>> Oracle JVM.
>>>
>>> Protection for container classes is provided by the filter(String)
>>> method. I suspect that you need to override this method and add
>>> filtering for additional container provided classes. Alternatively, some
>>> form for protected access to modify the packageTriggers* fields could be
>>> provided if that would be simpler.
>>>
>>> Mark
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: dev-help@tomcat.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: dev-help@tomcat.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: new classloader parent?
Posted by Mark Thomas <ma...@apache.org>.
Please don't top post.
On 18/02/2014 09:59, Romain Manni-Bucau wrote:
> We did it but
Did what?
> it doesn't cover the embedded case at all
What doesn't? Why?
> since you want to use system classloader.
What do you want to use that class loader for?
> I know this is a case tomcat doesn't handle
What case doesn't Tomcat handle?
> but it breaks applications using it before (new Tomcat() too).
Using what?
Mark
> Romain Manni-Bucau
> Twitter: @rmannibucau
> Blog: http://rmannibucau.wordpress.com/
> LinkedIn: http://fr.linkedin.com/in/rmannibucau
> Github: https://github.com/rmannibucau
>
>
>
> 2014-02-18 10:57 GMT+01:00 Mark Thomas <ma...@apache.org>:
>> On 18/02/2014 09:21, Romain Manni-Bucau wrote:
>>> Hello
>>>
>>> seems now parent classloader used to avoid to overwrite classes is
>>> j2seClassLoader which is extclassloader by default. This totally
>>> breaks tomee and i guess other apps since classes which were not
>>> overwritten in standalone (new Tomcat) are now overwritten by webapp
>>> classloader.
>>>
>>> Is it intended?
>>
>> Yes. There was a deliberate change to allow web applications to override
>> classes on the system class path. If you had looked at the svn log for
>> WebappClassLoader it would have led you to this bug:
>>
>> https://issues.apache.org/bugzilla/show_bug.cgi?id=55943
>>
>> The requirement from the Servlet specification (section 10.7.2) is to
>> ensure that neither Java SE nor container classes are overridden. The
>> j2seClassLoader check is solely for Java SE classes. I'd have preferred
>> a reference to the bootstrap class loader but that isn't available in an
>> Oracle JVM.
>>
>> Protection for container classes is provided by the filter(String)
>> method. I suspect that you need to override this method and add
>> filtering for additional container provided classes. Alternatively, some
>> form for protected access to modify the packageTriggers* fields could be
>> provided if that would be simpler.
>>
>> Mark
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: dev-help@tomcat.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: new classloader parent?
Posted by Romain Manni-Bucau <rm...@gmail.com>.
We did it but it doesn't cover the embedded case at all since you want
to use system classloader. I know this is a case tomcat doesn't handle
but it breaks applications using it before (new Tomcat() too).
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau
2014-02-18 10:57 GMT+01:00 Mark Thomas <ma...@apache.org>:
> On 18/02/2014 09:21, Romain Manni-Bucau wrote:
>> Hello
>>
>> seems now parent classloader used to avoid to overwrite classes is
>> j2seClassLoader which is extclassloader by default. This totally
>> breaks tomee and i guess other apps since classes which were not
>> overwritten in standalone (new Tomcat) are now overwritten by webapp
>> classloader.
>>
>> Is it intended?
>
> Yes. There was a deliberate change to allow web applications to override
> classes on the system class path. If you had looked at the svn log for
> WebappClassLoader it would have led you to this bug:
>
> https://issues.apache.org/bugzilla/show_bug.cgi?id=55943
>
> The requirement from the Servlet specification (section 10.7.2) is to
> ensure that neither Java SE nor container classes are overridden. The
> j2seClassLoader check is solely for Java SE classes. I'd have preferred
> a reference to the bootstrap class loader but that isn't available in an
> Oracle JVM.
>
> Protection for container classes is provided by the filter(String)
> method. I suspect that you need to override this method and add
> filtering for additional container provided classes. Alternatively, some
> form for protected access to modify the packageTriggers* fields could be
> provided if that would be simpler.
>
> Mark
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: new classloader parent?
Posted by Mark Thomas <ma...@apache.org>.
On 18/02/2014 09:21, Romain Manni-Bucau wrote:
> Hello
>
> seems now parent classloader used to avoid to overwrite classes is
> j2seClassLoader which is extclassloader by default. This totally
> breaks tomee and i guess other apps since classes which were not
> overwritten in standalone (new Tomcat) are now overwritten by webapp
> classloader.
>
> Is it intended?
Yes. There was a deliberate change to allow web applications to override
classes on the system class path. If you had looked at the svn log for
WebappClassLoader it would have led you to this bug:
https://issues.apache.org/bugzilla/show_bug.cgi?id=55943
The requirement from the Servlet specification (section 10.7.2) is to
ensure that neither Java SE nor container classes are overridden. The
j2seClassLoader check is solely for Java SE classes. I'd have preferred
a reference to the bootstrap class loader but that isn't available in an
Oracle JVM.
Protection for container classes is provided by the filter(String)
method. I suspect that you need to override this method and add
filtering for additional container provided classes. Alternatively, some
form for protected access to modify the packageTriggers* fields could be
provided if that would be simpler.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: new classloader parent?
Posted by Romain Manni-Bucau <rm...@gmail.com>.
PS: BTW system varaible is no more used in new code
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau
2014-02-18 10:21 GMT+01:00 Romain Manni-Bucau <rm...@gmail.com>:
> Hello
>
> seems now parent classloader used to avoid to overwrite classes is
> j2seClassLoader which is extclassloader by default. This totally
> breaks tomee and i guess other apps since classes which were not
> overwritten in standalone (new Tomcat) are now overwritten by webapp
> classloader.
>
> Is it intended?
>
> Romain Manni-Bucau
> Twitter: @rmannibucau
> Blog: http://rmannibucau.wordpress.com/
> LinkedIn: http://fr.linkedin.com/in/rmannibucau
> Github: https://github.com/rmannibucau
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org