Re: svn commit: r575798 - in /tomcat/tc6.0.x/trunk/java/org/apache: coyote/http11/Http11NioProtocol.java tomcat/util/net/NioEndpoint.java

2007-09-15 Thread Peter Rossbach
HI Filip, can you please add your changes at changelog.xml (BUG 43356) Peter Am 14.09.2007 um 23:30 schrieb [EMAIL PROTECTED]: Author: fhanik Date: Fri Sep 14 14:30:29 2007 New Revision: 575798 URL: http://svn.apache.org/viewvc?rev=575798view=rev Log: Backport from earlier fix

DO NOT REPLY [Bug 43366] - Session Statistics command in manager fails with Unknown command /sessions

2007-09-15 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=43366. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE.

DO NOT REPLY [Bug 43338] - Setting '*' as the servlet-name in filter-mapping causes IllegalArgumentException.

2007-09-15 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=43338. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE.

svn commit: r575890 - in /tomcat/tc6.0.x/trunk: java/org/apache/catalina/core/StandardContext.java webapps/docs/changelog.xml

2007-09-15 Thread pero
Author: pero Date: Sat Sep 15 00:55:42 2007 New Revision: 575890 URL: http://svn.apache.org/viewvc?rev=575890view=rev Log: SRV 6.2.5 says supporting for '*' as the servlet-name in filter-mapping. filter-mapping filter-nameSampleFilter/filter-name servlet-name*/servlet-name

DO NOT REPLY [Bug 43338] - Setting '*' as the servlet-name in filter-mapping causes IllegalArgumentException.

2007-09-15 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=43338. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE.

Re: svn commit: r575332 - in /tomcat/tc6.0.x/trunk: java/org/apache/naming/resources/FileDirContext.java webapps/docs/changelog.xml

2007-09-15 Thread Remy Maucherat
Tim Funk wrote: 2) If a deploy tool is used which is doing checks - adding an extra check to allow/deny/restrict scope should not be too hard to do. Since users can disable symlink checks in the same class (FileDirContext) - the same exposure could be had with a little more effort. I'm not

Re: [PATCH] jasper - enum support for tag libs

2007-09-15 Thread Remy Maucherat
David Blevins wrote: On Sep 14, 2007, at 10:34 AM, Filip Hanik - Dev Lists wrote: - adding methods or altering the signature of the javax. APIs is clearly illegal yes, that would not be spec compliant, that's essentially what spec compliant means, that we pass the signature test (which we

DO NOT REPLY [Bug 43366] - Session Statistics command in manager fails with Unknown command /sessions

2007-09-15 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=43366. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE.

Re: svn commit: r575332 - in /tomcat/tc6.0.x/trunk: java/org/apache/naming/resources/FileDirContext.java webapps/docs/changelog.xml

2007-09-15 Thread Mark Thomas
Remy Maucherat wrote: Tim Funk wrote: 2) If a deploy tool is used which is doing checks - adding an extra check to allow/deny/restrict scope should not be too hard to do. Since users can disable symlink checks in the same class (FileDirContext) - the same exposure could be had with a little

Re: svn commit: r575332 - in /tomcat/tc6.0.x/trunk: java/org/apache/naming/resources/FileDirContext.java webapps/docs/changelog.xml

2007-09-15 Thread Tim Funk
Remy Maucherat wrote: I tested with the security manager, and it doesn't behave correctly. If the context.xml inside a webapp is: Context Resources className=org.apache.naming.resources.FileDirContext docBase=c:/foo aliases=/mysecretpath/=c:/ / /Context The docBase hack

DO NOT REPLY [Bug 43366] - Session Statistics command in manager fails with Unknown command /sessions

2007-09-15 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=43366. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE.

Re: svn commit: r575332 - in /tomcat/tc6.0.x/trunk: java/org/apache/naming/resources/FileDirContext.java webapps/docs/changelog.xml

2007-09-15 Thread Mladen Turk
Filip Hanik - Dev Lists wrote: Mladen Turk wrote: This simply has to stop. taking trunk away, this turn of events is expected. I wish everyone would have thought of that before we got caught up in the personal, and not what is important, trunk debate. I did, as well others did (I hope)

Re: svn commit: r575332 - in /tomcat/tc6.0.x/trunk: java/org/apache/naming/resources/FileDirContext.java webapps/docs/changelog.xml

2007-09-15 Thread Costin Manolache
Well, regarding the veto - it's simple. I second Remy's opinion that the veto is valid and the change is not right at the moment, and I guess that should close this discussion. The discussion about whether to add such a feature or not - I think a simple vote would solve this as well, it's quite

Re: svn commit: r575332 - in /tomcat/tc6.0.x/trunk: java/org/apache/naming/resources/FileDirContext.java webapps/docs/changelog.

2007-09-15 Thread Jim Jagielski
Costin Manolache wrote: Well, regarding the veto - it's simple. I second Remy's opinion that the veto is valid and the change is not right at the moment, and I guess that should close this discussion. The discussion about whether to add such a feature or not - I think a simple vote

DO NOT REPLY [Bug 43366] - Session Statistics command in manager fails with Unknown command /sessions

2007-09-15 Thread bugzilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=43366. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE.

Re: svn commit: r575332 - in /tomcat/tc6.0.x/trunk: java/org/apache/naming/resources/FileDirContext.java webapps/docs/changelog.

2007-09-15 Thread Costin Manolache
On 9/15/07, Jim Jagielski [EMAIL PROTECTED] wrote: Costin Manolache wrote: Well, regarding the veto - it's simple. I second Remy's opinion that the veto is valid and the change is not right at the moment, and I guess that should close this discussion. The discussion about whether

svn commit: r575945 - in /tomcat/tc6.0.x/trunk: java/org/apache/naming/resources/FileDirContext.java webapps/docs/changelog.xml

2007-09-15 Thread funkman
Author: funkman Date: Sat Sep 15 10:42:01 2007 New Revision: 575945 URL: http://svn.apache.org/viewvc?rev=575945view=rev Log: undo 575332 (alias support) due to 2 vetos Modified: tomcat/tc6.0.x/trunk/java/org/apache/naming/resources/FileDirContext.java

Re: svn commit: r575332 - in /tomcat/tc6.0.x/trunk: java/org/apache/naming/resources/FileDirContext.java webapps/docs/changelog.xml

2007-09-15 Thread Filip Hanik - Dev Lists
Mladen Turk wrote: Filip Hanik - Dev Lists wrote: Mladen Turk wrote: This simply has to stop. taking trunk away, this turn of events is expected. I wish everyone would have thought of that before we got caught up in the personal, and not what is important, trunk debate. I did, as well

Re: svn commit: r575332 - in /tomcat/tc6.0.x/trunk: java/org/apache/naming/resources/FileDirContext.java

2007-09-15 Thread Jim Jagielski
Filip Hanik - Dev Lists wrote: I'll vote +1 for bringing trunk back any time when I see your TODO list. Sorry but without that Tomcat6 is not Tomact6 but rather your personal (and anyone else) playground. bummer, I guess you never saw this

Re: svn commit: r575332 - in /tomcat/tc6.0.x/trunk: java/org/apache/naming/resources/FileDirContext.java webapps/docs/changelog.

2007-09-15 Thread William A. Rowe, Jr.
Costin Manolache wrote: Regarding feedback on patch - I think I expressed my concerns: - more analysis and understanding of security implications - if possible to do it at a different (higher) level - if it can be done in a modular fashion, i.e. keeping the default impl the way it is,