Re: OS/2 Launchers in 5.0.29?

[Leslie Kishalmi]

Thanks for your quick reply!
 Let see. Cant we create a contrib directory under bin (or under the 
catalina root itself) it would contain some readme which says these 
stuff are officially not supported. Then comes some subdirectories per 
OS and place the launchers there.
For a normal user the name of "contrib" is enough to mark those stuff 
"AS IS" without official support.

Leslie Kishalmi
Shapira, Yoav wrote:
Hi,
We've seen your enhancement submission -- thank you for that.  We have
several others along the same lines, for different operating systems.
The question is where to put them such that it's clear to everyone we
don't support them.  I don't know the answer to that question, so I've
asked on this list, and apparently no one else knows or cares that much.
So we're at a standstill.  Don't hold your breath ;)
Yoav Shapira http://www.yoavshapira.com
 

-Original Message-
From: Leslie Kishalmi [mailto:[EMAIL PROTECTED]
Sent: Tuesday, October 12, 2004 12:21 PM
To: [EMAIL PROTECTED]
Subject: OS/2 Launchers in 5.0.29?
Dear all,
I've filed http://issues.apache.org/bugzilla/show_bug.cgi?id=31361 ,
asking for adding OS/2 launchers to the tomcat distribution nearly a
month ago. I've also prepared the full set of launchers. I've seen that
5.0.29 is coming out. Can't add the OS/2 launchers to it. I'm know that
OS/2 is not officially supported by the TomCat team, but I would. It
also would help to support NetBeans Web Development on OS/2. I also
think those launchers won't break anything.
Thanks,
  Laszlo Kishalmi
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
   



This e-mail, including any attachments, is a confidential business communication, and 
may contain information that is confidential, proprietary and/or privileged.  This 
e-mail is intended only for the individual(s) to whom it is addressed, and may not be 
saved, copied, printed, disclosed or used by anyone else.  If you are not the(an) 
intended recipient, please immediately delete this e-mail from your computer system 
and notify the sender.  Thank you.
-
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]

DO NOT REPLY [Bug 31090] - The session "disappears" when the context name contains the space character

