DO NOT REPLY [Bug 43394] New: - Some of application resouces are not being updated until debug mode startup

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=43394

   Summary: Some of application resouces are not being updated until
debug mode startup
   Product: Tomcat 5
   Version: 5.5.9
  Platform: Other
OS/Version: Windows XP
Status: NEW
  Severity: major
  Priority: P2
 Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Sometimes when an application's rebuilt, server doesn't apply the changes in
classes until it's started up in debug mode.

For example. We have found a bug in project. When it's fixed, changes still do
not come out. But when we start tomcat in debug mode and place breakpoints where
the bug was, it someway works fine without any changes. The project context
definition is placed in conf/Caltalina/localhost.

If that is not a bug in tomcat, please give an advice about how it's better to
redeploy applications.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

svn commit: r575617 - in /tomcat/tc6.0.x/trunk: java/org/apache/juli/ClassLoaderLogManager.java webapps/docs/changelog.xml

[pero]

Author: pero
Date: Fri Sep 14 04:01:06 2007
New Revision: 575617

URL: http://svn.apache.org/viewvc?rev=575617&view=rev
Log:
 Handle more then one system property replacement at file logging.properties.

Modified:
tomcat/tc6.0.x/trunk/java/org/apache/juli/ClassLoaderLogManager.java
tomcat/tc6.0.x/trunk/webapps/docs/changelog.xml

Modified: tomcat/tc6.0.x/trunk/java/org/apache/juli/ClassLoaderLogManager.java
URL: 
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/juli/ClassLoaderLogManager.java?rev=575617&r1=575616&r2=575617&view=diff
==
--- tomcat/tc6.0.x/trunk/java/org/apache/juli/ClassLoaderLogManager.java 
(original)
+++ tomcat/tc6.0.x/trunk/java/org/apache/juli/ClassLoaderLogManager.java Fri 
Sep 14 04:01:06 2007
@@ -442,13 +442,19 @@
  */
 protected String replace(String str) {
 String result = str;
-if (result.startsWith("${")) {
-int pos = result.indexOf('}');
-if (pos != -1) {
-String propName = result.substring(2, pos);
+int pos_start = result.indexOf("${");
+if (pos_start != -1) {
+int pos_end = result.indexOf('}');
+if (pos_end != -1) {
+String propName = result.substring(pos_start + 2, pos_end);
 String replacement = System.getProperty(propName);
 if (replacement != null) {
-result = replacement + result.substring(pos + 1);
+if(pos_start >0) {
+result = result.substring(0,pos_start) + 
+replacement + replace(result.substring(pos_end + 
1));
+} else {   
+result = replacement + 
replace(result.substring(pos_end + 1));
+}
 }
 }
 }

Modified: tomcat/tc6.0.x/trunk/webapps/docs/changelog.xml
URL: 
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/webapps/docs/changelog.xml?rev=575617&r1=575616&r2=575617&view=diff
==
--- tomcat/tc6.0.x/trunk/webapps/docs/changelog.xml (original)
+++ tomcat/tc6.0.x/trunk/webapps/docs/changelog.xml Fri Sep 14 04:01:06 2007
@@ -82,6 +82,9 @@
   
 Optimized JDBCAccessLogValve combined pattern request attribute 
access. (pero)
   
+  
+o.a.juli.ClassLoaderLogManager handle more then one system property 
replacement at file logging.properties. (pero)
+   
 
   
   



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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

[Yoav Shapira]

Hey,

On 9/13/07, Andrew J Snodgrass <[EMAIL PROTECTED]> wrote:
> The attached patch adds support for the direct use of enums in the
> attributes of tags.

Cool idea.  Is it in Bugzilla?

Yoav

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 43377] - RequestDumperValve garbles POST data

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=43377


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID




--- Additional Comments From [EMAIL PROTECTED]  2007-09-14 04:48 ---
Please read the comment just above the RequestDumperValve in server.xml or the
warning in the http://tomcat.apache.org/tomcat-5.5-doc/config/valve.html.

You need to use the RequestDumperFilter.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 43394] - Some of application resouces are not being updated until debug mode startup

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=43394


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID




--- Additional Comments From [EMAIL PROTECTED]  2007-09-14 04:45 ---
This looks like a question for the users list to me at the minute. Before
re-opening this bug, please try there for support. If you do re-open it you will
need to provide the following information as a minimum:
- What are you changing (JSP, Servlet, something else?)
- Results of testing with the latest stable 5.5.x release (currently 5.5.25)
- How often does this occur - every change, every few changes, once every few
hundred?

What would be ideal is a simple test case (as small as possible) that
demonstrated the issue.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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

[Remy Maucherat]

Yoav Shapira wrote:

Hey,

On 9/13/07, Andrew J Snodgrass <[EMAIL PROTECTED]> wrote:

The attached patch adds support for the direct use of enums in the
attributes of tags.


Cool idea.  Is it in Bugzilla?


I agree it seems like a good idea, but if it is not in the 
specification, then there's no way to include those custom syntax 
improvements.


Rémy

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 41797] - CNFE/NPE thrown from function mapper when externalizing

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=41797





--- Additional Comments From [EMAIL PROTECTED]  2007-09-14 05:25 ---
Over 6 months later this bug STILL exists in Tomcat 6.0.14. Implement the
fix by Tuomas Kiviaho. It really works.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 43396] New: - Tomcat src requires ant 1.7.0 to build

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=43396

   Summary: Tomcat src requires ant 1.7.0 to build
   Product: Tomcat 6
   Version: 6.0.14
  Platform: Other
OS/Version: Linux
Status: NEW
  Severity: trivial
  Priority: P2
 Component: Documentation
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


I attempted to build apache-tomcat-6.0.14-src on fc7
Using the distro's ant 1.6.5 the following error occurs:
[style] java.lang.ClassNotFoundException:
org.apache.tools.ant.taskdefs.optional.XslpLiaison
Using a downloaded ant 1.7.0 it works.

This is in conflict with what can be read line 28 in BUILDING.txt:
(1) Install Apache Ant 1.6.x on your computer

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 43397] New: - shutdown script malfunctions on fedora core 7

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=43397

   Summary: shutdown script malfunctions on fedora core 7
   Product: Tomcat 5
   Version: 5.0.25
  Platform: PC
OS/Version: other
Status: NEW
  Severity: normal
  Priority: P5
 Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


The shutdown script does not seem to work properly on Fedora Core 7.
Tried with both 5.5.17 and 5.5.25.

Here's the error that I get with both...

