Re: [VOTE] Release Apache Tomcat 8.0.0-RC7
On 14/12/2013 15:37, Konstantin Preißer wrote: If more info is needed to debug the problem, please let me know. No more info needed at the moment. I can re-create the problem. The issues appear to be related to the changes I made to support non-blocking IO with AJP so they should be limited to Tomcat 8. Actually, I think there is more than one problem here. I've fixed the first issue in r1551211. With that fix I still see corrupted downloads but not the memory leak. I'm still looking into this. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat 8.0.0-RC7
On 16/12/2013 14:07, Mark Thomas wrote: On 14/12/2013 15:37, Konstantin Preißer wrote: If more info is needed to debug the problem, please let me know. No more info needed at the moment. I can re-create the problem. The additional issues I thought I was seeing were user error rather than a problem. I think the issue is fixed - at least I can't reproduce it with httpd + mod_proxy_ajp + Tomcat trunk. It is possible that there is still a bug or two lurking in Tomcat, the ISAPI Redirector or maybe IIS. Can you retest and let me know how you get on. Thanks, Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
RE: [VOTE] Release Apache Tomcat 8.0.0-RC7
Hi Mark, -Original Message- From: Mark Thomas [mailto:ma...@apache.org] Sent: Monday, December 16, 2013 3:44 PM To: Tomcat Developers List Subject: Re: [VOTE] Release Apache Tomcat 8.0.0-RC7 On 16/12/2013 14:07, Mark Thomas wrote: On 14/12/2013 15:37, Konstantin Preißer wrote: If more info is needed to debug the problem, please let me know. No more info needed at the moment. I can re-create the problem. The additional issues I thought I was seeing were user error rather than a problem. I think the issue is fixed - at least I can't reproduce it with httpd + mod_proxy_ajp + Tomcat trunk. It is possible that there is still a bug or two lurking in Tomcat, the ISAPI Redirector or maybe IIS. Can you retest and let me know how you get on. Thanks a lot. I verified that the problems do not occur any more with trunk r1551211. I also verified that they don't occur with Tomcat 7.0.47. Regards, Konstantin Preißer - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
RE: [VOTE] Release Apache Tomcat 8.0.0-RC7
Hi Mark, -Original Message- From: Mark Thomas [mailto:ma...@apache.org] Sent: Thursday, December 12, 2013 12:28 AM The proposed 8.0.0-RC7 release is: [ ] Broken - do not release [ ] Alpha - go ahead and release as 8.0.0-RC7 alpha While the issue with large static files that I got with 8.0.0-RC6 is now solved when using the http (NIO) connector, I got another problem with downloading large files on Tomcat 8.0.0-RC7 when using the AJP NIO connector. I was using IIS 8.5 on Windows Server 2012 R2 with Java 1.7.0_45 x64, and configured the ISAPI Redirector 1.2.37 to forward all requests to Tomcat. 1) I placed a static file with a size of 208,687,239 bytes into a web application. If I request this file over Tomcat's HTTP connector, everything works. But if I request it over IIS's HTTP connector (which forwards the request to Tomcat over AJP), then the first time I get an download dialog in the browser (I canceled it), but Tomcat starts to use ~ 100% CPU in one core. If I request the file again, I get lots of OOMs in Tomcat's log: 14-Dec-2013 13:09:56.960 SEVERE [ajp-nio-8019-exec-8] org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun java.lang.OutOfMemoryError: Java heap space at java.nio.HeapByteBuffer.init(HeapByteBuffer.java:57) at java.nio.ByteBuffer.allocate(ByteBuffer.java:331) at org.apache.coyote.ajp.AbstractAjpProcessor.addToBuffers(AbstractAjpProcessor.java:1590) at org.apache.coyote.ajp.AbstractAjpProcessor.writeData(AbstractAjpProcessor.java:1582) at org.apache.coyote.ajp.AbstractAjpProcessor.access$200(AbstractAjpProcessor.java:62) at org.apache.coyote.ajp.AbstractAjpProcessor$SocketOutputBuffer.doWrite(AbstractAjpProcessor.java:1724) at org.apache.coyote.Response.doWrite(Response.java:520) at org.apache.catalina.connector.OutputBuffer.realWriteBytes(OutputBuffer.java:391) at org.apache.tomcat.util.buf.ByteChunk.flushBuffer(ByteChunk.java:426) at org.apache.tomcat.util.buf.ByteChunk.append(ByteChunk.java:339) at org.apache.catalina.connector.OutputBuffer.writeBytes(OutputBuffer.java:421) at org.apache.catalina.connector.OutputBuffer.write(OutputBuffer.java:409) at org.apache.catalina.connector.CoyoteOutputStream.write(CoyoteOutputStream.java:97) at org.apache.catalina.servlets.DefaultServlet.copyRange(DefaultServlet.java:1951) at org.apache.catalina.servlets.DefaultServlet.copy(DefaultServlet.java:1791) at org.apache.catalina.servlets.DefaultServlet.serveResource(DefaultServlet.java:919) at org.apache.catalina.servlets.DefaultServlet.doGet(DefaultServlet.java:400) at javax.servlet.http.HttpServlet.service(HttpServlet.java:621) at javax.servlet.http.HttpServlet.service(HttpServlet.java:728) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:303) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208) at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:51) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208) at org.tuckey.web.filters.urlrewrite.RuleChain.handleRewrite(RuleChain.java:176) at org.tuckey.web.filters.urlrewrite.RuleChain.doRules(RuleChain.java:145) at org.tuckey.web.filters.urlrewrite.UrlRewriter.processRequest(UrlRewriter.java:92) at org.tuckey.web.filters.urlrewrite.UrlRewriteFilter.doFilter(UrlRewriteFilter.java:394) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208) at common.XUaCompatibleHeaderFilter.doFilter(XUaCompatibleHeaderFilter.java:27) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241) 14-Dec-2013 13:09:58.694 SEVERE [ajp-nio-8019-ClientPoller-0] org.apache.tomcat.util.net.NioEndpoint$Poller.run java.lang.OutOfMemoryError: Java heap space at org.apache.tomcat.util.net.NioEndpoint.reclaimParachute(NioEndpoint.java:313) at org.apache.tomcat.util.net.NioEndpoint.checkParachute(NioEndpoint.java:298) at org.apache.tomcat.util.net.NioEndpoint$Poller.run(NioEndpoint.java:1128) at java.lang.Thread.run(Thread.java:744) 14-Dec-2013 13:09:58.694 SEVERE [ajp-nio-8019-ClientPoller-1] org.apache.tomcat.util.net.NioEndpoint$Poller.run java.lang.OutOfMemoryError: Java heap space at org.apache.tomcat.util.net.NioEndpoint.reclaimParachute(NioEndpoint.java:313) at org.apache.tomcat.util.net.NioEndpoint.checkParachute(NioEndpoint.java:298) at
RE: [VOTE] Release Apache Tomcat 8.0.0-RC7
-Original Message- From: Konstantin Preißer [mailto:kpreis...@apache.org] Sent: Saturday, December 14, 2013 1:53 PM To: 'Tomcat Developers List' Subject: RE: [VOTE] Release Apache Tomcat 8.0.0-RC7 Hi Mark, -Original Message- From: Mark Thomas [mailto:ma...@apache.org] Sent: Thursday, December 12, 2013 12:28 AM The proposed 8.0.0-RC7 release is: [ ] Broken - do not release [ ] Alpha - go ahead and release as 8.0.0-RC7 alpha While the issue with large static files that I got with 8.0.0-RC6 is now solved when using the http (NIO) connector, I got another problem with downloading large files on Tomcat 8.0.0-RC7 when using the AJP NIO connector. I was using IIS 8.5 on Windows Server 2012 R2 with Java 1.7.0_45 x64, and configured the ISAPI Redirector 1.2.37 to forward all requests to Tomcat. 1) I placed a static file with a size of 208,687,239 bytes into a web application. If I request this file over Tomcat's HTTP connector, everything works. But if I request it over IIS's HTTP connector (which forwards the request to Tomcat over AJP), then the first time I get an download dialog in the browser (I canceled it), but Tomcat starts to use ~ 100% CPU in one core. If I request the file again, I get lots of OOMs in Tomcat's log: snip 2) I had an issue today morning (also with Tomcat 8.0.0-RC7) where the ISAPI Redirector was only serving empty responses (but with correct headers). The raw request/response to IIS looked like this: Request: GET / HTTP/1.1 Host: mydomain.de Connection: keep-alive Response: HTTP/1.1 200 OK Transfer-Encoding: chunked Content-Type: application/xhtml+xml;charset=UTF-8 Expires: Sat, 01 Jan 2000 00:00:00 GMT Server: Microsoft-IIS/8.5 X-UA-Compatible: IE=edge Date: Sat, 14 Dec 2013 10:43:00 GMT 0 OK, I could reproduce both 1) and 2) in a local virtual machine running Windows Server 2012 R2, IIS 8.5, ISAPI Redirector 1.2.37 and Tomcat 8.0.0-RC7 with Java 1.7.0_45 x64. For 1: I could easily reproduce it by trying to download a ~200 MB file in Tomcat's ROOT webapp through IIS a few times. For 2: I could reproduce this by: 1) Setting the ISAPI redirector to allow chunked encoding, then limiting the response buffer for the IsapiModule in IIS to 1 byte by using the following web.config (otherwise IIS would buffer the whole response from Tomcat before starting to send it to the client): ?xml version=1.0 encoding=UTF-8? configuration system.webServer handlers remove name=ISAPI-dll / add name=ISAPI-dll path=*.dll verb=* modules=IsapiModule resourceType=File requireAccess=Execute allowPathInfo=true responseBufferLimit=1 / /handlers /system.webServer /configuration 2) Placing a ~ 20 MB file in Tomcat's ROOT webapp. 3) Try to download and cancel this zip file with a slow client a few times (I used my own Tcp forwarder tool to intercept the TCP connection between Firefox and IIS and to slow down the data transfer). 4) After some time, if I now request Tomcat's ROOT index page (http://localhost/), I only get a blank page. A raw request to IIS shows: GET / HTTP/1.1 Host: local2 Connection: keep-alive HTTP/1.1 200 OK Transfer-Encoding: chunked Content-Type: text/html;charset=UTF-8 Server: Microsoft-IIS/8.5 Date: Sat, 14 Dec 2013 15:30:48 GMT 0 If I do the same request directly to Tomcat's HTTP NIO connector, the response is: GET / HTTP/1.1 Host: local2 Connection: keep-alive HTTP/1.1 200 OK Server: Apache-Coyote/1.1 Content-Type: text/html;charset=UTF-8 Transfer-Encoding: chunked Date: Sat, 14 Dec 2013 15:31:22 GMT 2000 !DOCTYPE html html lang=en head meta charset=UTF-8 / titleApache Tomcat/8.0.0-RC7/title link href=favicon.ico rel=icon type=image/x-icon / link href=favicon.ico rel=shortcut icon type=image/x-icon / link href=tomcat.css rel=stylesheet type=text/css / /head [rest of index.jsp ...] So it seems the AJP NIO connector is in some weird state, as the HTTP NIO connector is working normally, but AJP only shows an empty content. I then intercepted the AJP conncetion between the ISAPI redirector and Tomcat's AJP connector to record the data that was sent and received. This is the log of sender channel: [ID 1] Local connection established from 127.0.0.1:49914. [ID 1] Data - Offset: 0x0, Count: 0x1A0. 12 34 01 9C 02 02 00 08 48 54 54 50 2F 31 2E 31 00 00 01 2F .4.œHTTP/1.1.../ 00 00 09 31 32 37 2E 30 2E 30 2E 31 00 00 09 31 32 37 2E 30 ...127.0.0.1...127.0 2E 30 2E 31 00 00 06 6C 6F 63 61 6C 32 00 00 50 00 00 08 00 .0.1...local2..P 0D 43 61 63 68 65 2D 43 6F 6E 74 72 6F 6C 00 00 09 6D 61 78 .Cache-Control...max 2D 61 67 65 3D 30 00 A0 06 00 0A 6B 65 65 70 2D 61 6C 69 76 -age=0. ...keep-aliv 65 00 A0 08 00 01 30 00 A0 01 00 3F 74 65 78 74 2F 68 74 6D e. ...0. ..?text/htm 6C 2C 61 70 70 6C 69 63 61 74 69 6F 6E 2F 78 68 74 6D 6C 2B l,application
Re: [VOTE] Release Apache Tomcat 8.0.0-RC7
2013/12/12 Mark Thomas ma...@apache.org
The proposed Apache Tomcat 8.0.0 release candidate 7 is now available
for voting.
Given this is a release candidate I am working on the basis that it is
equivalent to an alpha. The main changes since RC5 are:
- Better handling of generic types in the WebSocket 1.0 implementation
- Refactor resource handling for the class loader
- Add Cobertura support to the unit tests
- Remove anti-Jar locking feature and replace it with open stream
tracking
- Update to Commons Pool 2.0 release
- Complete refactoring of TLD handling including caching of parsed TLDs
- More consistent handling of XML validation options
- Much more detailed visibility of DBCP connections pools in JMX
- Better organisation of JMX beans in the default JConsole view
- Numerous bug fixes
It can be obtained from:
https://dist.apache.org/repos/dist/dev/tomcat/tomcat-8/v8.0.0-RC7/
The Maven staging repo is:
https://repository.apache.org/content/repositories/orgapachetomcat-047/
The svn tag is:
http://svn.apache.org/repos/asf/tomcat/tags/TOMCAT_8_0_0_RC6/
The proposed 8.0.0-RC7 release is:
[ ] Broken - do not release
[ ] Alpha - go ahead and release as 8.0.0-RC7 alpha
I'm receiving NPE when testing an application with jsp that specifies tld
location with relative path:
java.lang.NullPointerException
org.apache.jasper.compiler.TldCache.getTaglibXml(TldCache.java:97)
org.apache.jasper.compiler.TagLibraryInfoImpl.init(TagLibraryInfoImpl.java:150)
org.apache.jasper.compiler.Parser.parseTaglibDirective(Parser.java:411)
org.apache.jasper.compiler.Parser.parseDirective(Parser.java:469)
org.apache.jasper.compiler.Parser.parseElements(Parser.java:1455)
org.apache.jasper.compiler.Parser.parse(Parser.java:139)
org.apache.jasper.compiler.ParserController.doParse(ParserController.java:229)
org.apache.jasper.compiler.ParserController.parse(ParserController.java:100)
org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:200)
org.apache.jasper.compiler.Compiler.compile(Compiler.java:375)
org.apache.jasper.compiler.Compiler.compile(Compiler.java:355)
org.apache.jasper.compiler.Compiler.compile(Compiler.java:342)
org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:557)
Here is a test case that I used:
Index: test/org/apache/jasper/runtime/TestPageContextImpl.java
===
--- test/org/apache/jasper/runtime/TestPageContextImpl.java (revision
1549955)
+++ test/org/apache/jasper/runtime/TestPageContextImpl.java (working copy)
@@ -50,4 +50,19 @@
Assert.assertTrue(body.contains(OK));
Assert.assertFalse(body.contains(FAIL));
}
+
+@Test
+public void testRelativeTldLocation() throws Exception {
+Tomcat tomcat = getTomcatInstance();
+
+File appDir = new File(test/webapp);
+tomcat.addWebapp(null, /test, appDir.getAbsolutePath());
+
+tomcat.start();
+
+ByteChunk res = new ByteChunk();
+
+int rc = getUrl(http://localhost:; + getPort() +
+/test/jsp/test.jsp, res, null);
+}
}
Index: test/webapp/jsp
===
--- test/webapp/jsp (revision 0)
+++ test/webapp/jsp (working copy)
Property changes on: test/webapp/jsp
___
Added: bugtraq:label
## -0,0 +1 ##
+Bugzilla ID (optional)
\ No newline at end of property
Added: bugtraq:url
## -0,0 +1 ##
+https://issues.apache.org/bugzilla/show_bug.cgi?id=%BUGID%
\ No newline at end of property
Added: bugtraq:message
## -0,0 +1 ##
+Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=%BUGID%
\ No newline at end of property
Added: bugtraq:append
## -0,0 +1 ##
+false
\ No newline at end of property
Index: test/webapp/jsp/test.jsp
===
--- test/webapp/jsp/test.jsp(revision 0)
+++ test/webapp/jsp/test.jsp(working copy)
@@ -0,0 +1,2 @@
+%@ page contentType=text/plain %
+%@ taglib uri=../WEB-INF/test.tld prefix=test %
\ No newline at end of file
Index: test/webapp/jsp/test.jsp
===
--- test/webapp/jsp/test.jsp(revision 0)
+++ test/webapp/jsp/test.jsp(working copy)
Property changes on: test/webapp/jsp/test.jsp
___
Added: svn:eol-style
## -0,0 +1 ##
+native
\ No newline at end of property
Re: [VOTE] Release Apache Tomcat 8.0.0-RC7
2013/12/13 Violeta Georgieva miles...@gmail.com I'm receiving NPE when testing an application with jsp that specifies tld location with relative path: java.lang.NullPointerException org.apache.jasper.compiler.TldCache.getTaglibXml(TldCache.java:97) org.apache.jasper.compiler.TagLibraryInfoImpl.init(TagLibraryInfoImpl.java:150) org.apache.jasper.compiler.Parser.parseTaglibDirective(Parser.java:411) org.apache.jasper.compiler.Parser.parseDirective(Parser.java:469) org.apache.jasper.compiler.Parser.parseElements(Parser.java:1455) org.apache.jasper.compiler.Parser.parse(Parser.java:139) org.apache.jasper.compiler.ParserController.doParse(ParserController.java:229) org.apache.jasper.compiler.ParserController.parse(ParserController.java:100) org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:200) org.apache.jasper.compiler.Compiler.compile(Compiler.java:375) org.apache.jasper.compiler.Compiler.compile(Compiler.java:355) org.apache.jasper.compiler.Compiler.compile(Compiler.java:342) org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:557) There used to be some normalization code for the taglib uri, like uri = RequestUtil.normalize(uri); in TagLibraryInfoImpl.generateTLDLocation (now generateTldResourcePath), and since the uri is used to match the catch entry, I don't see how it can work without it. I'll add it back. Rémy
Re: [VOTE] Release Apache Tomcat 8.0.0-RC7
2013/12/12 Mark Thomas ma...@apache.org
The proposed Apache Tomcat 8.0.0 release candidate 7 is now available
for voting.
Given this is a release candidate I am working on the basis that it is
equivalent to an alpha. The main changes since RC5 are:
- Better handling of generic types in the WebSocket 1.0 implementation
- Refactor resource handling for the class loader
- Add Cobertura support to the unit tests
- Remove anti-Jar locking feature and replace it with open stream
tracking
- Update to Commons Pool 2.0 release
- Complete refactoring of TLD handling including caching of parsed TLDs
- More consistent handling of XML validation options
- Much more detailed visibility of DBCP connections pools in JMX
- Better organisation of JMX beans in the default JConsole view
- Numerous bug fixes
It can be obtained from:
https://dist.apache.org/repos/dist/dev/tomcat/tomcat-8/v8.0.0-RC7/
The Maven staging repo is:
https://repository.apache.org/content/repositories/orgapachetomcat-047/
The svn tag is:
http://svn.apache.org/repos/asf/tomcat/tags/TOMCAT_8_0_0_RC6/
The proposed 8.0.0-RC7 release is:
[ ] Broken - do not release
[ ] Alpha - go ahead and release as 8.0.0-RC7 alpha
I found another issue:
If a tag file is placed in a jar file in WEB-INF/lib and then is used, the
following exception appears:
org.apache.jasper.JasperException: Illegal tag file path:
/META-INF/tags/my.tag, must start with /WEB-INF/tags or /META-INF/tags
org.apache.jasper.compiler.DefaultErrorHandler.jspError(DefaultErrorHandler.java:56)
org.apache.jasper.compiler.ErrorDispatcher.dispatch(ErrorDispatcher.java:278)
org.apache.jasper.compiler.ErrorDispatcher.jspError(ErrorDispatcher.java:76)
org.apache.jasper.compiler.TagLibraryInfoImpl.createTagFileInfo(TagLibraryInfoImpl.java:287)
org.apache.jasper.compiler.TagLibraryInfoImpl.init(TagLibraryInfoImpl.java:171)
org.apache.jasper.compiler.Parser.parseTaglibDirective(Parser.java:411)
org.apache.jasper.compiler.Parser.parseDirective(Parser.java:469)
org.apache.jasper.compiler.Parser.parseElements(Parser.java:1455)
org.apache.jasper.compiler.Parser.parse(Parser.java:139)
org.apache.jasper.compiler.ParserController.doParse(ParserController.java:229)
org.apache.jasper.compiler.ParserController.parse(ParserController.java:100)
org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:200)
org.apache.jasper.compiler.Compiler.compile(Compiler.java:375)
org.apache.jasper.compiler.Compiler.compile(Compiler.java:355)
org.apache.jasper.compiler.Compiler.compile(Compiler.java:342)
org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:557)
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:357)
The change in the code is introduced with r1541960
Besides that the message is wrong because we check only for WEB-INF/tags
[1], what should be done in addition?
[1]
org.apache.jasper.compiler.TagLibraryInfoImpl.createTagFileInfo(TagFileXml,
Jar)
286} else if (!path.startsWith(/WEB-INF/tags)) {
287err.jspError(jsp.error.tagfile.illegalPath, path);
288}
Re: [VOTE] Release Apache Tomcat 8.0.0-RC7
2013/12/13 Violeta Georgieva miles...@gmail.com
I found another issue:
If a tag file is placed in a jar file in WEB-INF/lib and then is used, the
The change in the code is introduced with r1541960
Besides that the message is wrong because we check only for WEB-INF/tags
[1], what should be done in addition?
[1]
org.apache.jasper.compiler.TagLibraryInfoImpl.createTagFileInfo(TagFileXml,
Jar)
286} else if (!path.startsWith(/WEB-INF/tags)) {
287err.jspError(jsp.error.tagfile.illegalPath, path);
288}
It looks like the condition was not refactored correctly.
Rémy
Re: [VOTE] Release Apache Tomcat 8.0.0-RC7
On 13/12/2013 14:35, Rémy Maucherat wrote:
2013/12/13 Violeta Georgieva miles...@gmail.com
I found another issue:
If a tag file is placed in a jar file in WEB-INF/lib and then is used, the
The change in the code is introduced with r1541960
Besides that the message is wrong because we check only for WEB-INF/tags
[1], what should be done in addition?
[1]
org.apache.jasper.compiler.TagLibraryInfoImpl.createTagFileInfo(TagFileXml,
Jar)
286} else if (!path.startsWith(/WEB-INF/tags)) {
287err.jspError(jsp.error.tagfile.illegalPath, path);
288}
It looks like the condition was not refactored correctly.
Thanks for the fix. I'll roll an RC8 later today.
Mark
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat 8.0.0-RC7
2013/12/13 Rémy Maucherat r...@apache.org
2013/12/13 Violeta Georgieva miles...@gmail.com
I found another issue:
If a tag file is placed in a jar file in WEB-INF/lib and then is used,
the
The change in the code is introduced with r1541960
Besides that the message is wrong because we check only for WEB-INF/tags
[1], what should be done in addition?
[1]
org.apache.jasper.compiler.TagLibraryInfoImpl.createTagFileInfo(TagFileXml,
Jar)
286} else if (!path.startsWith(/WEB-INF/tags)) {
287err.jspError(jsp.error.tagfile.illegalPath, path);
288}
It looks like the condition was not refactored correctly.
Unfortunately with that fix I'm receiving FNF:
java.io.FileNotFoundException: /META-INF/tags/my.tag
org.apache.jasper.servlet.JspServletWrapper.loadTagFile(JspServletWrapper.java:235)
org.apache.jasper.compiler.TagFileProcessor.loadTagFile(TagFileProcessor.java:579)
org.apache.jasper.compiler.TagFileProcessor.access$000(TagFileProcessor.java:50)
org.apache.jasper.compiler.TagFileProcessor$TagFileLoaderVisitor.visit(TagFileProcessor.java:661)
org.apache.jasper.compiler.Node$CustomTag.accept(Node.java:1521)
org.apache.jasper.compiler.Node$Nodes.visit(Node.java:2359)
org.apache.jasper.compiler.Node$Visitor.visitBody(Node.java:2411)
org.apache.jasper.compiler.Node$Visitor.visit(Node.java:2417)
org.apache.jasper.compiler.Node$Root.accept(Node.java:464)
org.apache.jasper.compiler.Node$Nodes.visit(Node.java:2359)
org.apache.jasper.compiler.TagFileProcessor.loadTagFiles(TagFileProcessor.java:679)
org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:231)
org.apache.jasper.compiler.Compiler.compile(Compiler.java:375)
org.apache.jasper.compiler.Compiler.compile(Compiler.java:355)
org.apache.jasper.compiler.Compiler.compile(Compiler.java:342)
org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:557)
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:357)
I'll try to create a test case for that.
Re: [VOTE] Release Apache Tomcat 8.0.0-RC7
2013/12/13 Violeta Georgieva miles...@gmail.com
Unfortunately with that fix I'm receiving FNF:
java.io.FileNotFoundException: /META-INF/tags/my.tag
org.apache.jasper.servlet.JspServletWrapper.loadTagFile(JspServletWrapper.java:235)
org.apache.jasper.compiler.TagFileProcessor.loadTagFile(TagFileProcessor.java:579)
org.apache.jasper.compiler.TagFileProcessor.access$000(TagFileProcessor.java:50)
org.apache.jasper.compiler.TagFileProcessor$TagFileLoaderVisitor.visit(TagFileProcessor.java:661)
org.apache.jasper.compiler.Node$CustomTag.accept(Node.java:1521)
org.apache.jasper.compiler.Node$Nodes.visit(Node.java:2359)
org.apache.jasper.compiler.Node$Visitor.visitBody(Node.java:2411)
org.apache.jasper.compiler.Node$Visitor.visit(Node.java:2417)
org.apache.jasper.compiler.Node$Root.accept(Node.java:464)
org.apache.jasper.compiler.Node$Nodes.visit(Node.java:2359)
org.apache.jasper.compiler.TagFileProcessor.loadTagFiles(TagFileProcessor.java:679)
org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:231)
org.apache.jasper.compiler.Compiler.compile(Compiler.java:375)
org.apache.jasper.compiler.Compiler.compile(Compiler.java:355)
org.apache.jasper.compiler.Compiler.compile(Compiler.java:342)
org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:557)
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:357)
I'll try to create a test case for that.
The JspCompilationContext used to keep a map of the JarResource
corresponding to the tags:
public JarResource getTagFileJarResource(String tagFile) {
return this.tagFileJarUrls.get(tagFile);
}
public void setTagFileJarResource(String tagFile, JarResource
jarResource) {
this.tagFileJarUrls.put(tagFile, jarResource);
}
This was set in TagLibraryInfoImpl.createTagFileInfo and then used by the
TagFileProcessor.loadTagFile. This should be ok without it because the code
keeps around the Jar instead and uses the entry name now, but apparently
something is still missing and the removed flag gets set (this is what
causes this exception).
So I guess add a test, it can't hurt.
Rémy
Re: [VOTE] Release Apache Tomcat 8.0.0-RC7
2013/12/13 Rémy Maucherat r...@apache.org
2013/12/13 Violeta Georgieva miles...@gmail.com
Unfortunately with that fix I'm receiving FNF:
java.io.FileNotFoundException: /META-INF/tags/my.tag
org.apache.jasper.servlet.JspServletWrapper.loadTagFile(JspServletWrapper.java:235)
org.apache.jasper.compiler.TagFileProcessor.loadTagFile(TagFileProcessor.java:579)
org.apache.jasper.compiler.TagFileProcessor.access$000(TagFileProcessor.java:50)
org.apache.jasper.compiler.TagFileProcessor$TagFileLoaderVisitor.visit(TagFileProcessor.java:661)
org.apache.jasper.compiler.Node$CustomTag.accept(Node.java:1521)
org.apache.jasper.compiler.Node$Nodes.visit(Node.java:2359)
org.apache.jasper.compiler.Node$Visitor.visitBody(Node.java:2411)
org.apache.jasper.compiler.Node$Visitor.visit(Node.java:2417)
org.apache.jasper.compiler.Node$Root.accept(Node.java:464)
org.apache.jasper.compiler.Node$Nodes.visit(Node.java:2359)
org.apache.jasper.compiler.TagFileProcessor.loadTagFiles(TagFileProcessor.java:679)
org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:231)
org.apache.jasper.compiler.Compiler.compile(Compiler.java:375)
org.apache.jasper.compiler.Compiler.compile(Compiler.java:355)
org.apache.jasper.compiler.Compiler.compile(Compiler.java:342)
org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:557)
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:357)
I'll try to create a test case for that.
The JspCompilationContext used to keep a map of the JarResource
corresponding to the tags:
public JarResource getTagFileJarResource(String tagFile) {
return this.tagFileJarUrls.get(tagFile);
}
public void setTagFileJarResource(String tagFile, JarResource
jarResource) {
this.tagFileJarUrls.put(tagFile, jarResource);
}
This was set in TagLibraryInfoImpl.createTagFileInfo and then used by the
TagFileProcessor.loadTagFile. This should be ok without it because the
code
keeps around the Jar instead and uses the entry name now, but apparently
something is still missing and the removed flag gets set (this is what
causes this exception).
So I guess add a test, it can't hurt.
Here [1] is the test
[1] https://www.dropbox.com/s/3zd106lpqfb3ytv/test.zip
Re: [VOTE] Release Apache Tomcat 8.0.0-RC7
2013/12/13 Violeta Georgieva miles...@gmail.com Here [1] is the test [1] https://www.dropbox.com/s/3zd106lpqfb3ytv/test.zip Fixed. I didn't add the test yet since I suppose adding a binary should be avoided. Rémy
Re: [VOTE] Release Apache Tomcat 8.0.0-RC7
2013/12/13 Rémy Maucherat r...@apache.org 2013/12/13 Violeta Georgieva miles...@gmail.com Here [1] is the test [1] https://www.dropbox.com/s/3zd106lpqfb3ytv/test.zip Fixed. I didn't add the test yet since I suppose adding a binary should be avoided. Thanks it is working now.
Re: [VOTE] Release Apache Tomcat 8.0.0-RC7
On Dec 11, 2013, at 6:24 PM, Mark Thomas ma...@apache.org wrote: The proposed Apache Tomcat 8.0.0 release candidate 7 is now available for voting. Given this is a release candidate I am working on the basis that it is equivalent to an alpha. The main changes since RC5 are: - Better handling of generic types in the WebSocket 1.0 implementation - Refactor resource handling for the class loader - Add Cobertura support to the unit tests - Remove anti-Jar locking feature and replace it with open stream tracking - Update to Commons Pool 2.0 release - Complete refactoring of TLD handling including caching of parsed TLDs - More consistent handling of XML validation options - Much more detailed visibility of DBCP connections pools in JMX - Better organisation of JMX beans in the default JConsole view - Numerous bug fixes It can be obtained from: https://dist.apache.org/repos/dist/dev/tomcat/tomcat-8/v8.0.0-RC7/ The Maven staging repo is: https://repository.apache.org/content/repositories/orgapachetomcat-047/ The svn tag is: http://svn.apache.org/repos/asf/tomcat/tags/TOMCAT_8_0_0_RC6/ The proposed 8.0.0-RC7 release is: [ ] Broken - do not release [X] Alpha - go ahead and release as 8.0.0-RC7 alpha Ran some basic tests with non-blocking io, web sockets and EL 3.0. All worked fine. Dan Cheers, 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: [VOTE] Release Apache Tomcat 8.0.0-RC7
On 2013-12-11 6:24 PM, Mark Thomas wrote: The proposed 8.0.0-RC7 release is: [ ] Broken - do not release [X] Alpha - go ahead and release as 8.0.0-RC7 alpha -- Jeanfrancois - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat 8.0.0-RC7
On 11/12/2013 23:24, Mark Thomas wrote: The proposed Apache Tomcat 8.0.0 release candidate 7 is now available for voting. Given this is a release candidate I am working on the basis that it is equivalent to an alpha. The main changes since RC5 are: - Better handling of generic types in the WebSocket 1.0 implementation - Refactor resource handling for the class loader - Add Cobertura support to the unit tests - Remove anti-Jar locking feature and replace it with open stream tracking - Update to Commons Pool 2.0 release - Complete refactoring of TLD handling including caching of parsed TLDs - More consistent handling of XML validation options - Much more detailed visibility of DBCP connections pools in JMX - Better organisation of JMX beans in the default JConsole view - Numerous bug fixes It can be obtained from: https://dist.apache.org/repos/dist/dev/tomcat/tomcat-8/v8.0.0-RC7/ The Maven staging repo is: https://repository.apache.org/content/repositories/orgapachetomcat-047/ The svn tag is: http://svn.apache.org/repos/asf/tomcat/tags/TOMCAT_8_0_0_RC7/ The proposed 8.0.0-RC7 release is: [ ] Broken - do not release [X] Alpha - go ahead and release as 8.0.0-RC7 alpha Unit tests pass on Windows, Linux and OSX. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat 8.0.0-RC7
2013/12/12 Mark Thomas ma...@apache.org The proposed Apache Tomcat 8.0.0 release candidate 7 is now available for voting. Given this is a release candidate I am working on the basis that it is equivalent to an alpha. The main changes since RC5 are: - Better handling of generic types in the WebSocket 1.0 implementation - Refactor resource handling for the class loader - Add Cobertura support to the unit tests - Remove anti-Jar locking feature and replace it with open stream tracking - Update to Commons Pool 2.0 release - Complete refactoring of TLD handling including caching of parsed TLDs - More consistent handling of XML validation options - Much more detailed visibility of DBCP connections pools in JMX - Better organisation of JMX beans in the default JConsole view - Numerous bug fixes It can be obtained from: https://dist.apache.org/repos/dist/dev/tomcat/tomcat-8/v8.0.0-RC7/ The Maven staging repo is: https://repository.apache.org/content/repositories/orgapachetomcat-047/ The svn tag is: http://svn.apache.org/repos/asf/tomcat/tags/TOMCAT_8_0_0_RC6/ The proposed 8.0.0-RC7 release is: [ ] Broken - do not release [X] Alpha - go ahead and release as 8.0.0-RC7 alpha +1 Tested on some test applications (use DeltaManager and BackupManager). -- Keiichi.Fujino
[VOTE] Release Apache Tomcat 8.0.0-RC7
The proposed Apache Tomcat 8.0.0 release candidate 7 is now available for voting. Given this is a release candidate I am working on the basis that it is equivalent to an alpha. The main changes since RC5 are: - Better handling of generic types in the WebSocket 1.0 implementation - Refactor resource handling for the class loader - Add Cobertura support to the unit tests - Remove anti-Jar locking feature and replace it with open stream tracking - Update to Commons Pool 2.0 release - Complete refactoring of TLD handling including caching of parsed TLDs - More consistent handling of XML validation options - Much more detailed visibility of DBCP connections pools in JMX - Better organisation of JMX beans in the default JConsole view - Numerous bug fixes It can be obtained from: https://dist.apache.org/repos/dist/dev/tomcat/tomcat-8/v8.0.0-RC7/ The Maven staging repo is: https://repository.apache.org/content/repositories/orgapachetomcat-047/ The svn tag is: http://svn.apache.org/repos/asf/tomcat/tags/TOMCAT_8_0_0_RC6/ The proposed 8.0.0-RC7 release is: [ ] Broken - do not release [ ] Alpha - go ahead and release as 8.0.0-RC7 alpha Cheers, Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat 8.0.0-RC7
On 11/12/2013 23:24, Mark Thomas wrote: The proposed Apache Tomcat 8.0.0 release candidate 7 is now available for voting. Given this is a release candidate I am working on the basis that it is equivalent to an alpha. The main changes since RC5 are: - Better handling of generic types in the WebSocket 1.0 implementation - Refactor resource handling for the class loader - Add Cobertura support to the unit tests - Remove anti-Jar locking feature and replace it with open stream tracking - Update to Commons Pool 2.0 release - Complete refactoring of TLD handling including caching of parsed TLDs - More consistent handling of XML validation options - Much more detailed visibility of DBCP connections pools in JMX - Better organisation of JMX beans in the default JConsole view - Numerous bug fixes It can be obtained from: https://dist.apache.org/repos/dist/dev/tomcat/tomcat-8/v8.0.0-RC7/ The Maven staging repo is: https://repository.apache.org/content/repositories/orgapachetomcat-047/ The svn tag is: http://svn.apache.org/repos/asf/tomcat/tags/TOMCAT_8_0_0_RC6/ Bah - missed one, That should be: http://svn.apache.org/repos/asf/tomcat/tags/TOMCAT_8_0_0_RC7/ Mark The proposed 8.0.0-RC7 release is: [ ] Broken - do not release [ ] Alpha - go ahead and release as 8.0.0-RC7 alpha Cheers, 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