[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=31090

The session "disappears" when the context name contains the space character





--- Additional Comments From [EMAIL PROTECTED]  2004-10-13 02:16 ---
Created an attachment (id=13058)
Patch to encode spaces in session cookie path

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

DO NOT REPLY [Bug 31090] - The session "disappears" when the context name contains the space character

[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=31090

The session "disappears" when the context name contains the space character





--- Additional Comments From [EMAIL PROTECTED]  2004-10-13 02:14 ---
This is due to browsers not recognizing spaces in the session cookie's path. See
the headers from two hits to the example (from the war file by Yoav Shapira).

I'm attaching a patch to fix this.
Tested with MSIE 6 and Mozilla 1.7.2


Headers 
http://localhost:8080/Sample%20App/test



GET /Sample%20App/test HTTP/1.1

Host: localhost:8080

User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040803

Accept:
text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5

Accept-Language: en-us,en;q=0.5

Accept-Encoding: gzip,deflate

Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7

Keep-Alive: 300

Connection: keep-alive

Cache-Control: max-age=0



HTTP/1.x 200 OK

Server: Apache-Coyote/1.1

Set-Cookie: JSESSIONID=33047CF84AA4E7159F1262C21D4FEA83; Path=/Sample App

Content-Type: text/html;charset=ISO-8859-1

Content-Length: 165

Date: Wed, 13 Oct 2004 01:31:50 GMT

--

http://localhost:8080/Sample%20App/test



GET /Sample%20App/test HTTP/1.1

Host: localhost:8080

User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040803

Accept:
text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5

Accept-Language: en-us,en;q=0.5

Accept-Encoding: gzip,deflate

Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7

Keep-Alive: 300

Connection: keep-alive

Referer: http://localhost:8080/Sample%20App/test

Cache-Control: max-age=0



HTTP/1.x 200 OK

Server: Apache-Coyote/1.1

Set-Cookie: JSESSIONID=82313411257D1DA54FDFD741D4E1FE78; Path=/Sample App

Content-Type: text/html;charset=ISO-8859-1

Content-Length: 165

Date: Wed, 13 Oct 2004 01:32:03 GMT

--

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

RE: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/ap ache/catalina/connectorConnector.java mbeans-descriptors.xml Request.java [heur]

[Nick Lothian]

> 
> [EMAIL PROTECTED] wrote:
> 
> >remm2004/10/12 15:53:16
> >
> >  Modified:catalina/src/share/org/apache/catalina/connector
> >Connector.java 
> mbeans-descriptors.xml Request.java
> >  Log:
> >  - Add the ability to force session cookies to be set to 
> the root path "/". This should not be used on large servers, 
> otherwise tons of cookies
> >may be sent.
> >  - This will allow the use case of the Pluto folks, in a 
> reliable way.  
> >
> Thanks to Jan for suggesting this feature addition could be a 
> solution.
> 
> Rémy
> 

Thanks for this - it looks a much better solution than the original
proposal. I'll test it ASAP.

BTW, I think there's a cut-and-paste error in the javadoc (from the
changelog):

  +/**
  + * Set the "enable DNS lookups" flag.
  + *
  + * @param enableLookups The new "enable DNS lookups" flag value
  + */
  +public void setEmptySessionPath(boolean emptySessionPath) {
  +
  +this.emptySessionPath = emptySessionPath;
  +setProperty("emptySessionPath",
String.valueOf(emptySessionPath));
  +
  +}

Nick

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

DO NOT REPLY [Bug 31683] New: - It should be documented that JDBCRealm doesn't support digest authentication

[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=31683

It should be documented that JDBCRealm doesn't support digest authentication

   Summary: It should be documented that JDBCRealm doesn't support
digest authentication
   Product: Tomcat 5
   Version: 5.5.3
  Platform: Other
OS/Version: Other
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Webapps:Documentation
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


The realm documentaion e.g.
http://jakarta.apache.org/tomcat/tomcat-5.0-doc/config/realm.html doesn't
mention that JDBCRealm (and DataSourceRealm) currently cannot support DIGEST
authentication.

There is an old bug report, bug#19767, which analysis the problem in detail:
some basic functions which are required for the Digest authentication are not
implemented. Based on google search several people were affected by the problem.
Moreover, there isn't any kind of error message or log entry which could help, 
this makes the problem more severe.

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

Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/connector Connector.java mbeans-descriptors.xml Request.java

[Tim Funk]

Shouldn't log be private and not protected?
-Tim
[EMAIL PROTECTED] wrote:
remm2004/10/12 15:53:16
  Modified:catalina/src/share/org/apache/catalina/connector
Connector.java mbeans-descriptors.xml Request.java
  
  Revision  ChangesPath
  1.13  +56 -27jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/connector/Connector.java
  
  Index: Connector.java
  ===
  RCS file: /home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/connector/Connector.java,v
  retrieving revision 1.12
  retrieving revision 1.13
  diff -u -r1.12 -r1.13
  --- Connector.java	5 Oct 2004 08:03:25 -	1.12
  +++ Connector.java	12 Oct 2004 22:53:16 -	1.13
  @@ -54,7 +54,7 @@
   public class Connector
   implements Lifecycle, MBeanRegistration
   {
  -private static Log log = LogFactory.getLog(Connector.class);
  +protected static Log log = LogFactory.getLog(Connector.class);
   
   
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/connector Connector.java mbeans-descriptors.xml Request.java

[Remy Maucherat]

[EMAIL PROTECTED] wrote:
remm2004/10/12 15:53:16
 Modified:catalina/src/share/org/apache/catalina/connector
   Connector.java mbeans-descriptors.xml Request.java
 Log:
 - Add the ability to force session cookies to be set to the root path "/". This should not be used on large servers, otherwise tons of cookies
   may be sent.
 - This will allow the use case of the Pluto folks, in a reliable way.  

Thanks to Jan for suggesting this feature addition could be a solution.
Rémy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/connector Connector.java mbeans-descriptors.xml Request.java

[remm]

remm2004/10/12 15:53:16

  Modified:catalina/src/share/org/apache/catalina/connector
Connector.java mbeans-descriptors.xml Request.java
  Log:
  - Add the ability to force session cookies to be set to the root path "/". This 
should not be used on large servers, otherwise tons of cookies
may be sent.
  - This will allow the use case of the Pluto folks, in a reliable way.
  
  Revision  ChangesPath
  1.13  +56 -27
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/connector/Connector.java
  
  Index: Connector.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/connector/Connector.java,v
  retrieving revision 1.12
  retrieving revision 1.13
  diff -u -r1.12 -r1.13
  --- Connector.java5 Oct 2004 08:03:25 -   1.12
  +++ Connector.java12 Oct 2004 22:53:16 -  1.13
  @@ -54,7 +54,7 @@
   public class Connector
   implements Lifecycle, MBeanRegistration
   {
  -private static Log log = LogFactory.getLog(Connector.class);
  +protected static Log log = LogFactory.getLog(Connector.class);
   
   
   //  Constructor
  @@ -86,13 +86,13 @@
   /**
* The Service we are associated with (if any).
*/
  -private Service service = null;
  +protected Service service = null;
   
   
   /**
* Do we allow TRACE ?
*/
  -private boolean allowTrace = false;
  +protected boolean allowTrace = false;
   
   
   /**
  @@ -102,21 +102,27 @@
   
   
   /**
  + * Use "/" as path for session cookies ?
  + */
  +protected boolean emptySessionPath = false;
  +
  +
  +/**
* The "enable DNS lookups" flag for this Connector.
*/
  -private boolean enableLookups = false;
  +protected boolean enableLookups = false;
   
   
   /*
* Is generation of X-Powered-By response header enabled/disabled?
*/
  -private boolean xpoweredBy = false;
  +protected boolean xpoweredBy = false;
   
   
   /**
* Descriptive information about this Connector implementation.
*/
  -private static final String info =
  +protected static final String info =
   "org.apache.catalina.connector.Connector/2.1";
   
   
  @@ -129,7 +135,7 @@
   /**
* The port number on which we listen for requests.
*/
  -private int port = 0;
  +protected int port = 0;
   
   
   /**
  @@ -138,7 +144,7 @@
* server, so that redirects get constructed accurately.  If not specified,
* the server name included in the Host header is used.
*/
  -private String proxyName = null;
  +protected String proxyName = null;
   
   
   /**
  @@ -147,33 +153,33 @@
* server, so that redirects get constructed accurately.  If not specified,
* the port number specified by the port property is used.
*/
  -private int proxyPort = 0;
  +protected int proxyPort = 0;
   
   
   /**
* The redirect port for non-SSL to SSL redirects.
*/
  -private int redirectPort = 443;
  +protected int redirectPort = 443;
   
   
   /**
* The request scheme that will be set on all requests received
* through this connector.
*/
  -private String scheme = "http";
  +protected String scheme = "http";
   
   
   /**
* The secure connection flag that will be set on all requests received
* through this connector.
*/
  -private boolean secure = false;
  +protected boolean secure = false;
   
   
   /**
* The string manager for this package.
*/
  -private StringManager sm =
  +protected StringManager sm =
   StringManager.getManager(Constants.Package);
   
   
  @@ -181,75 +187,75 @@
* Maximum size of a POST which will be automatically parsed by the 
* container. 2MB by default.
*/
  -private int maxPostSize = 2 * 1024 * 1024;
  +protected int maxPostSize = 2 * 1024 * 1024;
   
   
   /**
* Has this component been initialized yet?
*/
  -private boolean initialized = false;
  +protected boolean initialized = false;
   
   
   /**
* Has this component been started yet?
*/
  -private boolean started = false;
  +protected boolean started = false;
   
   
   /**
* The shutdown signal to our background thread
*/
  -private boolean stopped = false;
  +protected boolean stopped = false;
   
   
   /**
* The background thread.
*/
  -private Thread thread = null;
  +protected Thread thread = null;
   
   
   /**
* Coyote Protocol handler class name.
* Defaults to the Coyote HTTP/1.1 protocolHandler.
*/
  -private String pr

Re: DO NOT REPLY [Bug 31677] - Cannot undeploy and deploy war file with on the same context

[Dave Oxley]

Remy,
Maybe this is me just misunderstanding how the new anti locking code 
works. I've seen comments on another issue that it works the same way as 
JBoss. If thats the case the jars must be copied and loaded from 
elsewhere (a temporary directory with a temporary name) and only deleted 
when Tomcat is next started. Is this correct or does it work differently?

Dave.
Remy Maucherat wrote:
Dave Oxley wrote:
Remy,
I'm sorry that you feel my comments were not constructive. My app 
uses Log4j and mail.jar to send an email when the server starts up.
With antiJARLocking set:
An undeploy leaves mail.jar and I am unable to delete it without 
stopping Tomcat.
With antiResourceLocking set:
Stopping Tomcat (I didn't do an undeploy), the webapp is deleted 
except for ALL jars which are left in the lib directory. Also the 
server/webapps/admin and server/webapps/manager folders are deleted 
but this maybe because I manually added the Contexts to server.xml. 
Please note I didn't do an undeploy.

I've attached the server.xml I'm using. When did you last test the 
deploy/undeploy on Windows? Maybe it broke recently. Also I have had 
no such problems with TC5.5 under Linux but I do not have either 
antiJARLocking or antiResourceLocking set as I have never required 
them under Linux. I think the bug should be reopened. 

Don't bother reopening your "bug", or I'll mark it as INVALID again.
I am not interested in debugging either your setup or your webapp, 
since what you describe cannot possibly occur if you have set the 
parameters that you mention you have set. I have mentioned what I used 
for testing. How about trying that on a clean environment, and see if 
it works ?

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: DO NOT REPLY [Bug 31677] - Cannot undeploy and deploy war file with on the same context

[Remy Maucherat]

Dave Oxley wrote:
Remy,
I'm sorry that you feel my comments were not constructive. My app uses 
Log4j and mail.jar to send an email when the server starts up.
With antiJARLocking set:
An undeploy leaves mail.jar and I am unable to delete it without 
stopping Tomcat.
With antiResourceLocking set:
Stopping Tomcat (I didn't do an undeploy), the webapp is deleted 
except for ALL jars which are left in the lib directory. Also the 
server/webapps/admin and server/webapps/manager folders are deleted 
but this maybe because I manually added the Contexts to server.xml. 
Please note I didn't do an undeploy.

I've attached the server.xml I'm using. When did you last test the 
deploy/undeploy on Windows? Maybe it broke recently. Also I have had 
no such problems with TC5.5 under Linux but I do not have either 
antiJARLocking or antiResourceLocking set as I have never required 
them under Linux. I think the bug should be reopened. 
Don't bother reopening your "bug", or I'll mark it as INVALID again.
I am not interested in debugging either your setup or your webapp, since 
what you describe cannot possibly occur if you have set the parameters 
that you mention you have set. I have mentioned what I used for testing. 
How about trying that on a clean environment, and see if it works ?

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

Re: DO NOT REPLY [Bug 31677] - Cannot undeploy and deploy war file with on the same context

[Dave Oxley]

Remy,
I'm sorry that you feel my comments were not constructive. My app uses 
Log4j and mail.jar to send an email when the server starts up.
With antiJARLocking set:
An undeploy leaves mail.jar and I am unable to delete it without 
stopping Tomcat.
With antiResourceLocking set:
Stopping Tomcat (I didn't do an undeploy), the webapp is deleted except 
for ALL jars which are left in the lib directory. Also the 
server/webapps/admin and server/webapps/manager folders are deleted but 
this maybe because I manually added the Contexts to server.xml. Please 
note I didn't do an undeploy.

I've attached the server.xml I'm using. When did you last test the 
deploy/undeploy on Windows? Maybe it broke recently. Also I have had no 
such problems with TC5.5 under Linux but I do not have either 
antiJARLocking or antiResourceLocking set as I have never required them 
under Linux. I think the bug should be reopened.


 
 
   debug="0"/>

 
   
 
 
   
   
   
   
   
 
 
  unpackWARs="true" autoDeploy="false"
  xmlValidation="false" xmlNamespaceAware="false">

   www.staffplanner.com
   
 
   
   
   debug="0" privileged="true">

 
   
   
 
   
   
   debug="0" privileged="true">

 
   
 
   
 

Dave
[EMAIL PROTECTED] wrote:
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=31677
Cannot undeploy and deploy war file with on the same context
[EMAIL PROTECTED] changed:
  What|Removed |Added

Status|NEW |RESOLVED
Resolution||INVALID

--- Additional Comments From [EMAIL PROTECTED]  2004-10-12 22:02 ---
I did test it, and I think you are not being very constructive in your comments.
Tested with Struts' example webapp, precompiled, deployed and undeployed using
the Tomcat deployer (which uses the Ant tasks), with both antiJARLocking and
antiResourceLocking (which both do deployment where expected). Without one of
these two options, some JARs remain, which is to be expected.
Please don't reopen this report.
-
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]

DO NOT REPLY [Bug 31677] - Cannot undeploy and deploy war file with on the same context

[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=31677

Cannot undeploy and deploy war file with on the same context

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID



--- Additional Comments From [EMAIL PROTECTED]  2004-10-12 22:02 ---
I did test it, and I think you are not being very constructive in your comments.
Tested with Struts' example webapp, precompiled, deployed and undeployed using
the Tomcat deployer (which uses the Ant tasks), with both antiJARLocking and
antiResourceLocking (which both do deployment where expected). Without one of
these two options, some JARs remain, which is to be expected.

Please don't reopen this report.

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

DO NOT REPLY [Bug 31677] - Cannot undeploy and deploy war file with on the same context

[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=31677

Cannot undeploy and deploy war file with on the same context





--- Additional Comments From [EMAIL PROTECTED]  2004-10-12 21:49 ---
The jar could not be deleted. I did have the case correct (antiJARLocking).

I also tried antiResourceLocking but got very strange results. mail.jar was
still locked and when I stopped Tomcat the manager and admin webapps got
deleted!!! This might be correct as I manually added the contexts for admin and
manager into server.xml which I know I'm not supposed to do now.

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

[GUMP@brutus]: Project jakarta-tomcat-4.0 (in module jakarta-tomcat-4.0) success

[Stefan Bodewig]

To whom it may satisfy...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at [EMAIL PROTECTED]

Project jakarta-tomcat-4.0 *no longer* has an issue.
The current state of this project is 'Success', with reason ''.

Full details are available at:

http://brutus.apache.org/gump/public/jakarta-tomcat-4.0/jakarta-tomcat-4.0/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were provided:
 -DEBUG- Output [naming-resources.jar] identifier set to output basename: 
[naming-resources]
 -DEBUG- Output [servlets-default.jar] identifier set to output basename: 
[servlets-default]
 -DEBUG- Output [naming-common.jar] identifier set to output basename: [naming-common]
 -DEBUG- Output [catalina.jar] identifier set to output basename: [catalina]
 -DEBUG- Output [bootstrap.jar] identifier set to output basename: [bootstrap]
 -DEBUG- Output [servlets-common.jar] identifier set to output basename: 
[servlets-common]
 -DEBUG- Output [servlets-invoker.jar] identifier set to output basename: 
[servlets-invoker]
 -DEBUG- Dependency on javamail exists, no need to add for property mail.jar.
 -DEBUG- Dependency on jaf exists, no need to add for property activation.jar.
 -DEBUG- Dependency on jmx exists, no need to add for property jmx.jar.
 -DEBUG- Dependency on jakarta-servletapi-4 exists, no need to add for property 
servlet.jar.
 -DEBUG- Dependency on xml-xerces exists, no need to add for property xerces.jar.
 -DEBUG- Dependency on jakarta-tomcat-util exists, no need to add for property 
tomcat-util.jar.
 -DEBUG- Dependency on commons-logging exists, no need to add for property 
commons-logging-api.jar.
 -DEBUG- Dependency on ant exists, no need to add for property ant.home.
 -DEBUG- Dependency on jakarta-servletapi-4 exists, no need to add for property 
servlet.home.
 -DEBUG- Dependency on jsse exists, no need to add for property jsse.home.
 -DEBUG- Dependency on jmx exists, no need to add for property jmx.home.
 -DEBUG- Dependency on jmx exists, no need to add for property jmxtools.jar.
 -DEBUG- Dependency on jndi exists, no need to add for property jndi.home.
 -DEBUG- Dependency on jakarta-regexp exists, no need to add for property regexp.home.
 -DEBUG- Dependency on jakarta-regexp exists, no need to add for property regexp.jar.
 -DEBUG- Dependency on javamail exists, no need to add for property mail.home.
 -DEBUG- Dependency on jaf exists, no need to add for property activation.home.
 -INFO- Optional dependency avalon-phoenix prerequisite failed with reason build failed
 -INFO- No license on redistributable project with outputs.



The following work was performed:
http://brutus.apache.org/gump/public/jakarta-tomcat-4.0/jakarta-tomcat-4.0/gump_work/build_jakarta-tomcat-4.0_jakarta-tomcat-4.0.html
Work Name: build_jakarta-tomcat-4.0_jakarta-tomcat-4.0 (Type: Build)
Work ended in a state of : Success
Elapsed: 45 secs
Command Line: java -Djava.awt.headless=true 
-Xbootclasspath/p:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-xerces2/java/build/xml-apis.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/xalan-unbundled.jar:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar
 org.apache.tools.ant.Main -Dgump.merge=/usr/local/gump/public/gump/work/merge.xml 
-Dbuild.sysclasspath=only -Djaas.jar=/usr/local/gump/packages/jaas1_0/lib/jaas.jar 
-Djmx.jar=/usr/local/gump/packages/jmx-1_2-ri/lib/jmxri.jar 
-Djmx.home=/usr/local/gump/packages/jmx-1_2-ri 
-Djdbc20ext.jar=/usr/local/gump/packages/jdbc2_0/jdbc2_0-stdext.jar 
-Dregexp.jar=/usr/local/gump/public/workspace/jakarta-regexp/build/jakarta-regexp-12102004.jar
 -Dmail.home=/usr/local/gump/packages/javamail-1.3 
-Dant.home=/usr/local/gump/public/workspace/ant/dist 
-Dservlet.jar=/usr/local/gump/public/workspace/jakarta-servletapi-4/lib/servlet.jar 
-Dsite2.home=/usr/local/gump/public/workspace/jakarta-site2 
-Dxerces.jar=/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar 
-Dcommons-collections.jar=/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-12102004.jar
 -Dldap.jar=/usr/local/gump/packages/ldap-1_2_4/lib/ldap.jar 
-Djsse.home=/usr/local/gump/packages/jsse1.0.3 
-Dtomcat-coyote.jar=/usr/local/gump/public/workspace/jakarta-tomcat-connectors/coyote/build/lib/tomcat-coyote.jar
 -Dmail.jar=/usr/local/gump/packages/javamail-1.3/mail.jar 
-Dcommons-digester.jar=/usr/local/gump/public/workspace/jakarta-commons/digester/dist/commons-digester.jar
 -Djndi.jar=/usr/local/gump/packages/jndi1_2_1/lib/jndi.jar 
-Djmxtools.jar=/usr/local/gump/packages/jmx-1_2-ri/lib/jmxtools.jar 
-Dactivation.home=/usr/local/gump/packages/jaf-1.0.1 
-Dregexp.home=/usr/local/gump/public/workspace/jakarta-regexp/build 
-Dcommons-beanutils.jar=/usr/local/gump/p

DO NOT REPLY [Bug 31439] - Manager webapp cannot undeploy/redeploy webapps webapp

[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=31439

Manager webapp cannot undeploy/redeploy webapps webapp





--- Additional Comments From [EMAIL PROTECTED]  2004-10-12 21:44 ---
Now that I have tested it - no, actually it does not...

If I add antiJARLocking="true" in context.xml I can deploy and undeploy my
application, provided that I don't actually use it in between :*|

If I deploy the application, access it and then tries to undeploy it, Tomcat
Manager will claim that it undeployed the application, but it will leave parts
of the expanded application (jars under WEB-INF/lib), and I have to stop Tomcat
to delete the remaining files.

With antiResourceLocking it's the same - except it never works. Dosn't matter if
I access the application or not.

I'm not entirely sure that I am doing this right, but I changed the context.xml
file in Tomcats conf directory to look like this: 

WEB-INF/web.xml
META-INF/context.xml


Btw, I tried to attach the .war file to this bug report, but that dosn't seem to
work either - maby it was too big (1.7MB), or I wasn't patient enough. Anyway,
if anyone wants it, let me know.

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

[GUMP@brutus]: Project jakarta-tomcat-5 (in module jakarta-tomcat-5) success

[bobh]

To whom it may satisfy...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at [EMAIL PROTECTED]

Project jakarta-tomcat-5 *no longer* has an issue.
The current state of this project is 'Success', with reason ''.

Full details are available at:
http://brutus.apache.org/gump/public/jakarta-tomcat-5/jakarta-tomcat-5/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were provided:
 -DEBUG- Output [naming-resources.jar] identifier set to output basename: 
[naming-resources]
 -DEBUG- Output [servlets-default.jar] identifier set to output basename: 
[servlets-default]
 -DEBUG- Output [catalina.jar] identifier set to output basename: [catalina]
 -DEBUG- Output [bootstrap.jar] identifier set to output basename: [bootstrap]
 -DEBUG- Output [servlets-invoker.jar] identifier set to output basename: 
[servlets-invoker]
 -DEBUG- Dependency on javamail exists, no need to add for property mail.jar.
 -DEBUG- Dependency on jaf exists, no need to add for property activation.jar.
 -DEBUG- Dependency on jakarta-servletapi-5-servlet exists, no need to add for 
property servlet-api.jar.
 -DEBUG- Dependency on jakarta-servletapi-5-jsp exists, no need to add for property 
jsp-api.jar.
 -DEBUG- Dependency on xml-xerces exists, no need to add for property xercesImpl.jar.
 -DEBUG- Dependency on xml-xerces exists, no need to add for property xml-apis.jar.
 -DEBUG- Dependency on jakarta-tomcat-util exists, no need to add for property 
tomcat-util.jar.
 -DEBUG- Dependency on commons-el exists, no need to add for property commons-el.jar.
 -DEBUG- Dependency on commons-logging exists, no need to add for property 
commons-logging-api.jar.
 -DEBUG- Dependency on commons-modeler exists, no need to add for property 
commons-modeler.jar.
 -DEBUG- Dependency on ant exists, no need to add for property ant.home.
 -DEBUG- Dependency on jsse exists, no need to add for property jsse.home.
 -DEBUG- Dependency on jmx exists, no need to add for property jmx.home.
 -DEBUG- Dependency on jmx exists, no need to add for property jmx.jar.
 -DEBUG- Dependency on jmx exists, no need to add for property jmx-tools.jar.
 -DEBUG- Dependency on jndi exists, no need to add for property jndi.home.
 -DEBUG- Dependency on jakarta-regexp exists, no need to add for property regexp.home.
 -DEBUG- Dependency on jakarta-regexp exists, no need to add for property regexp.jar.
 -DEBUG- Dependency on javamail exists, no need to add for property mail.home.
 -DEBUG- Dependency on jakarta-tomcat-coyote exists, no need to add for property 
tomcat-coyote.home.
 -DEBUG- Dependency on jakarta-tomcat-jasper_tc5 exists, no need to add for property 
jasper.home.
 -DEBUG- Dependency on jaf exists, no need to add for property activation.home.
 -DEBUG- Dependency on commons-modeler exists, no need to add for property 
commons-modeler.home.
 -DEBUG- Dependency on commons-daemon exists, no need to add for property 
commons-daemon.jsvc.tar.gz.
 -DEBUG- Dependency on struts exists, no need to add for property struts.home.



The following work was performed:
http://brutus.apache.org/gump/public/jakarta-tomcat-5/jakarta-tomcat-5/gump_work/build_jakarta-tomcat-5_jakarta-tomcat-5.html
Work Name: build_jakarta-tomcat-5_jakarta-tomcat-5 (Type: Build)
Work ended in a state of : Success
Elapsed: 1 min 53 secs
Command Line: java -Djava.awt.headless=true 
-Xbootclasspath/p:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-xerces2/java/build/xml-apis.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/xalan-unbundled.jar:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar
 org.apache.tools.ant.Main -Dgump.merge=/usr/local/gump/public/gump/work/merge.xml 
-Dbuild.sysclasspath=only -Dtomcat33.home=--UnSet-- 
-Djsp-api.jar=/usr/local/gump/public/workspace/jakarta-servletapi-5/jsr152/dist/lib/jsp-api.jar
 -Djmx.jar=/usr/local/gump/packages/jmx-1_2-ri/lib/jmxri.jar 
-Djasper-compiler-jdt.jar=/usr/local/gump/packages/eclipse-3.0.1/plugins/org.eclipse.jdt.core_3.0.1/jdtcore.jar
 -Djmx.home=/usr/local/gump/packages/jmx-1_2-ri 
-Djdbc20ext.jar=/usr/local/gump/packages/jdbc2_0/jdbc2_0-stdext.jar 
-Dregexp.jar=/usr/local/gump/public/workspace/jakarta-regexp/build/jakarta-regexp-12102004.jar
 -Dmail.home=/usr/local/gump/packages/javamail-1.3 
-Dant.home=/usr/local/gump/public/workspace/ant/dist 
-Dsite2.home=/usr/local/gump/public/workspace/jakarta-site2 
-Dcommons-collections.jar=/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-12102004.jar
 -Dxml-apis.jar=/usr/local/gump/public/workspace/xml-xerces2/java/build/xml-apis.jar 
-DxercesImpl.jar=/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar
 -Dstruts.home=/usr/local/gump/public/workspace/struts/dist 
-Djsse.home=/

[GUMP@brutus]: Project jakarta-tomcat-jk (in module jakarta-tomcat-connectors) success

[Bill Barker]

To whom it may satisfy...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at [EMAIL PROTECTED]

Project jakarta-tomcat-jk *no longer* has an issue.
The current state of this project is 'Success', with reason ''.

Full details are available at:

http://brutus.apache.org/gump/public/jakarta-tomcat-connectors/jakarta-tomcat-jk/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were provided:
 -DEBUG- Output [tomcat-jk2.jar] identifier set to output basename: [tomcat-jk2]
 -DEBUG- Output [jkconfig.jar] identifier set to output basename: [jkconfig]
 -DEBUG- Output [tomcat-jni.jar] identifier set to output basename: [tomcat-jni]
 -DEBUG- Dependency on jakarta-tomcat-coyote exists, no need to add for property 
tomcat-coyote.jar.
 -DEBUG- Dependency on jmx exists, no need to add for property jmx.home.
 -DEBUG- Dependency on jmx exists, no need to add for property jmx.jar.
 -INFO- No license on redistributable project with outputs.



The following work was performed:
http://brutus.apache.org/gump/public/jakarta-tomcat-connectors/jakarta-tomcat-jk/gump_work/build_jakarta-tomcat-connectors_jakarta-tomcat-jk.html
Work Name: build_jakarta-tomcat-connectors_jakarta-tomcat-jk (Type: Build)
Work ended in a state of : Success
Elapsed: 4 secs
Command Line: java -Djava.awt.headless=true 
-Xbootclasspath/p:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-xerces2/java/build/xml-apis.jar
 org.apache.tools.ant.Main -Dgump.merge=/usr/local/gump/public/gump/work/merge.xml 
-Dbuild.sysclasspath=only -Djsse.home=/usr/local/gump/packages/jsse1.0.3 
-Dcommons-modeler.jar=/usr/local/gump/public/workspace/jakarta-commons/modeler/dist/commons-modeler-12102004.jar
 -Djmx.jar=/usr/local/gump/public/workspace/jmx/jmx/lib/jmxri.jar 
-Dtomcat-coyote.jar=/usr/local/gump/public/workspace/jakarta-tomcat-connectors/coyote/build/lib/tomcat-coyote.jar
 -Djmx.home=/usr/local/gump/packages/jmx-1_2-ri 
-Dservlet-api.jar=/usr/local/gump/public/workspace/jakarta-servletapi-5/jsr154/dist/lib/servlet-api.jar
 
-Dtc5-catalina.jar=/usr/local/gump/public/workspace/jakarta-tomcat-catalina/build/server/lib/catalina.jar
 jkjava-tc5 
[Working Directory: /usr/local/gump/public/workspace/jakarta-tomcat-connectors/jk]
CLASSPATH : 
/opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-stylebook.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-api.jar:/usr/local/gump/packages/jmx-1_2-ri/lib/jmxri.jar:/usr/local/gump/packages/jmx-1_2-ri/lib/jmxtools.jar:/usr/local/gump/public/workspace/jakarta-tomcat-connectors/util/build/lib/tomcat-util.jar:/usr/local/gump/public/workspace/jakarta-tomcat-connectors/coyote/build/lib/tomcat-coyote.jar:/usr/local/gump/public/workspace/jakarta-commons/modeler/dist/commons-modeler-12102004.jar:/usr/local/gump/public/workspace/jakarta-tomcat-catalina/build/server/lib/catalina.jar:/usr/local/gump/public/workspace/jakarta-servletapi-5/jsr154/dist/lib/servlet-api.jar
-
Buildfile: build.xml

detect:
 [echo]  jakarta-tomcat-connectors 

prepare:
[mkdir] Created dir: 
/usr/local/gump/public/workspace/jakarta-tomcat-connectors/jk/build/conf
 [copy] Copying 9 files to 
/usr/local/gump/public/workspace/jakarta-tomcat-connectors/jk/build/conf
 [copy] Copying 1 file to 
/usr/local/gump/public/workspace/jakarta-tomcat-connectors/jk/build/lib
Overriding previous definition of reference to xml-apis.classpath

report:
 [echo] Tomcat33: ${tomcat33.detect} /usr/share/java/jakarta-tomcat-3.3.2
 [echo] Tomcat40:  ${tomcat40.detect} 
/usr/local/gump/public/workspace/jakarta-tomcat-4.0/build
 [echo] Tomcat41: ${tomcat41.detect} /usr/share/java/jakarta-tomcat-4.1.30
 [echo] Tomcat5:  true 
/usr/local/gump/public/workspace/jakarta-tomcat-catalina/build
 [echo] Apache13: ${apache13.detect} ${apache13.home}
 [echo] Apache2: ${apache2.detect} ${apache2.home}
 [echo] iPlanet:  ${iplanet.detect} ${iplanet.home}
 [echo] IIS:  ${iis.detect} ${iis.home}
 [echo] AOLserver: ${aolserver.detect} ${aolserver.home}
 [echo] jmx:  /usr/local/gump/public/workspace/jmx/jmx/lib/jmxri.jar 
${jmx.detect} 
/usr/local/gump/public/workspace/jakarta-commons/mod

[GUMP@brutus]: Project jakarta-tomcat-catalina (in module jakarta-tomcat-catalina) success

[bobh]

To whom it may satisfy...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at [EMAIL PROTECTED]

Project jakarta-tomcat-catalina *no longer* has an issue.
The current state of this project is 'Success', with reason ''.

Full details are available at:

http://brutus.apache.org/gump/public/jakarta-tomcat-catalina/jakarta-tomcat-catalina/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were provided:
 -DEBUG- Output [naming-resources.jar] identifier set to output basename: 
[naming-resources]
 -DEBUG- Output [servlets-default.jar] identifier set to output basename: 
[servlets-default]
 -DEBUG- Output [servlets-invoker.jar] identifier set to output basename: 
[servlets-invoker]
 -DEBUG- Output [bootstrap.jar] identifier set to output basename: [bootstrap]
 -DEBUG- Output [catalina-optional.jar] identifier set to output basename: 
[catalina-optional]
 -DEBUG- Output [catalina.jar] identifier set to output basename: [catalina]
 -DEBUG- Dependency on ant exists, no need to add for property ant.home.
 -DEBUG- Dependency on jsse exists, no need to add for property jsse.home.
 -DEBUG- Dependency on jmx exists, no need to add for property jmx.home.
 -DEBUG- Dependency on jndi exists, no need to add for property jndi.home.
 -DEBUG- Dependency on jakarta-regexp exists, no need to add for property regexp.home.
 -DEBUG- Dependency on jaf exists, no need to add for property activation.home.
 -DEBUG- Dependency on jakarta-tomcat-coyote exists, no need to add for property 
tomcat-coyote.home.



The following work was performed:
http://brutus.apache.org/gump/public/jakarta-tomcat-catalina/jakarta-tomcat-catalina/gump_work/build_jakarta-tomcat-catalina_jakarta-tomcat-catalina.html
Work Name: build_jakarta-tomcat-catalina_jakarta-tomcat-catalina (Type: Build)
Work ended in a state of : Success
Elapsed: 23 secs
Command Line: java -Djava.awt.headless=true 
-Xbootclasspath/p:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-xerces2/java/build/xml-apis.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/xalan-unbundled.jar:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar
 org.apache.tools.ant.Main -Dgump.merge=/usr/local/gump/public/gump/work/merge.xml 
-Dbuild.sysclasspath=only -Dtomcat33.home=--UnSet-- 
-Dcatalina.build=/usr/local/gump/public/workspace/jakarta-tomcat-catalina/build 
-Djmx.home=/usr/local/gump/packages/jmx-1_2-ri 
-Djdbc20ext.jar=/usr/local/gump/packages/jdbc2_0/jdbc2_0-stdext.jar 
-Djtc.home=/usr/local/gump/public/workspace/jakarta-tomcat-connectors 
-Djasper.home=/usr/local/gump/public/workspace/jakarta-tomcat-jasper_tc5/jasper2 
-Dant.home=/usr/local/gump/public/workspace/ant/dist 
-Dsite2.home=/usr/local/gump/public/workspace/jakarta-site2 -Dcompile.source=1.4 
-Dcommons-collections.jar=/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-12102004.jar
 -Dcatalina.deploy=/usr/local/gump/public/workspace/jakarta-tomcat-catalina/build 
-Dldap.jar=/usr/local/gump/packages/ldap-1_2_4/lib/ldap.jar 
-Djsse.home=/usr/local/gump/packages/jsse1.0.3 
-Djaas.jar=/usr/local/gump/packages/jaas1_0/lib/jaas.jar 
-Dcommons-fileupload.jar=/usr/local/gump/public/workspace/jakarta-commons/fileupload/target/commons-fileupload-12102004.jar
 
-Dcommons-digester.jar=/usr/local/gump/public/workspace/jakarta-commons/digester/dist/commons-digester.jar
 -Djndi.jar=/usr/local/gump/packages/jndi1_2_1/lib/jndi.jar 
-Dactivation.home=/usr/local/gump/packages/jaf-1.0.1 
-Dcatalina.home=/usr/local/gump/public/workspace/jakarta-tomcat-catalina/build 
-Dcommons-launcher.jar=/usr/local/gump/public/workspace/jakarta-commons/launcher/dist/bin/commons-launcher.jar
 -Dtomcat.build=/usr/local/gump/public/workspace/jakarta-tomcat-catalina/build 
-Dregexp.home=/usr/local/gump/public/workspace/jakarta-regexp/build 
-Dcommons-beanutils.jar=/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar
 
-Dcommons-modeler.jar=/usr/local/gump/public/workspace/jakarta-commons/modeler/dist/commons-modeler-12102004.jar
 
-Dtomcat-dbcp.jar=/usr/local/gump/public/workspace/jakarta-tomcat-5/tomcat-deps/naming-factory-dbcp.jar
 
-Dtomcat-coyote.home=/usr/local/gump/public/workspace/jakarta-tomcat-connectors/coyote 
-Dcommons-dbcp.jar=/usr/local/gump/public/workspace/jakarta-commons/dbcp/dist/commons-dbcp.jar
 
-Dcommons-logging-api.jar=/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-api.jar
 -Djndi.home=/usr/local/gump/packages/jndi1_2_1 
-Dcommons-pool.jar=/usr/local/gump/public/workspace/jakarta-commons/pool/dist/commons-pool.jar
 -Djta.jar=/usr/local/gump/packages/jta-spec1_0_1/jta-spec1_0_1.jar deploy-catalina 
[Working Directory: /usr/local/gump/public/workspace/jakarta-

DO NOT REPLY [Bug 31677] - Cannot undeploy and deploy war file with on the same context

[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=31677

Cannot undeploy and deploy war file with on the same context





--- Additional Comments From [EMAIL PROTECTED]  2004-10-12 21:31 ---
antiJARLocking (be careful about case) is not completely foolproof. Use
antiResourceLocking if you want true hotdeploy, but it's a lot more expensive in
terms of webapp startup time.

Please verify if mail.jar is actually locked (= try to delete it manually).

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

DO NOT REPLY [Bug 31677] New: - Cannot undeploy and deploy war file with on the same context

[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=31677

Cannot undeploy and deploy war file with on the same context

   Summary: Cannot undeploy and deploy war file with on the same
context
   Product: Tomcat 5
   Version: 5.5.3
  Platform: PC
OS/Version: Windows XP
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Webapps:Manager
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Have tested whether Bug 29526 is fixed for 5.5.3, but an undeploy still leaves
mail.jar in the lib directory. Everything else is deleted. antijARLocking was
set to true in conf/context.xml.

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

Re: AW: AW: DefaultServlet and getOutputStream() / getWriter()

[Ben Souther]

Martin,
The question wasn't "which is better?".  The question was "are the two
functionally the same?" which as you've pointed out, they're not.

Steffen,
Looking at the (longer) code example that you posted, I can see that in
both cases there is logic to stop the iteration if there is a problem.
So, in this case, you may be correct.  

I think the larger point that Yoav and Remmy were both trying to make is
that evaluating a newcomer's re-factored code is as time consuming as
refactoring it themselves. If it means getting a bug fixed or a MAJOR
performance gain, then it's worth it but to risk overlooking something
subtle and breaking a core component for a small gain in efficiency or
just to neaten the code is not worth the risk.






On Tue, 2004-10-12 at 16:08, Martin Gainty wrote:
> Ben
> In the first case the while contains the logic and doesnt allow the program
> to exit until until the while condition goes false..
> In the second case the try/catch allows the exception to propagate up to the
> caller as soon as the exception is caught
> Personally I would use the 2nd approach..
> Good Catch!!!
> Martin-
> - Original Message -
> From: "Ben Souther" <[EMAIL PROTECTED]>
> To: "Tomcat Developers List" <[EMAIL PROTECTED]>
> Sent: Tuesday, October 12, 2004 3:42 PM
> Subject: Re: AW: AW: DefaultServlet and getOutputStream() / getWriter()
> 
> 
> > This is the code that I saw (from the beginning of this discussion on
> > the user's list).
> >
> >
> > begin quote--
> > PS: Since I am already sending another mail, let me append a pending
> > question:
> >
> > I often see code like this in the servlet:
> >
> > while (...) {
> >   try {
> > ...
> >   } catch ( ... ) {
> > ...
> >   }
> > }
> >
> > which could be replaced with
> >
> > try {
> >   while (...) {
> > ...
> >   }
> > } catch ( ... ) {
> >   ...
> > }
> >
> > which is faster in my imagination.
> > Is there a reason or is my imagination false?
> > end quote--
> >
> >
> > If the discussion has moved on to something else, then I apologize for
> > wasting your time.
> >
> > -Ben
> >
> >
> >
> >
> >
> > On Tue, 2004-10-12 at 15:31, Steffen Heil wrote:
> > > Hi
> > >
> > > > Compile, run, and view the output from this program.
> > > > I think you'll see the difference :o)
> > >
> > > Sorry, but did you actually read the code it posted?
> > > I KNOW that there CAN be a difference in semantics.
> > > YOUR code has different semantics.
> > >
> > > BUT in the code I POSTED there is NONE !
> > >
> > > So, please read it first.
> > >
> > > Regards,
> > >   Steffen
> >
> >
> > -
> > 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]

[GUMP@brutus]: Project jakarta-tomcat-dbcp (in module jakarta-tomcat-5) success

[bobh]

To whom it may satisfy...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at [EMAIL PROTECTED]

Project jakarta-tomcat-dbcp *no longer* has an issue.
The current state of this project is 'Success', with reason ''.

Full details are available at:

http://brutus.apache.org/gump/public/jakarta-tomcat-5/jakarta-tomcat-dbcp/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were provided:
 -DEBUG- Sole output [naming-factory-dbcp.jar] identifier set to project name
 -INFO- Made directory [/usr/local/gump/public/workspace/jakarta-tomcat-5/tomcat-deps]



The following work was performed:
http://brutus.apache.org/gump/public/jakarta-tomcat-5/jakarta-tomcat-dbcp/gump_work/build_jakarta-tomcat-5_jakarta-tomcat-dbcp.html
Work Name: build_jakarta-tomcat-5_jakarta-tomcat-dbcp (Type: Build)
Work ended in a state of : Success
Elapsed: 4 secs
Command Line: java -Djava.awt.headless=true org.apache.tools.ant.Main 
-Dgump.merge=/usr/local/gump/public/gump/work/merge.xml -Dbuild.sysclasspath=only 
-Dcommons-collections.home=/usr/local/gump/public/workspace/jakarta-commons/collections
 -Dcommons-dbcp.home=/usr/local/gump/public/workspace/jakarta-commons/dbcp 
-Dcommons-dbcp.version=12102004 
-Dtomcat-dbcp.home=/usr/local/gump/public/workspace/jakarta-tomcat-5/tomcat-deps 
-Dcommons-pool.home=/usr/local/gump/public/workspace/jakarta-commons/pool 
build-tomcat-dbcp 
[Working Directory: /usr/local/gump/public/workspace/jakarta-tomcat-5]
CLASSPATH : 
/opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-stylebook.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar
-
Buildfile: build.xml

build-tomcat-dbcp:

-build-tomcat-dbcp:
 [copy] Copying 65 files to 
/usr/local/gump/public/workspace/jakarta-tomcat-5/tomcat-deps
[mkdir] Created dir: 
/usr/local/gump/public/workspace/jakarta-tomcat-5/tomcat-deps/src/java/org/apache/tomcat/dbcp
 [move] Moving 57 files to 
/usr/local/gump/public/workspace/jakarta-tomcat-5/tomcat-deps/src/java/org/apache/tomcat/dbcp
[mkdir] Created dir: 
/usr/local/gump/public/workspace/jakarta-tomcat-5/tomcat-deps/classes
[javac] Compiling 57 source files to 
/usr/local/gump/public/workspace/jakarta-tomcat-5/tomcat-deps/classes
[javac] Note: Some input files use or override a deprecated API.
[javac] Note: Recompile with -deprecation for details.
  [jar] Building jar: 
/usr/local/gump/public/workspace/jakarta-tomcat-5/tomcat-deps/naming-factory-dbcp.jar

BUILD SUCCESSFUL
Total time: 4 seconds
-

To subscribe to this information via syndicated feeds:
- RSS: 
http://brutus.apache.org/gump/public/jakarta-tomcat-5/jakarta-tomcat-dbcp/rss.xml
- Atom: 
http://brutus.apache.org/gump/public/jakarta-tomcat-5/jakarta-tomcat-dbcp/atom.xml

== Gump Tracking Only ===
Produced by Gump version 2.1.0-alpha-0003.
Gump Run 49001212102004, brutus:brutus-public:49001212102004
Gump E-mail Identifier (unique within run) #4.

--
Apache Gump
http://gump.apache.org/ [Instance: brutus]

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

Re: AW: AW: DefaultServlet and getOutputStream() / getWriter()

[Martin Gainty]

Ben
In the first case the while contains the logic and doesnt allow the program
to exit until until the while condition goes false..
In the second case the try/catch allows the exception to propagate up to the
caller as soon as the exception is caught
Personally I would use the 2nd approach..
Good Catch!!!
Martin-
- Original Message -
From: "Ben Souther" <[EMAIL PROTECTED]>
To: "Tomcat Developers List" <[EMAIL PROTECTED]>
Sent: Tuesday, October 12, 2004 3:42 PM
Subject: Re: AW: AW: DefaultServlet and getOutputStream() / getWriter()


> This is the code that I saw (from the beginning of this discussion on
> the user's list).
>
>
> begin quote--
> PS: Since I am already sending another mail, let me append a pending
> question:
>
> I often see code like this in the servlet:
>
> while (...) {
>   try {
> ...
>   } catch ( ... ) {
> ...
>   }
> }
>
> which could be replaced with
>
> try {
>   while (...) {
> ...
>   }
> } catch ( ... ) {
>   ...
> }
>
> which is faster in my imagination.
> Is there a reason or is my imagination false?
> end quote--
>
>
> If the discussion has moved on to something else, then I apologize for
> wasting your time.
>
> -Ben
>
>
>
>
>
> On Tue, 2004-10-12 at 15:31, Steffen Heil wrote:
> > Hi
> >
> > > Compile, run, and view the output from this program.
> > > I think you'll see the difference :o)
> >
> > Sorry, but did you actually read the code it posted?
> > I KNOW that there CAN be a difference in semantics.
> > YOUR code has different semantics.
> >
> > BUT in the code I POSTED there is NONE !
> >
> > So, please read it first.
> >
> > Regards,
> >   Steffen
>
>
> -
> 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: AW: AW: DefaultServlet and getOutputStream() / getWriter()

[Ben Souther]

This is the code that I saw (from the beginning of this discussion on
the user's list).


begin quote--
PS: Since I am already sending another mail, let me append a pending
question:

I often see code like this in the servlet:

while (...) {
  try {
...
  } catch ( ... ) {
...
  }
}

which could be replaced with 

try {
  while (...) {
...
  }
} catch ( ... ) {
  ...
}

which is faster in my imagination.
Is there a reason or is my imagination false?
end quote--


If the discussion has moved on to something else, then I apologize for
wasting your time.

-Ben





On Tue, 2004-10-12 at 15:31, Steffen Heil wrote:
> Hi
> 
> > Compile, run, and view the output from this program.
> > I think you'll see the difference :o)
> 
> Sorry, but did you actually read the code it posted?
> I KNOW that there CAN be a difference in semantics.
> YOUR code has different semantics.
> 
> BUT in the code I POSTED there is NONE !
> 
> So, please read it first.
> 
> Regards,
>   Steffen


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

AW: AW: DefaultServlet and getOutputStream() / getWriter()

[Steffen Heil]

Hi

> Compile, run, and view the output from this program.
> I think you'll see the difference :o)

Sorry, but did you actually read the code it posted?
I KNOW that there CAN be a difference in semantics.
YOUR code has different semantics.

BUT in the code I POSTED there is NONE !

So, please read it first.

Regards,
  Steffen


smime.p7s
Description: S/MIME cryptographic signature

Re: AW: DefaultServlet and getOutputStream() / getWriter()

[Ben Souther]

Steffen,

Compile, run, and view the output from this program.
I think you'll see the difference :o)


public class Loop{
public static void main(String[] args){
System.out.println("Try-Catch inside loop:");
for(int i = 0; i < 10; i++){
try{
System.out.println(String.valueOf(i));
if(i == 5) i = i / 0;
}catch(Exception e){
e.printStackTrace();
}
}
System.out.println("\nLoop inside try-catch");
try{
for(int i = 0; i < 10; i++){
System.out.println(String.valueOf(i));
if(i == 5) i = i /0;
}
}catch(Exception e){
e.printStackTrace();
}
}
}









On Tue, 2004-10-12 at 13:43, Steffen Heil wrote:
> Hi
> 
>  
> > The rewritten while{} patch you suggested definitely changed behavior
> significantly, as I and others pointed out ;)
> 
> Ãhm, no.
> Sorry to say that, but I think, you didn't review the code for that
> statement:
> One example taken from DefaultServlet.java, lines 2030 to 2054:
> 
> IOException exception = null;
> long bytesToRead = end - start + 1;
> 
> char buffer[] = new char[input];
> int len = buffer.length;
> while ( (bytesToRead > 0) && (len >= buffer.length)) {
> try {
> len = reader.read(buffer);
> if (bytesToRead >= len) {
> writer.write(buffer, 0, len);
> bytesToRead -= len;
> } else {
> writer.write(buffer, 0, (int) bytesToRead);
> bytesToRead = 0;
> }
> } catch (IOException e) {
> exception = e;
> len = -1;
> }
> if (len < buffer.length)
> break;
> }
> 
> return exception;
> 
> THIS IS EQUAL TO:
> 
> IOException exception = null;
> long bytesToRead = end - start + 1;
> 
> char buffer[] = new char[input];
> int len = buffer.length;
> try {
>while ( (bytesToRead > 0) && (len >= buffer.length)) {
> len = reader.read(buffer);
> if (bytesToRead >= len) {
> writer.write(buffer, 0, len);
> bytesToRead -= len;
> } else {
> writer.write(buffer, 0, (int) bytesToRead);
> bytesToRead = 0;
> }
> if (len < buffer.length)
> break;
>}
> } catch (IOException e) {
>exception = e;
>len = -1;
> }
> 
> return exception;
> 
> OR EVEN:
> 
> long bytesToRead = end - start + 1;
> 
> char buffer[] = new char[input];
> int len = buffer.length;
> try {
>while ( (bytesToRead > 0) && (len >= buffer.length)) {
> len = reader.read(buffer);
> if (bytesToRead >= len) {
> writer.write(buffer, 0, len);
> bytesToRead -= len;
> } else {
> writer.write(buffer, 0, (int) bytesToRead);
> bytesToRead = 0;
> }
>}
>return null;
> } catch (IOException e) {
>return e;
> }
> 
> I am very sure about this.
> And I also do NOT understand, why the exception is reported as result and
> not really thrown.
> The caller always uses:
> 
> IOException exception = null;
> 
> while ( (exception == null) && (ranges.hasMoreElements()) ) {
> 
> 
> exception = copyRange(istream, ostream, currentRange.start,
>   currentRange.end);
> ...
> 
> }
> 
> ostream.println();
> ostream.print("--" + mimeSeparation + "--");
> 
> // Rethrow any exception that has occurred
> if (exception != null)
> throw exception;
> 
> Whereas it would absolutely make more sense to me NOT to catch the Exception
> but rather use:
> 
> try {
> while ( ranges.hasMoreElements() ) {
> 
> 
> copyRange(istream, ostream, currentRange.start,
>   currentRange.end);
> ...
>  
> }
> } finally {
> // if nessesary, put code to ensure istream is closed here.
> ostream.println();
> ostream.print("--" + mimeSeparation + "--");
> }
> 
> This is what try-finally is all about, isn't it?
> 
> 
> I agree, that I am new to this and I might be wrong, but this leads me back
> right to where I started. Whom to ask to understand the existing code?
> 
> 
> > When you're looking at the code, keep in mind that Tomcat's DefaultServlet
> (like virtually every other Tomcat component) ca

Re: AW: DefaultServlet and getOutputStream() / getWriter()

[Remy Maucherat]

Steffen Heil wrote:
I agree, that I am new to this and I might be wrong, but this leads me back
right to where I started. Whom to ask to understand the existing code?
 

I implied it already: no one. There are too many people who have touched 
the code, and too many tricky things going on. As a result, it is 
impossible to get a real answer from anyone (without having the said 
committer do just as much work as if he was trying to refactor the 
DefaultServlet himself).

Hence my recommendation that we are likely not interested in this kind 
of refactoring (unless you're an experienced committer and do proper 
testing, etc). If you want to contribute, it would be far more useful if 
you picked actual bugs to fix. This is a good introduction.

I will propably do this some time soon. However, right now I am evaluating
the Default Servlet code because I need to build my customized one and I
thought a lot of work is already done. Not trying to reinvent the wheel
though. That's why I am staring at DefaultServlet.java only right now.
 

While you are obviously free to reuse anything you want, I have to say 
that I am very likely to refuse most of your contributions.

About the points in your message, while I don't see a problem with the 
"OR EVEN" proposed replacement (but I didn't test it), changing to try / 
finally does change the algorithm, and makes it more complex, especially 
for closing the input stream. So I don't like that. About the previous 
one (removing try/catch from doGet), I don't know. I don't think it 
should be changed for now.

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

RE: DefaultServlet and getOutputStream() / getWriter()

[Shapira, Yoav]

Hi,
I didn't look at the DefaultServlet code at all, there's no need.  The post I was 
referring to was one from you that said
Try { while { ... } } catch { ... }
Where either ... can throw an exception is the same as
While { ... try { ... } catch { ... } }

And obviously the two are not equal, because the second construct would keep working 
the while loop and the first one would abort on the first error.  That's a critical 
difference.  Now you're quoting specific DefaultServlet code, and that's fine, I don't 
care to look at it now because it obviously works and I have more important things to 
do.  But your original message had just an abstract while/try/catch comparison 
question, nothing specific to DefaultServlet, and that original message was wrong, and 
that's the one I was responding to.

Yoav Shapira http://www.yoavshapira.com


>-Original Message-
>From: Steffen Heil [mailto:[EMAIL PROTECTED]
>Sent: Tuesday, October 12, 2004 1:43 PM
>To: 'Tomcat Developers List'
>Subject: AW: DefaultServlet and getOutputStream() / getWriter()
>
>Hi
>
>
>> The rewritten while{} patch you suggested definitely changed behavior
>significantly, as I and others pointed out ;)
>
>Ähm, no.
>Sorry to say that, but I think, you didn't review the code for that
>statement:
>One example taken from DefaultServlet.java, lines 2030 to 2054:
>
>IOException exception = null;
>long bytesToRead = end - start + 1;
>
>char buffer[] = new char[input];
>int len = buffer.length;
>while ( (bytesToRead > 0) && (len >= buffer.length)) {
>try {
>len = reader.read(buffer);
>if (bytesToRead >= len) {
>writer.write(buffer, 0, len);
>bytesToRead -= len;
>} else {
>writer.write(buffer, 0, (int) bytesToRead);
>bytesToRead = 0;
>}
>} catch (IOException e) {
>exception = e;
>len = -1;
>}
>if (len < buffer.length)
>break;
>}
>
>return exception;
>
>THIS IS EQUAL TO:
>
>IOException exception = null;
>long bytesToRead = end - start + 1;
>
>char buffer[] = new char[input];
>int len = buffer.length;
>try {
>   while ( (bytesToRead > 0) && (len >= buffer.length)) {
>len = reader.read(buffer);
>if (bytesToRead >= len) {
>writer.write(buffer, 0, len);
>bytesToRead -= len;
>} else {
>writer.write(buffer, 0, (int) bytesToRead);
>bytesToRead = 0;
>}
>if (len < buffer.length)
>break;
>   }
>} catch (IOException e) {
>   exception = e;
>   len = -1;
>}
>
>return exception;
>
>OR EVEN:
>
>long bytesToRead = end - start + 1;
>
>char buffer[] = new char[input];
>int len = buffer.length;
>try {
>   while ( (bytesToRead > 0) && (len >= buffer.length)) {
>len = reader.read(buffer);
>if (bytesToRead >= len) {
>writer.write(buffer, 0, len);
>bytesToRead -= len;
>} else {
>writer.write(buffer, 0, (int) bytesToRead);
>bytesToRead = 0;
>}
>   }
>   return null;
>} catch (IOException e) {
>   return e;
>}
>
>I am very sure about this.
>And I also do NOT understand, why the exception is reported as result and
>not really thrown.
>The caller always uses:
>
>IOException exception = null;
>
>while ( (exception == null) && (ranges.hasMoreElements()) ) {
>
>
>exception = copyRange(istream, ostream, currentRange.start,
>  currentRange.end);
>...
>
>}
>
>ostream.println();
>ostream.print("--" + mimeSeparation + "--");
>
>// Rethrow any exception that has occurred
>if (exception != null)
>throw exception;
>
>Whereas it would absolutely make more sense to me NOT to catch the
>Exception
>but rather use:
>
>try {
>while ( ranges.hasMoreElements() ) {
>
>
>copyRange(istream, ostream, currentRange.start,
>  currentRange.end);
>...
>
>}
>} finally {
>// if nessesary, put code to ensure istream is closed here.
>ostream.println();
>ostream.print("--" + mimeSeparation + "--");
>}
>
>This is what try-finally is all about, isn't it?
>
>
>I agree, that I am new to this and I might be wrong, but this leads me back
>right to where I started. Whom to ask to understand the existing code?
>
>
>> When you're lo

AW: DefaultServlet and getOutputStream() / getWriter()

[Steffen Heil]

Hi

 
> The rewritten while{} patch you suggested definitely changed behavior
significantly, as I and others pointed out ;)

Ähm, no.
Sorry to say that, but I think, you didn't review the code for that
statement:
One example taken from DefaultServlet.java, lines 2030 to 2054:

IOException exception = null;
long bytesToRead = end - start + 1;

char buffer[] = new char[input];
int len = buffer.length;
while ( (bytesToRead > 0) && (len >= buffer.length)) {
try {
len = reader.read(buffer);
if (bytesToRead >= len) {
writer.write(buffer, 0, len);
bytesToRead -= len;
} else {
writer.write(buffer, 0, (int) bytesToRead);
bytesToRead = 0;
}
} catch (IOException e) {
exception = e;
len = -1;
}
if (len < buffer.length)
break;
}

return exception;

THIS IS EQUAL TO:

IOException exception = null;
long bytesToRead = end - start + 1;

char buffer[] = new char[input];
int len = buffer.length;
try {
   while ( (bytesToRead > 0) && (len >= buffer.length)) {
len = reader.read(buffer);
if (bytesToRead >= len) {
writer.write(buffer, 0, len);
bytesToRead -= len;
} else {
writer.write(buffer, 0, (int) bytesToRead);
bytesToRead = 0;
}
if (len < buffer.length)
break;
   }
} catch (IOException e) {
   exception = e;
   len = -1;
}

return exception;

OR EVEN:

long bytesToRead = end - start + 1;

char buffer[] = new char[input];
int len = buffer.length;
try {
   while ( (bytesToRead > 0) && (len >= buffer.length)) {
len = reader.read(buffer);
if (bytesToRead >= len) {
writer.write(buffer, 0, len);
bytesToRead -= len;
} else {
writer.write(buffer, 0, (int) bytesToRead);
bytesToRead = 0;
}
   }
   return null;
} catch (IOException e) {
   return e;
}

I am very sure about this.
And I also do NOT understand, why the exception is reported as result and
not really thrown.
The caller always uses:

IOException exception = null;

while ( (exception == null) && (ranges.hasMoreElements()) ) {


exception = copyRange(istream, ostream, currentRange.start,
  currentRange.end);
...

}

ostream.println();
ostream.print("--" + mimeSeparation + "--");

// Rethrow any exception that has occurred
if (exception != null)
throw exception;

Whereas it would absolutely make more sense to me NOT to catch the Exception
but rather use:

try {
while ( ranges.hasMoreElements() ) {


copyRange(istream, ostream, currentRange.start,
  currentRange.end);
...
 
}
} finally {
// if nessesary, put code to ensure istream is closed here.
ostream.println();
ostream.print("--" + mimeSeparation + "--");
}

This is what try-finally is all about, isn't it?


I agree, that I am new to this and I might be wrong, but this leads me back
right to where I started. Whom to ask to understand the existing code?


> When you're looking at the code, keep in mind that Tomcat's DefaultServlet
(like virtually every other Tomcat component) can be extended or wrapped.
Such wrappers or extenders could call getWriter first.  

Ok, I forgot about includes and such.

> I'm happy you're looking at the code.  If I were in your position (and I
definitely was, although that seems long ago now ;)), I would look instead
at Bugzilla, take a bug, and try to fix it.

I will propably do this some time soon. However, right now I am evaluating
the Default Servlet code because I need to build my customized one and I
thought a lot of work is already done. Not trying to reinvent the wheel
though. That's why I am staring at DefaultServlet.java only right now.

Regards,
  Steffen


smime.p7s
Description: S/MIME cryptographic signature

DO NOT REPLY [Bug 31439] - Manager webapp cannot undeploy/redeploy webapps webapp

[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=31439

Manager webapp cannot undeploy/redeploy webapps webapp





--- Additional Comments From [EMAIL PROTECTED]  2004-10-12 17:21 ---
And it works with that ?

If it doesn't, please restate the scenario which doesn't work.

Note: the JAR file locking prevention code is optional in 5.5 (it was always
enabled in 5.0) because I figured Linux users shouldn't have to suffer because
of Windows specific issues. The other more general file locking option is new in
5.5 (it copies everything away like JBoss which is cool for pure hot deployment,
but not that great for development usage).

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

DO NOT REPLY [Bug 31439] - Manager webapp cannot undeploy/redeploy webapps webapp

[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=31439

Manager webapp cannot undeploy/redeploy webapps webapp





--- Additional Comments From [EMAIL PROTECTED]  2004-10-12 17:11 ---
It was not so obvious to me, but with help from Yoav Shapira I finally found out
what was meant by "you obviously have to use one of the anti file locking
features"...
It's all right here:
http://jakarta.apache.org/tomcat/tomcat-5.5-doc/config/context.html.

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

RE: OS/2 Launchers in 5.0.29?

[Shapira, Yoav]

Hi,
We've seen your enhancement submission -- thank you for that.  We have
several others along the same lines, for different operating systems.
The question is where to put them such that it's clear to everyone we
don't support them.  I don't know the answer to that question, so I've
asked on this list, and apparently no one else knows or cares that much.
So we're at a standstill.  Don't hold your breath ;)

Yoav Shapira http://www.yoavshapira.com


>-Original Message-
>From: Leslie Kishalmi [mailto:[EMAIL PROTECTED]
>Sent: Tuesday, October 12, 2004 12:21 PM
>To: [EMAIL PROTECTED]
>Subject: OS/2 Launchers in 5.0.29?
>
>Dear all,
>
>I've filed http://issues.apache.org/bugzilla/show_bug.cgi?id=31361 ,
>asking for adding OS/2 launchers to the tomcat distribution nearly a
>month ago. I've also prepared the full set of launchers. I've seen that
>5.0.29 is coming out. Can't add the OS/2 launchers to it. I'm know that
>OS/2 is not officially supported by the TomCat team, but I would. It
>also would help to support NetBeans Web Development on OS/2. I also
>think those launchers won't break anything.
>
>Thanks,
>
>Laszlo Kishalmi
>
>-
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]




This e-mail, including any attachments, is a confidential business communication, and 
may contain information that is confidential, proprietary and/or privileged.  This 
e-mail is intended only for the individual(s) to whom it is addressed, and may not be 
saved, copied, printed, disclosed or used by anyone else.  If you are not the(an) 
intended recipient, please immediately delete this e-mail from your computer system 
and notify the sender.  Thank you.


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

OS/2 Launchers in 5.0.29?

[Leslie Kishalmi]

Dear all,
I've filed http://issues.apache.org/bugzilla/show_bug.cgi?id=31361 , 
asking for adding OS/2 launchers to the tomcat distribution nearly a 
month ago. I've also prepared the full set of launchers. I've seen that 
5.0.29 is coming out. Can't add the OS/2 launchers to it. I'm know that 
OS/2 is not officially supported by the TomCat team, but I would. It 
also would help to support NetBeans Web Development on OS/2. I also 
think those launchers won't break anything.

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

Re: [VOTE] 5.5.3 Stability Rating

[Remy Maucherat]

Shapira, Yoav wrote:
[ X ] Beta, it's getting closer to stable [what's missing?]
 

I can't really help Filip for any clustering issues, but it's a good 
build for the rest.

I update my TODO list (it's not a before-stable todo list):
- A simple host manager webapp (with Ant tasks)
- A String cache for ByteChunk and maybe also CharChunk (configurable 
and manageable - it needs management, as it will work in two phases: 
statistics gathering, and then caching - using system properties and at 
runtime with JMX; this is an experiment, and I don't know if it'll be 
efficient or useless)
- Allowing pluggability for commons-modeler
- Optimized access log valve

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

DO NOT REPLY [Bug 31439] - Manager webapp cannot undeploy/redeploy webapps webapp

[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=31439

Manager webapp cannot undeploy/redeploy webapps webapp





--- Additional Comments From [EMAIL PROTECTED]  2004-10-12 15:53 ---
Using 5.5.3 makes no difference.

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

Re: [VOTE] 5.5.3 Stability Rating

[Filip Hanik - Dev]

[ X ] Beta, it's getting closer to stable [what's missing?]

Unfortunately due to an acquisition I am jammed at work. Cluster features that 
previously worked and need to be fixed:
1. Farm deployment

I haven't had time to check the other stuff, I know that 5.0.28 had problem with 
reloading the context where it wouldn't assign a
cluster manager properly when reloading, this worked in 5.0.25,
it could be possible the same problem exists in 5.5

Filip

- Original Message -
From: "Shapira, Yoav" <[EMAIL PROTECTED]>
To: "Tomcat Developers List" <[EMAIL PROTECTED]>
Sent: Tuesday, October 12, 2004 10:36 AM
Subject: [VOTE] 5.5.3 Stability Rating



Hi,
Tomcat 5.5.3 has been available for about a week now, so it's time for a
stability vote.  I tentatively rated it Alpha when releasing as my own
personal impression, but I haven't had any significant issues with it
myself.  It passes our internal tests, and with the StandardWrapper
hotfix it passes the Servlet and JSP TCKs.  So:

Tomcat 5.5.3 should be rated:
[ ] Alpha still, because ???
[ X ] Beta, it's getting closer to stable [what's missing?]
[ ] Stable, it's rock solid

My vote, as shown above, is for Beta.  What's missing from Stable
rating: StandardWrapper hotfix, a few minor features for the JDT
compiler that are done only for the Ant compiler, JDT compiler support
for J2SE 5.0, a few bells and whistles.

This vote will run for about 72 hours as usual.  Also as usual, only
committer votes are binding, but opinions from other readers are
welcome.  Thanks,

Yoav Shapira http://www.yoavshapira.com





This e-mail, including any attachments, is a confidential business communication, and 
may contain information that is confidential,
proprietary and/or privileged.  This e-mail is intended only for the individual(s) to 
whom it is addressed, and may not be saved,
copied, printed, disclosed or used by anyone else.  If you are not the(an) intended 
recipient, please immediately delete this e-mail
from your computer system and notify the sender.  Thank you.


-
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]

[VOTE] 5.5.3 Stability Rating

[Shapira, Yoav]

Hi,
Tomcat 5.5.3 has been available for about a week now, so it's time for a
stability vote.  I tentatively rated it Alpha when releasing as my own
personal impression, but I haven't had any significant issues with it
myself.  It passes our internal tests, and with the StandardWrapper
hotfix it passes the Servlet and JSP TCKs.  So:

Tomcat 5.5.3 should be rated:
[ ] Alpha still, because ???
[ X ] Beta, it's getting closer to stable [what's missing?]
[ ] Stable, it's rock solid

My vote, as shown above, is for Beta.  What's missing from Stable
rating: StandardWrapper hotfix, a few minor features for the JDT
compiler that are done only for the Ant compiler, JDT compiler support
for J2SE 5.0, a few bells and whistles.

This vote will run for about 72 hours as usual.  Also as usual, only
committer votes are binding, but opinions from other readers are
welcome.  Thanks,

Yoav Shapira http://www.yoavshapira.com





This e-mail, including any attachments, is a confidential business communication, and 
may contain information that is confidential, proprietary and/or privileged.  This 
e-mail is intended only for the individual(s) to whom it is addressed, and may not be 
saved, copied, printed, disclosed or used by anyone else.  If you are not the(an) 
intended recipient, please immediately delete this e-mail from your computer system 
and notify the sender.  Thank you.


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

Re: JK Todo List

[Costin Manolache]

Henri Gomez wrote:
True, in ASF land as in other community, it's the users and
developpers base which make a solution/product successfull or
forgotten.
BTW, jk 1.2.x is allready very stable and should stay like this for now :
- JK 1.2.x is now on bug-fix only mode.
- AJP_PROXY/MOD_PROXY for Apache 2.1.x (built-in)
Should we start a new AJP/JK/whatever connector is another story which
has been debated this summer when we speak about mod_ajp.
We should first be very prudent since users may be puzzled by :
jk 1.2.x, jk 2.x, mod_webapp, ajp_proxy/mod_proxy, anewstufffwecouldimagine.
Since ajp_proxy/mod_proxy devel goes outside jakarta land, httpd-dev
and will be present only in Apache 2.1.x, may be there is a need for a
new piece of code for IIS/DOMINO/Apache1.3 or even Apache 2.x but we
should list the requested features missing in jk 1.2.x
For IIS/Domino - I think having it maintained and developed by apache is 
  a waste. In both mod_jk and mod_jk2 we pay a significant price for 
trying to be "multi-server", and it seems clear this is a feature that 
only few people want.

If an external project wants to create an IIS connector based on mod_ajp 
or jk - that's great. But they should do it taking full advantage of 
whatever IIS provides, including consistent config, etc.


I suggest take a look about what was detailed in mod_ajp thread (July
2004) and see if a new consensus could appears.
On Mon, 11 Oct 2004 16:21:44 -0700, Bill Barker <[EMAIL PROTECTED]> wrote:
- Original Message -
From: "Dave Oxley" <[EMAIL PROTECTED]>
To: "Tomcat Developers List" <[EMAIL PROTECTED]>
Sent: Monday, October 11, 2004 3:35 PM
Subject: Re: JK Todo List

So is JK2 dead because of proxy_ajp? Why doesn't JK2 just replace JK?
JK2 is dead because (like mod_webapp before it :), it failed to attract a
community interested in maintaining it.  You might as well ask 'why doesn't
mod_webapp just replace JK?'
There are also technical reasons I think. Like the attempt to "object 
oriented C" but without using one of the existing solutions. And not 
droping featurea from mod_jk. But you're right - lack of community 
interest was the main problem.

Costin


Dave.

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

This message is intended only for the use of the person(s) listed above as the 
intended recipient(s), and may contain information that is PRIVILEGED and 
CONFIDENTIAL.  If you are not an intended recipient, you may not read, copy, or 
distribute this message or any attachment. If you received this communication in 
error, please notify us immediately by e-mail and then delete all copies of this 
message and any attachments.
In addition you should be aware that ordinary (unencrypted) e-mail sent through the 
Internet is not secure. Do not send confidential or sensitive information, such as 
social security numbers, account numbers, personal identification numbers and 
passwords, to us via ordinary (unencrypted) e-mail.
-
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]

DO NOT REPLY [Bug 31671] - web.xml files are mix of 2.3 and 2.4 DTD

[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=31671

web.xml files are mix of 2.3 and 2.4 DTD





--- Additional Comments From [EMAIL PROTECTED]  2004-10-12 15:28 ---
Please delete/ignore my last comment above - I added it to the wrong bug 
report :)

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

DO NOT REPLY [Bug 31671] - web.xml files are mix of 2.3 and 2.4 DTD

[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=31671

web.xml files are mix of 2.3 and 2.4 DTD





--- Additional Comments From [EMAIL PROTECTED]  2004-10-12 15:26 ---
Agreed - using a 2.4 feature in a 2.3 file is clearly a user error.  However, 
should tomcat not throw an exception when it sees a tag in web.xml that is not 
defined in its DTD?  Tomcat is usually very strict at reporting problems in 
web.xml, which is a very useful feature, this is partly why I reported this 
problem.

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

[ANNOUNCEMENT] Jakarta Tomcat 4.1.31 Stable Released

[Keith Wannamaker]

The Jakarta Tomcat team is pleased to announce availability of
Jakarta Tomcat 4.1.31, available for download:
http://jakarta.apache.org/site/binindex.cgi
This is a maintenance release which incorporates a number of bug
fixes which were backported from Tomcat 5.  More information is 
available in the release notes,

http://www.apache.org/dist/jakarta/tomcat-4/v4.1.31/RELEASE-NOTES

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

DO NOT REPLY [Bug 31671] - web.xml files are mix of 2.3 and 2.4 DTD

[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=31671

web.xml files are mix of 2.3 and 2.4 DTD

[EMAIL PROTECTED] changed:

   What|Removed |Added

   Severity|Normal  |Enhancement



--- Additional Comments From [EMAIL PROTECTED]  2004-10-12 15:17 ---
You are welcome to submit pacthes ;-). But it's celarly a user errors, so
chaning this to an Enhancement.

-- Jeanfrancois

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

cvs commit: jakarta-tomcat-site/xdocs index.xml

[keith]

keith   2004/10/12 07:58:06

  Modified:docs index.html
   xdocsindex.xml
  Log:
  Tomcat 4.1.31 release changes
  
  Revision  ChangesPath
  1.69  +1 -1  jakarta-tomcat-site/docs/index.html
  
  Index: index.html
  ===
  RCS file: /home/cvs/jakarta-tomcat-site/docs/index.html,v
  retrieving revision 1.68
  retrieving revision 1.69
  diff -u -r1.68 -r1.69
  --- index.html14 Sep 2004 01:08:15 -  1.68
  +++ index.html12 Oct 2004 14:58:05 -  1.69
  @@ -205,7 +205,7 @@
   
   
   
  -4.1.30
  +4.1.31
   
   
   
  
  
  
  1.55  +1 -1  jakarta-tomcat-site/xdocs/index.xml
  
  Index: index.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-site/xdocs/index.xml,v
  retrieving revision 1.54
  retrieving revision 1.55
  diff -u -r1.54 -r1.55
  --- index.xml 7 Sep 2004 17:54:02 -   1.54
  +++ index.xml 12 Oct 2004 14:58:06 -  1.55
  @@ -46,7 +46,7 @@
   
   
 2.3/1.2
  -  4.1.30
  +  4.1.31
   
   
   
  
  
  

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

DO NOT REPLY [Bug 31671] New: - web.xml files are mix of 2.3 and 2.4 DTD

[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=31671

web.xml files are mix of 2.3 and 2.4 DTD

   Summary: web.xml files are mix of 2.3 and 2.4 DTD
   Product: Tomcat 5
   Version: 5.0.28
  Platform: PC
OS/Version: Windows NT/2K
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


There are a number of web.xml files bundled with the tomcat binary installer.  
Their headers are however a mixture of different versions - some are v2.3 and 
some are v2.4.  This has led me to make errors.  For example I accidentally 
based a web.xml file on a 2.3 DTD and then used the 2.4 feature  within it, which was then silently ignored (see report 31670).

I appreciate that 2.3 is still valid, and it is useful to distribute examples 
of each version. 

I'd like to suggest making all bundled web.xml files the latest version 
currently (2.4) but include the 2.3 headers commented out?  That way, people 
can clearly see the choice they are making, but can use all the new features 
without worrying about "upgrading" the bundled web.xml examples.

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

DO NOT REPLY [Bug 31670] New: - silently ignored in web.xml that uses 2.3 DTD

[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=31670

 silently ignored in web.xml that uses 2.3 DTD

   Summary:  silently ignored in web.xml that uses
2.3 DTD
   Product: Tomcat 5
   Version: 5.0.27
  Platform: PC
OS/Version: Windows NT/2K
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Jasper
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


It appears that  is ignored in a web.xml with 2.3 DTD headers, 
even though that tag was not introduced until 2.4.  Should use of this tag 
prior to v2.4 cause an exception to be thrown?

I reinstalled 5.0.27 from scratch (on Win2k / JDK 1.4.2_05).

I then added a simple webapp called "test" by adding these three files under
the webapps folder:
test\index.jsp
test\prelude.jspf
test\WEB-INF\web.xml

The file contents are as follows (I know that the jsps contain incomplete
HTML but they suffice to keep the example simple).

--index.jsp--
==
This is index.jsp
==

--prelude.jspf--
==
This is prelude.jspf
==

--web.xml--
==

http://java.sun.com/dtd/web-app_2_3.dtd";>



*.jsp
prelude.jspf



==

Note that the web.xml above uses the 2.3 DTD.  I made no other changes to the 
standard installation.

I then started tomcat (I already have it installed as a service).  I then
accessed http://localhost:8080/test/ using IE6.  This displayed the file
index.jsp. The browser showed just the text "This is index.jsp".  In other
words, no text from prelude.jspf was included even though this is configured
in web.xml.  No errors were logged in any of the logfiles.

As a check, I then stopped tomcat and edited web.xml to give it the 2.4
headers, deleted all the files from the work directory, then restarted
tomcat and ctrl-F5'd IE to force-reload the page.  This time, the text from
prelude.jspf was included in index.jsp, and no errors were logged.

So, as far as I can tell, it seems that the  tag is being
silently ignored when placed in a 2.3 web.xml, but no errors are being
thrown.

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

RE: Getting Tomcat Tests

[Shapira, Yoav]

Hi,

There are three sets of tests for Tomcat 5.0.x.



One is what we call the "tester" tests.  These are maintained in the
jakarta-tomcat-catalina CVS module, and ship with Tomcat's source
distribution.  You can compile and run them using the build.xml file you
use to build and package Tomcat.  I think the Ant target is called
"run-tester."  If any of these fails, it's broken.



The second set of tests is the "watchdog" one.  These used to be part of
Tomcat proper, and then were spun off into their own Jakarta project.
They were intended to be a complete Servlet and JSP TCK replacement.
They test to version 2.3, not 2.4, of the Spec.  For Tomcat 5.5, these
tests are no longer used by us.  But we did use them for 4.x and 5.0,
and you of course can use them as well.  There's an Ant target,
"run-watchdog" IIRC, in the main build.xml file you use to build Tomcat,
that will download, compile, and run these Watchdog tests for you.



The final set of tests is comprised of the Servlet and JSP TCKs.  These
are owned by Sun and you must obtain a TCK license from them if you want
to run these tests.  We run these last, after all the Tester (and for
Tomcat before 5.5, also Watchdog) tests pass.



Yoav Shapira



>-Original Message-

>From: Fisher, Mitchell L [mailto:[EMAIL PROTECTED]

>Sent: Friday, October 08, 2004 4:26 PM

>To: Tomcat Developers List

>Subject: Getting Tomcat Tests

>

>Where can I find test cases I can use to verify that my changes to the

>Coyote Connector haven't broken anything?

>

>I work for Unisys corporation, and we are modifying the Coyote
Connector to

>integrate Tomcat 5.0.28 with our native HTTP server on MCP systems

>("mainframe" systems with origins in the '70s).  This is similar to

>integrating Tomcat with Apache.  I want to make sure we haven't broken

>anything for supporting servlets.  I just joined this list, and saw a

>reference to "watchdog tests".  Are these the tests I want?

>

>Any suggestions appreciated.

>

>Mitchell Fisher

>Unisys, S&T, ClearPath MCP

>

>-

>To unsubscribe, e-mail: [EMAIL PROTECTED]

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






This e-mail, including any attachments, is a confidential business communication, and 
may contain information that is confidential, proprietary and/or privileged.  This 
e-mail is intended only for the individual(s) to whom it is addressed, and may not be 
saved, copied, printed, disclosed or used by anyone else.  If you are not the(an) 
intended recipient, please immediately delete this e-mail from your computer system 
and notify the sender.  Thank you.

RE: DefaultServlet and getOutputStream() / getWriter()

[Shapira, Yoav]

Hi,

>Additionally, every change I suggested (on tomcat-user) was definitly
not
>changing any behaviour, but maybe improving performance.

The rewritten while{} patch you suggested definitely changed behavior
significantly, as I and others pointed out ;)

>"Returns a ServletOutputStream suitable for writing binary data in the
>response. The servlet container does not encode the binary data.
>java.lang.IllegalStateException - if the getWriter method has been
called
>on
>this response
>java.io.IOException - if an input or output exception occurred"
>
>If I believe that javadocs, THERE IS NO REASON to do what the code
does,
>sind getWriter is never called before getOutputStream, so there will
never
>be the IllegalStateException and half of the code is obsolete.

When you're looking at the code, keep in mind that Tomcat's
DefaultServlet (like virtually every other Tomcat component) can be
extended or wrapped.  Such wrappers or extenders could call getWriter
first.

In addition, since an exception CAN be thrown as the JavaDoc says, it's
only good practice to catch it: if the exception isn't thrown the
performance penalty on any modern JVM is virtually zero.

It also behooves us to be safe and careful in our code and design,
because we can never know all the possible uses of Tomcat.  With Filters
and Wrappers, the request and response can be in various states
practically all along the processing pipeline, and so optimizations like
you suggest are risky at best.

I'm happy you're looking at the code.  If I were in your position (and I
definitely was, although that seems long ago now ;)), I would look
instead at Bugzilla, take a bug, and try to fix it.  The reason that's
better than just looking for optimizations in random places is that you
can test your work.  You still gain familiarity with the Tomcat code, as
well as familiarity with the bug fixing / submission process, the CVS
environments, Tomcat's build, etc, all of which are necessary if you're
going to be submitting patches.

Thanks,

Yoav





This e-mail, including any attachments, is a confidential business communication, and 
may contain information that is confidential, proprietary and/or privileged.  This 
e-mail is intended only for the individual(s) to whom it is addressed, and may not be 
saved, copied, printed, disclosed or used by anyone else.  If you are not the(an) 
intended recipient, please immediately delete this e-mail from your computer system 
and notify the sender.  Thank you.


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

RE: Bug 4690: sessions not scoped according to spec section 7.3

[Shapira, Yoav]

Hola,



>> What I see is that you have engaged in a widespread political

>> campaign

>> to have this changed, rather than rely on technical issues. I really

>> hate this kind of tactic.

>>

>

>I'm not quite sure what you are referring to.

>

>So far I have:

>(a) Discussed this on the Pluto-Dev & Pluto-User lists.

>(b) Added a comment to issue

> asking for

>clarification.

>(c) Written the previous email to Tomcat-Dev, which in which I
attempted to

>state my case for having the behaviour changed. I apologise if it
offended

>anyone - in no way was it supposed to.



The comment on theserverside.com was political IMHO ;)



Remy already covered the reasons for not doing this.  I'd just add that
if a feature is not in the Spec, and it's fragile as even its supporters
admit, then I don't want to implement it.  We have enough to worry about
with making Tomcat more stable, more efficient, faster, more suited to
other environments (smaller footprint, smaller distros, etc.), and all
that stuff is more important.  All this is far more than enough to -1
this.



Yoav




This e-mail, including any attachments, is a confidential business communication, and 
may contain information that is confidential, proprietary and/or privileged.  This 
e-mail is intended only for the individual(s) to whom it is addressed, and may not be 
saved, copied, printed, disclosed or used by anyone else.  If you are not the(an) 
intended recipient, please immediately delete this e-mail from your computer system 
and notify the sender.  Thank you.

Re: JK Todo List

[Henri Gomez]

True, in ASF land as in other community, it's the users and
developpers base which make a solution/product successfull or
forgotten.

BTW, jk 1.2.x is allready very stable and should stay like this for now :

- JK 1.2.x is now on bug-fix only mode.

- AJP_PROXY/MOD_PROXY for Apache 2.1.x (built-in)

Should we start a new AJP/JK/whatever connector is another story which
has been debated this summer when we speak about mod_ajp.

We should first be very prudent since users may be puzzled by :

jk 1.2.x, jk 2.x, mod_webapp, ajp_proxy/mod_proxy, anewstufffwecouldimagine.


Since ajp_proxy/mod_proxy devel goes outside jakarta land, httpd-dev
and will be present only in Apache 2.1.x, may be there is a need for a
new piece of code for IIS/DOMINO/Apache1.3 or even Apache 2.x but we
should list the requested features missing in jk 1.2.x

I suggest take a look about what was detailed in mod_ajp thread (July
2004) and see if a new consensus could appears.


On Mon, 11 Oct 2004 16:21:44 -0700, Bill Barker <[EMAIL PROTECTED]> wrote:
> 
> - Original Message -
> From: "Dave Oxley" <[EMAIL PROTECTED]>
> To: "Tomcat Developers List" <[EMAIL PROTECTED]>
> Sent: Monday, October 11, 2004 3:35 PM
> Subject: Re: JK Todo List
> 
> > So is JK2 dead because of proxy_ajp? Why doesn't JK2 just replace JK?
> >
> 
> JK2 is dead because (like mod_webapp before it :), it failed to attract a
> community interested in maintaining it.  You might as well ask 'why doesn't
> mod_webapp just replace JK?'
> 
> 
> 
> > Dave.
> >
> >
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> 
> 
> 
> This message is intended only for the use of the person(s) listed above as the 
> intended recipient(s), and may contain information that is PRIVILEGED and 
> CONFIDENTIAL.  If you are not an intended recipient, you may not read, copy, or 
> distribute this message or any attachment. If you received this communication in 
> error, please notify us immediately by e-mail and then delete all copies of this 
> message and any attachments.
> 
> In addition you should be aware that ordinary (unencrypted) e-mail sent through the 
> Internet is not secure. Do not send confidential or sensitive information, such as 
> social security numbers, account numbers, personal identification numbers and 
> passwords, to us via ordinary (unencrypted) e-mail.
> 
> 
> -
> 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: RE : The good way of making JAAS and Realm authentication use the same back-end authentication system?

[Antoine Brocard - Vertical*i S.A.]

Yes, certainly for this specific case...
But from a more "philosophical" point of view, why do I have to do that?
I mean why isn't it provided in standard with Tomcat (it is not a critic
it's only a question)?
Does my code interest the Tomcat community?
LERBSCHER Jean-Pierre wrote:
It seems that the simplest way is to write your own login module or try to
use/configure/debug the existing JNDI login module.
Regards,
-Message d'origine-
De : Antoine Brocard - Vertical*i S.A. [mailto:[EMAIL PROTECTED] 
Envoyé : mardi 12 octobre 2004 09:52
À : [EMAIL PROTECTED]
Objet : The good way of making JAAS and Realm authentication use the same
back-end authentication system?

Maybe this question should be in the User mailing list, but I think it
could interest some Developers...
The problem I had to solve is the following:
My application needs J2EE container authentication AND JAAS (to
authenticates requests coming from
an application that don't support standard authentication scheme, like
BASIC or FORM). The back-end
authentication system is an LDAP server. I would like that both J2EE
authentication and JAAS access
the same LDAP server.
As a first try I set up the following configuration:
Use the Tomcat JAASRealm for J2EE authentication.
Use the JDNILoginModule as JAAS login module, to access the LDAP   server.
The problem was that the JDNILoginModule was known to have bugs, and I
dind't succeeded to make this
configuration work.
The other solution is to make JAAS use the current J2EE authentication;
in other words make the JAAS
login module access the current Tomcat Realm and forward authentication
requests on it. I look for such
a module, without success.
I decided to write one myself, using the following hacks:
In order to access the current Realm from inside a loginmodule, I used
JMX. I copied some code from the
Tomcat sources. At this point I was able to get the current Realm but I
realized that the "authenticate"
method wasn't manageable through JMX.
To solve that, I decided to subclass the standard Tomcat Realm and to
make them accessible through JMX
by modifying the mbeans-descriptor.xml file. Finally it worked fine.
The last problem I had was related to location of .jar files.  In order
to make this work, I had to move the
content of TOMCAT_HOME/server/lib into TOMCAT_HOME/common/lib. This is
not very elegant and can lead to security
issues in some cases. Moreover clients are often reluctant to do such
operations...
My question(s) is(are) the following:
1)Is there is better/simpler procedure to make JAAS and J2EE container
authentication use the same back-end
mechanism? Maybe I missed a step somewhere...
1bis) If not, is there a simpler way of getting the current Realm from
Java code, instead of the ugly JMX
hack I used?
2)Why isn't there a "TomcatLogin" JAAS loginmodule, like there is with
Weblogic or Websphere? It seems that
"JAAS asking Realm" is the "standard" way of doing, not the "Realm
asking JAAS" one used by Tomcat...
Thanks in advance for your help
-
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]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE : The good way of making JAAS and Realm authentication use the same back-end authentication system?

[LERBSCHER Jean-Pierre]

It seems that the simplest way is to write your own login module or try to
use/configure/debug the existing JNDI login module.
Regards,

-Message d'origine-
De : Antoine Brocard - Vertical*i S.A. [mailto:[EMAIL PROTECTED] 
Envoyé : mardi 12 octobre 2004 09:52
À : [EMAIL PROTECTED]
Objet : The good way of making JAAS and Realm authentication use the same
back-end authentication system?

Maybe this question should be in the User mailing list, but I think it
could interest some Developers...


The problem I had to solve is the following:

My application needs J2EE container authentication AND JAAS (to
authenticates requests coming from
an application that don't support standard authentication scheme, like
BASIC or FORM). The back-end
authentication system is an LDAP server. I would like that both J2EE
authentication and JAAS access
the same LDAP server.


As a first try I set up the following configuration:

Use the Tomcat JAASRealm for J2EE authentication.
Use the JDNILoginModule as JAAS login module, to access the LDAP   server.

The problem was that the JDNILoginModule was known to have bugs, and I
dind't succeeded to make this
configuration work.


The other solution is to make JAAS use the current J2EE authentication;
in other words make the JAAS
login module access the current Tomcat Realm and forward authentication
requests on it. I look for such
a module, without success.

I decided to write one myself, using the following hacks:

In order to access the current Realm from inside a loginmodule, I used
JMX. I copied some code from the
Tomcat sources. At this point I was able to get the current Realm but I
realized that the "authenticate"
method wasn't manageable through JMX.
To solve that, I decided to subclass the standard Tomcat Realm and to
make them accessible through JMX
by modifying the mbeans-descriptor.xml file. Finally it worked fine.

The last problem I had was related to location of .jar files.  In order
to make this work, I had to move the
content of TOMCAT_HOME/server/lib into TOMCAT_HOME/common/lib. This is
not very elegant and can lead to security
issues in some cases. Moreover clients are often reluctant to do such
operations...


My question(s) is(are) the following:

1)Is there is better/simpler procedure to make JAAS and J2EE container
authentication use the same back-end
mechanism? Maybe I missed a step somewhere...

1bis) If not, is there a simpler way of getting the current Realm from
Java code, instead of the ugly JMX
hack I used?

2)Why isn't there a "TomcatLogin" JAAS loginmodule, like there is with
Weblogic or Websphere? It seems that
"JAAS asking Realm" is the "standard" way of doing, not the "Realm
asking JAAS" one used by Tomcat...

Thanks in advance for your help


-
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: cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/threads ThreadPool.java

[Yoshinori$B!!(BAshizawa]

[EMAIL PROTECTED] wrote:
(B> remm2004/10/12 01:03:33
(B> 
(B>   Modified:util/java/org/apache/tomcat/util/threads ThreadPool.java
(B>   Log:
(B>   - Use the interval field (bug 31663).
(B>   
(B>   Revision  ChangesPath
(B>   1.29  +1 -1  
(B> jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/threads/ThreadPool.java
(B>   
(B>   Index: ThreadPool.java
(B>   ===
(B>   RCS file: 
(B> /home/cvs/jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/threads/ThreadPool.java,v
(B>   retrieving revision 1.28
(B>   retrieving revision 1.29
(B>   diff -u -r1.28 -r1.29
(B>   --- ThreadPool.java 30 Aug 2004 19:24:02 -  1.28
(B>   +++ ThreadPool.java 12 Oct 2004 08:03:33 -  1.29
(B>   @@ -556,7 +556,7 @@
(B>
(B>// Sleep for a while.
(B>synchronized(this) {
(B>   -this.wait(WORK_WAIT_TIMEOUT);
(B>   +this.wait(interval);
(B>}
(B>
(B>// Check if should terminate.
(B>   
(B>   
(B>   
(B> 
(B> -
(B> To unsubscribe, e-mail: [EMAIL PROTECTED]
(B> For additional commands, e-mail: [EMAIL PROTECTED]
(B> 
(B> 
(B
(B
(B-
(BTo unsubscribe, e-mail: [EMAIL PROTECTED]
(BFor additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 31663] - 버그 유발 가능성 코드

[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=31663

버그 유발 가능성 코드

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2004-10-12 08:05 ---
Ok.

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

cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/threads ThreadPool.java

[remm]

remm2004/10/12 01:03:33

  Modified:util/java/org/apache/tomcat/util/threads ThreadPool.java
  Log:
  - Use the interval field (bug 31663).
  
  Revision  ChangesPath
  1.29  +1 -1  
jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/threads/ThreadPool.java
  
  Index: ThreadPool.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/threads/ThreadPool.java,v
  retrieving revision 1.28
  retrieving revision 1.29
  diff -u -r1.28 -r1.29
  --- ThreadPool.java   30 Aug 2004 19:24:02 -  1.28
  +++ ThreadPool.java   12 Oct 2004 08:03:33 -  1.29
  @@ -556,7 +556,7 @@
   
   // Sleep for a while.
   synchronized(this) {
  -this.wait(WORK_WAIT_TIMEOUT);
  +this.wait(interval);
   }
   
   // Check if should terminate.
  
  
  

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

The good way of making JAAS and Realm authentication use the same back-end authentication system?

[Antoine Brocard - Vertical*i S.A.]

Maybe this question should be in the User mailing list, but I think it
could interest some Developers...
The problem I had to solve is the following:
My application needs J2EE container authentication AND JAAS (to
authenticates requests coming from
an application that don't support standard authentication scheme, like
BASIC or FORM). The back-end
authentication system is an LDAP server. I would like that both J2EE
authentication and JAAS access
the same LDAP server.
As a first try I set up the following configuration:
Use the Tomcat JAASRealm for J2EE authentication.
Use the JDNILoginModule as JAAS login module, to access the LDAP   server.
The problem was that the JDNILoginModule was known to have bugs, and I
dind't succeeded to make this
configuration work.
The other solution is to make JAAS use the current J2EE authentication;
in other words make the JAAS
login module access the current Tomcat Realm and forward authentication
requests on it. I look for such
a module, without success.
I decided to write one myself, using the following hacks:
In order to access the current Realm from inside a loginmodule, I used
JMX. I copied some code from the
Tomcat sources. At this point I was able to get the current Realm but I
realized that the "authenticate"
method wasn't manageable through JMX.
To solve that, I decided to subclass the standard Tomcat Realm and to
make them accessible through JMX
by modifying the mbeans-descriptor.xml file. Finally it worked fine.
The last problem I had was related to location of .jar files.  In order
to make this work, I had to move the
content of TOMCAT_HOME/server/lib into TOMCAT_HOME/common/lib. This is
not very elegant and can lead to security
issues in some cases. Moreover clients are often reluctant to do such
operations...
My question(s) is(are) the following:
1)Is there is better/simpler procedure to make JAAS and J2EE container
authentication use the same back-end
mechanism? Maybe I missed a step somewhere...
1bis) If not, is there a simpler way of getting the current Realm from
Java code, instead of the ugly JMX
hack I used?
2)Why isn't there a "TomcatLogin" JAAS loginmodule, like there is with
Weblogic or Websphere? It seems that
"JAAS asking Realm" is the "standard" way of doing, not the "Realm
asking JAAS" one used by Tomcat...
Thanks in advance for your help
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 31663] New: - 버그 유발 가능성 코드

[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=31663

버그 유발 가능성 코드

   Summary: 버그 유발 가능성 코드
   Product: Tomcat 5
   Version: 5.0.28
  Platform: Other
OS/Version: Other
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Connector:HTTP
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


--- ThreadPool.java.orig2004-10-12 15:59:39.0 +0900
+++ ThreadPool.java 2004-10-12 16:01:46.0 +0900
@@ -556,7 +556,7 @@

 // Sleep for a while.
 synchronized(this) {
-this.wait(WORK_WAIT_TIMEOUT);
+this.wait(interval);
 }

 // Check if should terminate.

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