Sep 14, 2007 9:38:32 AM org.apache.coyote.http11.Http11BaseProtocol pause
INFO: Pausing Coyote HTTP/1.1 on http-8080
Sep 14, 2007 9:41:41 AM org.apache.catalina.connector.Connector pause
SEVERE: Protocol handler pause failed
java.net.ConnectException: Connection timed out
at java.net.PlainSocketImpl.socketConnect(Native Method)
at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:333)
at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:195)
at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:182)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:366)
at java.net.Socket.connect(Socket.java:519)
at java.net.Socket.connect(Socket.java:469)
at java.net.Socket.(Socket.java:366)
at java.net.Socket.(Socket.java:208)
at 
org.apache.jk.common.ChannelSocket.unLockSocket(ChannelSocket.java:473)
at org.apache.jk.common.ChannelSocket.pause(ChannelSocket.java:270)
at org.apache.jk.server.JkMain.pause(JkMain.java:679)
at org.apache.jk.server.JkCoyoteHandler.pause(JkCoyoteHandler.java:162)
at org.apache.catalina.connector.Connector.pause(Connector.java:1031)
at 
org.apache.catalina.core.StandardService.stop(StandardService.java:491)
at org.apache.catalina.core.StandardServer.stop(StandardServer.java:743)
at org.apache.catalina.startup.Catalina.stop(Catalina.java:601)
at org.apache.catalina.startup.Catalina.start(Catalina.java:576)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:294)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:432)
Sep 14, 2007 9:41:42 AM org.apache.catalina.core.StandardService stop
INFO: Stopping service Catalina
Sep 14, 2007 9:41:42 AM org.apache.coyote.http11.Http11BaseProtocol destroy
INFO: Stopping Coyote HTTP/1.1 on http-8080
Sep 14, 2007 9:41:42 AM org.apache.catalina.core.AprLifecycleListener 
lifecycleEvent
INFO: Failed shutdown of Apache Portable Runtime

Work around is to use 'pkill -9 java'.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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

[Filip Hanik - Dev Lists]

Yoav Shapira wrote:

Hey,

On 9/13/07, Andrew J Snodgrass <[EMAIL PROTECTED]> wrote:
  

The attached patch adds support for the direct use of enums in the
attributes of tags.



Cool idea.  Is it in Bugzilla?
  

I agree, think it is very useful. Would you mind opening a bugzilla,
http://issues.apache.org/bugzilla/enter_bug.cgi?product=Tomcat%206

Spec or not spec, Tomcat's goal is to be compliant with the JSP spec, 
not restricted by it. And this is a useful feature


Filip

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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

[Remy Maucherat]

Remy Maucherat wrote:
It's not a real veto anyway, but no proper review mechanism exists at 
the moment, and it's hard to integrate feature additions in 6.0.x 
without prior discussion.


I did review the patch:
- the syntax seems appropriate
- I don't know if it allows redirecting a single fine, but I think it 
should if it does not (I did not test it; at least the list feature 
would not be working right now)
- it seems like it will still validate going out of the remapped "base" 
path, which is good
- interaction with the webapp classloader, which might have special 
handling for /WEB-INF on the file based resources, is a question mark 
(compatibility with that would be good, if possible)
- security wise, it needs to be verified if the security manager 
prevents usage of the feature (normally it should, there are no 
privileged actions)


Rémy

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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

[Remy Maucherat]

Filip Hanik - Dev Lists wrote:

Yoav Shapira wrote:

Hey,

On 9/13/07, Andrew J Snodgrass <[EMAIL PROTECTED]> wrote:
 

The attached patch adds support for the direct use of enums in the
attributes of tags.



Cool idea.  Is it in Bugzilla?
  

I agree, think it is very useful. Would you mind opening a bugzilla,
http://issues.apache.org/bugzilla/enter_bug.cgi?product=Tomcat%206

Spec or not spec, Tomcat's goal is to be compliant with the JSP spec, 
not restricted by it. And this is a useful feature


There are a number of situations:
- adding flags to allow previous behaviors for unclear portions of the 
specification (which used pass the relevant TCK); I think this is acceptable
- adding methods or altering the signature of the javax. APIs is clearly 
illegal
- adding language constructs in JSP, elements in JCP DTDs or xsds is 
quite similar to that one, and I don't know if it's legal


Rémy

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

svn commit: r575741 - /tomcat/connectors/trunk/juli/src/java/org/apache/juli/ClassLoaderLogManager.java

[pero]

Author: pero
Date: Fri Sep 14 09:20:23 2007
New Revision: 575741

URL: http://svn.apache.org/viewvc?rev=575741&view=rev
Log:
Handle more then one system property replacement at file logging.properties.

Modified:

tomcat/connectors/trunk/juli/src/java/org/apache/juli/ClassLoaderLogManager.java

Modified: 
tomcat/connectors/trunk/juli/src/java/org/apache/juli/ClassLoaderLogManager.java
URL: 
http://svn.apache.org/viewvc/tomcat/connectors/trunk/juli/src/java/org/apache/juli/ClassLoaderLogManager.java?rev=575741&r1=575740&r2=575741&view=diff
==
--- 
tomcat/connectors/trunk/juli/src/java/org/apache/juli/ClassLoaderLogManager.java
 (original)
+++ 
tomcat/connectors/trunk/juli/src/java/org/apache/juli/ClassLoaderLogManager.java
 Fri Sep 14 09:20:23 2007
@@ -452,19 +452,24 @@
  */
 protected String replace(String str) {
 String result = str;
-if (result.startsWith("${")) {
-int pos = result.indexOf('}');
-if (pos != -1) {
-String propName = result.substring(2, pos);
+int pos_start = result.indexOf("${");
+if (pos_start != -1) {
+int pos_end = result.indexOf('}');
+if (pos_end != -1) {
+String propName = result.substring(pos_start + 2, pos_end);
 String replacement = System.getProperty(propName);
 if (replacement != null) {
-result = replacement + result.substring(pos + 1);
+if(pos_start >0) {
+result = result.substring(0,pos_start) + 
+replacement + replace(result.substring(pos_end + 
1));
+} else {   
+result = replacement + 
replace(result.substring(pos_end + 1));
+}
 }
 }
 }
 return result;
 }
-
 
 //  LogNode Inner Class
 



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

svn commit: r575742 - /tomcat/container/tc5.5.x/webapps/docs/changelog.xml

[pero]

Author: pero
Date: Fri Sep 14 09:20:28 2007
New Revision: 575742

URL: http://svn.apache.org/viewvc?rev=575742&view=rev
Log:
Handle more then one system property replacement at file logging.properties.

Modified:
tomcat/container/tc5.5.x/webapps/docs/changelog.xml

Modified: tomcat/container/tc5.5.x/webapps/docs/changelog.xml
URL: 
http://svn.apache.org/viewvc/tomcat/container/tc5.5.x/webapps/docs/changelog.xml?rev=575742&r1=575741&r2=575742&view=diff
==
--- tomcat/container/tc5.5.x/webapps/docs/changelog.xml (original)
+++ tomcat/container/tc5.5.x/webapps/docs/changelog.xml Fri Sep 14 09:20:28 2007
@@ -53,6 +53,9 @@
 Support logging of current thread name at AccessLogValve (ex. add %I 
to your pattern).
 Usefull to compare access logging entry later with a stacktraces. 
(pero)
 
+  
+o.a.juli.ClassLoaderLogManager handle more then one system property 
replacement at file logging.properties. (pero)
+   
 
   
   



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 43377] - RequestDumperValve garbles POST data

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=43377





--- Additional Comments From [EMAIL PROTECTED]  2007-09-14 09:26 ---
Thanks for the pointer. One could, however, argue that the comment could be just
a wee bit more explicit. Like "WARNING: using it will break stuff in
unpredictable ways" or at least include a pointer to the URL you mentioned.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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

[Filip Hanik - Dev Lists]

Remy Maucherat wrote:

Filip Hanik - Dev Lists wrote:

Yoav Shapira wrote:

Hey,

On 9/13/07, Andrew J Snodgrass <[EMAIL PROTECTED]> wrote:
 

The attached patch adds support for the direct use of enums in the
attributes of tags.



Cool idea.  Is it in Bugzilla?
  

I agree, think it is very useful. Would you mind opening a bugzilla,
http://issues.apache.org/bugzilla/enter_bug.cgi?product=Tomcat%206

Spec or not spec, Tomcat's goal is to be compliant with the JSP spec, 
not restricted by it. And this is a useful feature


There are a number of situations:
- adding flags to allow previous behaviors for unclear portions of the 
specification (which used pass the relevant TCK); I think this is 
acceptable
- 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 haven't done 
for a couple of years, until the Geronimo guy submitted the patches)

