[Bug 56148] support (multiple) ocsp stapling
https://issues.apache.org/bugzilla/show_bug.cgi?id=56148 Mark Thomas changed: What|Removed |Added OS||All --- Comment #1 from Mark Thomas --- Support for this in the BIO and NIO connectors is going to have to wait until Java provides the support. I don't see it in Java 8 which means that it is likely to be at least Java 9. It should be possible to do something for APR/native. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
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-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: new classloader parent?
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 : > 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-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 56137] Change HTTPS connector example (protocol attribute) from "HTTP/1.1" to Http11NioProtocol
https://issues.apache.org/bugzilla/show_bug.cgi?id=56137 Ognjen Blagojevic changed: What|Removed |Added Status|RESOLVED|CLOSED --- Comment #2 from Ognjen Blagojevic --- Thank you. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 55943] Provide a way prevent looking at the System classloader before the webapp classloaders
https://issues.apache.org/bugzilla/show_bug.cgi?id=55943 --- Comment #8 from romain.manni-bucau --- Hi this totaally breaks tomcat and tomee usage in embeded mode (+ has a lot of side effect in normal mode). 1) the j2seClassLoader is not overridable in children classloader which is a pain since system was 2) system is no more used 3) it breaks compatibility can you revert it and make it active just with a flag is asked? Side note: for a minor this is an important change which should have been showed a bit more (7.1 maybe) -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: new classloader parent?
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
Re: new classloader parent?
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 : > 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
Re: new classloader parent?
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 : >> 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
Re: new classloader parent?
2014-02-18 11:04 GMT+01:00 Mark Thomas : > 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 : >>> 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 > - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: new classloader parent?
On 18/02/2014 10:07, Romain Manni-Bucau wrote: > 2014-02-18 11:04 GMT+01:00 Mark Thomas : >> On 18/02/2014 09:59, Romain Manni-Bucau wrote: >>> 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-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
false in filter?
Hi false is no more supported by default int tomcat for filter? it is used in tcks and seems broken now 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-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: new classloader parent?
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 : > On 18/02/2014 10:07, Romain Manni-Bucau wrote: >> 2014-02-18 11:04 GMT+01:00 Mark Thomas : >>> On 18/02/2014 09:59, Romain Manni-Bucau wrote: > > > 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-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
Re: false in filter?
edit: org.apache.jasper.compiler.JspConfig#processWebDotXml validates the xml immediately and doesn't read the version from WebXml - from ContextConfig with getMajorVersion, getMinorVersion methods 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:12 GMT+01:00 Romain Manni-Bucau : > Hi > > false is no more supported by > default int tomcat for filter? > > it is used in tcks and seems broken now > > 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-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: new classloader parent?
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-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: new classloader parent?
2014-02-18 11:44 GMT+01:00 Mark Thomas : > 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-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
Re: false in filter?
Yet again, please don't top post. On 18/02/2014 10:21, Romain Manni-Bucau wrote: > edit: org.apache.jasper.compiler.JspConfig#processWebDotXml validates > the xml immediately and doesn't read the version from WebXml - from > ContextConfig with getMajorVersion, getMinorVersion methods Which Tomcat release are you referring to? What has Jasper's processing of web.xml (which is looking at a sub-set of configuration that doesn't include async support) got to do with this issue? > 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:12 GMT+01:00 Romain Manni-Bucau : >> Hi >> >> false is no more supported by >> default int tomcat for filter? It should be supported. There were some changes to xml parsing to improve validation but that shouldn't impact this. I don't recall any other changes but it isn't impossible that something has been missed. >> it is used in tcks and seems broken now Which TCK? With which Tomcat version? Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: false in filter?
2014-02-18 11:54 GMT+01:00 Mark Thomas : > Yet again, please don't top post. > > On 18/02/2014 10:21, Romain Manni-Bucau wrote: >> edit: org.apache.jasper.compiler.JspConfig#processWebDotXml validates >> the xml immediately and doesn't read the version from WebXml - from >> ContextConfig with getMajorVersion, getMinorVersion methods > > Which Tomcat release are you referring to? 7.0.52 > > What has Jasper's processing of web.xml (which is looking at a sub-set > of configuration that doesn't include async support) got to do with this > issue? > I got it from JspConfig: org.apache.jasper.compiler.JspConfig.processWebDotXml(JspConfig.java:230) org.apache.jasper.compiler.JspConfig.init(JspConfig.java:243) org.apache.jasper.compiler.JspConfig.findJspProperty(JspConfig.java:302) org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:114) org.apache.jasper.compiler.Compiler.compile(Compiler.java:373) org.apache.jasper.compiler.Compiler.compile(Compiler.java:353) org.apache.jasper.compiler.Compiler.compile(Compiler.java:340) org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:657) org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:357) org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:390) org.apache.jasper.servlet.JspServlet.service(JspServlet.java:334) javax.servlet.http.HttpServlet.service(HttpServlet.java:727) >> 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:12 GMT+01:00 Romain Manni-Bucau : >>> Hi >>> >>> false is no more supported by >>> default int tomcat for filter? > > It should be supported. There were some changes to xml parsing to > improve validation but that shouldn't impact this. I don't recall any > other changes but it isn't impossible that something has been missed. > basically deactivated tldValidation to make it passing >>> it is used in tcks and seems broken now > > Which TCK? With which Tomcat version? CDI TCKs (didnt check JavaEE ones yet) > > 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
Re: new classloader parent?
On 18/02/2014 10:50, Romain Manni-Bucau wrote: > 2014-02-18 11:44 GMT+01:00 Mark Thomas : >> On 18/02/2014 10:14, Romain Manni-Bucau wrote: >>> 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-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: false in filter?
On 18/02/2014 11:06, Romain Manni-Bucau wrote: > 2014-02-18 11:54 GMT+01:00 Mark Thomas : >> Yet again, please don't top post. >> >> On 18/02/2014 10:21, Romain Manni-Bucau wrote: >>> edit: org.apache.jasper.compiler.JspConfig#processWebDotXml validates >>> the xml immediately and doesn't read the version from WebXml - from >>> ContextConfig with getMajorVersion, getMinorVersion methods >> >> Which Tomcat release are you referring to? > > 7.0.52 > >> >> What has Jasper's processing of web.xml (which is looking at a sub-set >> of configuration that doesn't include async support) got to do with this >> issue? >> > > I got it from JspConfig: Got what from JspConfig? And how does this relate to an issue with async processing? > basically deactivated tldValidation to make it passing That doesn't surprise me. The Servlet TCK won't pass either unless tldValidation is disabled. The specs don't mandate tldValidation so disabling it for the TCKs should be OK. it is used in tcks and seems broken now >> >> Which TCK? With which Tomcat version? > > CDI TCKs (didnt check JavaEE ones yet) I don't understand how TLD validation is triggering a problem with async (unless a whole web application is failing to start) and I'd like to. If disabling TLD validation enables the TCK to pass then I don't see an issue with doing that. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: false in filter?
2014-02-18 12:15 GMT+01:00 Mark Thomas : > On 18/02/2014 11:06, Romain Manni-Bucau wrote: >> 2014-02-18 11:54 GMT+01:00 Mark Thomas : >>> Yet again, please don't top post. >>> >>> On 18/02/2014 10:21, Romain Manni-Bucau wrote: edit: org.apache.jasper.compiler.JspConfig#processWebDotXml validates the xml immediately and doesn't read the version from WebXml - from ContextConfig with getMajorVersion, getMinorVersion methods >>> >>> Which Tomcat release are you referring to? >> >> 7.0.52 >> >>> >>> What has Jasper's processing of web.xml (which is looking at a sub-set >>> of configuration that doesn't include async support) got to do with this >>> issue? >>> >> >> I got it from JspConfig: > > Got what from JspConfig? the previous stack: INFO: Apache Tomcat (TomEE)/7.0.52 (1.6.1-SNAPSHOT) - Error report HTTP Status 500 - org.apache.jasper.JasperException: XML parsing error on file org.apache.tomcat.util.scan.MergedWebXml: (line 13, col 22)type Exception reportmessage org.apache.jasper.JasperException: XML parsing error on file org.apache.tomcat.util.scan.MergedWebXml: (line 13, col 22)description The server encountered an internal error that prevented it from fulfilling this request.exception org.apache.jasper.JasperException: org.apache.jasper.JasperException: XML parsing error on file org.apache.tomcat.util.scan.MergedWebXml: (line 13, col 22) org.apache.jasper.compiler.JspConfig.processWebDotXml(JspConfig.java:230) org.apache.jasper.compiler.JspConfig.init(JspConfig.java:243) org.apache.jasper.compiler.JspConfig.findJspProperty(JspConfig.java:302) > > And how does this relate to an issue with async processing? > >> basically deactivated tldValidation to make it passing > > That doesn't surprise me. The Servlet TCK won't pass either unless > tldValidation is disabled. The specs don't mandate tldValidation so > disabling it for the TCKs should be OK. > > it is used in tcks and seems broken now >>> >>> Which TCK? With which Tomcat version? >> >> CDI TCKs (didnt check JavaEE ones yet) > > I don't understand how TLD validation is triggering a problem with async > (unless a whole web application is failing to start) and I'd like to. If > disabling TLD validation enables the TCK to pass then I don't see an > issue with doing that. me neither seems tomcat is parsing web.xml using tld validation property > > 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
Re: false in filter?
On 18/02/2014 12:01, Romain Manni-Bucau wrote: > 2014-02-18 12:15 GMT+01:00 Mark Thomas : >> On 18/02/2014 11:06, Romain Manni-Bucau wrote: >>> I got it from JspConfig: >> >> Got what from JspConfig? > > the previous stack: > > INFO: Apache Tomcat (TomEE)/7.0.52 (1.6.1-SNAPSHOT) > - Error report HTTP Status 500 - > org.apache.jasper.JasperException: XML parsing error on file > org.apache.tomcat.util.scan.MergedWebXml: (line 13, col 22) size="1" noshade="noshade">type Exception > reportmessage org.apache.jasper.JasperException: XML > parsing error on file org.apache.tomcat.util.scan.MergedWebXml: (line > 13, col 22)description The server encountered an > internal error that prevented it from fulfilling this > request.exception > org.apache.jasper.JasperException: > org.apache.jasper.JasperException: XML parsing error on file > org.apache.tomcat.util.scan.MergedWebXml: (line 13, col 22) > org.apache.jasper.compiler.JspConfig.processWebDotXml(JspConfig.java:230) > org.apache.jasper.compiler.JspConfig.init(JspConfig.java:243) > org.apache.jasper.compiler.JspConfig.findJspProperty(JspConfig.java:302) >> I don't understand how TLD validation is triggering a problem with async >> (unless a whole web application is failing to start) and I'd like to. If >> disabling TLD validation enables the TCK to pass then I don't see an >> issue with doing that. > > me neither seems tomcat is parsing web.xml using tld validation property Looks like there might be a couple of problems here. Any chance you could debug this and provide the full text of the merged web.xml? Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: new classloader parent?
2014-02-18 12:09 GMT+01:00 Mark Thomas : > On 18/02/2014 10:50, Romain Manni-Bucau wrote: >> 2014-02-18 11:44 GMT+01:00 Mark Thomas : >>> On 18/02/2014 10:14, Romain Manni-Bucau wrote: > > > 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-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
Re: false in filter?
2014-02-18 13:10 GMT+01:00 Mark Thomas : > On 18/02/2014 12:01, Romain Manni-Bucau wrote: >> 2014-02-18 12:15 GMT+01:00 Mark Thomas : >>> On 18/02/2014 11:06, Romain Manni-Bucau wrote: > > > I got it from JspConfig: >>> >>> Got what from JspConfig? >> >> the previous stack: >> >> INFO: Apache Tomcat (TomEE)/7.0.52 (1.6.1-SNAPSHOT) >> - Error report HTTP Status 500 - >> org.apache.jasper.JasperException: XML parsing error on file >> org.apache.tomcat.util.scan.MergedWebXml: (line 13, col 22)> size="1" noshade="noshade">type Exception >> reportmessage org.apache.jasper.JasperException: XML >> parsing error on file org.apache.tomcat.util.scan.MergedWebXml: (line >> 13, col 22)description The server encountered an >> internal error that prevented it from fulfilling this >> request.exception >> org.apache.jasper.JasperException: >> org.apache.jasper.JasperException: XML parsing error on file >> org.apache.tomcat.util.scan.MergedWebXml: (line 13, col 22) >> org.apache.jasper.compiler.JspConfig.processWebDotXml(JspConfig.java:230) >> org.apache.jasper.compiler.JspConfig.init(JspConfig.java:243) >> org.apache.jasper.compiler.JspConfig.findJspProperty(JspConfig.java:302) > > > >>> I don't understand how TLD validation is triggering a problem with async >>> (unless a whole web application is failing to start) and I'd like to. If >>> disabling TLD validation enables the TCK to pass then I don't see an >>> issue with doing that. >> >> me neither seems tomcat is parsing web.xml using tld validation property > > Looks like there might be a couple of problems here. Any chance you > could debug this and provide the full text of the merged web.xml? > https://gist.github.com/rmannibucau/38292f66783c0d49965b > 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
[jira] [Updated] (MTOMCAT-238) Parameter staticContextDocbase cant be used
[ https://issues.apache.org/jira/browse/MTOMCAT-238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Laurent GARCIA updated MTOMCAT-238: --- Attachment: tomcat7-maven-plugin-2.2.jar.zip Version patchée > Parameter staticContextDocbase cant be used > --- > > Key: MTOMCAT-238 > URL: https://issues.apache.org/jira/browse/MTOMCAT-238 > Project: Apache Tomcat Maven Plugin > Issue Type: Bug > Components: tomcat6, tomcat7 >Affects Versions: 2.0-beta-1, 2.1 >Reporter: Michal Franc >Assignee: Olivier Lamy (*$^¨%`£) > Fix For: moreinfo > > Attachments: tomcat7-maven-plugin-2.2.jar.zip > > > Attribute staticContextDocbase leads to IllegalArgumentException > org.apache.tomcat.maven.plugin.tomcat7.run.AbstractRunMojo#createStaticContext > is context created from container and at the and added again to server which > leads to java.lang.IllegalArgumentException: addChild: Child name '/' is not > unique -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[jira] [Comment Edited] (MTOMCAT-238) Parameter staticContextDocbase cant be used
[ https://issues.apache.org/jira/browse/MTOMCAT-238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13904147#comment-13904147 ] Laurent GARCIA edited comment on MTOMCAT-238 at 2/18/14 3:30 PM: - I added to this jira a patch, which is exactly what I said and works fine for me (just comment the addChild). An official release would be really appreciated. was (Author: lgarcia): Version patchée > Parameter staticContextDocbase cant be used > --- > > Key: MTOMCAT-238 > URL: https://issues.apache.org/jira/browse/MTOMCAT-238 > Project: Apache Tomcat Maven Plugin > Issue Type: Bug > Components: tomcat6, tomcat7 >Affects Versions: 2.0-beta-1, 2.1 >Reporter: Michal Franc >Assignee: Olivier Lamy (*$^¨%`£) > Fix For: moreinfo > > Attachments: tomcat7-maven-plugin-2.2.jar.zip > > > Attribute staticContextDocbase leads to IllegalArgumentException > org.apache.tomcat.maven.plugin.tomcat7.run.AbstractRunMojo#createStaticContext > is context created from container and at the and added again to server which > leads to java.lang.IllegalArgumentException: addChild: Child name '/' is not > unique -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1569398 - in /tomcat/trunk/java/org/apache/catalina/loader: LocalStrings.properties WebappClassLoader.java
Author: markt
Date: Tue Feb 18 16:00:34 2014
New Revision: 1569398
URL: http://svn.apache.org/r1569398
Log:
Make it easier for TomEE to modify the j2seClassLoader
Modified:
tomcat/trunk/java/org/apache/catalina/loader/LocalStrings.properties
tomcat/trunk/java/org/apache/catalina/loader/WebappClassLoader.java
Modified: tomcat/trunk/java/org/apache/catalina/loader/LocalStrings.properties
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/loader/LocalStrings.properties?rev=1569398&r1=1569397&r2=1569398&view=diff
==
--- tomcat/trunk/java/org/apache/catalina/loader/LocalStrings.properties
(original)
+++ tomcat/trunk/java/org/apache/catalina/loader/LocalStrings.properties Tue
Feb 18 16:00:34 2014
@@ -37,6 +37,7 @@ webappClassLoader.loadedByThisOrChildFai
webappClassLoader.jarsAdded=One or more JARs have been added to the web
application [{0}]
webappClassLoader.jarsModified=One or more JARs have been modified in the web
application [{0}]
webappClassLoader.jarsRemoved=One or more JARs have been removed from the web
application [{0}]
+webappClassLoader.j2seClassLoaderNull=The j2seClassLoader attribute may not be
null
webappClassLoader.resourceModified=Resource [{0}] has been modified. The last
modified time was [{1}] and is now [{2}]
webappClassLoader.stopThreadFail=Failed to terminate thread named [{0}] for
web application [{1}]
webappClassLoader.stopTimerThreadFail=Failed to terminate TimerThread named
[{0}] for web application [{1}]
Modified: tomcat/trunk/java/org/apache/catalina/loader/WebappClassLoader.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/loader/WebappClassLoader.java?rev=1569398&r1=1569397&r2=1569398&view=diff
==
--- tomcat/trunk/java/org/apache/catalina/loader/WebappClassLoader.java
(original)
+++ tomcat/trunk/java/org/apache/catalina/loader/WebappClassLoader.java Tue Feb
18 16:00:34 2014
@@ -339,7 +339,7 @@ public class WebappClassLoader extends U
* those cases {@link ClassLoader#getParent()} will be called recursively
on
* the system class loader and the last non-null result used.
*/
-protected final ClassLoader j2seClassLoader;
+private ClassLoader j2seClassLoader;
/**
@@ -1240,9 +1240,10 @@ public class WebappClassLoader extends U
// (0.2) Try loading the class with the system class loader, to prevent
// the webapp from overriding J2SE classes
String resourceName = binaryNameToPath(name, false);
-if (j2seClassLoader.getResource(resourceName) != null) {
+ClassLoader j2seLoader = getJ2seClassLoader();
+if (j2seLoader.getResource(resourceName) != null) {
try {
-clazz = j2seClassLoader.loadClass(name);
+clazz = j2seLoader.loadClass(name);
if (clazz != null) {
if (resolve)
resolveClass(clazz);
@@ -1505,6 +1506,18 @@ public class WebappClassLoader extends U
// -- Protected Methods
+protected ClassLoader getJ2seClassLoader() {
+return j2seClassLoader;
+}
+
+protected void setJ2seClassLoader(ClassLoader classLoader) {
+if (classLoader == null) {
+throw new IllegalArgumentException(
+sm.getString("webappClassLoader.j2seClassLoaderNull"));
+}
+j2seClassLoader = classLoader;
+}
+
/**
* Clear references.
*/
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: new classloader parent?
On 18/02/2014 13:05, Romain Manni-Bucau wrote: > 2014-02-18 12:09 GMT+01:00 Mark Thomas : >> 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-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: false in filter?
On 18/02/2014 13:07, Romain Manni-Bucau wrote: > 2014-02-18 13:10 GMT+01:00 Mark Thomas : >> Looks like there might be a couple of problems here. Any chance you >> could debug this and provide the full text of the merged web.xml? >> > > https://gist.github.com/rmannibucau/38292f66783c0d49965b OK. The error is valid. You have a 2.5 web.xml using 3.0 syntax. However, if the base web.xml is using 2.5, then there should not have been any merging. Hmm. What schema does /WEB-INF/web.xml declare in your app and where is TestFilter declared not to support async? Exactly how were you enabling/disabling tldValidation? I'm still trying to figure out why enabling that triggered validation of web.xml. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: new classloader parent?
2014-02-18 17:01 GMT+01:00 Mark Thomas : > On 18/02/2014 13:05, Romain Manni-Bucau wrote: >> 2014-02-18 12:09 GMT+01:00 Mark Thomas : > > > >>> 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-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
Re: false in filter?
2014-02-18 17:05 GMT+01:00 Mark Thomas :
> On 18/02/2014 13:07, Romain Manni-Bucau wrote:
>> 2014-02-18 13:10 GMT+01:00 Mark Thomas :
>
>
>
>>> Looks like there might be a couple of problems here. Any chance you
>>> could debug this and provide the full text of the merged web.xml?
>>>
>>
>> https://gist.github.com/rmannibucau/38292f66783c0d49965b
>
> OK. The error is valid. You have a 2.5 web.xml using 3.0 syntax.
> However, if the base web.xml is using 2.5, then there should not have
> been any merging. Hmm.
>
> What schema does /WEB-INF/web.xml declare in your app and where is
> TestFilter declared not to support async?
>
https://github.com/cdi-spec/cdi-tck/blob/1.0/impl/src/main/java/org/jboss/jsr299/tck/tests/lookup/injection/non/contextual/TestFilter.java
https://github.com/cdi-spec/cdi-tck/blob/1.0/impl/src/main/resources/org/jboss/jsr299/tck/tests/lookup/injection/non/contextual/web.xml
> Exactly how were you enabling/disabling tldValidation? I'm still trying
> to figure out why enabling that triggered validation of web.xml.
>
standardContext.setTldValidation(System.getProperty("myprop", "false"));
> 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
Re: new classloader parent?
On 18/02/2014 16:06, Romain Manni-Bucau wrote: > 2014-02-18 17:01 GMT+01:00 Mark Thomas : >> On 18/02/2014 13:05, Romain Manni-Bucau wrote: >>> 2014-02-18 12:09 GMT+01:00 Mark Thomas : >> >> >> 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-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: false in filter?
On 18/02/2014 16:11, Romain Manni-Bucau wrote:
> 2014-02-18 17:05 GMT+01:00 Mark Thomas :
>> On 18/02/2014 13:07, Romain Manni-Bucau wrote:
>>> 2014-02-18 13:10 GMT+01:00 Mark Thomas :
>>
>>
>>
Looks like there might be a couple of problems here. Any chance you
could debug this and provide the full text of the merged web.xml?
>>>
>>> https://gist.github.com/rmannibucau/38292f66783c0d49965b
>>
>> OK. The error is valid. You have a 2.5 web.xml using 3.0 syntax.
>> However, if the base web.xml is using 2.5, then there should not have
>> been any merging. Hmm.
>>
>> What schema does /WEB-INF/web.xml declare in your app and where is
>> TestFilter declared not to support async?
>>
>
> https://github.com/cdi-spec/cdi-tck/blob/1.0/impl/src/main/java/org/jboss/jsr299/tck/tests/lookup/injection/non/contextual/TestFilter.java
Not quite what I meant but I should be able to find what I need. Just to
confirm, you are using version 1.0.0 of the CDI TCK?
> https://github.com/cdi-spec/cdi-tck/blob/1.0/impl/src/main/resources/org/jboss/jsr299/tck/tests/lookup/injection/non/contextual/web.xml
OK. So definitely a 2.5 web app.
>> Exactly how were you enabling/disabling tldValidation? I'm still trying
>> to figure out why enabling that triggered validation of web.xml.
>>
>
> standardContext.setTldValidation(System.getProperty("myprop", "false"));
OK. I can trace it from there.
Mark
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: new classloader parent?
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 : > On 18/02/2014 16:06, Romain Manni-Bucau wrote: >> 2014-02-18 17:01 GMT+01:00 Mark Thomas : >>> On 18/02/2014 13:05, Romain Manni-Bucau wrote: 2014-02-18 12:09 GMT+01:00 Mark Thomas : >>> >>> >>> > 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-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
Re: new classloader parent?
2014-02-18 20:01 GMT+04:00 Mark Thomas : > On 18/02/2014 13:05, Romain Manni-Bucau wrote: >> 2014-02-18 12:09 GMT+01:00 Mark Thomas : > > > >>> 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-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: false in filter?
2014-02-18 20:05 GMT+04:00 Mark Thomas : > On 18/02/2014 13:07, Romain Manni-Bucau wrote: >> 2014-02-18 13:10 GMT+01:00 Mark Thomas : > > > >>> Looks like there might be a couple of problems here. Any chance you >>> could debug this and provide the full text of the merged web.xml? >>> >> >> https://gist.github.com/rmannibucau/38292f66783c0d49965b > > OK. The error is valid. You have a 2.5 web.xml using 3.0 syntax. > However, if the base web.xml is using 2.5, then there should not have > been any merging. Hmm. > > What schema does /WEB-INF/web.xml declare in your app and where is > TestFilter declared not to support async? > In WebXml.toXml() lines 715-716 (in trunk) [[[ appendElement(sb, INDENT4, "async-supported", filterDef.getAsyncSupported()); ]]] needs to be wrapped by an if(version>=...). I tested that default conf/web.xml serializes/parses correctly but it has no s in it, so apparently it slipped. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: new classloader parent?
2014-02-18 18:49 GMT+01:00 Konstantin Kolinko : > 2014-02-18 20:01 GMT+04:00 Mark Thomas : >> On 18/02/2014 13:05, Romain Manni-Bucau wrote: >>> 2014-02-18 12:09 GMT+01:00 Mark Thomas : >> >> >> 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-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
svn commit: r1569459 - in /tomcat/trunk/java/org/apache/catalina/loader: LocalStrings.properties WebappClassLoader.java
Author: markt
Date: Tue Feb 18 18:19:18 2014
New Revision: 1569459
URL: http://svn.apache.org/r1569459
Log:
s/j2se/javase/
Modified:
tomcat/trunk/java/org/apache/catalina/loader/LocalStrings.properties
tomcat/trunk/java/org/apache/catalina/loader/WebappClassLoader.java
Modified: tomcat/trunk/java/org/apache/catalina/loader/LocalStrings.properties
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/loader/LocalStrings.properties?rev=1569459&r1=1569458&r2=1569459&view=diff
==
--- tomcat/trunk/java/org/apache/catalina/loader/LocalStrings.properties
(original)
+++ tomcat/trunk/java/org/apache/catalina/loader/LocalStrings.properties Tue
Feb 18 18:19:18 2014
@@ -37,7 +37,7 @@ webappClassLoader.loadedByThisOrChildFai
webappClassLoader.jarsAdded=One or more JARs have been added to the web
application [{0}]
webappClassLoader.jarsModified=One or more JARs have been modified in the web
application [{0}]
webappClassLoader.jarsRemoved=One or more JARs have been removed from the web
application [{0}]
-webappClassLoader.j2seClassLoaderNull=The j2seClassLoader attribute may not be
null
+webappClassLoader.javaseClassLoaderNull=The j2seClassLoader attribute may not
be null
webappClassLoader.resourceModified=Resource [{0}] has been modified. The last
modified time was [{1}] and is now [{2}]
webappClassLoader.stopThreadFail=Failed to terminate thread named [{0}] for
web application [{1}]
webappClassLoader.stopTimerThreadFail=Failed to terminate TimerThread named
[{0}] for web application [{1}]
Modified: tomcat/trunk/java/org/apache/catalina/loader/WebappClassLoader.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/loader/WebappClassLoader.java?rev=1569459&r1=1569458&r2=1569459&view=diff
==
--- tomcat/trunk/java/org/apache/catalina/loader/WebappClassLoader.java
(original)
+++ tomcat/trunk/java/org/apache/catalina/loader/WebappClassLoader.java Tue Feb
18 18:19:18 2014
@@ -229,7 +229,7 @@ public class WebappClassLoader extends U
j = j.getParent();
}
}
-this.j2seClassLoader = j;
+this.javaseClassLoader = j;
securityManager = System.getSecurityManager();
if (securityManager != null) {
@@ -264,7 +264,7 @@ public class WebappClassLoader extends U
j = j.getParent();
}
}
-this.j2seClassLoader = j;
+this.javaseClassLoader = j;
securityManager = System.getSecurityManager();
if (securityManager != null) {
@@ -334,12 +334,12 @@ public class WebappClassLoader extends U
/**
- * The bootstrap class loader used to load the J2SE classes. In some
+ * The bootstrap class loader used to load the JavaSE classes. In some
* implementations this class loader is always null and in
* those cases {@link ClassLoader#getParent()} will be called recursively
on
* the system class loader and the last non-null result used.
*/
-private ClassLoader j2seClassLoader;
+private ClassLoader javaseClassLoader;
/**
@@ -1240,10 +1240,10 @@ public class WebappClassLoader extends U
// (0.2) Try loading the class with the system class loader, to prevent
// the webapp from overriding J2SE classes
String resourceName = binaryNameToPath(name, false);
-ClassLoader j2seLoader = getJ2seClassLoader();
-if (j2seLoader.getResource(resourceName) != null) {
+ClassLoader javaseLoader = getJavaseClassLoader();
+if (javaseLoader.getResource(resourceName) != null) {
try {
-clazz = j2seLoader.loadClass(name);
+clazz = javaseLoader.loadClass(name);
if (clazz != null) {
if (resolve)
resolveClass(clazz);
@@ -1506,16 +1506,16 @@ public class WebappClassLoader extends U
// -- Protected Methods
-protected ClassLoader getJ2seClassLoader() {
-return j2seClassLoader;
+protected ClassLoader getJavaseClassLoader() {
+return javaseClassLoader;
}
-protected void setJ2seClassLoader(ClassLoader classLoader) {
+protected void setJavaseClassLoader(ClassLoader classLoader) {
if (classLoader == null) {
throw new IllegalArgumentException(
-sm.getString("webappClassLoader.j2seClassLoaderNull"));
+sm.getString("webappClassLoader.javaseClassLoaderNull"));
}
-j2seClassLoader = classLoader;
+javaseClassLoader = classLoader;
}
/**
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.or
svn commit: r1569461 - /tomcat/trunk/webapps/docs/changelog.xml
Author: markt Date: Tue Feb 18 18:22:51 2014 New Revision: 1569461 URL: http://svn.apache.org/r1569461 Log: Update Modified: tomcat/trunk/webapps/docs/changelog.xml Modified: tomcat/trunk/webapps/docs/changelog.xml URL: http://svn.apache.org/viewvc/tomcat/trunk/webapps/docs/changelog.xml?rev=1569461&r1=1569460&r2=1569461&view=diff == --- tomcat/trunk/webapps/docs/changelog.xml (original) +++ tomcat/trunk/webapps/docs/changelog.xml Tue Feb 18 18:22:51 2014 @@ -60,6 +60,11 @@ Generate a valid root element for the effective web.xml for a web application for all supported versions of web.xml. (markt) + +Make it easier for applications embedding and/or extending Tomcat to +modify the javaseClassLoader attribute of the +WebappClassLoader. (markt) + - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1569465 - in /tomcat/tc7.0.x/trunk: ./ java/org/apache/catalina/loader/LocalStrings.properties java/org/apache/catalina/loader/WebappClassLoader.java webapps/docs/changelog.xml
Author: markt
Date: Tue Feb 18 18:29:11 2014
New Revision: 1569465
URL: http://svn.apache.org/r1569465
Log:
Make it easier for TomEE to modify the j2seClassLoader
Modified:
tomcat/tc7.0.x/trunk/ (props changed)
tomcat/tc7.0.x/trunk/java/org/apache/catalina/loader/LocalStrings.properties
tomcat/tc7.0.x/trunk/java/org/apache/catalina/loader/WebappClassLoader.java
tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml
Propchange: tomcat/tc7.0.x/trunk/
--
Merged /tomcat/trunk:r1569398,1569459
Modified:
tomcat/tc7.0.x/trunk/java/org/apache/catalina/loader/LocalStrings.properties
URL:
http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/java/org/apache/catalina/loader/LocalStrings.properties?rev=1569465&r1=1569464&r2=1569465&view=diff
==
---
tomcat/tc7.0.x/trunk/java/org/apache/catalina/loader/LocalStrings.properties
(original)
+++
tomcat/tc7.0.x/trunk/java/org/apache/catalina/loader/LocalStrings.properties
Tue Feb 18 18:29:11 2014
@@ -53,6 +53,7 @@ webappClassLoader.checkThreadLocalsForLe
webappClassLoader.checkThreadsHttpClient=Found HttpClient keep-alive thread
using web application class loader. Fixed by switching thread to the parent
class loader.
webappClassLoader.getThreadGroupError=Unable to obtain the parent for
ThreadGroup [{0}]. It will not be possible to check all threads for potential
memory leaks
webappClassLoader.loadedByThisOrChildFail=Failed to fully check the entries in
an instance of [{0}] for potential memory leaks in context [{1}]
+webappClassLoader.javaseClassLoaderNull=The j2seClassLoader attribute may not
be null
webappClassLoader.stopThreadFail=Failed to terminate thread named [{0}] for
web application [{1}]
webappClassLoader.stopTimerThreadFail=Failed to terminate TimerThread named
[{0}] for web application [{1}]
webappClassLoader.validationErrorJarPath=Unable to validate JAR entry with
name {0}
Modified:
tomcat/tc7.0.x/trunk/java/org/apache/catalina/loader/WebappClassLoader.java
URL:
http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/java/org/apache/catalina/loader/WebappClassLoader.java?rev=1569465&r1=1569464&r2=1569465&view=diff
==
--- tomcat/tc7.0.x/trunk/java/org/apache/catalina/loader/WebappClassLoader.java
(original)
+++ tomcat/tc7.0.x/trunk/java/org/apache/catalina/loader/WebappClassLoader.java
Tue Feb 18 18:29:11 2014
@@ -435,12 +435,12 @@ public class WebappClassLoader
/**
- * The bootstrap class loader used to load the J2SE classes. In some
+ * The bootstrap class loader used to load the JavaSE classes. In some
* implementations this class loader is always null and in
* those cases {@link ClassLoader#getParent()} will be called recursively
on
* the system class loader and the last non-null result used.
*/
-protected final ClassLoader j2seClassLoader;
+protected ClassLoader j2seClassLoader;
/**
@@ -1984,6 +1984,17 @@ public class WebappClassLoader
// -- Protected Methods
+protected ClassLoader getJavaseClassLoader() {
+return j2seClassLoader;
+}
+
+protected void setJavaseClassLoader(ClassLoader classLoader) {
+if (classLoader == null) {
+throw new IllegalArgumentException(
+sm.getString("webappClassLoader.javaseClassLoaderNull"));
+}
+j2seClassLoader = classLoader;
+}
/**
* Clear references.
Modified: tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml
URL:
http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml?rev=1569465&r1=1569464&r2=1569465&view=diff
==
--- tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml (original)
+++ tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml Tue Feb 18 18:29:11 2014
@@ -56,6 +56,15 @@
issues to not "pop up" wrt. others).
-->
+
+
+
+Make it easier for applications embedding and/or extending Tomcat to
+modify the javaseClassLoader attribute of the
+WebappClassLoader. (markt)
+
+
+
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[jira] [Commented] (MTOMCAT-238) Parameter staticContextDocbase cant be used
[ https://issues.apache.org/jira/browse/MTOMCAT-238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13904680#comment-13904680 ] Olivier Lamy (*$^¨%`£) commented on MTOMCAT-238: [~lgarcia] If you want your patch integrated you must provide a sources patch not a binary form > Parameter staticContextDocbase cant be used > --- > > Key: MTOMCAT-238 > URL: https://issues.apache.org/jira/browse/MTOMCAT-238 > Project: Apache Tomcat Maven Plugin > Issue Type: Bug > Components: tomcat6, tomcat7 >Affects Versions: 2.0-beta-1, 2.1 >Reporter: Michal Franc >Assignee: Olivier Lamy (*$^¨%`£) > Fix For: moreinfo > > Attachments: tomcat7-maven-plugin-2.2.jar.zip > > > Attribute staticContextDocbase leads to IllegalArgumentException > org.apache.tomcat.maven.plugin.tomcat7.run.AbstractRunMojo#createStaticContext > is context created from container and at the and added again to server which > leads to java.lang.IllegalArgumentException: addChild: Child name '/' is not > unique -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 55837] ServletContext.getRealPath() returns null
https://issues.apache.org/bugzilla/show_bug.cgi?id=55837 --- Comment #6 from Patrick Mi --- Should the method return the CanonicalPath or AbsolutePath? I used this method in Tomcat 4 and it returned AbsolutePath and now I found that it returns CanonicalPath which means the I couldn't locate my file anymore due to symbolic link is used for my docBase. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
