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-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: dev-h...@tomcat.apache.org >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