Filip
- adding language constructs in JSP, elements in JCP DTDs or xsds is 
quite similar to that one, and I don't know if it's legal


Rémy

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]






-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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

[Tim Funk]

The basic concept behind the logic is:
- Look for prefix
- Replace with new base path

The new path replacement is done before the symlink and case check is 
done so those checks are still preserved. (Just with the new path alias).


If there is a security manager in play - it should already be blocking 
access to directories outside of one's control.


For file/directory redirection such as replacing requesting /foo and 
then redirecting to /foo/ - I will add (if this is accepted) an entry to 
the FAQ to strongly recommend replacements include the trailing / - such 
that a user shoudl enter: /foo/bar/=/docs/tmp/ AND NOT 
/foo/bar=/docs/tmp since wierd behaviors can arise since a request of 
/foo/barry/file.pdf would yield /docs/tmpry/file.pdf (notice the last ry 
being preserved). I left this behavior in instead of requiring a 
trailing / since ... well if someone wishes to shoot themself in the 
foot - I won't stop them.


For /WEB-INF/ handling - this does provide an ability to have WEB-INF 
live somewhere else on the filesystem other than the webapp. When I 
first made the patch - I thought about making an exception for that - 
but then decided not to since I couldn't ponder a reason security wise 
to do so.


From a security point of view - the only gotcha I see is in a shared 
environment where you might suck in part of someone else's webapp in a 
shared environment. If this can be done - then it would be worthwhile 
adding a flag which would allow any aliasing to occur. Or a simpler 
alternative is if you are running with a security manager turned on - 
then aliasing is disabled.



-Tim

Remy Maucherat wrote:

Remy Maucherat wrote:
It's not a real veto anyway, but no proper review mechanism exists at 
the moment, and it's hard to integrate feature additions in 6.0.x 
without prior discussion.


I did review the patch:
- the syntax seems appropriate
- I don't know if it allows redirecting a single fine, but I think it 
should if it does not (I did not test it; at least the list feature 
would not be working right now)
- it seems like it will still validate going out of the remapped "base" 
path, which is good
- interaction with the webapp classloader, which might have special 
handling for /WEB-INF on the file based resources, is a question mark 
(compatibility with that would be good, if possible)
- security wise, it needs to be verified if the security manager 
prevents usage of the feature (normally it should, there are no 
privileged actions)



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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

[Costin Manolache]

I'm not sure the security discussion is that simple, this seems quite a
dangerous change.
Currently  the user is restricted  to the webapps/ directory ( well,  he can
add a context
with the base in /etc and expose passwd I guess - but hopefully if a deploy
tool is used
or some automation is done on adding webapps, it can be controlled ). At
least this
introduces one more risk.

It may also have some implications on other use cases - deployment ( the
current pattern
is that all files for a webapp are in one place ), replication ( i.e. if
someone wants same webapps
on a pool of servers ).

Also questions about servlet API - are the aliases considered as part of the
webapp and returned
as resources ? Portability ? Will anything break or be confusing ?

But the most important question I have - why at this level ? If you have
files in a different
 directory - just add a servlet that is configured to serve files from
there, doesn't have to
be a tomcat-specific feature.

Costin

On 9/14/07, Tim Funk <[EMAIL PROTECTED]> wrote:
>
> The basic concept behind the logic is:
> - Look for prefix
> - Replace with new base path
>
> The new path replacement is done before the symlink and case check is
> done so those checks are still preserved. (Just with the new path alias).
>
> If there is a security manager in play - it should already be blocking
> access to directories outside of one's control.
>
> For file/directory redirection such as replacing requesting /foo and
> then redirecting to /foo/ - I will add (if this is accepted) an entry to
> the FAQ to strongly recommend replacements include the trailing / - such
> that a user shoudl enter: /foo/bar/=/docs/tmp/ AND NOT
> /foo/bar=/docs/tmp since wierd behaviors can arise since a request of
> /foo/barry/file.pdf would yield /docs/tmpry/file.pdf (notice the last ry
> being preserved). I left this behavior in instead of requiring a
> trailing / since ... well if someone wishes to shoot themself in the
> foot - I won't stop them.
>
> For /WEB-INF/ handling - this does provide an ability to have WEB-INF
> live somewhere else on the filesystem other than the webapp. When I
> first made the patch - I thought about making an exception for that -
> but then decided not to since I couldn't ponder a reason security wise
> to do so.
>
> From a security point of view - the only gotcha I see is in a shared
> environment where you might suck in part of someone else's webapp in a
> shared environment. If this can be done - then it would be worthwhile
> adding a flag which would allow any aliasing to occur. Or a simpler
> alternative is if you are running with a security manager turned on -
> then aliasing is disabled.
>
>
> -Tim
>
> Remy Maucherat wrote:
> > Remy Maucherat wrote:
> >> It's not a real veto anyway, but no proper review mechanism exists at
> >> the moment, and it's hard to integrate feature additions in 6.0.x
> >> without prior discussion.
> >
> > I did review the patch:
> > - the syntax seems appropriate
> > - I don't know if it allows redirecting a single fine, but I think it
> > should if it does not (I did not test it; at least the list feature
> > would not be working right now)
> > - it seems like it will still validate going out of the remapped "base"
> > path, which is good
> > - interaction with the webapp classloader, which might have special
> > handling for /WEB-INF on the file based resources, is a question mark
> > (compatibility with that would be good, if possible)
> > - security wise, it needs to be verified if the security manager
> > prevents usage of the feature (normally it should, there are no
> > privileged actions)
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

DO NOT REPLY [Bug 43400] New: - enum support for tag libs

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=43400

   Summary: enum support for tag libs
   Product: Tomcat 6
   Version: unspecified
  Platform: All
   URL: http://www.007names.com
OS/Version: All
Status: NEW
  Severity: enhancement
  Priority: P5
 Component: Jasper
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Support for the direct use of enums in the attributes of tags.

Assume there is the enum:

public enum LoginType {
  account, manager, reseller;
}

and a setter for a tag called 'page':

public void setLogin_required_type( LoginType login_required_type ) { ...

then the jsp code:



would result in the generation of the java code:

page_tag_instance.setLogin_required_type(LoginType.account);

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 43400] - enum support for tag libs

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=43400





--- Additional Comments From [EMAIL PROTECTED]  2007-09-14 11:56 ---
Created an attachment (id=20827)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=20827&action=view)
tag enum support patch


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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

[Filip Hanik - Dev Lists]

Costin Manolache wrote:

I'm not sure the security discussion is that simple, this seems quite a
dangerous change.
Currently  the user is restricted  to the webapps/ directory ( well,  he can
add a context
with the base in /etc and expose passwd I guess - but hopefully if a deploy
tool is used
or some automation is done on adding webapps, it can be controlled ). At
least this
introduces one more risk.
  
