DO NOT REPLY [Bug 51624] Request is not forwarded to servlet... goes to 404 instead.
https://issues.apache.org/bugzilla/show_bug.cgi?id=51624 --- Comment #10 from Pid 2011-08-09 08:10:54 UTC --- > ...as i see it, a relative path is one that is resolvable generally against an > URI or File, which is the case of "" and ".", both valid paths denoting the > "current" directory. If "." is valid, Tomcat would deploy "." and it will also detect every directory in "." (because it's the same as appBase) and separately, deploy them as applications - each of those dirs is presumably missing a WEB-INF/web.xml, which means that no security constraints are applied. The extra applications take priority over the ROOT application (as they have a longer context path), so any requests to resources in them would be unprotected. Now please, join to the Tomcat Users list (not because I'm user, but because *you* are) and we'll explain all of this to you, if you still don't understand why you are wrong. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- 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
svn commit: r1155255 - in /tomcat/tc7.0.x/tags/TOMCAT_7_0_20: ./ build.properties.default modules/bayeux/ modules/tomcat-lite/
Author: markt Date: Tue Aug 9 08:25:55 2011 New Revision: 1155255 URL: http://svn.apache.org/viewvc?rev=1155255&view=rev Log: Tag 7.0.20 Added: tomcat/tc7.0.x/tags/TOMCAT_7_0_20/ - copied from r1155252, tomcat/trunk/ Removed: tomcat/tc7.0.x/tags/TOMCAT_7_0_20/modules/bayeux/ tomcat/tc7.0.x/tags/TOMCAT_7_0_20/modules/tomcat-lite/ Modified: tomcat/tc7.0.x/tags/TOMCAT_7_0_20/build.properties.default Modified: tomcat/tc7.0.x/tags/TOMCAT_7_0_20/build.properties.default URL: http://svn.apache.org/viewvc/tomcat/tc7.0.x/tags/TOMCAT_7_0_20/build.properties.default?rev=1155255&r1=1155252&r2=1155255&view=diff == --- tomcat/tc7.0.x/tags/TOMCAT_7_0_20/build.properties.default (original) +++ tomcat/tc7.0.x/tags/TOMCAT_7_0_20/build.properties.default Tue Aug 9 08:25:55 2011 @@ -29,7 +29,7 @@ version.major=7 version.minor=0 version.build=20 version.patch=0 -version.suffix=-dev +version.suffix= # - Build control flags - # Note enabling validation uses Checkstyle which is LGPL licensed - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1155257 - in /tomcat/trunk: build.properties.default res/maven/mvn.properties.default
Author: markt Date: Tue Aug 9 08:28:18 2011 New Revision: 1155257 URL: http://svn.apache.org/viewvc?rev=1155257&view=rev Log: Update post tag Modified: tomcat/trunk/build.properties.default tomcat/trunk/res/maven/mvn.properties.default Modified: tomcat/trunk/build.properties.default URL: http://svn.apache.org/viewvc/tomcat/trunk/build.properties.default?rev=1155257&r1=1155256&r2=1155257&view=diff == --- tomcat/trunk/build.properties.default (original) +++ tomcat/trunk/build.properties.default Tue Aug 9 08:28:18 2011 @@ -27,7 +27,7 @@ # - Version Control Flags - version.major=7 version.minor=0 -version.build=20 +version.build=21 version.patch=0 version.suffix=-dev Modified: tomcat/trunk/res/maven/mvn.properties.default URL: http://svn.apache.org/viewvc/tomcat/trunk/res/maven/mvn.properties.default?rev=1155257&r1=1155256&r2=1155257&view=diff == --- tomcat/trunk/res/maven/mvn.properties.default (original) +++ tomcat/trunk/res/maven/mvn.properties.default Tue Aug 9 08:28:18 2011 @@ -33,12 +33,12 @@ maven.snapshot.repo.repositoryId=apache. #Maven release properties for Tomcat staging maven.release.repo.url=scp://people.apache.org/www/tomcat.apache.org/dev/dist/m2-repository maven.release.repo.repositoryId=tomcat-staging -maven.release.deploy.version=7.0.20 +maven.release.deploy.version=7.0.21 #Maven release properties for the main ASF repo maven.asf.release.repo.url=scp://people.apache.org/www/people.apache.org/repo/m2-ibiblio-rsync-repository maven.asf.release.repo.repositoryId=apache.releases -maven.asf.release.deploy.version=7.0.20 +maven.asf.release.deploy.version=7.0.21 #Where do we load the libraries from - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Replacing tcnative java classes by svn:externals?
On 08/08/2011 19:44, Rainer Jung wrote: > On 08.08.2011 14:29, Konstantin Kolinko wrote: >> 2011/8/8 Mark Thomas : >>> On 08/08/2011 12:09, Konstantin Kolinko wrote: 2011/8/6 Mark Thomas : > On 06/08/2011 19:51, Rainer Jung wrote: >> Anything I have overlooked? > > Tagging. > > If you use an external, you have to be very careful creating tags else > the contents of the tag will appear to change over time. > When tc7.0.x branch is created, what is the plan for jdbc-pool? Will it be copied over to the branch as well, or we can use externals pointing to trunk here? >>> >>> I think the best approach would be for 7.0.x to have an external that >>> pointed to trunk but used an explicit revision. That means we have to >>> make a concious decision to update the jdbc-pool in 7.0.x but tagging >>> will just work. It also means experimental work can go on in trunk for >>> jdbc-pool without 'infecting' 7.0.x. >>> >> >> Sounds good. >> We can use the same approach for tcnative. > > Yes, that's a good start. So we would usually set the external in > tcnative to some released TC 7 version, and if there's something > important in the TC 7 branch which is not yet released and should become > part of the tcnative next release, we can make a special TC 7 tag for that. I'd actually go the other way and have 7.0.x have an external to native 1.1.x using the revision associated with the version of native that 7..0.x is currently configured to use. 7.0.x trunk would have an external linking to either 1.1.x head or trunk head. That way we have one copy of the native code to maintain. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[VOTE] Release Apache Tomcat 7.0.20
The proposed Apache Tomcat 7.0.20 release is now available for voting. It can be obtained from: http://people.apache.org/~markt/dev/tomcat-7/v7.0.20/ The svn tag is: http://svn.apache.org/repos/asf/tomcat/tc7.0.x/tags/TOMCAT_7_0_20/ The proposed 7.0.20 release is: [ ] Broken - do not release [ ] Alpha - go ahead and release as 7.0.20 Alpha [ ] Beta - go ahead and release as 7.0.20 Beta [ ] Stable - go ahead and release as 7.0.20 Stable Cheers, Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Replacing tcnative java classes by svn:externals?
On 09.08.2011 10:37, Mark Thomas wrote: > On 08/08/2011 19:44, Rainer Jung wrote: >> On 08.08.2011 14:29, Konstantin Kolinko wrote: >>> 2011/8/8 Mark Thomas : On 08/08/2011 12:09, Konstantin Kolinko wrote: > 2011/8/6 Mark Thomas : >> On 06/08/2011 19:51, Rainer Jung wrote: >>> Anything I have overlooked? >> >> Tagging. >> >> If you use an external, you have to be very careful creating tags else >> the contents of the tag will appear to change over time. >> > > When tc7.0.x branch is created, what is the plan for jdbc-pool? > > Will it be copied over to the branch as well, or we can use externals > pointing to trunk here? I think the best approach would be for 7.0.x to have an external that pointed to trunk but used an explicit revision. That means we have to make a concious decision to update the jdbc-pool in 7.0.x but tagging will just work. It also means experimental work can go on in trunk for jdbc-pool without 'infecting' 7.0.x. >>> >>> Sounds good. >>> We can use the same approach for tcnative. >> >> Yes, that's a good start. So we would usually set the external in >> tcnative to some released TC 7 version, and if there's something >> important in the TC 7 branch which is not yet released and should become >> part of the tcnative next release, we can make a special TC 7 tag for that. > > I'd actually go the other way and have 7.0.x have an external to native > 1.1.x using the revision associated with the version of native that > 7..0.x is currently configured to use. > > 7.0.x trunk would have an external linking to either 1.1.x head or trunk > head. > > That way we have one copy of the native code to maintain. Even better :) Rainer - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Replacing tcnative java classes by svn:externals?
On 09/08/2011 10:38, Rainer Jung wrote: > On 09.08.2011 10:37, Mark Thomas wrote: >> On 08/08/2011 19:44, Rainer Jung wrote: >>> On 08.08.2011 14:29, Konstantin Kolinko wrote: 2011/8/8 Mark Thomas : > On 08/08/2011 12:09, Konstantin Kolinko wrote: >> 2011/8/6 Mark Thomas : >>> On 06/08/2011 19:51, Rainer Jung wrote: Anything I have overlooked? >>> >>> Tagging. >>> >>> If you use an external, you have to be very careful creating tags else >>> the contents of the tag will appear to change over time. >>> >> >> When tc7.0.x branch is created, what is the plan for jdbc-pool? >> >> Will it be copied over to the branch as well, or we can use externals >> pointing to trunk here? > > I think the best approach would be for 7.0.x to have an external that > pointed to trunk but used an explicit revision. That means we have to > make a concious decision to update the jdbc-pool in 7.0.x but tagging > will just work. It also means experimental work can go on in trunk for > jdbc-pool without 'infecting' 7.0.x. > Sounds good. We can use the same approach for tcnative. >>> >>> Yes, that's a good start. So we would usually set the external in >>> tcnative to some released TC 7 version, and if there's something >>> important in the TC 7 branch which is not yet released and should become >>> part of the tcnative next release, we can make a special TC 7 tag for that. >> >> I'd actually go the other way and have 7.0.x have an external to native >> 1.1.x using the revision associated with the version of native that >> 7..0.x is currently configured to use. >> >> 7.0.x trunk would have an external linking to either 1.1.x head or trunk >> head. >> >> That way we have one copy of the native code to maintain. > > Even better :) We just need to be careful to end up with the latest versions of everything. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Bug 51497 -- Use canonical IPv6 text representation in logs
Hi devs, Is anyone interested to review the patch for bug 51497 (Use canonical IPv6 text representation in logs) [1]? It modifies IPv6 textual representation to be aligned with usual practice on Linux, Windows, HTTPD, and recommendations from RFC 5952. Regards, Ognjen [1] https://issues.apache.org/bugzilla/show_bug.cgi?id=51497 - 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.20
On 08/09/2011 11:33 AM, Mark Thomas wrote: The proposed 7.0.20 release is: [X] Stable - go ahead and release as 7.0.20 Stable Tested on Linux and Windows. Regards -- ^TM - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 51637] New: Lifecyclebase.start() method should be non-final
https://issues.apache.org/bugzilla/show_bug.cgi?id=51637 Bug #: 51637 Summary: Lifecyclebase.start() method should be non-final Product: Tomcat 7 Version: unspecified Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: Catalina AssignedTo: dev@tomcat.apache.org ReportedBy: anilsaldh...@gmail.com Classification: Unclassified If we need to have deeper integration with the web container security, then there is a need to extend the default Tomcat Authenticators. This is what we have done in project PicketLink where we bring SAML based Web Browser SSO to Tomcat Applications. As highlighted by our user in http://community.jboss.org/thread/170430?tstart=0, there is a JVM byte code verification error now that the Lifecyclebase.start() method has been made final. This affects all valves/authenticators users are going to write. The start() method is usually overriden such that the valve/authenticator can do initialization before they are started via super.start(). -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- 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
DO NOT REPLY [Bug 51637] Lifecyclebase.start() method should be non-final
https://issues.apache.org/bugzilla/show_bug.cgi?id=51637 Mark Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Comment #1 from Mark Thomas 2011-08-09 12:10:06 UTC --- For Tomcat 7, you should be overriding startInternal(), not start(). -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- 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
DO NOT REPLY [Bug 51637] Lifecyclebase.start() method should be non-final
https://issues.apache.org/bugzilla/show_bug.cgi?id=51637 --- Comment #2 from Anil Saldhana 2011-08-09 12:17:34 UTC --- Basically you are saying we cannot port code that was working in TC55 and TC6. Now we need to write a fresh set of authenticator for TC7? -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- 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
DO NOT REPLY [Bug 51637] Lifecyclebase.start() method should be non-final
https://issues.apache.org/bugzilla/show_bug.cgi?id=51637 --- Comment #3 from Mark Thomas 2011-08-09 12:46:25 UTC --- In short, yes. The longer version is that prior to Tomcat 7 the Lifecycle interface was loosely defined, largely optional and inconsistently implemented with large quantities of almost but not quite duplicate code. The code wasn't unmaintainable but it was a lot harder to maintain than it should have been. The inconsistencies in things like component start/stop and JMX registration of components was also causing problems. As part of the wider code clean-up for Tomcat 7 the Lifecycle interface was more tightly defined - particularly the permitted state transitions - and made non-optional for most internal components. Most (all?) of those components all extend LifecycleMBeanBase which ensures that MBean registration and de-registration happens at the correct point. It also ensures that components that extend correctly implement Lifecycle both in terms of the allowed state transitions and the firing of associated events. A side effect of this is that custom code that extends these components must override different methods. API changes are going to happen between major versions. They aren't made for the sake of it but neither are they avoided. It may be as simple as overriding a different method but you may find that other changes are required as well. It depends on exactly what the custom component is doing. As an aside, initialisation should be happening in init() not start() which probably means overriding initInternal(). -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- 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: [VOTE] Release Apache Tomcat 7.0.20
On 09/08/2011 10:33, Mark Thomas wrote: > The proposed Apache Tomcat 7.0.20 release is now available for voting. > > It can be obtained from: > http://people.apache.org/~markt/dev/tomcat-7/v7.0.20/ > The svn tag is: > http://svn.apache.org/repos/asf/tomcat/tc7.0.x/tags/TOMCAT_7_0_20/ > > The proposed 7.0.20 release is: > > [ ] Broken - do not release > [ ] Alpha - go ahead and release as 7.0.20 Alpha > [ ] Beta - go ahead and release as 7.0.20 Beta > [X] Stable - go ahead and release as 7.0.20 Stable Unit tests pass on 64-bit Linux and 64-bit Windows. EL TCK passes. JSP TCK passes with HTTP BIO, HTTP NIO and HTTP APR Servlet TCK passes with: - HTTP (BIO, NIO, APR) - mod_jk + AJP (BIO, NIO, APR) - mod_proxy_ajp + AJP (BIO, NIO, APR) - mod_proxy_http + HTTP (BIO, NIO, APR) Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Hosting the current Tomcat Maven Plugin from mojo codehaus
On 08/08/2011 13:15, Olivier Lamy wrote: > Hello, > So Ip clearance committed [1] > Web site need sync. > Let me know how do move forward now ? According to http://incubator.apache.org/ip-clearance/index.html the incubator PMC needs to approve this then we are free to import the code. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 51638] New: Sessions are not serialized during shutdown
https://issues.apache.org/bugzilla/show_bug.cgi?id=51638 Bug #: 51638 Summary: Sessions are not serialized during shutdown Product: Tomcat 7 Version: 7.0.19 Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: Catalina AssignedTo: dev@tomcat.apache.org ReportedBy: johnashud...@gmail.com Classification: Unclassified It seems sessions are not serialized to SESSIONS.ser when we manually stop Tomcat by executing the shutdown.sh script. Thus, if we restart Tomcat by executing the startup.sh script, previous active sessions are lost. However, if we stop a particular application via the Tomcat Manager, the SESSIONS.ser file is created and sessions are restored successfully after the application is started again via the Tomcat Manager. Not sure if previous versions of Tomcat 7 have the same problem, but 7.0.19 is affected. Tomcat 6 works fine. Thank you very much! -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- 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
DO NOT REPLY [Bug 51637] Lifecyclebase.start() method should be non-final
https://issues.apache.org/bugzilla/show_bug.cgi?id=51637 --- Comment #4 from Anil Saldhana 2011-08-09 13:23:03 UTC --- Thanks Mark, for the explanation. We will write a fresh set of authenticators for TC7 derived code. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- 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: Hosting the current Tomcat Maven Plugin from mojo codehaus
In the same page, I can read a note about lazy consensus. FYI I have asked in this thread [1]. Thanks, -- Olivier [1] http://markmail.org/message/guvbec2h7hdj3zps 2011/8/9 Mark Thomas : > On 08/08/2011 13:15, Olivier Lamy wrote: >> Hello, >> So Ip clearance committed [1] >> Web site need sync. >> Let me know how do move forward now ? > > According to http://incubator.apache.org/ip-clearance/index.html the > incubator PMC needs to approve this then we are free to import the code. > > Mark > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > > -- Olivier Lamy Talend : http://talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1155369 - /tomcat/tc7.0.x/trunk/
Author: markt Date: Tue Aug 9 14:03:02 2011 New Revision: 1155369 URL: http://svn.apache.org/viewvc?rev=1155369&view=rev Log: Create separate trunk for Tomcat 7 Added: tomcat/tc7.0.x/trunk/ - copied from r1155368, tomcat/trunk/ - 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.20
On 09.08.2011 11:33, Mark Thomas wrote: > [X] Stable - go ahead and release as 7.0.20 Stable - MD5 OK - signatures OK - key in KEYS file - gz and zip for src and bin consistent - src consistent with svn tag Except for the following minor points: - The files we copy before building, e.g. catalina.properties and jdbc-pool.xml are of course not in svn for the cp target location, but they are there in the src bundles. - File modules/jdbc-pool/sign.sh is in svn but not part of the gz or zip sources - line ends of modules/jdbc-pool/resources/MANIFEST.MF differ between svn and gz although eol-style is set correctly. - builds fine - build result looks consistent with binaries - no checkstyle complaints - no Javadoc errors - Unit tests run OK for BIO, NIO and APR No single test failure - JMX MBean-Comparison OK - new SetCharacterEncoding filter for manager and host-manager - new attribute alwaysUseSession in BasicAuthenticator Valve Build and tests were done using Java 1.6.0_26, OS was Solaris 10 Sparc, tcnative was 1.1.22 based on APR 1.4.5 and OpenSSL 0.9.8r. Looks pretty good! Regards, Rainer - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1155378 - in /tomcat/tc7.0.x/trunk/modules: bayeux/ jdbc-pool/ tomcat-lite/
Author: markt Date: Tue Aug 9 14:16:02 2011 New Revision: 1155378 URL: http://svn.apache.org/viewvc?rev=1155378&view=rev Log: Remove the modules from 7.0.x/trunk Removed: tomcat/tc7.0.x/trunk/modules/bayeux/ tomcat/tc7.0.x/trunk/modules/jdbc-pool/ tomcat/tc7.0.x/trunk/modules/tomcat-lite/ - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1155383 - /tomcat/tc7.0.x/trunk/modules/
Author: markt Date: Tue Aug 9 14:21:00 2011 New Revision: 1155383 URL: http://svn.apache.org/viewvc?rev=1155383&view=rev Log: Add external to pick up jdbc-pool. Use same revision as 7.0.20 tag. Modified: tomcat/tc7.0.x/trunk/modules/ (props changed) Propchange: tomcat/tc7.0.x/trunk/modules/ -- --- svn:externals (added) +++ svn:externals Tue Aug 9 14:21:00 2011 @@ -0,0 +1 @@ +-r 1155255 ../../../trunk/modules/jdbc-pool jdbc-pool - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Replacing tcnative java classes by svn:externals?
On 09/08/2011 10:46, Mark Thomas wrote: > On 09/08/2011 10:38, Rainer Jung wrote: >> On 09.08.2011 10:37, Mark Thomas wrote: >>> On 08/08/2011 19:44, Rainer Jung wrote: On 08.08.2011 14:29, Konstantin Kolinko wrote: > 2011/8/8 Mark Thomas : >> On 08/08/2011 12:09, Konstantin Kolinko wrote: >>> 2011/8/6 Mark Thomas : On 06/08/2011 19:51, Rainer Jung wrote: > Anything I have overlooked? Tagging. If you use an external, you have to be very careful creating tags else the contents of the tag will appear to change over time. >>> >>> When tc7.0.x branch is created, what is the plan for jdbc-pool? >>> >>> Will it be copied over to the branch as well, or we can use externals >>> pointing to trunk here? >> >> I think the best approach would be for 7.0.x to have an external that >> pointed to trunk but used an explicit revision. That means we have to >> make a concious decision to update the jdbc-pool in 7.0.x but tagging >> will just work. It also means experimental work can go on in trunk for >> jdbc-pool without 'infecting' 7.0.x. >> > > Sounds good. > We can use the same approach for tcnative. Yes, that's a good start. So we would usually set the external in tcnative to some released TC 7 version, and if there's something important in the TC 7 branch which is not yet released and should become part of the tcnative next release, we can make a special TC 7 tag for that. >>> >>> I'd actually go the other way and have 7.0.x have an external to native >>> 1.1.x using the revision associated with the version of native that >>> 7..0.x is currently configured to use. >>> >>> 7.0.x trunk would have an external linking to either 1.1.x head or trunk >>> head. >>> >>> That way we have one copy of the native code to maintain. >> >> Even better :) > > We just need to be careful to end up with the latest versions of everything. I've been thinking about this some more and how we usually work with this code. On reflection, I think Rainer is right and trunk should be the master copy for this code, with changes ported back to 7.0.x, 6.0.x and 5.5.x as they are now. With that in mind, I think an external from native (1.1.x and trunk) that points to trunk is the way to go. The revision number used for the external can be updated as part of the native release process. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1155393 - in /tomcat/trunk: BUILDING.txt RELEASE-NOTES build.properties.default build.xml
Author: markt
Date: Tue Aug 9 15:18:58 2011
New Revision: 1155393
URL: http://svn.apache.org/viewvc?rev=1155393&view=rev
Log:
Update version numbers to 8.0.x
Modified:
tomcat/trunk/BUILDING.txt
tomcat/trunk/RELEASE-NOTES
tomcat/trunk/build.properties.default
tomcat/trunk/build.xml
Modified: tomcat/trunk/BUILDING.txt
URL:
http://svn.apache.org/viewvc/tomcat/trunk/BUILDING.txt?rev=1155393&r1=1155392&r2=1155393&view=diff
==
--- tomcat/trunk/BUILDING.txt (original)
+++ tomcat/trunk/BUILDING.txt Tue Aug 9 15:18:58 2011
@@ -72,7 +72,7 @@ do the following:
http://svn.apache.org/repos/asf/tomcat/tc@VERSION_MAJOR_MINOR@.x/
* Download a source package from:
- http://tomcat.apache.org/download-70.cgi
+ http://tomcat.apache.org/download-@version_ma...@0.cgi
* Checkout the source using SVN, selecting the desired version or
branch (current development source is at
Modified: tomcat/trunk/RELEASE-NOTES
URL:
http://svn.apache.org/viewvc/tomcat/trunk/RELEASE-NOTES?rev=1155393&r1=1155392&r2=1155393&view=diff
==
--- tomcat/trunk/RELEASE-NOTES (original)
+++ tomcat/trunk/RELEASE-NOTES Tue Aug 9 15:18:58 2011
@@ -58,15 +58,15 @@ by Apache Ant.
API Stability:
==
The public interfaces for the following classes are fixed and will not be
-changed at all during the remaining lifetime of the 7.x series:
-- javax/**/*
+changed at all during the remaining lifetime of the @VERSION_MAJOR@.x series:
+- None
The public interfaces for the following classes may be added to in order to
resolve bugs and/or add new features. No existing interface will be removed or
changed although it may be deprecated.
-- org/apache/catalina/*
+- None
-Note: As Tomcat 7 matures, the above list will be added to. The list is not
+Note: As Tomcat @VERSION_MAJOR@ matures, the above list will be added to. The
list is not
considered complete at this time.
The remaining classes are considered part of the Tomcat internals and may
change
Modified: tomcat/trunk/build.properties.default
URL:
http://svn.apache.org/viewvc/tomcat/trunk/build.properties.default?rev=1155393&r1=1155392&r2=1155393&view=diff
==
--- tomcat/trunk/build.properties.default (original)
+++ tomcat/trunk/build.properties.default Tue Aug 9 15:18:58 2011
@@ -25,9 +25,9 @@
# -
# - Version Control Flags -
-version.major=7
+version.major=8
version.minor=0
-version.build=21
+version.build=0
version.patch=0
version.suffix=-dev
Modified: tomcat/trunk/build.xml
URL:
http://svn.apache.org/viewvc/tomcat/trunk/build.xml?rev=1155393&r1=1155392&r2=1155393&view=diff
==
--- tomcat/trunk/build.xml (original)
+++ tomcat/trunk/build.xml Tue Aug 9 15:18:58 2011
@@ -15,7 +15,7 @@
See the License for the specific language governing permissions and
limitations under the License.
-->
-
+
@@ -1688,7 +1688,7 @@ Apache Tomcat ${version} native binaries
+description="Create a Tomcat 8 packaged distribution">
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1155395 - /tomcat/trunk/RELEASE-NOTES
Author: markt Date: Tue Aug 9 15:21:14 2011 New Revision: 1155395 URL: http://svn.apache.org/viewvc?rev=1155395&view=rev Log: Remove some old info. Update the change log info. Modified: tomcat/trunk/RELEASE-NOTES Modified: tomcat/trunk/RELEASE-NOTES URL: http://svn.apache.org/viewvc/tomcat/trunk/RELEASE-NOTES?rev=1155395&r1=1155394&r2=1155395&view=diff == --- tomcat/trunk/RELEASE-NOTES (original) +++ tomcat/trunk/RELEASE-NOTES Tue Aug 9 15:21:14 2011 @@ -137,35 +137,6 @@ and putting them in the shared classload "lib" folder, and classes should be put in the "classes" folder). - -Tomcat on Linux: - -GLIBC 2.2 / Linux 2.4 users should define an environment variable: -export LD_ASSUME_KERNEL=2.2.5 - -Redhat Linux 9.0 users should use the following setting to avoid -stability problems: -export LD_ASSUME_KERNEL=2.4.1 - -There are some Linux bugs reported against the NIO sendfile behavior, make sure you -have a JDK that is up to date, or disable sendfile behavior in the Connector. -6427312: (fc) FileChannel.transferTo() throws IOException "system call interrupted" -5103988: (fc) FileChannel.transferTo should return -1 for EAGAIN instead throws IOException -6253145: (fc) FileChannel.transferTo on Linux fails when going beyond 2GB boundary -6470086: (fc) FileChannel.transferTo(2147483647, 1, channel) cause "Value too large" exception - - -= -Enabling SSI and CGI Support: -= -Because of the security risks associated with CGI and SSI available -to web applications, these features are disabled by default. - -To enable and configure CGI support, please see the cgi-howto.html page. - -To enable and configue SSI support, please see the ssi-howto.html page. - - == Security manager URLs: == @@ -189,7 +160,8 @@ the check. == Viewing the Tomcat Change Log: == -See changelog.html in this directory. +The full change log is available from http://tomcat.apache.org and is also +included in the documentation web application. = - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1155397 - /tomcat/trunk/res/maven/mvn.properties.default
Author: markt Date: Tue Aug 9 15:21:59 2011 New Revision: 1155397 URL: http://svn.apache.org/viewvc?rev=1155397&view=rev Log: Update Maven release versions Modified: tomcat/trunk/res/maven/mvn.properties.default Modified: tomcat/trunk/res/maven/mvn.properties.default URL: http://svn.apache.org/viewvc/tomcat/trunk/res/maven/mvn.properties.default?rev=1155397&r1=1155396&r2=1155397&view=diff == --- tomcat/trunk/res/maven/mvn.properties.default (original) +++ tomcat/trunk/res/maven/mvn.properties.default Tue Aug 9 15:21:59 2011 @@ -33,12 +33,12 @@ maven.snapshot.repo.repositoryId=apache. #Maven release properties for Tomcat staging maven.release.repo.url=scp://people.apache.org/www/tomcat.apache.org/dev/dist/m2-repository maven.release.repo.repositoryId=tomcat-staging -maven.release.deploy.version=7.0.21 +maven.release.deploy.version=8.0.0 #Maven release properties for the main ASF repo maven.asf.release.repo.url=scp://people.apache.org/www/people.apache.org/repo/m2-ibiblio-rsync-repository maven.asf.release.repo.repositoryId=apache.releases -maven.asf.release.deploy.version=7.0.21 +maven.asf.release.deploy.version=8.0.0 #Where do we load the libraries from - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1155398 - in /tomcat/trunk/res/ide-support/eclipse: eclipse.project start-tomcat.launch stop-tomcat.launch
Author: markt Date: Tue Aug 9 15:22:38 2011 New Revision: 1155398 URL: http://svn.apache.org/viewvc?rev=1155398&view=rev Log: Update the same Eclipse files Modified: tomcat/trunk/res/ide-support/eclipse/eclipse.project tomcat/trunk/res/ide-support/eclipse/start-tomcat.launch tomcat/trunk/res/ide-support/eclipse/stop-tomcat.launch Modified: tomcat/trunk/res/ide-support/eclipse/eclipse.project URL: http://svn.apache.org/viewvc/tomcat/trunk/res/ide-support/eclipse/eclipse.project?rev=1155398&r1=1155397&r2=1155398&view=diff == --- tomcat/trunk/res/ide-support/eclipse/eclipse.project (original) +++ tomcat/trunk/res/ide-support/eclipse/eclipse.project Tue Aug 9 15:22:38 2011 @@ -16,7 +16,7 @@ limitations under the License. --> -tomcat-7.0.x +tomcat-8.0.x Modified: tomcat/trunk/res/ide-support/eclipse/start-tomcat.launch URL: http://svn.apache.org/viewvc/tomcat/trunk/res/ide-support/eclipse/start-tomcat.launch?rev=1155398&r1=1155397&r2=1155398&view=diff == --- tomcat/trunk/res/ide-support/eclipse/start-tomcat.launch (original) +++ tomcat/trunk/res/ide-support/eclipse/start-tomcat.launch Tue Aug 9 15:22:38 2011 @@ -17,13 +17,13 @@ --> - + - + Modified: tomcat/trunk/res/ide-support/eclipse/stop-tomcat.launch URL: http://svn.apache.org/viewvc/tomcat/trunk/res/ide-support/eclipse/stop-tomcat.launch?rev=1155398&r1=1155397&r2=1155398&view=diff == --- tomcat/trunk/res/ide-support/eclipse/stop-tomcat.launch (original) +++ tomcat/trunk/res/ide-support/eclipse/stop-tomcat.launch Tue Aug 9 15:22:38 2011 @@ -17,13 +17,13 @@ --> - + - + - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1155400 - in /tomcat/trunk/res/ide-support/eclipse: start-tomcat.launch stop-tomcat.launch
Author: markt Date: Tue Aug 9 15:25:46 2011 New Revision: 1155400 URL: http://svn.apache.org/viewvc?rev=1155400&view=rev Log: Missed a version change Modified: tomcat/trunk/res/ide-support/eclipse/start-tomcat.launch tomcat/trunk/res/ide-support/eclipse/stop-tomcat.launch Modified: tomcat/trunk/res/ide-support/eclipse/start-tomcat.launch URL: http://svn.apache.org/viewvc/tomcat/trunk/res/ide-support/eclipse/start-tomcat.launch?rev=1155400&r1=1155399&r2=1155400&view=diff == --- tomcat/trunk/res/ide-support/eclipse/start-tomcat.launch (original) +++ tomcat/trunk/res/ide-support/eclipse/start-tomcat.launch Tue Aug 9 15:25:46 2011 @@ -25,5 +25,5 @@ - + Modified: tomcat/trunk/res/ide-support/eclipse/stop-tomcat.launch URL: http://svn.apache.org/viewvc/tomcat/trunk/res/ide-support/eclipse/stop-tomcat.launch?rev=1155400&r1=1155399&r2=1155400&view=diff == --- tomcat/trunk/res/ide-support/eclipse/stop-tomcat.launch (original) +++ tomcat/trunk/res/ide-support/eclipse/stop-tomcat.launch Tue Aug 9 15:25:46 2011 @@ -25,5 +25,5 @@ - + - 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.20
On Tue, Aug 9, 2011 at 5:33 AM, Mark Thomas wrote: > The proposed Apache Tomcat 7.0.20 release is now available for voting. > > It can be obtained from: > http://people.apache.org/~markt/dev/tomcat-7/v7.0.20/ > The svn tag is: > http://svn.apache.org/repos/asf/tomcat/tc7.0.x/tags/TOMCAT_7_0_20/ > > The proposed 7.0.20 release is: > > [ ] Broken - do not release > [ ] Alpha - go ahead and release as 7.0.20 Alpha > [ ] Beta - go ahead and release as 7.0.20 Beta > [ X ] Stable - go ahead and release as 7.0.20 Stable Stable, works for me on home-made apps. Did not run TCKs. Yoav > > 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
svn commit: r1155406 [1/2] - /tomcat/trunk/webapps/docs/changelog.xml
Author: markt Date: Tue Aug 9 15:36:44 2011 New Revision: 1155406 URL: http://svn.apache.org/viewvc?rev=1155406&view=rev Log: Prep the changelog Modified: tomcat/trunk/webapps/docs/changelog.xml - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1155408 - /tomcat/trunk/TOMCAT-NEXT.txt
Author: markt Date: Tue Aug 9 15:41:09 2011 New Revision: 1155408 URL: http://svn.apache.org/viewvc?rev=1155408&view=rev Log: Ideas for Tomcat 8 Added: tomcat/trunk/TOMCAT-NEXT.txt (with props) Added: tomcat/trunk/TOMCAT-NEXT.txt URL: http://svn.apache.org/viewvc/tomcat/trunk/TOMCAT-NEXT.txt?rev=1155408&view=auto == --- tomcat/trunk/TOMCAT-NEXT.txt (added) +++ tomcat/trunk/TOMCAT-NEXT.txt Tue Aug 9 15:41:09 2011 @@ -0,0 +1,41 @@ + + Licensed to the Apache Software Foundation (ASF) under one or more + contributor license agreements. See the NOTICE file distributed with + this work for additional information regarding copyright ownership. + The ASF licenses this file to You under the Apache License, Version 2.0 + (the "License"); you may not use this file except in compliance with + the License. You may obtain a copy of the License at + + http://www.apache.org/licenses/LICENSE-2.0 + + Unless required by applicable law or agreed to in writing, software + distributed under the License is distributed on an "AS IS" BASIS, + WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + See the License for the specific language governing permissions and + limitations under the License. + + +Notes of things to consider for the next major Tomcat release (probably 8.0.x +but possibly 7.1.x). + +1. Refactor the TLD parsing. TLDs are currently parsed twice. Once by Catalina + looking for listeners and once by Jasper. + +2. Refactor the XML parsing (org.apache.tomcat.util.xml ?) to remove duplicate + XML parsing code in Catalina and Jasper such as the entity resolvers used for + validation. + +3. TLDs may have a many to many relationship between URIs and TLD files. This + can result in the same TLD file being parsed many times. Refactor the + TldLocationCache to cache the parsed nodes (will need to check for changes to + TLD files). + +4. TLD files should be included in the dependencies for JSP and Tag files. + +5. Run the unused code detector and remove everything that isn't currently used. + Add deprecation markers for the removed code to Tomcat 7.0.x + +6. Change the default URIEncoding on the connector to UTF-8. + +7. Rip out all the JNDI code in resource handling and replace it with straight + URLs (File or WAR). \ No newline at end of file Propchange: tomcat/trunk/TOMCAT-NEXT.txt -- svn:eol-style = native - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 51638] Sessions are not serialized during shutdown
https://issues.apache.org/bugzilla/show_bug.cgi?id=51638 Mark Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME --- Comment #1 from Mark Thomas 2011-08-09 16:06:12 UTC --- This works for me with the latest 7.0.x code and the most recent change in this area was to fix a bug in 7.0.17. This looks like a configuration problem so please use the users mailing list for assistance. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- 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: Replacing tcnative java classes by svn:externals?
2011/8/9 Mark Thomas : > On 09/08/2011 10:46, Mark Thomas wrote: >> We just need to be careful to end up with the latest versions of everything. > > I've been thinking about this some more and how we usually work with > this code. On reflection, I think Rainer is right and trunk should be > the master copy for this code, with changes ported back to 7.0.x, 6.0.x > and 5.5.x as they are now. With that in mind, I think an external from > native (1.1.x and trunk) that points to trunk is the way to go. The > revision number used for the external can be updated as part of the > native release process. > Is there a difference between the Java code of native 1.1.x and native trunk? If there is, one has to keep "1.1.x" sources somewhere. This can be decided at a later date though. BTW, technically, regarding r1155383 --- svn:externals (added) +-r 1155255 ../../../trunk/modules/jdbc-pool jdbc-pool 1) such externals have to use a peg revision while "-r" in this "new" syntax specifies operative revision. Thus the syntax with @ below. (@ specifies peg revision, and operative revision is by the fault the same as the peg one). 2) "../.." will not work when tagging, because "tags/tagname" is two path segments to be eaten by ".." while current "trunk" is just one. Thus: ^/tomcat/trunk/modules/jdbc-pool@1155255 jdbc-pool Documentation: http://svnbook.red-bean.com/nightly/en/svn.advanced.externals.html http://svnbook.red-bean.com/nightly/en/svn.advanced.pegrevs.html Second, I was so enjoyed with Subversion 1.7 that it removes ".svn" subdirectories from within the working copy. It keeps a single ".svn" directory in the root of the working copy. With a sparse checkout it is at a higher level than Eclipse project. It solved some problems, e.g. Eclipse IDE trying to copy "java//.svn/**" to the output folder when compiling Java classes. With introduction of externals the project in Eclipse now gets an ".svn" directory inside modules/jdbc-pool, because each external is a "separate working copy" in svn. It would be a bit of nuisance, but I think it is manageable, because it is not a part of java sources. With native there will be similar problem: I wouldn't want /java/org/apache/tomcat/jni/ to be an external, because that would bring in "/java/org/apache/tomcat/jni/.svn/**" into the source tree. Instead it should be some separate project, e.g. "modules/native" where "java" is a subdirectory inside of it. It follows that there will be changes in Eclipse project configuration and in build scripts to take care of the new sources directory. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Replacing tcnative java classes by svn:externals?
On 09.08.2011 18:42, Konstantin Kolinko wrote: > 2011/8/9 Mark Thomas : >> On 09/08/2011 10:46, Mark Thomas wrote: >>> We just need to be careful to end up with the latest versions of everything. >> >> I've been thinking about this some more and how we usually work with >> this code. On reflection, I think Rainer is right and trunk should be >> the master copy for this code, with changes ported back to 7.0.x, 6.0.x >> and 5.5.x as they are now. With that in mind, I think an external from >> native (1.1.x and trunk) that points to trunk is the way to go. The >> revision number used for the external can be updated as part of the >> native release process. >> > > Is there a difference between the Java code of native 1.1.x and native > trunk? If there is, one has to keep "1.1.x" sources somewhere. This > can be decided at a later date though. native trunk does no longer have the java classes. Only the examples and test classes are there, but not the jni package. It was removed in http://svn.apache.org/viewvc?view=revision&revision=802243 as part of the big svn reorg (and test and examples later recreated). Regards, Rainer - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 51638] Sessions are not serialized during shutdown
https://issues.apache.org/bugzilla/show_bug.cgi?id=51638 Johnas H. changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|WORKSFORME | --- Comment #2 from Johnas H. 2011-08-09 19:53:56 UTC --- Hello Mark, You're totally right, it works well on 7.0.19. I was trying this on a server with 7.0.16 while all my other servers already run 7.0.19. I didn't realise this one hadn't been updated to the latest version. Please accept my apologies for making you loose your time testing this. Regards, Johnas. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- 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
ServletRequestListener.requestDestroyed is called before request leaves a webapp
Hello, everyone. I think I have found a bug in Tomcat's lifecycle handling of ServletRequestListener. I'd like to discuss it here before posting. Tomcat 7.0.19, jdk 1.7.0-b147, Ubuntu Linux 11.04 Steps to reproduce: 1. declare error page for 404 code in web.xml 2. Set location of that page to some servlet (let's call it ErrorServlet) 3. go to any invalid URL in webapp (to cause 404) 4. ErrorServlet is called after requestDestroyed on any registered listener. This kind of behaviour is not correct in my opinion because it contradicts to contract of ServletRequestListener. Also it breaks org.springframework.web.context.request.RequestContextListener if ErrorServlet uses session-scoped beans. What do you think about that. Should I post in to Bugzilla? - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 51638] Sessions are not serialized during shutdown
https://issues.apache.org/bugzilla/show_bug.cgi?id=51638 Mark Thomas changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||DUPLICATE --- Comment #3 from Mark Thomas 2011-08-09 20:12:26 UTC --- *** This bug has been marked as a duplicate of bug 51310 *** -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- 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
DO NOT REPLY [Bug 51310] Connector destroyInternal Execution
https://issues.apache.org/bugzilla/show_bug.cgi?id=51310 Mark Thomas changed: What|Removed |Added CC||johnashud...@gmail.com --- Comment #2 from Mark Thomas 2011-08-09 20:12:26 UTC --- *** Bug 51638 has been marked as a duplicate of this bug. *** -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- 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: ServletRequestListener.requestDestroyed is called before request leaves a webapp
On 09/08/2011 20:55, Volodymyr Sobotovich wrote: > Hello, everyone. > > I think I have found a bug in Tomcat's lifecycle handling of > ServletRequestListener. I'd like to discuss it here before posting. > Tomcat 7.0.19, jdk 1.7.0-b147, Ubuntu Linux 11.04 > Steps to reproduce: > 1. declare error page for 404 code in web.xml > 2. Set location of that page to some servlet (let's call it ErrorServlet) > 3. go to any invalid URL in webapp (to cause 404) > 4. ErrorServlet is called after requestDestroyed on any registered listener. > This kind of behaviour is not correct in my opinion because it > contradicts to contract of ServletRequestListener. > Also it breaks org.springframework.web.context.request.RequestContextListener > if ErrorServlet uses session-scoped beans. > > What do you think about that. Should I post in to Bugzilla? Hmm. The error page handling is currently at the host level. One could argue the listeners are being fired in the right place (when processing enters/leaves the context). However, custom error pages defined by the web app are currently outside the listener calls and that doesn't seem right. Addressing this would mean either: a) moving the error handling to the context (inside the calls to the ServletRequestListener) or b) moving the calls to ServletRequestListener to the host level I am leaning towards a) but wondering why things are the way the are currently. I'd suggest leaving this on the dev list for other folks to comment and then add it to BZ in a couple of days unless the consensus is that it is not a bug. The next 7.0.x release won;t be until early Sept so there is plenty of time to get this right. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 51640] New: clearReferencesJdbc seems to be causing leaks with com.oracle.ojdbc5 driver
https://issues.apache.org/bugzilla/show_bug.cgi?id=51640 Bug #: 51640 Summary: clearReferencesJdbc seems to be causing leaks with com.oracle.ojdbc5 driver Product: Tomcat 7 Version: 7.0.11 Platform: PC OS/Version: Windows XP Status: NEW Severity: normal Priority: P2 Component: Catalina AssignedTo: dev@tomcat.apache.org ReportedBy: pmoh...@gmail.com Classification: Unclassified Created attachment 27365 --> https://issues.apache.org/bugzilla/attachment.cgi?id=27365 Example project to reproduce the problem clearReferencesJdbc seems to be causing reference leaks when used with com.oracle.ojdbc5 version 11.1.0.7.0, even if that class isn't loaded by the application. As best as I can tell, that function is loading one or more classes from the jar. Those classes are then adding a jmx MBean which then causes a reference leak. Error message: Aug 9, 2011 4:53:11 PM org.apache.catalina.loader.WebappClassLoader clearReferencesJdbc SEVERE: The web application [/mavenproject1-1.0-SNAPSHOT] registered the JDBC driver [oracle.jdbc.OracleDriver] but failed to unregister it when the web application was stopped. To prevent a memory leak, the JDBC Driver has been forcibly unregistered. List of classes in the class-loader: 0 : class org.apache.catalina.loader.JdbcLeakPrevention (84 bytes) 1 : class oracle.jdbc.driver.OracleDriver (84 bytes) 2 : class oracle.jdbc.OracleDriver (84 bytes) 3 : class oracle.jdbc.driver.OracleDriverExtension (84 bytes) 4 : class oracle.jdbc.driver.OracleDriver$1 (84 bytes) 5 : class oracle.jdbc.driver.DiagnosabilityMXBean (84 bytes) 6 : class oracle.jdbc.driver.OracleDiagnosabilityMBean (84 bytes) 7 : class oracle.jdbc.driver.DatabaseError (84 bytes) 8 : class oracle.jdbc.driver.OracleSQLException (84 bytes) 9 : class oracle.net.ns.NetException (84 bytes) 10 : class oracle.jdbc.driver.SQLStateMapping (84 bytes) 11 : class oracle.jdbc.driver.SQLStateMapping$Tokenizer (84 bytes) 12 : class oracle.jdbc.driver.Message (84 bytes) 13 : class oracle.jdbc.driver.Message11 (84 bytes) 14 : class oracle.jdbc.internal.ObjectDataFactory (84 bytes) 15 : class oracle.sql.ORADataFactory (84 bytes) 16 : class oracle.sql.AnyDataFactory (84 bytes) 17 : class oracle.jdbc.internal.ObjectData (84 bytes) 18 : class oracle.sql.ORAData (84 bytes) 19 : class oracle.sql.TypeDescriptorFactory (84 bytes) I believe this means that JdbcLeakPrevention is the first class to actually be loaded. Steps to reproduce: 1) Compile the project, using the driver from http://www.oracle.com/technetwork/database/enterprise-edition/jdbc-111060-084321.html 2) Deploy the project to tomcat. 3) Undeploy the project from tomcat. You should get the error about clearReferencesJdbc Expected: While I would expect Tomcat to not leak the class, I would be happy if there was an option to make Tomcat not run clearReferencesJdbc, allowing me to undeploy the app without leaking. This would not be as much of a problem if it wasn't causing the entire classloader and everything that implies to be leaked too. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- 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
DO NOT REPLY [Bug 51640] clearReferencesJdbc seems to be causing leaks with com.oracle.ojdbc5 driver
https://issues.apache.org/bugzilla/show_bug.cgi?id=51640 Patrick M changed: What|Removed |Added CC||pmoh...@gmail.com -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- 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
DO NOT REPLY [Bug 51640] clearReferencesJdbc seems to be causing leaks with com.oracle.ojdbc5 driver
https://issues.apache.org/bugzilla/show_bug.cgi?id=51640 Patrick M changed: What|Removed |Added Attachment #27365|Example project to |Example Maven project to description|reproduce the problem |reproduce the problem -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- 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
DO NOT REPLY [Bug 51641] New: Http11NioProcessor not correct release
https://issues.apache.org/bugzilla/show_bug.cgi?id=51641
Bug #: 51641
Summary: Http11NioProcessor not correct release
Product: Tomcat 7
Version: trunk
Platform: PC
OS/Version: Windows XP
Status: NEW
Severity: normal
Priority: P2
Component: Connectors
AssignedTo: dev@tomcat.apache.org
ReportedBy: zhh200...@gmail.com
Classification: Unclassified
org.apache.coyote.http11.Http11NioProtocol.Http11ConnectionHandler
code segment:
==
@Override
public void release(SocketWrapper socket) {
Http11NioProcessor processor = connections.remove(socket);
if (processor != null) {
processor.recycle();
recycledProcessors.offer(processor);
}
}
==
should be:
==
@Override
public void release(SocketWrapper socket) {
Http11NioProcessor processor =
connections.remove(socket.getSocket());
if (processor != null) {
processor.recycle();
recycledProcessors.offer(processor);
}
}
==
type of connections is ConcurrentHashMap ,
not ConcurrentHashMap, Http11NioProcessor>.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- 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
