Re: [VOTE] Release Apache Tomcat 7.0.4
On 19/10/2010 08:56, Mark Thomas wrote: Ping. Just a gentle reminder that there are ~2 days left for this vote. So far we have 1 vote for beta and no other votes. Sorry - it should have said ~1 day above. I've been traveling and got my dates mixed up. I'll leave the vote open for another 24 hours or so. Currently there are 4 votes for beta (2*PMC, 1*committer, 1*contributor) so we need at least 1 more PMC vote in order to proceed with this release. 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 7.0.4
On 10/20/2010 5:45 AM, Mark Thomas wrote: On 19/10/2010 08:56, Mark Thomas wrote: Ping. Just a gentle reminder that there are ~2 days left for this vote. So far we have 1 vote for beta and no other votes. Sorry - it should have said ~1 day above. I've been traveling and got my dates mixed up. I'll leave the vote open for another 24 hours or so. Currently there are 4 votes for beta (2*PMC, 1*committer, 1*contributor) so we need at least 1 more PMC vote in order to proceed with this release. As someone trying to figure out when to take the plunge into Tomcat 7, but needing something that is definitely stable, is there any sort of list as to what hurdles remain to be cleared before considering Tomcat 7 is considered stable? I'm not trying to rush anyone (most especially a premature labeling of Tomcat 7 as stable), but some insight into the remaining gap between Tomcat 7 and stability would be helpful to me -- and others as well, I suspect. If there's just a collective gut feeling that more experience with Tomcat 7 is needed prior to feeling comfortable with a stable label that's fine, of course, but right now I have no sense as to what makes Tomcat 7 still a beta at this point. -- Jess Holle - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat 7.0.4
On 20/10/2010 06:39, Jess Holle wrote: On 10/20/2010 5:45 AM, Mark Thomas wrote: On 19/10/2010 08:56, Mark Thomas wrote: Ping. Just a gentle reminder that there are ~2 days left for this vote. So far we have 1 vote for beta and no other votes. Sorry - it should have said ~1 day above. I've been traveling and got my dates mixed up. I'll leave the vote open for another 24 hours or so. Currently there are 4 votes for beta (2*PMC, 1*committer, 1*contributor) so we need at least 1 more PMC vote in order to proceed with this release. As someone trying to figure out when to take the plunge into Tomcat 7, but needing something that is definitely stable, is there any sort of list as to what hurdles remain to be cleared before considering Tomcat 7 is considered stable? My own view is that to be considered stable, Tomcat 7 needs to meet the following criteria: 1. Implement all aspects of Servlet 3.0, JSP 2.2, EL 2.2 2. Pass all unit tests with all three HTTP connectors 4. Pass all relevant TCKs with the security manager enabled - Servlet TCK with all three HTTP connectors and both AJP connectors - JSP TCK with any connector - EL TCK (doesn't use web requests) 4. Have no 'significant' open bugs 5. Have reasonable adoption 6. Have a couple of releases with no 'serious' bugs emerging In term of progress: 1. Done (to the best of my knowledge). 2. It does. 3. It does (as have all 7.0.x releases). 4. There is currently 1 (yes one!) open bug without a patch across 5.5.x, 6.0.x and 7.0.x so I think we can call this one done. 5. Based on some analysis of download requests and the number and quality of bug reports I am happy that there is reasonable adoption at this stage. 6. I see this as the only thing between 7.0.x and stability. Serious is subjective but the sort of things I would include are: - anything that requires a major refactoring to fix - anything that breaks typical use cases As an example, I would consider another bug 49884 serious due to both the async issues it caused and the scale of the refactoring required to fix. I wouldn't consider another 50072 serious mainly because that issue has been present in the 6.0.x code base and hasn't been a problem (at least not one folks have reported). So in summary, if 7.0.4 and 7.0.5 go well, things are looking good for 7.0.6. HTH, 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 7.0.4
Thanks for the detailed reply! On 10/20/2010 7:03 AM, Mark Thomas wrote: On 20/10/2010 06:39, Jess Holle wrote: On 10/20/2010 5:45 AM, Mark Thomas wrote: On 19/10/2010 08:56, Mark Thomas wrote: Ping. Just a gentle reminder that there are ~2 days left for this vote. So far we have 1 vote for beta and no other votes. Sorry - it should have said ~1 day above. I've been traveling and got my dates mixed up. I'll leave the vote open for another 24 hours or so. Currently there are 4 votes for beta (2*PMC, 1*committer, 1*contributor) so we need at least 1 more PMC vote in order to proceed with this release. As someone trying to figure out when to take the plunge into Tomcat 7, but needing something that is definitely stable, is there any sort of list as to what hurdles remain to be cleared before considering Tomcat 7 is considered stable? My own view is that to be considered stable, Tomcat 7 needs to meet the following criteria: 1. Implement all aspects of Servlet 3.0, JSP 2.2, EL 2.2 2. Pass all unit tests with all three HTTP connectors 4. Pass all relevant TCKs with the security manager enabled - Servlet TCK with all three HTTP connectors and both AJP connectors - JSP TCK with any connector - EL TCK (doesn't use web requests) 4. Have no 'significant' open bugs 5. Have reasonable adoption 6. Have a couple of releases with no 'serious' bugs emerging In term of progress: 1. Done (to the best of my knowledge). 2. It does. 3. It does (as have all 7.0.x releases). 4. There is currently 1 (yes one!) open bug without a patch across 5.5.x, 6.0.x and 7.0.x so I think we can call this one done. 5. Based on some analysis of download requests and the number and quality of bug reports I am happy that there is reasonable adoption at this stage. 6. I see this as the only thing between 7.0.x and stability. Serious is subjective but the sort of things I would include are: - anything that requires a major refactoring to fix - anything that breaks typical use cases As an example, I would consider another bug 49884 serious due to both the async issues it caused and the scale of the refactoring required to fix. I wouldn't consider another 50072 serious mainly because that issue has been present in the 6.0.x code base and hasn't been a problem (at least not one folks have reported). So in summary, if 7.0.4 and 7.0.5 go well, things are looking good for 7.0.6. HTH, 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 7.0.4
On 20.10.2010 14:03, Mark Thomas wrote: On 20/10/2010 06:39, Jess Holle wrote: On 10/20/2010 5:45 AM, Mark Thomas wrote: On 19/10/2010 08:56, Mark Thomas wrote: Ping. Just a gentle reminder that there are ~2 days left for this vote. So far we have 1 vote for beta and no other votes. Sorry - it should have said ~1 day above. I've been traveling and got my dates mixed up. I'll leave the vote open for another 24 hours or so. Currently there are 4 votes for beta (2*PMC, 1*committer, 1*contributor) so we need at least 1 more PMC vote in order to proceed with this release. As someone trying to figure out when to take the plunge into Tomcat 7, but needing something that is definitely stable, is there any sort of list as to what hurdles remain to be cleared before considering Tomcat 7 is considered stable? My own view is that to be considered stable, Tomcat 7 needs to meet the following criteria: 1. Implement all aspects of Servlet 3.0, JSP 2.2, EL 2.2 2. Pass all unit tests with all three HTTP connectors 4. Pass all relevant TCKs with the security manager enabled - Servlet TCK with all three HTTP connectors and both AJP connectors - JSP TCK with any connector - EL TCK (doesn't use web requests) 4. Have no 'significant' open bugs 5. Have reasonable adoption 6. Have a couple of releases with no 'serious' bugs emerging In term of progress: 1. Done (to the best of my knowledge). 2. It does. 3. It does (as have all 7.0.x releases). 4. There is currently 1 (yes one!) open bug without a patch across 5.5.x, 6.0.x and 7.0.x so I think we can call this one done. 5. Based on some analysis of download requests and the number and quality of bug reports I am happy that there is reasonable adoption at this stage. 6. I see this as the only thing between 7.0.x and stability. Serious is subjective but the sort of things I would include are: - anything that requires a major refactoring to fix - anything that breaks typical use cases As an example, I would consider another bug 49884 serious due to both the async issues it caused and the scale of the refactoring required to fix. I wouldn't consider another 50072 serious mainly because that issue has been present in the 6.0.x code base and hasn't been a problem (at least not one folks have reported). So in summary, if 7.0.4 and 7.0.5 go well, things are looking good for 7.0.6. For what its worth: I fully agree. The biggest reason why 7.0.4 shouldn't already be stable is the major refactoring that was necessary lately. If 7.0.4 survives the real adoption without serious bugs in the definition of Mark, I guess we could have a stable in about a month. Don't know whether we actually need many more betas (in the sense of a couple), but we might need to wait a bit to gather feedback. If fixing minor problems and adding minor features stays at middle to high rate we might want to release often to catch anything important early. And yes: I'll add my vote until tomorrow, expecting beta. Regards, Rainer - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat 7.0.4
On Oct 20, 2010, at 5:03 AM, Mark Thomas wrote: On 20/10/2010 06:39, Jess Holle wrote: On 10/20/2010 5:45 AM, Mark Thomas wrote: On 19/10/2010 08:56, Mark Thomas wrote: Ping. Just a gentle reminder that there are ~2 days left for this vote. So far we have 1 vote for beta and no other votes. Sorry - it should have said ~1 day above. I've been traveling and got my dates mixed up. I'll leave the vote open for another 24 hours or so. Currently there are 4 votes for beta (2*PMC, 1*committer, 1*contributor) so we need at least 1 more PMC vote in order to proceed with this release. As someone trying to figure out when to take the plunge into Tomcat 7, but needing something that is definitely stable, is there any sort of list as to what hurdles remain to be cleared before considering Tomcat 7 is considered stable? My own view is that to be considered stable, Tomcat 7 needs to meet the following criteria: 1. Implement all aspects of Servlet 3.0, JSP 2.2, EL 2.2 2. Pass all unit tests with all three HTTP connectors 4. Pass all relevant TCKs with the security manager enabled - Servlet TCK with all three HTTP connectors and both AJP connectors - JSP TCK with any connector - EL TCK (doesn't use web requests) 4. Have no 'significant' open bugs 5. Have reasonable adoption 6. Have a couple of releases with no 'serious' bugs emerging In term of progress: 1. Done (to the best of my knowledge). I don't think tomcat is processing security constraints added through ServletRegistration. I added some hooks in one of my patches so the info got to an appropriate class but only implemented the actual processing in geronimo. see https://issues.apache.org/bugzilla/show_bug.cgi?id=50015 thanks david jencks 2. It does. 3. It does (as have all 7.0.x releases). 4. There is currently 1 (yes one!) open bug without a patch across 5.5.x, 6.0.x and 7.0.x so I think we can call this one done. 5. Based on some analysis of download requests and the number and quality of bug reports I am happy that there is reasonable adoption at this stage. 6. I see this as the only thing between 7.0.x and stability. Serious is subjective but the sort of things I would include are: - anything that requires a major refactoring to fix - anything that breaks typical use cases As an example, I would consider another bug 49884 serious due to both the async issues it caused and the scale of the refactoring required to fix. I wouldn't consider another 50072 serious mainly because that issue has been present in the 6.0.x code base and hasn't been a problem (at least not one folks have reported). So in summary, if 7.0.4 and 7.0.5 go well, things are looking good for 7.0.6. HTH, 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 7.0.4
On 15.10.2010 10:47, Mark Thomas wrote: The proposed 7.0.4 release is: [X] Beta - go ahead and release as 7.0.4 Beta - Checksums and Signatures OK - Identity between Unix and Windows files and subversion fine Minor observations: - extras build couldn't download the servlet api jar from the maven repos. Folder http://repo1.maven.org/maven/servletapi/jars/; is empty at the moment. Alternatively it seems http://repo1.maven.org/maven2/javax/servlet/servlet-api/2.3/ could be used? - one test failed because my rusty Solaris 8 Sparc system testing on top of NFS is to slow: Testsuite: org.apache.tomcat.util.http.mapper.TestMapper Tests run: 3, Failures: 1, Errors: 0, Time elapsed: 7.298 sec Testcase: testAddHost took 0.074 sec Testcase: testMap took 0.04 sec Testcase: testPerformance took 7.111 sec »···FAILED null junit.framework.AssertionFailedError »···at org.apache.tomcat.util.http.mapper.TestMapper.testPerformance(TestMapper.java:145) It took 7.1 seconds, allowed are only 3 seconds. There wont be an optimal solution here. Thanks for pushing TC 7! Rainer - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat 7.0.4
On 15/10/2010 12:20, Mark Thomas wrote: On 15/10/2010 09:47, Mark Thomas wrote: The proposed Apache Tomcat 7.0.4 release is now available for voting. It can be obtained from: http://people.apache.org/~markt/dev/tomcat-7/v7.0.4/ The svn tag is: http://svn.apache.org/repos/asf/tomcat/tc7.0.x/tags/TOMCAT_7_0_4/ As with previous votes, I have included a stable option below although my personal inclination is still to vote beta. The proposed 7.0.4 release is: [ ] Broken - do not release [ ] Alpha - go ahead and release as 7.0.4 Alpha [X] Beta - go ahead and release as 7.0.4 Beta [ ] Stable - go ahead and release as 7.0.4 Stable This vote will run until 10.00 UTC Wednesday 20th October (3 working days). Sevlet TCK passes with security manager for HTTP BIO, NIO APR/native Sevlet TCK passes with security manager for AJP BIO APR/native JSP TCK passes with security manager EL TCK passes with security manager The bug count is currently nice and low. If we don't see any nasty issues between this and the next release I'd be tempted to start voting stable. Ping. Just a gentle reminder that there are ~2 days left for this vote. So far we have 1 vote for beta and no other votes. 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 7.0.4
+1 Beta On Fri, Oct 15, 2010 at 4:47 AM, Mark Thomas ma...@apache.org wrote: The proposed Apache Tomcat 7.0.4 release is now available for voting. It can be obtained from: http://people.apache.org/~markt/dev/tomcat-7/v7.0.4/http://people.apache.org/%7Emarkt/dev/tomcat-7/v7.0.4/ The svn tag is: http://svn.apache.org/repos/asf/tomcat/tc7.0.x/tags/TOMCAT_7_0_4/ As with previous votes, I have included a stable option below although my personal inclination is still to vote beta. The proposed 7.0.4 release is: [ ] Broken - do not release [ ] Alpha - go ahead and release as 7.0.4 Alpha [X] Beta - go ahead and release as 7.0.4 Beta [ ] Stable - go ahead and release as 7.0.4 Stable This vote will run until 10.00 UTC Wednesday 20th October (3 working days). 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 7.0.4
+1 Beta The proposed 7.0.4 release is: [ ] Broken - do not release [ ] Alpha - go ahead and release as 7.0.4 Alpha [x ] Beta - go ahead and release as 7.0.4 Beta [ ] Stable - go ahead and release as 7.0.4 Stable - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat 7.0.4
[X] Beta - go ahead and release as 7.0.4 Beta -Tim On 10/15/2010 4:47 AM, Mark Thomas wrote: The proposed Apache Tomcat 7.0.4 release is now available for voting. It can be obtained from: http://people.apache.org/~markt/dev/tomcat-7/v7.0.4/ The svn tag is: http://svn.apache.org/repos/asf/tomcat/tc7.0.x/tags/TOMCAT_7_0_4/ As with previous votes, I have included a stable option below although my personal inclination is still to vote beta. The proposed 7.0.4 release is: [ ] Broken - do not release [ ] Beta - go ahead and release as 7.0.4 Beta [ ] Alpha - go ahead and release as 7.0.4 Alpha [ ] Stable - go ahead and release as 7.0.4 Stable This vote will run until 10.00 UTC Wednesday 20th October (3 working days). - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat 7.0.4
On Sun, 2010-10-17 at 22:38 +0100, Mark Thomas wrote: Yes, this is stupid but it is what the spec requires. I have to disagree, there was agreement in the expert group that wildcard mappings and welcome files cannot be mixed at the moment, unless for specific proprietary hacks, or if a static file is present. Rémy - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat 7.0.4
On 18/10/2010 16:34, Remy Maucherat wrote: On Sun, 2010-10-17 at 22:38 +0100, Mark Thomas wrote: Yes, this is stupid but it is what the spec requires. I have to disagree, there was agreement in the expert group that wildcard mappings and welcome files cannot be mixed at the moment, unless for specific proprietary hacks, or if a static file is present. Knowing what the expert group agreed is helpful in deciding how we might handle this mess but it remains the case the the specification says the exact opposite of your statement above. Mar - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat 7.0.4
Indeed, that's the problem I'm facing. After spending some time reading the spec and the comments in both bug reports, I'm inclined to believe that the current behavior of tomcat 7.0.4 is not spec compliant. I created a webapp that matches the example given in chapter 10.10 (Welcome files) of the spec. The files are the same, and my web.xml is like this : web-app xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xmlns=http://java.sun.com/xml/ns/javaee; xmlns:web=http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd; xsi:schemaLocation=http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd; id=WebApp_ID version=2.5 display-nametestWelcomeFiles/display-name welcome-file-list welcome-fileindex.html/welcome-file welcome-filedefault.jsp/welcome-file /welcome-file-list servlet description/description display-nameMyDefaultServlet/display-name servlet-nameMyDefaultServlet/servlet-name servlet-classtest.MyDefaultServlet/servlet-class /servlet servlet-mapping servlet-nameMyDefaultServlet/servlet-name url-pattern//url-pattern /servlet-mapping /web-app All the behaviors described in the spec are OK except this one : A request URI of /catalog/products/ will be passed to the “default” servlet, if any. Despite having declared a default servlet (as defined in section 12.2), it was not called when requesting catalog/products/ and I got a 404 instead... Sylvain On 16 oct. 2010, at 21:36, Mark Thomas wrote: On 15/10/2010 22:01, Sylvain Laurent wrote: I just played with a Roo application and I get a 404 with 7.0.4 whereas the very same application works OK with 6.0.29. I'll try to investigate this week-end. Best guess without seeing the app is https://issues.apache.org/bugzilla/show_bug.cgi?id=49422 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 7.0.4
the same example works OK with jetty 7.1.6 and GlassFish 3.0.1... And there's also a difference of behavior between tc7.0.4 and those 2 others : Let's suppose we have the follwoing web.xml welcome-file-list welcome-filedefault.dummy/welcome-file /welcome-file-list servlet description/description servlet-nameMyDummyServlet/servlet-name servlet-classtest.MyDummyServlet/servlet-class /servlet servlet-mapping servlet-nameMyDummyServlet/servlet-name url-pattern*.dummy/url-pattern /servlet-mapping servlet description/description servlet-nameMyDefaultServlet/servlet-name servlet-classtest.MyDefaultServlet/servlet-class /servlet servlet-mapping servlet-nameMyDefaultServlet/servlet-name url-pattern//url-pattern /servlet-mapping When requesting the root of the context, tomcat 7 dispatches to MyDummyServlet whereas jetty and glassfish use MyDefaultServlet. On this one I'd say tomcat is right... A clarification of the Expert Group on the servlet spec would be welcome ! Sylvain On 17 oct. 2010, at 17:04, Sylvain Laurent wrote: Indeed, that's the problem I'm facing. After spending some time reading the spec and the comments in both bug reports, I'm inclined to believe that the current behavior of tomcat 7.0.4 is not spec compliant. I created a webapp that matches the example given in chapter 10.10 (Welcome files) of the spec. The files are the same, and my web.xml is like this : web-app xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xmlns=http://java.sun.com/xml/ns/javaee; xmlns:web=http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd; xsi:schemaLocation=http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd; id=WebApp_ID version=2.5 display-nametestWelcomeFiles/display-name welcome-file-list welcome-fileindex.html/welcome-file welcome-filedefault.jsp/welcome-file /welcome-file-list servlet description/description display-nameMyDefaultServlet/display-name servlet-nameMyDefaultServlet/servlet-name servlet-classtest.MyDefaultServlet/servlet-class /servlet servlet-mapping servlet-nameMyDefaultServlet/servlet-name url-pattern//url-pattern /servlet-mapping /web-app All the behaviors described in the spec are OK except this one : A request URI of /catalog/products/ will be passed to the “default” servlet, if any. Despite having declared a default servlet (as defined in section 12.2), it was not called when requesting catalog/products/ and I got a 404 instead... Sylvain On 16 oct. 2010, at 21:36, Mark Thomas wrote: On 15/10/2010 22:01, Sylvain Laurent wrote: I just played with a Roo application and I get a 404 with 7.0.4 whereas the very same application works OK with 6.0.29. I'll try to investigate this week-end. Best guess without seeing the app is https://issues.apache.org/bugzilla/show_bug.cgi?id=49422 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 7.0.4
From: Sylvain Laurent [mailto:sylvain.laur...@gmail.com] On Behalf Of Sylvain Laurent Subject: Re: [VOTE] Release Apache Tomcat 7.0.4 After spending some time reading the spec and the comments in both bug reports, I'm inclined to believe that the current behavior of tomcat 7.0.4 is not spec compliant. I'd have to agree. The pertinent wording in the spec is this (10.10): The Web server must append each welcome file in the order specified in the deployment descriptor to the partial request and check whether a static resource in the WAR is mapped to that request URI. If no match is found, the Web server MUST again append each welcome file in the order specified in the deployment descriptor to the partial request and check if a servlet is mapped to that request URI. The Web container must send the request to the first resource in the WAR that matches. and (12.1): 4. If neither [sic] of the previous three rules [exact, prefix, extension] result in a servlet match, the container will attempt to serve content appropriate for the resource requested. If a 'default' servlet is defined for the application, it will be used. and (12.2): A string containing only the '/' character indicates the 'default' servlet of the application. Since no matches are found for the welcome files as static resources, and no matches are found using the first three rules in 12.1, the fourth rule of 12.1 applies - and the request must be passed to the declared default servlet of the application. On the subject of welcome files, what in the world is the following paragraph doing in the middle of section 8.1.6? By default all applications will have index.htm(l) and index.jsp in the list of welcome-file-list. The descriptor may to be used to override these default settings. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
RE: [VOTE] Release Apache Tomcat 7.0.4
From: Sylvain Laurent [mailto:sylvain.laur...@gmail.com] On Behalf Of Sylvain Laurent Subject: Re: [VOTE] Release Apache Tomcat 7.0.4 When requesting the root of the context, tomcat 7 dispatches to MyDummyServlet whereas jetty and glassfish use MyDefaultServlet. On this one I'd say tomcat is right... Also agreed. Tomcat is correctly following the second set of matching operations as specified in 10.10: If no match is found [static check], the Web server MUST again append each welcome file in the order specified in the deployment descriptor to the partial request and check if a servlet is mapped to that request URI. Jetty and GlassFish seem to be ignoring that part. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat 7.0.4
On 17/10/2010 16:04, Sylvain Laurent wrote: Indeed, that's the problem I'm facing. After spending some time reading the spec and the comments in both bug reports, I'm inclined to believe that the current behavior of tomcat 7.0.4 is not spec compliant. I created a webapp that matches the example given in chapter 10.10 (Welcome files) of the spec. The files are the same, and my web.xml is like this : web-app xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xmlns=http://java.sun.com/xml/ns/javaee; xmlns:web=http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd; xsi:schemaLocation=http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd; id=WebApp_ID version=2.5 display-nametestWelcomeFiles/display-name welcome-file-list welcome-fileindex.html/welcome-file welcome-filedefault.jsp/welcome-file /welcome-file-list servlet description/description display-nameMyDefaultServlet/display-name servlet-nameMyDefaultServlet/servlet-name servlet-classtest.MyDefaultServlet/servlet-class /servlet servlet-mapping servlet-nameMyDefaultServlet/servlet-name url-pattern//url-pattern /servlet-mapping /web-app All the behaviors described in the spec are OK except this one : A request URI of /catalog/products/ will be passed to the “default” servlet, if any. The example in the spec is wrong. It doesn't follow the rules set out above the example. quote The Web server must append each welcome file in the order specified in the deployment descriptor to the partial request and check whether a static resource in the WAR is mapped to that request URI. If no match is found, the Web server MUST again append each welcome file in the order specified in the deployment descriptor to the partial request and check if a servlet is mapped to that request URI. /quote There are no matches for the static files so all is OK for the first sentence. However there is a match (to *.jsp) the second time through so Tomcat passes /catalog/products/default.jsp to the JSP servlet which returns a 404. Despite having declared a default servlet (as defined in section 12.2), it was not called when requesting catalog/products/ and I got a 404 instead... As per the spec. Yes, this is stupid but it is what the spec requires. Tomcat can't tell the difference between a Servlet that expects to be backed by a static resource and one that does not so can't make a reasonable decision on what to map and what not. It this behaviour is disabled, other apps will break in the opposite direction - e.g. a struts app the uses index.do as a welcome file. The best solution to this is probably a configuration option (disabled by default?) that requires welcome files to be backed by static resources. Could be a global or a per context option. The rules for mapping welcome files are in the Mapper which does have access to the Context but should really access it via reflection since o.a.tomcat isn't meant to depend on o.a.catalina. Maybe handle it at mapper creation? 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 7.0.4
From: Mark Thomas [mailto:ma...@apache.org] Subject: Re: [VOTE] Release Apache Tomcat 7.0.4 There are no matches for the static files so all is OK for the first sentence. However there is a match (to *.jsp) the second time through so Tomcat passes /catalog/products/default.jsp to the JSP servlet which returns a 404. This might be the crux of the matter: section 12.2.1 of the spec states that *.jsp is an /implicit/ mapping (unless overridden by the webapp), and the second matching protocol in 10.10 seems to be referring to /explicit/ mappings (my interpretation, not definitive in the spec). Tomcat does not differentiate between implicit and explicit mappings, whereas the other containers seem to do so. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat 7.0.4
On 17/10/2010 22:58, Caldarale, Charles R wrote: From: Mark Thomas [mailto:ma...@apache.org] Subject: Re: [VOTE] Release Apache Tomcat 7.0.4 There are no matches for the static files so all is OK for the first sentence. However there is a match (to *.jsp) the second time through so Tomcat passes /catalog/products/default.jsp to the JSP servlet which returns a 404. This might be the crux of the matter: section 12.2.1 of the spec states that *.jsp is an /implicit/ mapping (unless overridden by the webapp), and the second matching protocol in 10.10 seems to be referring to /explicit/ mappings (my interpretation, not definitive in the spec). Tomcat does not differentiate between implicit and explicit mappings, whereas the other containers seem to do so. Implicit seems to be a term used in section exclusively 12.2.1 (OK apart from a single mention in 12.1). It isn't used elsewhere in the Servlet spec so it isn't at all clear what - if any - special treatment implicit mappings are meant to have. 12.2.1 doesn't mention *.jspx which doesn't give me a great deal of confidence in the completeness or correctness of that section. Something else that requires some clarity for Servlet 3.1. I'll add it to my list. My previous suggestion regarding a new config option would at least allow users to control this behaviour until we get some clarity in the spec. 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 7.0.4
On 15/10/2010 22:01, Sylvain Laurent wrote: I just played with a Roo application and I get a 404 with 7.0.4 whereas the very same application works OK with 6.0.29. I'll try to investigate this week-end. Best guess without seeing the app is https://issues.apache.org/bugzilla/show_bug.cgi?id=49422 Mark Sylvain On 15 oct. 2010, at 10:47, Mark Thomas wrote: The proposed Apache Tomcat 7.0.4 release is now available for voting. It can be obtained from: http://people.apache.org/~markt/dev/tomcat-7/v7.0.4/ The svn tag is: http://svn.apache.org/repos/asf/tomcat/tc7.0.x/tags/TOMCAT_7_0_4/ As with previous votes, I have included a stable option below although my personal inclination is still to vote beta. The proposed 7.0.4 release is: [ ] Broken - do not release [ ] Alpha - go ahead and release as 7.0.4 Alpha [ ] Beta - go ahead and release as 7.0.4 Beta [ ] Stable - go ahead and release as 7.0.4 Stable This vote will run until 10.00 UTC Wednesday 20th October (3 working days). 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 - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat 7.0.4
On 15/10/2010 09:47, Mark Thomas wrote: The proposed Apache Tomcat 7.0.4 release is now available for voting. It can be obtained from: http://people.apache.org/~markt/dev/tomcat-7/v7.0.4/ The svn tag is: http://svn.apache.org/repos/asf/tomcat/tc7.0.x/tags/TOMCAT_7_0_4/ As with previous votes, I have included a stable option below although my personal inclination is still to vote beta. The proposed 7.0.4 release is: [ ] Broken - do not release [ ] Alpha - go ahead and release as 7.0.4 Alpha [X] Beta - go ahead and release as 7.0.4 Beta [ ] Stable - go ahead and release as 7.0.4 Stable This vote will run until 10.00 UTC Wednesday 20th October (3 working days). Sevlet TCK passes with security manager for HTTP BIO, NIO APR/native Sevlet TCK passes with security manager for AJP BIO APR/native JSP TCK passes with security manager EL TCK passes with security manager The bug count is currently nice and low. If we don't see any nasty issues between this and the next release I'd be tempted to start voting stable. 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 7.0.4
I just played with a Roo application and I get a 404 with 7.0.4 whereas the very same application works OK with 6.0.29. I'll try to investigate this week-end. Sylvain On 15 oct. 2010, at 10:47, Mark Thomas wrote: The proposed Apache Tomcat 7.0.4 release is now available for voting. It can be obtained from: http://people.apache.org/~markt/dev/tomcat-7/v7.0.4/ The svn tag is: http://svn.apache.org/repos/asf/tomcat/tc7.0.x/tags/TOMCAT_7_0_4/ As with previous votes, I have included a stable option below although my personal inclination is still to vote beta. The proposed 7.0.4 release is: [ ] Broken - do not release [ ] Alpha - go ahead and release as 7.0.4 Alpha [ ] Beta - go ahead and release as 7.0.4 Beta [ ] Stable - go ahead and release as 7.0.4 Stable This vote will run until 10.00 UTC Wednesday 20th October (3 working days). 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