what does httpd do when you do set up an alias or document root for the 
/etc directory?
Since it does, would that mean that httpd should not include the Alias 
feature?
This is the same scenario, adding a useful feature, though it can go 
wrong when when misconfigured, doesn't mean we shouldn't do it.

Tomcat already would allow you do to docBase=/etc"
so the risk already exists, and no, the user is not restricted to the 
webapps directory.



It may also have some implications on other use cases - deployment ( the
current pattern
is that all files for a webapp are in one place ), replication ( i.e. if
someone wants same webapps
on a pool of servers ).

Also questions about servlet API - are the aliases considered as part of the
webapp and returned
as resources ? Portability ? Will anything break or be confusing ?
  
This is important, it shouldn't break anything from spec compliant, but 
that goes with every single feature we put in Tomcat.

If it does break the spec, then a -1 is justified in a heartbeat.

But the most important question I have - why at this level ? If you have
files in a different
 directory - just add a servlet that is configured to serve files from
there, doesn't have to
be a tomcat-specific feature.
  
Back to the httpd analogy, that would be equivalent of saying, remove 
the Alias feature, and write a perl/php/asp script that does this for you
I find the feature useful, and if it doesn't go against the spec, I've 
seen the feature requested on tomcat-user as well.

Filip

Costin

On 9/14/07, Tim Funk <[EMAIL PROTECTED]> wrote:
  

The basic concept behind the logic is:
- Look for prefix
- Replace with new base path

The new path replacement is done before the symlink and case check is
done so those checks are still preserved. (Just with the new path alias).

If there is a security manager in play - it should already be blocking
access to directories outside of one's control.

For file/directory redirection such as replacing requesting /foo and
then redirecting to /foo/ - I will add (if this is accepted) an entry to
the FAQ to strongly recommend replacements include the trailing / - such
that a user shoudl enter: /foo/bar/=/docs/tmp/ AND NOT
/foo/bar=/docs/tmp since wierd behaviors can arise since a request of
/foo/barry/file.pdf would yield /docs/tmpry/file.pdf (notice the last ry
being preserved). I left this behavior in instead of requiring a
trailing / since ... well if someone wishes to shoot themself in the
foot - I won't stop them.

For /WEB-INF/ handling - this does provide an ability to have WEB-INF
live somewhere else on the filesystem other than the webapp. When I
first made the patch - I thought about making an exception for that -
but then decided not to since I couldn't ponder a reason security wise
to do so.

From a security point of view - the only gotcha I see is in a shared
environment where you might suck in part of someone else's webapp in a
shared environment. If this can be done - then it would be worthwhile
adding a flag which would allow any aliasing to occur. Or a simpler
alternative is if you are running with a security manager turned on -
then aliasing is disabled.


-Tim

Remy Maucherat wrote:


Remy Maucherat wrote:
  

It's not a real veto anyway, but no proper review mechanism exists at
the moment, and it's hard to integrate feature additions in 6.0.x
without prior discussion.


I did review the patch:
- the syntax seems appropriate
- I don't know if it allows redirecting a single fine, but I think it
should if it does not (I did not test it; at least the list feature
would not be working right now)
- it seems like it will still validate going out of the remapped "base"
path, which is good
- interaction with the webapp classloader, which might have special
handling for /WEB-INF on the file based resources, is a question mark
(compatibility with that would be good, if possible)
- security wise, it needs to be verified if the security manager
prevents usage of the feature (normally it should, there are no
privileged actions)
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





  



No virus found in this incoming message.
Checked by AVG Free Edition. 
Version: 7.5.487 / Virus Database: 269.13.19/1008 - Release Date: 9/14/2007 8:59 AM
  



-
To unsubscribe, e-mail: [EMAIL PR

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

[Jim Jagielski]

On Sep 14, 2007, at 3:30 PM, Filip Hanik - Dev Lists wrote:


Costin Manolache wrote:
I'm not sure the security discussion is that simple, this seems  
quite a

dangerous change.
Currently  the user is restricted  to the webapps/ directory  
( well,  he can

add a context
with the base in /etc and expose passwd I guess - but hopefully if  
a deploy

tool is used
or some automation is done on adding webapps, it can be  
controlled ). At

least this
introduces one more risk.

what does httpd do when you do set up an alias or document root for  
the /etc directory?
Since it does, would that mean that httpd should not include the  
Alias feature?
This is the same scenario, adding a useful feature, though it can  
go wrong when when misconfigured, doesn't mean we shouldn't do it.

Tomcat already would allow you do to docBase=/etc"
so the risk already exists, and no, the user is not restricted to  
the webapps directory.




httpd allows for not only following of symlinks but
also having content outside of DocumentRoot via
the Alias directive.

But, of course httpd has had this for ages, and the
core internals of httpd know how to handle the security
implications of both symlinks on the file system
and Aliases in the configuration... The question
is does this patch open any holes it shouldn't...

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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

[Jim Jagielski]

On Sep 14, 2007, at 2:49 PM, Costin Manolache wrote:



It may also have some implications on other use cases - deployment  
( the

current pattern
is that all files for a webapp are in one place ), replication  
( i.e. if

someone wants same webapps
on a pool of servers ).



To me this is an important point... the beauty of
webapps is that, well, they are self contained.

But I can also easily see the advantage, from an admin
and even developer PoV for more flexibility.

Basically, of course, Aliases are runtime configurations
of what could be done via file-system provided symlinks...
So the security and API issues should see what, if anything,
can be gleamed from that...


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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

[Remy Maucherat]

Jim Jagielski wrote:


On Sep 14, 2007, at 2:49 PM, Costin Manolache wrote:



It may also have some implications on other use cases - deployment ( the
current pattern
is that all files for a webapp are in one place ), replication ( i.e. if
someone wants same webapps
on a pool of servers ).



To me this is an important point... the beauty of
webapps is that, well, they are self contained.

But I can also easily see the advantage, from an admin
and even developer PoV for more flexibility.

Basically, of course, Aliases are runtime configurations
of what could be done via file-system provided symlinks...
So the security and API issues should see what, if anything,
can be gleamed from that...


Yes, this is hard to compare to httpd, as in the case of Tomcat, there 
is precise specification which defines a portable web application 
packaging. I see the latest changes have all aimed at breaking 
portability, and I don't like that at all.


Rémy


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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

[Filip Hanik - Dev Lists]

Remy Maucherat wrote:

Jim Jagielski wrote:


On Sep 14, 2007, at 2:49 PM, Costin Manolache wrote:



It may also have some implications on other use cases - deployment ( 
the

current pattern
is that all files for a webapp are in one place ), replication ( 
i.e. if

someone wants same webapps
on a pool of servers ).



To me this is an important point... the beauty of
webapps is that, well, they are self contained.

But I can also easily see the advantage, from an admin
and even developer PoV for more flexibility.

Basically, of course, Aliases are runtime configurations
of what could be done via file-system provided symlinks...
So the security and API issues should see what, if anything,
can be gleamed from that...


Yes, this is hard to compare to httpd, as in the case of Tomcat, there 
is precise specification which defines a portable web application 
packaging. I see the latest changes have all aimed at breaking 
portability, and I don't like that at all.
I don't subscribe to this point of view, basically, if that was the 
case, we wouldn't have META-INF/context.xml as a feature either (as just 
one example).
Portability is not something that is enforced by Tomcat, but by the 
spec. So if a user writes a portable webapp on weblogic, then the spec 
(and tomcat) make that webapp being able to run on Tomcat. and the other 
way around. However, pretty much every single servlet engine, Tomcat 
included, does add additional features, useful to the users for the 
frameworks.
If Tomcat didn't have any custom features, then it wouldn't be half as 
popular as it is today.


Writing a portable webapp, is doable, and essentially has nothing to do 
with the optional feature set in Tomcat. If you want a portable webapp, 
simply don't use the non portable features in Tomcat.


Filip

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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

[Jim Jagielski]

On Sep 14, 2007, at 3:50 PM, Remy Maucherat wrote:


Jim Jagielski wrote:

On Sep 14, 2007, at 2:49 PM, Costin Manolache wrote:


It may also have some implications on other use cases -  
deployment ( the

current pattern
is that all files for a webapp are in one place ), replication  
( i.e. if

someone wants same webapps
on a pool of servers ).


To me this is an important point... the beauty of
webapps is that, well, they are self contained.
But I can also easily see the advantage, from an admin
and even developer PoV for more flexibility.
Basically, of course, Aliases are runtime configurations
of what could be done via file-system provided symlinks...
So the security and API issues should see what, if anything,
can be gleamed from that...


Yes, this is hard to compare to httpd, as in the case of Tomcat,  
there is precise specification which defines a portable web  
application packaging. I see the latest changes have all aimed at  
breaking portability, and I don't like that at all.




I agree that if you use this feature, then portability is
broken. But does *providing* this, in and of itself,
break portability? Basically this would be a "feature"
that if not used, from what it appears to me, adds no
overhead or concerns. However, for those who do choose to
use it, they break portability... So, assuming that
TC does All The Right Things internally when passed
an Alias, the question boils down to TC saying "We
don't think you should do this and we aren't going
to make it easy for you to do so" or "We don't
think you should be doing this, but since you are
anyway, here's an 'official' way of doing it".




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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

[Remy Maucherat]

Filip Hanik - Dev Lists wrote:

Remy Maucherat wrote:
Yes, this is hard to compare to httpd, as in the case of Tomcat, there 
is precise specification which defines a portable web application 
packaging. I see the latest changes have all aimed at breaking 
portability, and I don't like that at all.
I don't subscribe to this point of view, basically, if that was the 
case, we wouldn't have META-INF/context.xml as a feature either (as just 
one example).
Portability is not something that is enforced by Tomcat, but by the 
spec. So if a user writes a portable webapp on weblogic, then the spec 
(and tomcat) make that webapp being able to run on Tomcat. and the other 
way around. However, pretty much every single servlet engine, Tomcat 
included, does add additional features, useful to the users for the 
frameworks.
If Tomcat didn't have any custom features, then it wouldn't be half as 
popular as it is today.


This is history rewriting. Actually, people used it (in that order) 
because of:
- it was a component of the RI, which meant not too many spec breaking 
features, and that an app that ran on Tomcat was likely to run on the 
production server (which was rarely Tomcat)

- the Apache brand
- relatively small and light

Writing a portable webapp, is doable, and essentially has nothing to do 
with the optional feature set in Tomcat. If you want a portable webapp, 
simply don't use the non portable features in Tomcat.


It's another strategy: add as many of the features that a few users ask 
for, regardless of what the specification. This is what many commercial 
appservers often do, basically. It's quite amazing you cannot seem to 
accept that I do not like this policy.


Rémy

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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

[Jim Jagielski]

On Sep 14, 2007, at 4:27 PM, Remy Maucherat wrote:


Filip Hanik - Dev Lists wrote:
Writing a portable webapp, is doable, and essentially has nothing  
to do with the optional feature set in Tomcat. If you want a  
portable webapp, simply don't use the non portable features in  
Tomcat.


It's another strategy: add as many of the features that a few users  
ask for, regardless of what the specification. This is what many  
commercial appservers often do, basically. It's quite amazing you  
cannot seem to accept that I do not like this policy.




Filip agreed that if it went against the specification then
the patch had no place being committed. In fact, I think
everyone did :)

If, however, the specification is moot, then the decision
on "how much to add in response to user or developer
desire" is, I think we all agree, a personal choice...
I can certainly see your PoV where each feature is
extra code to maintain and increases the footprint
of TC. I can also see Filip and Tim's PoV that extra
features that make users/developers happy are "worth"
it.

(Jim has this funny mental image of Remy and Filip
in those Samurai Fat Suits resolving their differing
PoVs :) )

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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

[Filip Hanik - Dev Lists]

Remy Maucherat wrote:

Filip Hanik - Dev Lists wrote:

Remy Maucherat wrote:
Yes, this is hard to compare to httpd, as in the case of Tomcat, 
there is precise specification which defines a portable web 
application packaging. I see the latest changes have all aimed at 
breaking portability, and I don't like that at all.
I don't subscribe to this point of view, basically, if that was the 
case, we wouldn't have META-INF/context.xml as a feature either (as 
just one example).
Portability is not something that is enforced by Tomcat, but by the 
spec. So if a user writes a portable webapp on weblogic, then the 
spec (and tomcat) make that webapp being able to run on Tomcat. and 
the other way around. However, pretty much every single servlet 
engine, Tomcat included, does add additional features, useful to the 
users for the frameworks.
If Tomcat didn't have any custom features, then it wouldn't be half 
as popular as it is today.


This is history rewriting. Actually, people used it (in that order) 
because of:
- it was a component of the RI, which meant not too many spec breaking 
features, and that an app that ran on Tomcat was likely to run on the 
production server (which was rarely Tomcat)

- the Apache brand
- relatively small and light

Writing a portable webapp, is doable, and essentially has nothing to 
do with the optional feature set in Tomcat. If you want a portable 
webapp, simply don't use the non portable features in Tomcat.


It's another strategy: add as many of the features that a few users 
ask for, regardless of what the specification. This is what many 
commercial appservers often do, basically. It's quite amazing you 
cannot seem to accept that I do not like this policy.
I totally accept that you dont like the policy, but it doesn't justify 
vetos. and that has been one of the core of the issues.
the one time it would fly for a veto would be when, a) others feel the 
same, b) no one likes the feature


Filip

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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

[Remy Maucherat]

Jim Jagielski wrote:

Filip agreed that if it went against the specification then
the patch had no place being committed. In fact, I think
everyone did :)

If, however, the specification is moot, then the decision
on "how much to add in response to user or developer
desire" is, I think we all agree, a personal choice...
I can certainly see your PoV where each feature is
extra code to maintain and increases the footprint
of TC. I can also see Filip and Tim's PoV that extra
features that make users/developers happy are "worth"
it.


This adds ways to work around the specification. The reason for which 
most people used Tomcat in the first place, as I said, was "it was a 
component of the RI, which meant not too many spec breaking features, 
and that an app that ran on Tomcat was likely to run on the production 
server (which was rarely Tomcat)". Do you have evidence which shows 
otherwise ?



(Jim has this funny mental image of Remy and Filip
in those Samurai Fat Suits resolving their differing
PoVs :) )


Hmm, I don't think so :|

Rémy

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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

[Remy Maucherat]

Filip Hanik - Dev Lists wrote:
I totally accept that you dont like the policy, but it doesn't justify 
vetos. and that has been one of the core of the issues.
the one time it would fly for a veto would be when, a) others feel the 
same, b) no one likes the feature


I detailed a number of reason for this veto, which I qualified as quite 
lightweight. Unfortunately, there's no appropriate review mechanism, and 
as usual, this commit was made (in a branch of which I am the RM) 
without prior discussion, etc. I think understanding the overall problem 
is quite simple.


I did post a review of the patch - which, in case you read it, seems 
acceptable to me, unlike the JSP change -, and Tim responded with good 
explanations.


Rémy

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

svn commit: r575793 - in /tomcat/sandbox/gdev6x/java/org/apache: coyote/http11/Http11NioProtocol.java tomcat/util/net/NioEndpoint.java

[fhanik]

Author: fhanik
Date: Fri Sep 14 14:10:11 2007
New Revision: 575793

URL: http://svn.apache.org/viewvc?rev=575793&view=rev
Log:
Use a truststore if defined bz 
http://issues.apache.org/bugzilla/show_bug.cgi?id=43356

Modified:
tomcat/sandbox/gdev6x/java/org/apache/coyote/http11/Http11NioProtocol.java
tomcat/sandbox/gdev6x/java/org/apache/tomcat/util/net/NioEndpoint.java

Modified: 
tomcat/sandbox/gdev6x/java/org/apache/coyote/http11/Http11NioProtocol.java
URL: 
http://svn.apache.org/viewvc/tomcat/sandbox/gdev6x/java/org/apache/coyote/http11/Http11NioProtocol.java?rev=575793&r1=575792&r2=575793&view=diff
==
--- tomcat/sandbox/gdev6x/java/org/apache/coyote/http11/Http11NioProtocol.java 
(original)
+++ tomcat/sandbox/gdev6x/java/org/apache/coyote/http11/Http11NioProtocol.java 
Fri Sep 14 14:10:11 2007
@@ -547,17 +547,25 @@
 public String getAlgorithm() { return ep.getAlgorithm();}
 public void setAlgorithm(String s ) { ep.setAlgorithm(s);}
 
-public boolean getClientAuth() { return ep.getClientAuth();}
-public void setClientAuth(boolean b ) { ep.setClientAuth(b);}
+public void setClientauth(String s) {setClientAuth(s);}
+public String getClientauth(){ return getClientAuth();}
+public String getClientAuth() { return ep.getClientAuth();}
+public void setClientAuth(String s ) { ep.setClientAuth(s);}
 
 public String getKeystorePass() { return ep.getKeystorePass();}
 public void setKeystorePass(String s ) { ep.setKeystorePass(s);}
 public void setKeypass(String s) { setKeystorePass(s);}
 public String getKeypass() { return getKeystorePass();}
-
-
 public String getKeystoreType() { return ep.getKeystoreType();}
 public void setKeystoreType(String s ) { ep.setKeystoreType(s);}
+
+public void setTruststoreFile(String f){ep.setTruststoreFile(f);}
+public String getTruststoreFile(){return ep.getTruststoreFile();}
+public void setTruststorePass(String p){ep.setTruststorePass(p);}
+public String getTruststorePass(){return ep.getTruststorePass();}
+public void setTruststoreType(String t){ep.setTruststoreType(t);}
+public String getTruststoreType(){ return ep.getTruststoreType();}
+
 
 public String getSslProtocol() { return ep.getSslProtocol();}
 public void setSslProtocol(String s) { ep.setSslProtocol(s);}

Modified: tomcat/sandbox/gdev6x/java/org/apache/tomcat/util/net/NioEndpoint.java
URL: 
http://svn.apache.org/viewvc/tomcat/sandbox/gdev6x/java/org/apache/tomcat/util/net/NioEndpoint.java?rev=575793&r1=575792&r2=575793&view=diff
==
--- tomcat/sandbox/gdev6x/java/org/apache/tomcat/util/net/NioEndpoint.java 
(original)
+++ tomcat/sandbox/gdev6x/java/org/apache/tomcat/util/net/NioEndpoint.java Fri 
Sep 14 14:10:11 2007
@@ -518,10 +518,42 @@
 }
 
 
+public String adjustRelativePath(String path, String relativeTo) {
+File f = new File(path);
+if ( !f.isAbsolute()) {
+path = relativeTo + File.separator + path;
+f = new File(path);
+}
+if (!f.exists()) {
+log.warn("configured file:["+path+"] does not exist.");
+}
+return path;
+}
+
+public String defaultIfNull(String val, String defaultValue) {
+if (val==null) return defaultValue;
+else return val;
+}
 //   SSL related properties 
+protected String truststoreFile = 
System.getProperty("javax.net.ssl.trustStore");
+public void setTruststoreFile(String s) {
+s = adjustRelativePath(s,System.getProperty("catalina.base"));
+this.truststoreFile = s;
+}
+public String getTruststoreFile() {return truststoreFile;}
+protected String truststorePass = 
System.getProperty("javax.net.ssl.trustStorePassword");
+public void setTruststorePass(String truststorePass) {this.truststorePass 
= truststorePass;}
+public String getTruststorePass() {return truststorePass;}
+protected String truststoreType = 
System.getProperty("javax.net.ssl.trustStoreType");
+public void setTruststoreType(String truststoreType) {this.truststoreType 
= truststoreType;}
+public String getTruststoreType() {return truststoreType;}
+
 protected String keystoreFile = 
System.getProperty("user.home")+"/.keystore";
 public String getKeystoreFile() { return keystoreFile;}
-public void setKeystoreFile(String s ) { this.keystoreFile = s; }
+public void setKeystoreFile(String s ) { 
+s = adjustRelativePath(s,System.getProperty("catalina.base"));
+this.keystoreFile = s; 
+}
 public void setKeystore(String s ) { setKeystoreFile(s);}
 public String getKeystore() { return getKeystoreFile();}
 
@@ -529,9 +561,9 @@
 public String getAlgorithm() { return algorithm;}
 public void setAlgorith

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

[fhanik]

Author: fhanik
Date: Fri Sep 14 14:30:29 2007
New Revision: 575798

URL: http://svn.apache.org/viewvc?rev=575798&view=rev
Log:
Backport from earlier fix
http://issues.apache.org/bugzilla/show_bug.cgi?id=43356

Modified:
tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11/Http11NioProtocol.java
tomcat/tc6.0.x/trunk/java/org/apache/tomcat/util/net/NioEndpoint.java

Modified: 
tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11/Http11NioProtocol.java
URL: 
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11/Http11NioProtocol.java?rev=575798&r1=575797&r2=575798&view=diff
==
--- tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11/Http11NioProtocol.java 
(original)
+++ tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11/Http11NioProtocol.java 
Fri Sep 14 14:30:29 2007
@@ -547,17 +547,25 @@
 public String getAlgorithm() { return ep.getAlgorithm();}
 public void setAlgorithm(String s ) { ep.setAlgorithm(s);}
 
-public boolean getClientAuth() { return ep.getClientAuth();}
-public void setClientAuth(boolean b ) { ep.setClientAuth(b);}
+public void setClientauth(String s) {setClientAuth(s);}
+public String getClientauth(){ return getClientAuth();}
+public String getClientAuth() { return ep.getClientAuth();}
+public void setClientAuth(String s ) { ep.setClientAuth(s);}
 
 public String getKeystorePass() { return ep.getKeystorePass();}
 public void setKeystorePass(String s ) { ep.setKeystorePass(s);}
 public void setKeypass(String s) { setKeystorePass(s);}
 public String getKeypass() { return getKeystorePass();}
-
-
 public String getKeystoreType() { return ep.getKeystoreType();}
 public void setKeystoreType(String s ) { ep.setKeystoreType(s);}
+
+public void setTruststoreFile(String f){ep.setTruststoreFile(f);}
+public String getTruststoreFile(){return ep.getTruststoreFile();}
+public void setTruststorePass(String p){ep.setTruststorePass(p);}
+public String getTruststorePass(){return ep.getTruststorePass();}
+public void setTruststoreType(String t){ep.setTruststoreType(t);}
+public String getTruststoreType(){ return ep.getTruststoreType();}
+
 
 public String getSslProtocol() { return ep.getSslProtocol();}
 public void setSslProtocol(String s) { ep.setSslProtocol(s);}

Modified: tomcat/tc6.0.x/trunk/java/org/apache/tomcat/util/net/NioEndpoint.java
URL: 
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/tomcat/util/net/NioEndpoint.java?rev=575798&r1=575797&r2=575798&view=diff
==
--- tomcat/tc6.0.x/trunk/java/org/apache/tomcat/util/net/NioEndpoint.java 
(original)
+++ tomcat/tc6.0.x/trunk/java/org/apache/tomcat/util/net/NioEndpoint.java Fri 
Sep 14 14:30:29 2007
@@ -527,20 +527,50 @@
 }
 
 
+public String adjustRelativePath(String path, String relativeTo) {
+File f = new File(path);
+if ( !f.isAbsolute()) {
+path = relativeTo + File.separator + path;
+f = new File(path);
+}
+if (!f.exists()) {
+log.warn("configured file:["+path+"] does not exist.");
+}
+return path;
+}
+
+public String defaultIfNull(String val, String defaultValue) {
+if (val==null) return defaultValue;
+else return val;
+}
 //   SSL related properties 
+protected String truststoreFile = 
System.getProperty("javax.net.ssl.trustStore");
+public void setTruststoreFile(String s) {
+s = adjustRelativePath(s,System.getProperty("catalina.base"));
+this.truststoreFile = s;
+}
+public String getTruststoreFile() {return truststoreFile;}
+protected String truststorePass = 
System.getProperty("javax.net.ssl.trustStorePassword");
+public void setTruststorePass(String truststorePass) {this.truststorePass 
= truststorePass;}
+public String getTruststorePass() {return truststorePass;}
+protected String truststoreType = 
System.getProperty("javax.net.ssl.trustStoreType");
+public void setTruststoreType(String truststoreType) {this.truststoreType 
= truststoreType;}
+public String getTruststoreType() {return truststoreType;}
+
 protected String keystoreFile = 
System.getProperty("user.home")+"/.keystore";
 public String getKeystoreFile() { return keystoreFile;}
-public void setKeystoreFile(String s ) { this.keystoreFile = s; }
-public void setKeystore(String s ) { setKeystoreFile(s);}
-public String getKeystore() { return getKeystoreFile();}
+public void setKeystoreFile(String s ) { 
+s = adjustRelativePath(s,System.getProperty("catalina.base"));
+this.keystoreFile = s; 
+}
 
 protected String algorithm = "SunX509";
 public String getAlgorithm() { return algorithm;}
 public voi

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

[Tim Funk]

Hopefully I can get all the concerns in one email ...
[Pardon me if this is not the most coherent - I been on vacation this 
week and I was staining and putting sealer or some wood furniture and 
got too many fumes to the head ... but don't let that reflect badly on 
the patch ... that was done weeks ago .. I finally got around to 
cleaning up the rough edges on it before the final commit]


* Security by allowing new path exposure *
1) Its just as "easy" to write a wrapper to accomplish the same thing if 
one wishes to bypass the security.


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 trying to hand wave the concerns away with the previous 2 
points. I've thought a while about how I can exploit this patch and most 
examples relied on assumptions which if the assumption were true - your 
system would have already been compromised.


* Servlet API Portability *
I chose this route since it is more portable. Other app servers provide 
the ability to do aliases. It really becomes a configuration exercise 
from appserverA to appserverB.


(Ignoring the alias issue at the moment) The beautiful thing about using 
JNDI as the method of serving resources is one can swap in WARDircontext 
instead of FileDirContext and the webapp code is none the wiser. In 
fact, I could create a JDBCDirContext which houses all resources as 
clobs/blobs and its STILL spec compliant and the webapp code is none the 
wiser.


(Now back on topic .. And history of the project that uses the patch - 
well not this exact patch but one darn near close since the original 
patch was done against 5.0)
The reason for aliases is I had static resources that needed to be 
served securely as part of a webapp. I can easily secure them via a 
web.xml security constraint or ServletFilter but the resources needed to 
appear as part of a webapp. But these resources are sourced by a 
different Enterprise system. I cannot drop a WEB-INF and child 
directories into a legacy Enterprise directory. (nor mirror it via a 
copy of the files) I also wanted to use the DefaultServlet as the means 
to serve the files. These were just pdfs and similar binary assets. 
Nothing magically, but potentially messy with If-Modified-Checks and 
partial content requests. I'd rather not reinvent (or copy) the wheel. 
So in a nutshell I needed a way for the Enterprise sourced content to 
look like it was part of the webapp. I would think this would not be an 
isolated case particular to me.


* Portability *
So depending on your point of view - this is portable or not portable. 
My vantage point is it is portable since I am writing user land code 
which assumes everything is contained inside my webapp. I can then rely 
on the servlet container to pull from other areas of the file system 
when need be to make the webapp appear as one logical unit. In this case 
- the user code is extremely portable but the configuration is dependent 
on the servlet container providing support for aliases.


* Summary *
I wanted a way for resources from various areas in the filesystem to 
appear as part of the webapp such the ServletContext.getResource() 
didn't know or care that the some content while being served from a 
directory sourced by some Enterprise system looked like part of the webapp.


At the end of the day - I could have relied on symlinks to implement the 
 project that dealt with this issue - but then when I needed to mirror 
content to our cluster of servers - I would've needed special setup to 
create the symlink as well as special rules to ensure that file 
replication excluded the symlink and its contents. Adding a symlink was 
a "much easy" alternative.


Yes - this is potentially bloaty and I tried on my first pass to 
subclass FileDirContext but the the number of touch points was to high 
that doing it right inside FileDirContext felt like the better alternative.


I have noticed other projects in the past few years at my employer where 
aliases would've come in handy instead of relying on symlinks.



* PS Summary *
I'm glad I didn't try to bring up the topic of asking how we can somehow 
detect OS so for the case sensitive OS's we can have the case checks 
turned off automagically ... and in other cases provide a switch to turn 
off symlink checking globally since these 2 checks can involve a lot of 
extra stat() calls. ;)


-Tim


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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

[David Blevins]

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 haven't  
done for a couple of years, until the Geronimo guy submitted the  
patches)


On that note, is the issue with the annotations-api compliance  
cleared up.  Happy to submit a patch if not.


We're running into this in the OpenEJB 3.0 / Tomcat 6 integration and  
have to add "delete this jar, add this one instead, restart" to the  
setup instructions.


If it is cleared up, any idea what release it might show up in --  
just looking for something to mention in the docs.


--
David Blevins




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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

[Bill Barker]

"Remy Maucherat" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
> Peter Rossbach wrote:
>> Hi,
>>
>> I like this FileDirContext extension. It is a very nice way to include 
>> external content without symlinks!
>
> I'm not hot about it, and this seems like a a sort of superset of the 
> customizable classloader (which I already didn't like much, if you're 
> following my idea). In the end, it reduces portability, can cause a lot of 
> hacking, and is going to have to get supported (= the capabilities and 
> configuration need some thought).
>

Going to agree with Remy:  I don't like it.  But since it is optional, and 
off by default, I can't come up with a valid reason to support a veto.  So 
as long as Tim is willing to continue supporting this feature, I don't see a 
problem.  Where I see a problem is if Tim gets tired of supporting this, and 
leaves it to the rest of us to deal with user questions (e.g. the /admin 
webapp, which was abandoned when Amy went to GlassFish).

TC in it's 3.3.x and 4.0.x days tried to support all sorts of addons, and 
most of them failed (Mark is still trying to maintain CGI, and SSI, but 
nobody else is).  Now, I'd prefer that TC is just the Servlet/JSP container 
that it is meant to be, and not try to add on proprietary features.  But 
that is just me ;).

> Rémy 




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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

[Mladen Turk]

Bill Barker wrote:


Now, I'd prefer that TC is just the Servlet/JSP container 
that it is meant to be, and not try to add on proprietary features.  But 
that is just me ;).




You are not the only one ;)
Seems we have lost the clear vision of the project somewhere
in the flame wars.

It has become a common rule rather then a exception that
code gets committed without any prior discussion.

Although this particular patch might be useful, bringing
it inside in the middle of the branch lifetime is something
unacceptable without prior discussion, notifying users
about TODO long before the actual release having that feature
will appear.

From a user PoV this makes each Tomcat release as *surprise*
with a question WTF changed from the last version.

Tomcat6 is now at version 6.0.14 and who can tell what 6.0.15
will look alike? Not to mention the 6.0.20 :)


This simply has to stop.

Regards,
Mladen

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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

[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=575798&view=rev
Log:
Backport from earlier fix
http://issues.apache.org/bugzilla/show_bug.cgi?id=43356

Modified:
tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11/ 
Http11NioProtocol.java
tomcat/tc6.0.x/trunk/java/org/apache/tomcat/util/net/ 
NioEndpoint.java


Modified: tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11/ 
Http11NioProtocol.java
URL: http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/ 
apache/coyote/http11/Http11NioProtocol.java? 
rev=575798&r1=575797&r2=575798&view=diff
== 

--- tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11/ 
Http11NioProtocol.java (original)
+++ tomcat/tc6.0.x/trunk/java/org/apache/coyote/http11/ 
Http11NioProtocol.java Fri Sep 14 14:30:29 2007

@@ -547,17 +547,25 @@
 public String getAlgorithm() { return ep.getAlgorithm();}
 public void setAlgorithm(String s ) { ep.setAlgorithm(s);}

-public boolean getClientAuth() { return ep.getClientAuth();}
-public void setClientAuth(boolean b ) { ep.setClientAuth(b);}
+public void setClientauth(String s) {setClientAuth(s);}
+public String getClientauth(){ return getClientAuth();}
+public String getClientAuth() { return ep.getClientAuth();}
+public void setClientAuth(String s ) { ep.setClientAuth(s);}

 public String getKeystorePass() { return ep.getKeystorePass();}
 public void setKeystorePass(String s ) { ep.setKeystorePass(s);}
 public void setKeypass(String s) { setKeystorePass(s);}
 public String getKeypass() { return getKeystorePass();}
-
-
 public String getKeystoreType() { return ep.getKeystoreType();}
 public void setKeystoreType(String s ) { ep.setKeystoreType(s);}
+
+public void setTruststoreFile(String f){ep.setTruststoreFile(f);}
+public String getTruststoreFile(){return ep.getTruststoreFile();}
+public void setTruststorePass(String p){ep.setTruststorePass(p);}
+public String getTruststorePass(){return ep.getTruststorePass();}
+public void setTruststoreType(String t){ep.setTruststoreType(t);}
+public String getTruststoreType(){ return ep.getTruststoreType 
();}

+

 public String getSslProtocol() { return ep.getSslProtocol();}
 public void setSslProtocol(String s) { ep.setSslProtocol(s);}

Modified: tomcat/tc6.0.x/trunk/java/org/apache/tomcat/util/net/ 
NioEndpoint.java
URL: http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/ 
apache/tomcat/util/net/NioEndpoint.java? 
rev=575798&r1=575797&r2=575798&view=diff
== 

--- tomcat/tc6.0.x/trunk/java/org/apache/tomcat/util/net/ 
NioEndpoint.java (original)
+++ tomcat/tc6.0.x/trunk/java/org/apache/tomcat/util/net/ 
NioEndpoint.java Fri Sep 14 14:30:29 2007

@@ -527,20 +527,50 @@
 }


+public String adjustRelativePath(String path, String  
relativeTo) {

+File f = new File(path);
+if ( !f.isAbsolute()) {
+path = relativeTo + File.separator + path;
+f = new File(path);
+}
+if (!f.exists()) {
+log.warn("configured file:["+path+"] does not exist.");
+}
+return path;
+}
+
+public String defaultIfNull(String val, String defaultValue) {
+if (val==null) return defaultValue;
+else return val;
+}
 //   SSL related properties  

+protected String truststoreFile = System.getProperty 
("javax.net.ssl.trustStore");

+public void setTruststoreFile(String s) {
+s = adjustRelativePath(s,System.getProperty 
("catalina.base"));

+this.truststoreFile = s;
+}
+public String getTruststoreFile() {return truststoreFile;}
+protected String truststorePass = System.getProperty 
("javax.net.ssl.trustStorePassword");
+public void setTruststorePass(String truststorePass)  
{this.truststorePass = truststorePass;}

+public String getTruststorePass() {return truststorePass;}
+protected String truststoreType = System.getProperty 
("javax.net.ssl.trustStoreType");
+public void setTruststoreType(String truststoreType)  
{this.truststoreType = truststoreType;}

+public String getTruststoreType() {return truststoreType;}
+
 protected String keystoreFile = System.getProperty("user.home") 
+"/.keystore";

 public String getKeystoreFile() { return keystoreFile;}
-public void setKeystoreFile(String s ) { this.keystoreFile = s; }
-public void setKeystore(String s ) { setKeystoreFile(s);}
-public String getKeystore() { return getKeystoreFile();}
+public void setKeystoreFile(String s ) {
+s = adjustRelativePath(s,System.getProperty 
("catalina.base"));

+this.keystor

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

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=43366


[EMAIL PROTECTED] changed:

   What|Removed |Added

URL|http://tomcat.apache.org/tom|http://tomcat.apache.org/tom
   |cat-6.0-doc/manager-|cat-6.0-doc/manager-
   |howto.html#Session%20Statist|howto.html#Session%20Statist
   |ics |ics
 Status|NEW |RESOLVED
 Resolution||WONTFIX




--- Additional Comments From [EMAIL PROTECTED]  2007-09-14 23:41 ---
The manager API has changed at 6.0.x ! Currently only the HTMLManagerServlet 
/manager/html/sessions 
is supported. :-)

I hope Remy or Rainer can help

Peter

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=43338


[EMAIL PROTECTED] changed:

   What|Removed |Added

   Priority|P2  |P1




--- Additional Comments From [EMAIL PROTECTED]  2007-09-14 23:53 ---
OK!

I check you fix later today

Peter


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]