date:20021204

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://nagoya.apache.org/bugzilla/show_bug.cgi?id=15002

Tag files in different directories not belonging to different tag libraries





--- Additional Comments From [EMAIL PROTECTED]  2002-12-05 00:00 ---
Looking into this. Problem must be related to file path separators on Windows.
Examples work fine on Solaris.

--
To unsubscribe, e-mail:   
For additional commands, e-mail:

Re: [PATCH] SSI->CGI fix in Tomcat 4.1.12

2002-12-04 Thread Amy Roh

It's done.

Thanks,
Amy

Nick Bauman wrote:
> 
> Currently under Tomcat 4.1.12 SSI "normal" configuration which invokes a
> CGI script does not work. The reason for this is pretty obvious: The SSI
> servelet uses the pathInfo (PATH_INFO) value and calls the request
> dispatcher for any resources needed. The request dispatcher eats the
> pathInfo value and the CGI servlet can't find the CGI program, because
> it relies on pathInfo to tell it where the script is.
> 
> I made minor changes to three files in the current 4.1.12 distro
> to solve this problem. The strategy is thus: SSI-invoked resources flag
> the request with an attibute. When CGI servlet finally gets the request
> dispached, he checks whether SSI servlet invoked the resource via said
> attribute. If this is the case, he ignores the request.getPathInfo()
> method in favor of an already-present attribute on the request which
> already has the PATH_INFO environment value in it.
> 
> Voila, everything works now. Diffs attached.
> 
> Nick Bauman
> Software Engineer
> Cortexity Development
> 3600 N. Dupont
> Minneapolis, MN
> 55412
> M: 612-232-7120
> 
>   
> 
>ssipluscgi.patchName: ssipluscgi.patch
>Type: Plain Text (text/plain)
> 
>   
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 

--
To unsubscribe, e-mail:   
For additional commands, e-mail:

cvs commit: jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote ActionCode.java

2002-12-04 Thread costin

costin  2002/12/04 15:33:28

  Modified:coyote/src/java/org/apache/coyote ActionCode.java
  Log:
  A small change to ActionCode - add an int id to each action. It can
  be used in switch().
  
  Revision  ChangesPath
  1.11  +34 -25
jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/ActionCode.java
  
  Index: ActionCode.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/ActionCode.java,v
  retrieving revision 1.10
  retrieving revision 1.11
  diff -u -r1.10 -r1.11
  --- ActionCode.java   24 Nov 2002 11:56:14 -  1.10
  +++ ActionCode.java   4 Dec 2002 23:33:27 -   1.11
  @@ -70,78 +70,87 @@
   // -- Constants
   
   
  -public static final ActionCode ACTION_ACK = new ActionCode();
  +public static final ActionCode ACTION_ACK = new ActionCode(1);
   
   
  -public static final ActionCode ACTION_CLOSE = new ActionCode();
  +public static final ActionCode ACTION_CLOSE = new ActionCode(2);
   
   
  -public static final ActionCode ACTION_COMMIT = new ActionCode();
  +public static final ActionCode ACTION_COMMIT = new ActionCode(3);
   
   
   /**
* A flush() operation originated by the client ( i.e. a flush() on
* the servlet output stream or writer, called by a servlet ).
*/
  -public static final ActionCode ACTION_CLIENT_FLUSH = new ActionCode();
  +public static final ActionCode ACTION_CLIENT_FLUSH = new ActionCode(4);
   
   
  -public static final ActionCode ACTION_CUSTOM = new ActionCode();
  +public static final ActionCode ACTION_CUSTOM = new ActionCode(5);
   
   
  -public static final ActionCode ACTION_RESET = new ActionCode();
  +public static final ActionCode ACTION_RESET = new ActionCode(6);
   
   
  -public static final ActionCode ACTION_START = new ActionCode();
  +public static final ActionCode ACTION_START = new ActionCode(7);
   
   
  -public static final ActionCode ACTION_STOP = new ActionCode();
  +public static final ActionCode ACTION_STOP = new ActionCode(8);
   
   
  -public static final ActionCode ACTION_WEBAPP = new ActionCode();
  +public static final ActionCode ACTION_WEBAPP = new ActionCode(9);
   
  -
  -/**
  - * Hook called after request, but before recycling. Can be used
  - * for logging, to update counters, custom cleanup - the request
  - * is still visible
  - */
  -public static final ActionCode ACTION_POST_REQUEST = new ActionCode();
  +/** Hook called after request, but before recycling. Can be used
  +for logging, to update counters, custom cleanup - the request
  +is still visible
  +*/
  +public static final ActionCode ACTION_POST_REQUEST = new ActionCode(10);
   
   /**
* Callback for lazy evaluation - extract the remote host name.
*/
   public static final ActionCode ACTION_REQ_HOST_ATTRIBUTE = 
  -new ActionCode();
  +new ActionCode(11);
   
   
   /**
  - * Callback for lazy evaluation - extract the remote host address.
  + * Callback for lazy evaluation - extract the SSL-related attributes.
*/
  -public static final ActionCode ACTION_REQ_HOST_ADDR_ATTRIBUTE = 
  -new ActionCode();
  -
  +public static final ActionCode ACTION_REQ_HOST_ADDR_ATTRIBUTE = new 
ActionCode(12);
   
   /**
* Callback for lazy evaluation - extract the SSL-related attributes.
*/
  -public static final ActionCode ACTION_REQ_SSL_ATTRIBUTE = new ActionCode();
  +public static final ActionCode ACTION_REQ_SSL_ATTRIBUTE = new ActionCode(13);
  +
  +
  +/** Chain for request creation. Called each time a new request is created
  +( requests are recycled ).
  + */
  +public static final ActionCode ACTION_NEW_REQUEST = new ActionCode(14);
   
   
   /**
* Callback for lazy evaluation - extract the SSL-certificate 
* (including forcing a re-handshake if necessary)
*/
  -public static final ActionCode ACTION_REQ_SSL_CERTIFICATE = new ActionCode();
  +public static final ActionCode ACTION_REQ_SSL_CERTIFICATE = new ActionCode(14);
   
   
   // --- Constructors
  -
  +int code;
   
   /**
* Private constructor.
*/
  -private ActionCode() {
  +private ActionCode(int code) {
  +this.code=code;
  +}
  +
  +/** Action id, useable in switches and table indexes
  + */
  +public int getCode() {
  +return code;
   }
   
   
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail:

[PATCH] SSI->CGI fix in Tomcat 4.1.12

2002-12-04 Thread Nick Bauman

Currently under Tomcat 4.1.12 SSI "normal" configuration which invokes a
CGI script does not work. The reason for this is pretty obvious: The SSI
servelet uses the pathInfo (PATH_INFO) value and calls the request
dispatcher for any resources needed. The request dispatcher eats the
pathInfo value and the CGI servlet can't find the CGI program, because
it relies on pathInfo to tell it where the script is.

I made minor changes to three files in the current 4.1.12 distro
to solve this problem. The strategy is thus: SSI-invoked resources flag
the request with an attibute. When CGI servlet finally gets the request
dispached, he checks whether SSI servlet invoked the resource via said
attribute. If this is the case, he ignores the request.getPathInfo()
method in favor of an already-present attribute on the request which
already has the PATH_INFO environment value in it.

Voila, everything works now. Diffs attached.

Nick Bauman
Software Engineer
Cortexity Development
3600 N. Dupont
Minneapolis, MN
55412
M: 612-232-7120


diff -uNr
jakarta-tomcat-4.1.12-orig/catalina/src/share/org/apache/catalina/Globals.java
jakarta-tomcat-4.1.12-src/catalina/src/share/org/apache/catalina/Globals.java
---
jakarta-tomcat-4.1.12-orig/catalina/src/share/org/apache/catalina/Globals.java
2002-09-23
03:24:20.0 -0600
+++
jakarta-tomcat-4.1.12-src/catalina/src/share/org/apache/catalina/Globals.java
2002-12-03
20:48:00.0 -0600
@@ -290,5 +290,13 @@
 public static final String WORK_DIR_ATTR =
 "javax.servlet.context.tempdir";
 
-
+/**
+ * The servlet context attribute under which we store a flag used 
+ * to mark this request as having been processed by the SSIServlet. 
+ * We do this because of the pathInfo mangling happening when using 
+ * the CGIServlet in conjunction with the SSI servlet. (value stored 
+ * as an object of type String)
+ */
+public static final String SSI_FLAG_ATTR = 
+"org.apache.catalina.ssi.SSIServlet";
 }
diff -uNr
jakarta-tomcat-4.1.12-orig/catalina/src/share/org/apache/catalina/servlets/CGIServlet.java
jakarta-tomcat-4.1.12-src/catalina/src/share/org/apache/catalina/servlets/CGIServlet.java
---
jakarta-tomcat-4.1.12-orig/catalina/src/share/org/apache/catalina/servlets/CGIServlet.java
2002-09-23
03:24:18.0 -0600
+++
jakarta-tomcat-4.1.12-src/catalina/src/share/org/apache/catalina/servlets/CGIServlet.java
2002-12-03
20:54:32.0 -0600
@@ -966,8 +966,12 @@
 String sCGIName = null;
 String[] sCGINames;
 
-
-sPathInfoOrig = this.pathInfo;
+if(null != req.getAttribute(Globals.SSI_FLAG_ATTR)) {
+// invoked by SSIServlet, which eats our req.getPathInfo() data
+sPathInfoOrig = (String) req.getAttribute(Globals.PATH_INFO_ATTR);
+} else {
+sPathInfoOrig = this.pathInfo;
+}
 sPathInfoOrig = sPathInfoOrig == null ? "" : sPathInfoOrig;
 
 sPathTranslatedOrig = req.getPathTranslated();
diff -uNr
jakarta-tomcat-4.1.12-orig/catalina/src/share/org/apache/catalina/ssi/SSIServlet.java
jakarta-tomcat-4.1.12-src/catalina/src/share/org/apache/catalina/ssi/SSIServlet.java
---
jakarta-tomcat-4.1.12-orig/catalina/src/share/org/apache/catalina/ssi/SSIServlet.java  
  2002-09-23
03:24:18.0 -0600
+++
jakarta-tomcat-4.1.12-src/catalina/src/share/org/apache/catalina/ssi/SSIServlet.java   
 2002-12-03
19:44:06.0 -0600
@@ -64,38 +64,24 @@
 
 package org.apache.catalina.ssi;
 
+import java.io.BufferedReader;
 import java.io.IOException;
 import java.io.InputStream;
 import java.io.InputStreamReader;
-import java.io.OutputStream;
-import java.io.OutputStreamWriter;
-import java.io.BufferedInputStream;
-import java.io.BufferedReader;
-import java.io.ByteArrayOutputStream;
 import java.io.PrintWriter;
-import java.io.Reader;
 import java.io.StringWriter;
-import java.io.Writer;
 import java.net.URL;
 import java.net.URLConnection;
-import java.net.URLDecoder;
-import java.util.ArrayList;
-import java.util.Collection;
 import java.util.Date;
-import java.util.Enumeration;
-import java.util.HashMap;
-import java.util.Locale;
-import java.text.SimpleDateFormat;
-import java.util.StringTokenizer;
-import java.util.TimeZone;
-import javax.servlet.RequestDispatcher;
-import javax.servlet.ServletException;
+
 import javax.servlet.ServletContext;
-import javax.servlet.ServletOutputStream;
+import javax.servlet.ServletException;
 import javax.servlet.http.HttpServlet;
 import javax.servlet.http.HttpServletRequest;
 import javax.servlet.http.HttpServletResponse;
 
+import org.apache.catalina.Globals;
+
 /**
  * Servlet to process SSI requests within a webpage.
  * Mapped to a path from within web.xml.
@@ -234,7 +220,7 @@
 res.setDateHeader("Expires", (
 new java.util.Date()).getTime() + expires.longValue() * 1000);

DO NOT REPLY [Bug 15002] - Tag files in different directories not belonging to different tag libraries

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://nagoya.apache.org/bugzilla/show_bug.cgi?id=15002

Tag files in different directories not belonging to different tag libraries





--- Additional Comments From [EMAIL PROTECTED]  2002-12-04 22:47 ---
I also get the same error as Richard, both for the JSP examples and for any tag 
files I write from scratch.  I am using the nightly build of Tomcat 5 on 
Windows NT 4.0, with clean directories.  It worked up until November 27 and 
stopped working after this fix was applied.

--
To unsubscribe, e-mail:   
For additional commands, e-mail:

DO NOT REPLY [Bug 15088] New: - org.apache.jasper.servlet.JspServlet doesn't close a FileInputStream.

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://nagoya.apache.org/bugzilla/show_bug.cgi?id=15088

org.apache.jasper.servlet.JspServlet doesn't close a FileInputStream.

   Summary: org.apache.jasper.servlet.JspServlet doesn't close a
FileInputStream.
   Product: Tomcat 4
   Version: 4.0.6 Final
  Platform: All
OS/Version: All
Status: NEW
  Severity: Major
  Priority: Other
 Component: Jasper
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


As I know, JspServlet is responsible for checking if jsp should be reloaded or
not, etc.

I found that JspServlet is checking it by opening the jsp file input stream.
In the loadJSP() method of JspServlet,

// First check if the requested JSP page exists, to avoid creating
// unnecessary directories and files.
if (context.getResourceAsStream(jspUri) == null)
throw new FileNotFoundException(jspUri);

context.getResourceAsStream() returns a InputStream object for the jsp file.
I think this routine would call `org.apache.catalina.core.ApplicationContext''s
getResourceAsStream() method, and then call
`org.apache.naming.resources.FileDirContext''s `streamContent()' method, which
would return a FileInputStream object.

If my inference is true, then `if (context.getResourceAsStream(jspUri) == null)'
code has a problem. Because this code doesn't close the FileInputStream object
explicitly, the file handle might be monitored only by garbage collector.
This can be a problem in case that the limit count of open files is set on a
system. Every request can open a jsp stream, so the open file count increases.

I don't think it's efficient to open the stream to check whether the jsp should
be reloaded or not.

Thanks. (My opinion could be based on misunderstandings.)

--
To unsubscribe, e-mail:   
For additional commands, e-mail:

How to print to logs?

2002-12-04 Thread michael . miu

Hi, i'm creating JSP's in Tomcat, and i want to print stuff out to the log.
I tried system.out.println ("..."), but it doesn't work.
Do any of you know how I can do this?

Thanks in advance,

-Mike


--
To unsubscribe, e-mail:   
For additional commands, e-mail:

Re: [RFC] Make jakarta-tomcat-catalina codebase common for both Tomcat 4 and Tomcat 5

Jeanfrancois Arcand wrote:

> This is hard to do (Catalina has never been written to allow facades).
> Also, for Tomcat 5, j-t-catalina is actually the Servlet 2.4 facade.

> Euh...I also like the module idea, but I share Remy's view and I doubt
> about having a single o.a.c workspace for all Servlet specs (starting
> 2.3 & 2.4). Without facade, I don't see how we can achieve that. I would
> prefer having a shared workspace for everything except stuffs related to
> Servlet. Something like:
> 
> o.a.catalina (basic web server stuff)
> o.a.catalina.servletEngine (where the Servlet spec is implemented)

Well, if you move auth* and session to modules and use Action ( or something 
like that ) for hooks - catalina will be the facade and have all the 
Servlet spec implementation.

And all modules should work with any version of tomcat that uses coyote
( i.e. 3.3, 4.0, 4.1, 5.0, etc ). 

If we also move ( or replace ) some of the 3.3 modules ( for example
the mapper, or auth* ) - then 3.3 core will also act as a facade. 

There is no need for a servletEngine package, it's much better to go 
the other way around and move ahead with moving modules out.

We'll need to keep the existing modules in - probably as small wrappers
around the new modules - for backward compatibility. So only new 
modules or existing module implementation will need to move ( and not
all at once ). Probably a "backward-compat" module could be used
for all the code that is deprecated but needs to be around for backward
compat.

> or something like that. That probably what Facade meansMaybe I'm
> dreaming ;-). We should really think of having an extension mechanism
> where module can be added easily. The solution resides probably by
> having a consistent hook mechanism...

Part of the solution, yes. The other part is ( IMO ) JNDI/JMX.

JNDI+JMX will take care of configuring ( you can't do it with JMX alone -
you also need JNDI to locate the objects ). A "module" will be an mbean
that also implements the hook interface.

We can theoretically use JMX alone - without a hook interface and using
invoke() - but that would hurt performance. 

To add a module - you can use any JMX mechanism ( including mlet ) 
_and_ register the module in a catalina:/jmx/OBJECT_NAME jndi.
Tomcat will listen for object notifications - and pick up all
modules and configure them based on the name.

The JNDI/JMX name of each module is very important - as it contains
the position where it must be inserted.

It is quite simple. And it can be implemented without affecting too
much the existing code - it'll be just another module. We'll need to
add some JMX awareness into the code, but it seems the proposal
to require jmx will pass.

Costin

--
To unsubscribe, e-mail:   
For additional commands, e-mail:

cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/ssi SSIServlet.java

2002-12-04 Thread amyroh

amyroh  2002/12/04 13:09:08

  Modified:catalina/src/share/org/apache/catalina Globals.java
   catalina/src/share/org/apache/catalina/servlets
CGIServlet.java
   catalina/src/share/org/apache/catalina/ssi SSIServlet.java
  Log:
  Fix for SSI "normal" configuration which invokes a CGI script.
  
  Patch submitted by Nick Bauman <[EMAIL PROTECTED]>.
  
  Revision  ChangesPath
  1.45  +15 -4 
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/Globals.java
  
  Index: Globals.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/Globals.java,v
  retrieving revision 1.44
  retrieving revision 1.45
  diff -u -r1.44 -r1.45
  --- Globals.java  23 Sep 2002 00:16:35 -  1.44
  +++ Globals.java  4 Dec 2002 21:09:07 -   1.45
  @@ -266,6 +266,17 @@
   public static final String SESSION_PARAMETER_NAME = "jsessionid";
   
   
  +   /**
  +* The servlet context attribute under which we store a flag used 
  +* to mark this request as having been processed by the SSIServlet. 
  +* We do this because of the pathInfo mangling happening when using 
  +* the CGIServlet in conjunction with the SSI servlet. (value stored 
  +* as an object of type String)
  +*/
  +public static final String SSI_FLAG_ATTR = 
  +"org.apache.catalina.ssi.SSIServlet";
  +
  +
   /**
* The request attribute under which we forward an HTTP status code
* (as an object of type Integer) to an error page.
  
  
  
  1.11  +13 -8 
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/CGIServlet.java
  
  Index: CGIServlet.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/CGIServlet.java,v
  retrieving revision 1.10
  retrieving revision 1.11
  diff -u -r1.10 -r1.11
  --- CGIServlet.java   22 Nov 2002 21:51:14 -  1.10
  +++ CGIServlet.java   4 Dec 2002 21:09:07 -   1.11
  @@ -967,7 +967,12 @@
   String[] sCGINames;
   
   
  -sPathInfoOrig = this.pathInfo;
  +if (null != req.getAttribute(Globals.SSI_FLAG_ATTR)) {
  +// invoked by SSIServlet, which eats our req.getPathInfo() data
  +sPathInfoOrig = (String) req.getAttribute(Globals.PATH_INFO_ATTR);
  +} else {
  +sPathInfoOrig = this.pathInfo;
  +}
   sPathInfoOrig = sPathInfoOrig == null ? "" : sPathInfoOrig;
   
   sPathTranslatedOrig = req.getPathTranslated();
  
  
  
  1.2   +35 -28
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/ssi/SSIServlet.java
  
  Index: SSIServlet.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/ssi/SSIServlet.java,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- SSIServlet.java   26 May 2002 00:00:55 -  1.1
  +++ SSIServlet.java   4 Dec 2002 21:09:08 -   1.2
  @@ -95,6 +95,7 @@
   import javax.servlet.http.HttpServlet;
   import javax.servlet.http.HttpServletRequest;
   import javax.servlet.http.HttpServletResponse;
  +import org.apache.catalina.Globals;
   
   /**
* Servlet to process SSI requests within a webpage.
  @@ -106,6 +107,7 @@
* @version $Revision$, $Date$
*/
   public class SSIServlet extends HttpServlet {
  +
   /** Debug level for this servlet. */
   protected int debug = 0;
   
  @@ -217,14 +219,14 @@
path.toUpperCase().startsWith("/META-INF") ) {
   
   res.sendError(res.SC_NOT_FOUND, path);
  - log( "Can't serve file: " + path );
  +log( "Can't serve file: " + path );
   return;
   }
  - 
  - URL resource = servletContext.getResource(path);
  +
  +URL resource = servletContext.getResource(path);
   if (resource==null) {
   res.sendError(res.SC_NOT_FOUND, path);
  - log( "Can't find file: " + path );
  +log( "Can't find file: " + path );
   return;
   }
   
  @@ -234,37 +236,42 @@
   res.setDateHeader("Expires", (
   new java.util.Date()).getTime() + expires.longValue() * 1000);
   }
  -
  - processSSI( req, res, resource );
  +
  +req.setAttribute(Globals.SSI_FLAG_ATTR,"true");
  +processSSI( req, res, resource );
   }
   
   protected void processSSI( HttpServletRequest req,
  -HttpServletResponse res,
  -URL resource ) throws IOException {
  - SSIExternalResolver ssiExternalResolver = new SSIServletExternalResolver( 
this, req, res,
  -

DO NOT REPLY [Bug 15086] - System.out from destroy goes to different place than init message

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://nagoya.apache.org/bugzilla/show_bug.cgi?id=15086

System.out from destroy goes to different place than init message





--- Additional Comments From [EMAIL PROTECTED]  2002-12-04 21:08 ---
Created an attachment (id=4054)
test application in war file

--
To unsubscribe, e-mail:   
For additional commands, e-mail:

DO NOT REPLY [Bug 15086] - System.out from destroy goes to different place than init message

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://nagoya.apache.org/bugzilla/show_bug.cgi?id=15086

System.out from destroy goes to different place than init message

[EMAIL PROTECTED] changed:

   What|Removed |Added

 OS/Version|Other   |Windows XP
   Platform|Other   |PC

--
To unsubscribe, e-mail:   
For additional commands, e-mail:

DO NOT REPLY [Bug 15086] New: - System.out from destroy goes to different place than init message

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://nagoya.apache.org/bugzilla/show_bug.cgi?id=15086

System.out from destroy goes to different place than init message

   Summary: System.out from destroy goes to different place than
init message
   Product: Tomcat 4
   Version: 4.1.16
  Platform: Other
OS/Version: Other
Status: NEW
  Severity: Minor
  Priority: Other
 Component: Servlet & JSP API
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Suppose you have a jsp that prints a message to System.out from both
it's jspInit and jspDestroy methods.
The init message goes to the window where tomcat was started, but
the destroy message goes to the Tomcat log.
Shouldn't these to messages go to the same place? (either the window
or the log, or both -- but at least be consistent?)
The same issue exists with Servlets that have a init and destroy method.

I will attach a test war file. It contains two simple
jsp's (preload1.jsp, preload2.jsp) that print out messages to System.out
in both their jspInit and jspDestroy methods.
Also contains a Servlet that does the same kind of thing (init/destroy 
methods).
Reload the context a couple times and note where the messages go.

--
To unsubscribe, e-mail:   
For additional commands, e-mail:

DO NOT REPLY [Bug 14797] - Request headers are broken after invoking pageContext.include()

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://nagoya.apache.org/bugzilla/show_bug.cgi?id=14797

Request headers are broken after invoking pageContext.include()

[EMAIL PROTECTED] changed:

   What|Removed |Added

 CC||[EMAIL PROTECTED]



--- Additional Comments From [EMAIL PROTECTED]  2002-12-04 21:03 ---
*** Bug 15032 has been marked as a duplicate of this bug. ***

--
To unsubscribe, e-mail:   
For additional commands, e-mail:

DO NOT REPLY [Bug 15032] - Headers get corrupted when used with mod_jk/mod_jk2 and apache 2.0.43

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://nagoya.apache.org/bugzilla/show_bug.cgi?id=15032

Headers get corrupted when used with mod_jk/mod_jk2 and apache 2.0.43

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE



--- Additional Comments From [EMAIL PROTECTED]  2002-12-04 21:03 ---


*** This bug has been marked as a duplicate of 14797 ***

--
To unsubscribe, e-mail:   
For additional commands, e-mail:

DO NOT REPLY [Bug 15084] - preloaded jsp's have their init method called again on first hit

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://nagoya.apache.org/bugzilla/show_bug.cgi?id=15084

preloaded jsp's have their init method called again on first hit





--- Additional Comments From [EMAIL PROTECTED]  2002-12-04 20:51 ---
Created an attachment (id=4052)
War file for test application

--
To unsubscribe, e-mail:   
For additional commands, e-mail:

DO NOT REPLY [Bug 15084] New: - preloaded jsp's have their init method called again on first hit

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://nagoya.apache.org/bugzilla/show_bug.cgi?id=15084

preloaded jsp's have their init method called again on first hit

   Summary: preloaded jsp's have their init method called again on
first hit
   Product: Tomcat 4
   Version: 4.1.16
  Platform: PC
OS/Version: Windows XP
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Servlet & JSP API
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


If you have a jsp with a jspInit method, and you preload
this jsp, the jspInit method gets called, as it should,
upon server startup. But now if you hit that jsp with your
web browser, Tomcat calls the jspInit method again.
(If you hit the jsp a second time, it's ok, doesn't call jspInit a third time.)
I will attach a war file that demonstrates this problem.
Simply load this application (test_app.war) and two pages
(preload1.jsp, preload2.jsp) each print out
that their jspInit methods are called.
Then hit the pages (http://host:port/test_app/preload1.jsp, etc.)
and see that they print out (to System.out) that their jspInit
methods are called once more.

--
To unsubscribe, e-mail:   
For additional commands, e-mail:

Re: [RFC] Make jakarta-tomcat-catalina codebase common for both Tomcat4 and Tomcat 5

2002-12-04 Thread Jeanfrancois Arcand



Remy Maucherat wrote:


Costin Manolache wrote:


Glenn Nielsen wrote:



Remy Maucherat wrote:


Glenn Nielsen wrote:



With Tomcat 4.1 released many tomcat developers have been reticent to
add new features
to its codebase for a number of reasons.  All the development 
going on
in Tomcat 5 and
wanting to keep the number of codebase's where bug fix patches 
have to
be applied to a
minimum.

There are alot of ideas for new features that I would like to see end
up in a Tomcat 4.2
release. Especially since we don't know when the Servlet 2.4/JSP 2.0
specs will be finalized
so that Tomcat 5 can be released.

There isn't that much difference in the core of catalina between the
Servlet 2.3 and
Servlet 2.4 specs. It might be possible to change the
jakarta-tomcat-catalina codebase
to make it neutral to what Servlet spec is implemented.  Then this
codebase could be
used for future Tomcat 4 and Tomcat 5 development.  And we then 
have a
common codebase
for applying bug fix patches.

This seems to fit in with the direction we have been going where
different components
are kept in different code bases. naming, connectors, jasper, etc.

Comments?



This is hard to do (Catalina has never been written to allow facades).
Also, for Tomcat 5, j-t-catalina is actually the Servlet 2.4 facade.




Right, I am aware of that. There isn't that much difference between
Servlet 2.3
and Servlet 2.4.  Having a common codebase for both would make 
addition of
new non spec related features easier and bug fix patching easier.



There are new methods in interfaces, etc. It won't be easy, I tried 
that ( for 2.2/2.3 ).

I agree with your idea of having common code between tomcat4 and tomcat5
( and tomcat3 ) - j-t-c is the best place to do that.

If we agree on a hook mechanism at coyote level - i.e. move auth* and 
other
hooks to implement Action or similar interface - then a lot of stuff 
can be moved to j-t-c ( or j-t-modules ) and be common. All auth*, 
mapping,
security - and we already have connectors and Request. 


I'm coming, I'm coming with a proposal :-)




That will also simplify the codebase in j-t-catalina - i.e. the code 
will
be more focused on implementing the servlet spec.


Yes, probably moving some code would be a nice solution. I'd prefer 
j-t-modules for that use, personally. 

Euh...I also like the module idea, but I share Remy's view and I doubt 
about having a single o.a.c workspace for all Servlet specs (starting 
2.3 & 2.4). Without facade, I don't see how we can achieve that. I would 
prefer having a shared workspace for everything except stuffs related to 
Servlet. Something like:

o.a.catalina (basic web server stuff)
o.a.catalina.servletEngine (where the Servlet spec is implemented)

or something like that. That probably what Facade meansMaybe I'm 
dreaming ;-). We should really think of having an extension mechanism 
where module can be added easily. The solution resides probably by 
having a consistent hook mechanism...




There needs to be someplace where new features can be added to the 
Tocmat
4 branch. You have been against adding new features to Tomcat 4 head,
creating a Tocmat 4.2 branch for developement, and now against making
j-t-catalina common to both Tomcat 4 & 5.



I think adding features in j-t-c was allways open, and so will be for
a potential j-t-module.

The reason for the negative votes on 4.2 was simple - if you find 3 
people to vote +1 on 4.2 ( i.e. who are interested in working on it 
), then
I don't see any reason not to do it.
I can hardly find time to work on 5.0 ( and thanks to Bill I don't 
have to
worry about 3.3 :-), and we have a lot of stuff on the todo list. That
shouldn't stop a 4.2 effort - if it gets at least the minimum 3 
committers.
I voted -0, I think Remy will change the vote to -0 as well. My -0 
means: I don't have time or interest in that, and I would preffer
that the features are done in 5.0 - but if 3 committers have this itch
I won't stop it.


This is a conspiracy ;-) I already voted -0 ;-) 

-0. I would prefer concentrating my works on 5.0 since I don't see a 
major difference between 4.2/5.0.  

-- Jeanfrancois



Remy


--
To unsubscribe, e-mail:   

For additional commands, e-mail: 





--
To unsubscribe, e-mail:   
For additional commands, e-mail:

DO NOT REPLY [Bug 15083] New: - App Deployed by manager can't find properties file in the classpath

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://nagoya.apache.org/bugzilla/show_bug.cgi?id=15083

App Deployed by manager can't find properties file in the classpath

   Summary: App Deployed by manager can't find properties file in
the classpath
   Product: Tomcat 4
   Version: 4.1.16
  Platform: PC
OS/Version: Windows XP
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Unknown
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


I have a JAXB application that I deploy through the manager. The app has a file
called jaxb.properties that is loaded by the jaxb runtime. This file is in the
war at web-inf/classes/long/class/path/jaxb.properties. When the runtime tries
to load the file it fails.

If I deploy the same war to tomcat/webapps or if I explode the war into
tomcat/webapps/appname then everything works fine

--
To unsubscribe, e-mail:   
For additional commands, e-mail:

Re: [RFC] Make jakarta-tomcat-catalina codebase common for both Tomcat4 and Tomcat 5

Costin Manolache wrote:

Glenn Nielsen wrote:



Remy Maucherat wrote:


Glenn Nielsen wrote:



With Tomcat 4.1 released many tomcat developers have been reticent to
add new features
to its codebase for a number of reasons.  All the development going on
in Tomcat 5 and
wanting to keep the number of codebase's where bug fix patches have to
be applied to a
minimum.

There are alot of ideas for new features that I would like to see end
up in a Tomcat 4.2
release. Especially since we don't know when the Servlet 2.4/JSP 2.0
specs will be finalized
so that Tomcat 5 can be released.

There isn't that much difference in the core of catalina between the
Servlet 2.3 and
Servlet 2.4 specs. It might be possible to change the
jakarta-tomcat-catalina codebase
to make it neutral to what Servlet spec is implemented.  Then this
codebase could be
used for future Tomcat 4 and Tomcat 5 development.  And we then have a
common codebase
for applying bug fix patches.

This seems to fit in with the direction we have been going where
different components
are kept in different code bases. naming, connectors, jasper, etc.

Comments?



This is hard to do (Catalina has never been written to allow facades).
Also, for Tomcat 5, j-t-catalina is actually the Servlet 2.4 facade.



Right, I am aware of that. There isn't that much difference between
Servlet 2.3
and Servlet 2.4.  Having a common codebase for both would make addition of
new non spec related features easier and bug fix patching easier.



There are new methods in interfaces, etc. It won't be easy, I tried that 
( for 2.2/2.3 ).

I agree with your idea of having common code between tomcat4 and tomcat5
( and tomcat3 ) - j-t-c is the best place to do that.

If we agree on a hook mechanism at coyote level - i.e. move auth* and other
hooks to implement Action or similar interface - then a lot of stuff 
can be moved to j-t-c ( or j-t-modules ) and be common. All auth*, mapping,
security - and we already have connectors and Request.

That will also simplify the codebase in j-t-catalina - i.e. the code will
be more focused on implementing the servlet spec.

Yes, probably moving some code would be a nice solution. I'd prefer 
j-t-modules for that use, personally.

There needs to be someplace where new features can be added to the Tocmat
4 branch. You have been against adding new features to Tomcat 4 head,
creating a Tocmat 4.2 branch for developement, and now against making
j-t-catalina common to both Tomcat 4 & 5.



I think adding features in j-t-c was allways open, and so will be for
a potential j-t-module.

The reason for the negative votes on 4.2 was simple - if you find 3 people 
to vote +1 on 4.2 ( i.e. who are interested in working on it ), then
I don't see any reason not to do it. 

I can hardly find time to work on 5.0 ( and thanks to Bill I don't have to
worry about 3.3 :-), and we have a lot of stuff on the todo list. That
shouldn't stop a 4.2 effort - if it gets at least the minimum 3 committers.
I voted -0, I think Remy will change the vote to -0 as well. 
My -0 means: I don't have time or interest in that, and I would preffer
that the features are done in 5.0 - but if 3 committers have this itch
I won't stop it.

This is a conspiracy ;-) I already voted -0 ;-)

Remy


--
To unsubscribe, e-mail:   
For additional commands, e-mail:

DO NOT REPLY [Bug 15009] - Classloading behavior does not follow specification/documentation

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://nagoya.apache.org/bugzilla/show_bug.cgi?id=15009

Classloading behavior does not follow specification/documentation

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||WONTFIX



--- Additional Comments From [EMAIL PROTECTED]  2002-12-04 20:04 ---
No, it violates the spec wording (and wouldn't work right anyway).

--
To unsubscribe, e-mail:   
For additional commands, e-mail:

Re: Jasper 2 Synchronized JSP compiles

Glenn Nielsen wrote:

I have some ideas on how invoking the javac compiler for compiling JSP 
pages can be
improved.  Currently Jasper 2 uses ant to do compiles from within Tomcat 
which are
synchronized.

There are currently several problems.

1. The known javac memory leak.

2. JSP page compiles are synchronized.

3. Jikes currently can't be configured for windows because the windows 
build of
   jikes doesn't support -encoding.

4. We may be getting some bug reports related to this problem noted in 
the Ant
   documentation for the javac task:

Windows Note:When the modern compiler is used in unforked mode on 
Windows, it locks up the files present in the classpath of the  
task, and does not release them. The side effect of this is that you 
will not be able to delete or move those files later on in the build. 
The workaround is to fork when invoking the compiler.

Recommendation:

Change Jasper 2 so that it tells ant to fork the javac compile.  This 
should remove the need
to synchronize the compiles.  It will also move java compilation outside 
of the JVM process
Tomcat is running in saving JVM heap memory and reducing GC overhead 
from objects created for
JSP compiles.  This could be done by just adding another parameter 
called "fork" to the
JspServlet paramters. If fork=true ant forks the javac compile and no 
synchronization is done.
The default for fork would be false.


+1. The compilation is not completely thread safe for concurrent 
requests on the same JSP, BTW (and it's quite complex to make it thread 
safe - I tried).

Remy


--
To unsubscribe, e-mail:   
For additional commands, e-mail:

DO NOT REPLY [Bug 15009] - Classloading behavior does not follow specification/documentation

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://nagoya.apache.org/bugzilla/show_bug.cgi?id=15009

Classloading behavior does not follow specification/documentation

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|WONTFIX |



--- Additional Comments From [EMAIL PROTECTED]  2002-12-04 19:48 ---
 What's the opinion about restoring the "delegate" attribute's original purpose?

--
To unsubscribe, e-mail:   
For additional commands, e-mail:

Coyote Connector/Tomcat 4.1.12 flushBuffer()

2002-12-04 Thread Randy Watler

I hesitate to send this message to this list, but I have had no nibbles
on the
tomcat-user list. As I noted below, I think there may be a bug in the
tomcat4 Coyote Connector code that implements flushBuffer(). Can
anyone in the Tomcat developer community comment here or point me
to someone that "owns" the Coyote connectors?

Thanks in advance,

Randy Watler
Finali Corporation



We are using Tomcat to serve pages that can take a long time to
generate, (in excess of 1 minute). To prevent the browser from retrying
to resend the request, we are committing the request using flushBuffer()

immediately after setting the response headers. However, it appears that

the CoyoteConnector ServletResponse.flushBuffer() implementation does
not execute unless the output stream or writer has been written to. We
are currently working around this problem by using chunked encoding and
pushing some white space out onto the stream. Of course, this does
commit the request, but is ugly.

The Servlet 2.3 standard seems to imply that flushBuffer() should commit

the request and flush the response headers. Furthermore, the code in
tomcat4/CoyoteResponse.java appears to attempt to commit the request and

flush the stream. When CoyoteResponse.flushBuffer() invokes
OutputBuffer.flush(), it attempts to call
OutputBuffer.realWriteBytes(null, 0, 0). This almost calls the necessary

doWrite() protocol on the underlying Response object, but the "cnt > 0"
argument safety check in OutputBuffer.realWriteBytes():377 prevents it.

Is there a bug here or are my eyes missing something subtle, (or
obvious)?

Re: Jasper 2 Synchronized JSP compiles

2002-12-04 Thread Kin-Man Chung

Performance-wise, wouldn't doing javac compilation in another process
be much worse than synchronized javac, at least for systems with small
number of processors?  It would nice if we can have some numbers for
comparision.

I know javac used to have memory leak, but is it still true for modern
compilers, such as the one in JDK 1.4.0?

BTW, I am +1 on the proposal.

> Date: Wed, 04 Dec 2002 09:04:35 -0600
> From: Glenn Nielsen <[EMAIL PROTECTED]>
> Subject: Jasper 2 Synchronized JSP compiles
> To: [EMAIL PROTECTED]
> 
> I have some ideas on how invoking the javac compiler for compiling JSP pages 
can be
> improved.  Currently Jasper 2 uses ant to do compiles from within Tomcat which 
are
> synchronized.
> 
> There are currently several problems.
> 
> 1. The known javac memory leak.
> 
> 2. JSP page compiles are synchronized.
> 
> 3. Jikes currently can't be configured for windows because the windows build 
of
> jikes doesn't support -encoding.
> 
> 4. We may be getting some bug reports related to this problem noted in the Ant
> documentation for the javac task:
> 
> Windows Note:When the modern compiler is used in unforked mode on Windows, it 
locks up the files present in the 
> classpath of the  task, and does not release them. The side effect of 
this is that you will not be able to delete 
> or move those files later on in the build. The workaround is to fork when 
invoking the compiler.
> 
> Recommendation:
> 
> Change Jasper 2 so that it tells ant to fork the javac compile.  This should 
remove the need
> to synchronize the compiles.  It will also move java compilation outside of 
the JVM process
> Tomcat is running in saving JVM heap memory and reducing GC overhead from 
objects created for
> JSP compiles.  This could be done by just adding another parameter called 
"fork" to the
> JspServlet paramters. If fork=true ant forks the javac compile and no 
synchronization is done.
> The default for fork would be false.
> 
> Comments?
> 
> Regards,
> 
> Glenn
> 
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
> 


--
To unsubscribe, e-mail:   
For additional commands, e-mail:

Re: [RFC] Make jakarta-tomcat-catalina codebase common for both Tomcat 4 and Tomcat 5

Glenn Nielsen wrote:

> Remy Maucherat wrote:
>> Glenn Nielsen wrote:
>> 
>>> With Tomcat 4.1 released many tomcat developers have been reticent to
>>> add new features
>>> to its codebase for a number of reasons.  All the development going on
>>> in Tomcat 5 and
>>> wanting to keep the number of codebase's where bug fix patches have to
>>> be applied to a
>>> minimum.
>>>
>>> There are alot of ideas for new features that I would like to see end
>>> up in a Tomcat 4.2
>>> release. Especially since we don't know when the Servlet 2.4/JSP 2.0
>>> specs will be finalized
>>> so that Tomcat 5 can be released.
>>>
>>> There isn't that much difference in the core of catalina between the
>>> Servlet 2.3 and
>>> Servlet 2.4 specs. It might be possible to change the
>>> jakarta-tomcat-catalina codebase
>>> to make it neutral to what Servlet spec is implemented.  Then this
>>> codebase could be
>>> used for future Tomcat 4 and Tomcat 5 development.  And we then have a
>>> common codebase
>>> for applying bug fix patches.
>>>
>>> This seems to fit in with the direction we have been going where
>>> different components
>>> are kept in different code bases. naming, connectors, jasper, etc.
>>>
>>> Comments?
>> 
>> 
>> This is hard to do (Catalina has never been written to allow facades).
>> Also, for Tomcat 5, j-t-catalina is actually the Servlet 2.4 facade.
> 
> 
> Right, I am aware of that. There isn't that much difference between
> Servlet 2.3
> and Servlet 2.4.  Having a common codebase for both would make addition of
> new non spec related features easier and bug fix patching easier.

There are new methods in interfaces, etc. It won't be easy, I tried that 
( for 2.2/2.3 ).

I agree with your idea of having common code between tomcat4 and tomcat5
( and tomcat3 ) - j-t-c is the best place to do that.

If we agree on a hook mechanism at coyote level - i.e. move auth* and other
hooks to implement Action or similar interface - then a lot of stuff 
can be moved to j-t-c ( or j-t-modules ) and be common. All auth*, mapping,
security - and we already have connectors and Request.

That will also simplify the codebase in j-t-catalina - i.e. the code will
be more focused on implementing the servlet spec.

> There needs to be someplace where new features can be added to the Tocmat
> 4 branch. You have been against adding new features to Tomcat 4 head,
> creating a Tocmat 4.2 branch for developement, and now against making
> j-t-catalina common to both Tomcat 4 & 5.

I think adding features in j-t-c was allways open, and so will be for
a potential j-t-module.

The reason for the negative votes on 4.2 was simple - if you find 3 people 
to vote +1 on 4.2 ( i.e. who are interested in working on it ), then
I don't see any reason not to do it. 

I can hardly find time to work on 5.0 ( and thanks to Bill I don't have to
worry about 3.3 :-), and we have a lot of stuff on the todo list. That
shouldn't stop a 4.2 effort - if it gets at least the minimum 3 committers.
I voted -0, I think Remy will change the vote to -0 as well. 
My -0 means: I don't have time or interest in that, and I would preffer
that the features are done in 5.0 - but if 3 committers have this itch
I won't stop it.

> If this is what you want then perhaps you should propose a VOTE to freeze
> all work on
> Tomcat 4 except for bug fixes.  And I mean all work.  If the community
> votes to do that then I will stop asking and perhaps go review the rules
> for revolutionaries.

I don't see the point of a vote to freeze ( and I think it would be a very 
bad idea ). 

Tomcat4 ( and tomcat33 - I think ) can get new features if enough interest
exists. They do get new features all the time ( at connector level ). 
If any of the features in 5.0 gets 3 +1 for porting it back to 4.x - 
then it should be done. 

If we move auth* and other stuff to couyte level and use Action - more 
featurs will be common across versions.

You can start a revolution and make any changes you want in proposal/, but
you'll still need at least 3 +1 votes to release it (well, you need a 
majority - but again I don't see why anyone would vote -1 ).

Costin 

--
To unsubscribe, e-mail:   
For additional commands, e-mail:

Re: [5] [Proposal] Adding an authorization interface

Glenn Nielsen wrote:

> There are a number of different types of realm implementations in
> org.apache.catalina.realm. These are all solely used for web application
> realm based authentication except for those which implement the
> UserDatabase which understands users, groups, and roles and has methods
> for managing these.  Also a UserDatabase can be instantiated as a JNDI
> resource.
> 
> It would be nice if all realm implementations could support not only
> authentication
> and authorization but also management of users, groups, and roles.  And be
> instantiated as a JNDI resource so it can be provided by the container as
> a resource to a virtual host.

Requiring all realm implementations to support user management is 
not a good idea. Some realms can do that ( database, our own file, ldap)
and some just can't ( passwd, kerberos/radius/tacacs, etc ).

I think we have 3 distinct issues:
- authorization: I think tomcat needs to expose a single hook and provide
a default implementation ( using the mapper - it can also implement jsr115,
but it needs to be efficient )

- authentication: again one hook that could be implemented by delegating
to apache or use JAAS ( that should be the default - and all current
Realms migrated to JAAS plugins ! )

- user management. That should be optional - and probably the best 
abstraction is JNDI. Besides user/pass/certificate it can store all other
user attributes. I think we should be consistent on naming the attributes 
as in the inetUser LDAP schema ( it will work out-of-box with existing
ldap servers and easy to translate to databases, etc ). All UserDatabase
impl should be migrated to JNDI providers, and UserDatabase deprecated (
or implemented on top of jndi ).

Costin



--
To unsubscribe, e-mail:   
For additional commands, e-mail:

Re: Jasper 2 Synchronized JSP compiles

+1, good idea !

Costin

Glenn Nielsen wrote:

> I have some ideas on how invoking the javac compiler for compiling JSP
> pages can be
> improved.  Currently Jasper 2 uses ant to do compiles from within Tomcat
> which are synchronized.
> 
> There are currently several problems.
> 
> 1. The known javac memory leak.
> 
> 2. JSP page compiles are synchronized.
> 
> 3. Jikes currently can't be configured for windows because the windows
> build of
> jikes doesn't support -encoding.
> 
> 4. We may be getting some bug reports related to this problem noted in the
> Ant
> documentation for the javac task:
> 
> Windows Note:When the modern compiler is used in unforked mode on Windows,
> it locks up the files present in the classpath of the  task, and
> does not release them. The side effect of this is that you will not be
> able to delete or move those files later on in the build. The workaround
> is to fork when invoking the compiler.
> 
> Recommendation:
> 
> Change Jasper 2 so that it tells ant to fork the javac compile.  This
> should remove the need
> to synchronize the compiles.  It will also move java compilation outside
> of the JVM process Tomcat is running in saving JVM heap memory and
> reducing GC overhead from objects created for
> JSP compiles.  This could be done by just adding another parameter called
> "fork" to the JspServlet paramters. If fork=true ant forks the javac
> compile and no synchronization is done. The default for fork would be
> false.
> 
> Comments?
> 
> Regards,
> 
> Glenn




--
To unsubscribe, e-mail:   
For additional commands, e-mail:

Re: [RFC] Make jakarta-tomcat-catalina codebase common for both Tomcat4 and Tomcat 5

Glenn Nielsen wrote:

> Remy Maucherat wrote:
>
>> Glenn Nielsen wrote:
>>
>>> With Tomcat 4.1 released many tomcat developers have been reticent 
to add new features
>>> to its codebase for a number of reasons.  All the development going 
on in Tomcat 5 and
>>> wanting to keep the number of codebase's where bug fix patches have 
to be applied to a
>>> minimum.
>>>
>>> There are alot of ideas for new features that I would like to see 
end up in a Tomcat 4.2
>>> release. Especially since we don't know when the Servlet 2.4/JSP 
2.0 specs will be finalized
>>> so that Tomcat 5 can be released.
>>>
>>> There isn't that much difference in the core of catalina between 
the Servlet 2.3 and
>>> Servlet 2.4 specs. It might be possible to change the 
jakarta-tomcat-catalina codebase
>>> to make it neutral to what Servlet spec is implemented.  Then this 
codebase could be
>>> used for future Tomcat 4 and Tomcat 5 development.  And we then 
have a common codebase
>>> for applying bug fix patches.
>>>
>>> This seems to fit in with the direction we have been going where 
different components
>>> are kept in different code bases. naming, connectors, jasper, etc.
>>>
>>> Comments?
>>
>>
>>
>>
>> This is hard to do (Catalina has never been written to allow 
facades). Also, for Tomcat 5, j-t-catalina is actually the Servlet 2.4 
facade.
>
>
>
>
> Right, I am aware of that. There isn't that much difference between 
Servlet 2.3
> and Servlet 2.4.  Having a common codebase for both would make 
addition of new
> non spec related features easier and bug fix patching easier.
>
>>
>> I'd like to point out that Jasper 2 from TC 5 is diverging from 
Jasper 2 from TC 4.1 very very quickly. Do you want a common codebase 
and some facades for that too ? ;-)
>>
>
> No. The JSP 2 spec changes from JSP 1.2 are so extensive it doesn't make
> sense to do so, also jasper is primarily implementing the JSP spec.
> Whereas the core of catalina is where all the non spec related 
features get added.

I mentioned Jasper since it was in your list of components in common.

>> Connectors is in common, because of the set of facades used in Coyote.
>>
>> I have no interest in that project, and see no point in trying to 
extend the life of the old API (given that the new one is quite similar).
>>
>> -0 from me (ie, go ahead if there's some developer interest; of 
course, implementation details will need to be discussed further).
>>
>> Remy
>>
>
> There needs to be someplace where new features can be added to the 
Tocmat 4 branch.
> You have been against adding new features to Tomcat 4 head, creating 
a Tocmat 4.2 branch for
> developement, and now against making j-t-catalina common to both 
Tomcat 4 & 5.

I am not against it (I would have been -1). I just think it is not such 
a great idea, so as it stands, I do not support it and don't plan to help.

BTW, I have been regularly adding features to 4.1.x, excluding the 
features which change existing behavior or lead to API changes (of 
course, given your recent posts, I guess you don't really know what 
occurred in tomcat-dev in the last 2 months). Please read the commits 
and the changelog.

> If this is what you want then perhaps you should propose a VOTE to 
freeze all work on
> Tomcat 4 except for bug fixes.  And I mean all work.  If the 
community votes to do that
> then I will stop asking and perhaps go review the rules for 
revolutionaries.

Glenn, I do not understand what is it that is not in 4.1 that you would 
want to add. Costin posted a comment the last time you mentioned 4.2 (I 
think it was one month ago), and I fully agree with it.

If you want to make a proposal, including a revolution, please do so. As 
is, my personal opinion is that having a common j-t-catalina between 4.x 
and 5.x is not doable from a technical standpoint (given that we have 
limited development resources), and even not desirable, as some API 
changes will be needed to make Catalina faster (right now, mapping and 
auth are really slow, and will need access to j-t-c/util objects to have 
acceptable speed and GC behavior).

Another possibility, given that the API 2.4 is close from 2.3, is that 
we release j-t-catalina as part of a 4.2 release, and advertise it as 
supporting servlets 2.3.

Remy

--
To unsubscribe, e-mail:   
For additional commands, e-mail:

DO NOT REPLY [Bug 15081] New: - WAR loses date information for enclosed contents

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://nagoya.apache.org/bugzilla/show_bug.cgi?id=15081

WAR loses date information for enclosed contents

   Summary: WAR loses date information for enclosed contents
   Product: Tomcat 4
   Version: 4.0 Beta 1
  Platform: PC
OS/Version: Windows XP
Status: NEW
  Severity: Major
  Priority: Other
 Component: Connector:Webapp
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


When the .war is decompressed, the file contents are all given the file 
creation date for the time of extraction.   The .war contains the correct 
dates.  I.e. if you open the .war with pkzip or WinZIP, you'll see that the 
correct creation dates are present.

Why do I need the actual creation dates?

I am using an autodeploy process (Java Web Start) for distributing my rich 
client.  Because the .war loses the dates, each new .war requires every file 
to download.  If the .war was properly decompressed, only the updated files 
(i.e. those with new build dates) would be downloaded because Java Web Start 
would have access to the correct creation dates.

thanks,
anthony

--
To unsubscribe, e-mail:   
For additional commands, e-mail:

cvs commit: jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat4 CoyoteResponse.java

2002-12-04 Thread jfarcand

jfarcand2002/12/04 09:43:05

  Modified:coyote/src/java/org/apache/coyote/tomcat4
CoyoteResponse.java
  Log:
  Fix for bugtraq 4772112 encodeURL does not encode session with empty URL (rfc2396)
  
  Revision  ChangesPath
  1.30  +12 -6 
jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat4/CoyoteResponse.java
  
  Index: CoyoteResponse.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat4/CoyoteResponse.java,v
  retrieving revision 1.29
  retrieving revision 1.30
  diff -u -r1.29 -r1.30
  --- CoyoteResponse.java   11 Nov 2002 11:01:04 -  1.29
  +++ CoyoteResponse.java   4 Dec 2002 17:43:05 -   1.30
  @@ -981,10 +981,16 @@
* @param url URL to be encoded
*/
   public String encodeURL(String url) {
  -
  -if (isEncodeable(toAbsolute(url))) {
  +
  +String absolute = toAbsolute(url);
  +if (isEncodeable(absolute)) {
   HttpServletRequest hreq =
   (HttpServletRequest) request.getRequest();
  +
  +// W3c spec clearly said 
  +if (url.equalsIgnoreCase("")){
  +url = absolute;
  +}
   return (toEncoded(url, hreq.getSession().getId()));
   } else {
   return (url);
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail:

cvs commit: jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat5 CoyoteResponse.java

2002-12-04 Thread jfarcand

jfarcand2002/12/04 09:42:32

  Modified:coyote/src/java/org/apache/coyote/tomcat5
CoyoteResponse.java
  Log:
  Fix for bugtraq 4772112 encodeURL does not encode session with empty URL (rfc2396)
  
  Revision  ChangesPath
  1.15  +12 -6 
jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat5/CoyoteResponse.java
  
  Index: CoyoteResponse.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat5/CoyoteResponse.java,v
  retrieving revision 1.14
  retrieving revision 1.15
  diff -u -r1.14 -r1.15
  --- CoyoteResponse.java   3 Dec 2002 16:37:59 -   1.14
  +++ CoyoteResponse.java   4 Dec 2002 17:42:31 -   1.15
  @@ -1033,10 +1033,16 @@
* @param url URL to be encoded
*/
   public String encodeURL(String url) {
  -
  -if (isEncodeable(toAbsolute(url))) {
  +
  +String absolute = toAbsolute(url);
  +if (isEncodeable(absolute)) {
   HttpServletRequest hreq =
   (HttpServletRequest) request.getRequest();
  +
  +// W3c spec clearly said 
  +if (url.equalsIgnoreCase("")){
  +url = absolute;
  +}
   return (toEncoded(url, hreq.getSession().getId()));
   } else {
   return (url);
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail:

Re: [RFC] Make jakarta-tomcat-catalina codebase common for both Tomcat4 and Tomcat 5

Glenn Nielsen wrote:

Remy Maucherat wrote:


Glenn Nielsen wrote:


With Tomcat 4.1 released many tomcat developers have been reticent to 
add new features
to its codebase for a number of reasons.  All the development going 
on in Tomcat 5 and
wanting to keep the number of codebase's where bug fix patches have 
to be applied to a
minimum.

There are alot of ideas for new features that I would like to see end 
up in a Tomcat 4.2
release. Especially since we don't know when the Servlet 2.4/JSP 2.0 
specs will be finalized
so that Tomcat 5 can be released.

There isn't that much difference in the core of catalina between the 
Servlet 2.3 and
Servlet 2.4 specs. It might be possible to change the 
jakarta-tomcat-catalina codebase
to make it neutral to what Servlet spec is implemented.  Then this 
codebase could be
used for future Tomcat 4 and Tomcat 5 development.  And we then have 
a common codebase
for applying bug fix patches.

This seems to fit in with the direction we have been going where 
different components
are kept in different code bases. naming, connectors, jasper, etc.

Comments?



This is hard to do (Catalina has never been written to allow facades). 
Also, for Tomcat 5, j-t-catalina is actually the Servlet 2.4 facade.



Right, I am aware of that. There isn't that much difference between 
Servlet 2.3
and Servlet 2.4.  Having a common codebase for both would make addition 
of new
non spec related features easier and bug fix patching easier.


I'd like to point out that Jasper 2 from TC 5 is diverging from Jasper 
2 from TC 4.1 very very quickly. Do you want a common codebase and 
some facades for that too ? ;-)


No. The JSP 2 spec changes from JSP 1.2 are so extensive it doesn't make
sense to do so, also jasper is primarily implementing the JSP spec.
Whereas the core of catalina is where all the non spec related features 
get added.

I mentioned Jasper since it was in your list of components in common.


Connectors is in common, because of the set of facades used in Coyote.

I have no interest in that project, and see no point in trying to 
extend the life of the old API (given that the new one is quite similar).

-0 from me (ie, go ahead if there's some developer interest; of 
course, implementation details will need to be discussed further).

Remy


There needs to be someplace where new features can be added to the 
Tocmat 4 branch.
You have been against adding new features to Tomcat 4 head, creating a 
Tocmat 4.2 branch for
developement, and now against making j-t-catalina common to both Tomcat 
4 & 5.

I am not against it (I would have been -1). I just think it is not such 
a great idea, so as it stands, I do not support it and don't plan to help.

BTW, I have been regularly adding features to 4.1.x, excluding the 
features which change existing behavior or lead to API changes (of 
course, given your recent posts, I guess you don't really know what 
occurred in tomcat-dev in the last 2 months). Please read the commits 
and the changelog.

If this is what you want then perhaps you should propose a VOTE to 
freeze all work on
Tomcat 4 except for bug fixes.  And I mean all work.  If the community 
votes to do that
then I will stop asking and perhaps go review the rules for 
revolutionaries.

Glenn, I do not understand what is it that is not in 4.1 that you would 
want to add. Costin posted a comment the last time you mentioned 4.2 (I 
think it was one month ago), and I fully agree with it.

If you want to make a proposal, including a revolution, please do so. As 
is, my personal opinion is that having a common j-t-catalina between 4.x 
and 5.x is not doable from a technical standpoint (given that we have 
limited development resources), and even not desirable, as some API 
changes will be needed to make Catalina faster (right now, mapping and 
auth are really slow, and will need access to j-t-c/util objects to have 
acceptable speed and GC behavior).

Another possibility, given that the API 2.4 is close from 2.3, is that 
we release j-t-catalina as part of a 4.2 release, and advertise it as 
supporting servlets 2.3.

Remy


--
To unsubscribe, e-mail:   
For additional commands, e-mail:

Re: [VOTE] Making JMX required in tomcat5

2002-12-04 Thread Craig R. McClanahan



On Tue, 3 Dec 2002, Costin Manolache wrote:

> Date: Tue, 03 Dec 2002 12:22:18 -0800
> From: Costin Manolache <[EMAIL PROTECTED]>
> Reply-To: Tomcat Developers List <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: [VOTE] Making JMX required in tomcat5
>
> The subject should be clear. The benefit is that we'll be able
> to build more JMX awareness in the code without doing tricks -
> each component will know about its ObjectName and will be
> able to return ObjectName[].
>
> I'm not proposing MBeans all over tomcat - modeler works very
> well in transforming our components into model mbeans.
>
> We already have 3 +1 votes ( costin, Remy and Jean Francois ).
>

Add a +1 from me as well.

> The only possible problem is the classical licensing issue
> ( we must use mx4j - but I don't know if they passed the TCK
> or if they will or if the TCK is available yet, etc ).
>

Has anyone asked the MX4J developers about this?  That would seem to be
the next course of action.

> Costin
>

Craig


--
To unsubscribe, e-mail:   
For additional commands, e-mail:

Repost: SSI invoking CGI fix PATCH

2002-12-04 Thread Nick Bauman

Errr, Anyone care about this?

How do I get a patch in the repository?

> Hello Tom Cats,
>
> Currently under Tomcat 4.1.12 SSI "normal" configuration which invokes a
> CGI script does not work. The reason for this is pretty obvious: The SSI
> servelet uses the pathInfo (PATH_INFO) value and calls the request
> dispatcher for any resources needed. The request dispatcher eats the
> pathInfo value and the CGI servlet can't find the CGI program, because
> it relies on pathInfo to tell it where the script is. Or something like
> that, whatever, you cats probably know better.
>
> Anyway, I made minor changes to three files in the current 4.1.12 distro
> to solve this problem. The strategy is thus: SSI-invoked resources flag
> the request with an attibute. When CGI servlet finally gets the request
> dispached, he checks whether SSI servlet invoked the resource via said
> attribute. If this is the case, he ignores the request.getPathInfo()
> method in favor of an already-present attribute on the request which
> already has the PATH_INFO environment value in it.
>
> Voila, everything works now. Diff attached.
>
> Nick Bauman
> Software Engineer
> Cortexity Development
> 3600 N. Dupont
> Minneapolis, MN
> 55412
> M: 612-232-7120




--
To unsubscribe, e-mail:   
For additional commands, e-mail:

DO NOT REPLY [Bug 15032] - Headers get corrupted when used with mod_jk/mod_jk2 and apache 2.0.43

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://nagoya.apache.org/bugzilla/show_bug.cgi?id=15032

Headers get corrupted when used with mod_jk/mod_jk2 and apache 2.0.43





--- Additional Comments From [EMAIL PROTECTED]  2002-12-04 17:50 ---
tested with mod_jk2.so version 2.0.2 has the same issue...

--
To unsubscribe, e-mail:   
For additional commands, e-mail:

DO NOT REPLY [Bug 15077] New: - NPE when reloading servlets in org.apache.catalina.core.StandardWrapper.allocate(StandardWrapper.java:686)

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://nagoya.apache.org/bugzilla/show_bug.cgi?id=15077

NPE when reloading servlets in  
org.apache.catalina.core.StandardWrapper.allocate(StandardWrapper.java:686)

   Summary: NPE when reloading servlets in
org.apache.catalina.core.StandardWrapper.allocate(Standa
rdWrapper.java:686)
   Product: Tomcat 4
   Version: 4.1.16
  Platform: PC
OS/Version: Windows NT/2K
Status: NEW
  Severity: Major
  Priority: Other
 Component: Catalina:Modules
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Hi

Dynamic reloading of a servlet (with or without SingleThreadModel interface) 
leads to a NullPointerException in  
org.apache.catalina.core.StandardWrapper.allocate(StandardWrapper.java:686). It 
seems that the instancePool stack is not properly constructed when the 
allocated method is call during a reload. The servlet has nothing really 
special except that it is a second level derivation of HttpServlet and is 
activated thru RequestDispatcher.forward().

2002-12-04 17:42:38 StandardContext[/primer]: Le rechargement de ce contexte a 
démarré
2002-12-04 17:42:38 MYSERVLET01 : MYSERVLET00: DESTROYED
2002-12-04 17:42:38 MYSERVLET01 : MYSERVLET00: DESTROYED
2002-12-04 17:42:38 MYSERVLET00 : MYSERVLET00: DESTROYED
2002-12-04 17:42:38 MYSERVLET00 : MYSERVLET00: DESTROYED
2002-12-04 17:42:38 StandardContext[/primer]: Sending application stop events
2002-12-04 17:42:38 StandardContext[/primer]: Stopping filters
2002-12-04 17:42:38 WebappLoader[/primer]: Deploying class repositories to work 
directory C:\Program Files\Apache Group\Tomcat 4.1.16
\work\Standalone\localhost\primer
2002-12-04 17:42:38 WebappLoader[/primer]: Deploy class files /WEB-INF/classes 
to C:\IWK\MyApp\Primer\WEB-INF\classes
2002-12-04 17:42:38 WebappLoader[/primer]: Deploy JAR /WEB-INF/lib/myapp.jar to 
C:\IWK\MyApp\Primer\WEB-INF\lib\myapp.jar
2002-12-04 17:42:38 WebappLoader[/primer]: Deploy JAR /WEB-INF/lib/percobol.jar 
to C:\IWK\MyApp\Primer\WEB-INF\lib\percobol.jar
2002-12-04 17:42:38 WebappLoader[/primer]: Reloading checks are enabled for 
this Context
2002-12-04 17:42:38 NamingContextListener[/Standalone/localhost/primer]: 
Creating JNDI naming context
2002-12-04 17:42:38 NamingContextListener[/Standalone/localhost/primer]:   
Resource parameters for UserTransaction = null
2002-12-04 17:42:38 StandardContext[/primer]: Configuring application event 
listeners
2002-12-04 17:42:38 StandardContext[/primer]: Sending application start events
2002-12-04 17:42:38 StandardContext[/primer]: Starting filters
2002-12-04 17:42:38 StandardWrapper[/primer:default]: Chargement du conteneur 
(container) de servlet default
2002-12-04 17:42:38 StandardWrapper[/primer:invoker]: Chargement du conteneur 
(container) de servlet invoker
2002-12-04 17:42:38 StandardManager[/primer]: Alimentation de la classe du 
générateur de nombre aléatoire java.security.SecureRandom
2002-12-04 17:42:38 StandardManager[/primer]: L'alimentation du générateur de 
nombre aléatoire est terminé
2002-12-04 17:42:38 StandardContext[/primer]: Le rechargement de ce contexte 
est terminé
2002-12-04 17:42:39 StandardContext[/primer]: Mapping contextPath='/primer' 
with requestURI='/primer/kix' and relativeURI='/kix'
2002-12-04 17:42:39 StandardContext[/primer]:   Trying exact match
2002-12-04 17:42:39 StandardContext[/primer]:  Mapped to servlet 'MyApp 
Executive' with servlet path '/kix' and path info 'null' and update=true
2002-12-04 17:42:39 StandardWrapperValve[MyApp Executive]: Exception lors de 
lallocation pour la servlet {0}
java.lang.NullPointerException
at org.apache.catalina.core.StandardWrapper.allocate
(StandardWrapper.java:686)
at org.apache.catalina.core.StandardWrapperValve.invoke
(StandardWrapperValve.java:214)
at 
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNex
t(StandardPipeline.java:643)
at org.apache.catalina.core.StandardPipeline.invoke
(StandardPipeline.java:480)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at org.apache.catalina.core.StandardContextValve.invoke
(StandardContextValve.java:191)
at 
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNex
t(StandardPipeline.java:643)
at org.apache.catalina.core.StandardPipeline.invoke
(StandardPipeline.java:480)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at org.apache.catalina.core.StandardContext.invoke
(StandardContext.java:2407)
at org.apache.catalina.core.StandardHostValve.invoke
(StandardHostValve.java:180)
at 
org.apa

Re: [RFC] Make jakarta-tomcat-catalina codebase common for both Tomcat4 and Tomcat 5

Remy Maucherat wrote:

Glenn Nielsen wrote:

With Tomcat 4.1 released many tomcat developers have been reticent to
add new features
to its codebase for a number of reasons. All the development going on
in Tomcat 5 and
wanting to keep the number of codebase's where bug fix patches have to
be applied to a
minimum.

There are alot of ideas for new features that I would like to see end
up in a Tomcat 4.2
release. Especially since we don't know when the Servlet 2.4/JSP 2.0
specs will be finalized
so that Tomcat 5 can be released.

There isn't that much difference in the core of catalina between the
Servlet 2.3 and
Servlet 2.4 specs. It might be possible to change the
jakarta-tomcat-catalina codebase
to make it neutral to what Servlet spec is implemented. Then this
codebase could be
used for future Tomcat 4 and Tomcat 5 development. And we then have a
common codebase
for applying bug fix patches.

This seems to fit in with the direction we have been going where
different components
are kept in different code bases. naming, connectors, jasper, etc.

Comments?

This is hard to do (Catalina has never been written to allow facades).
Also, for Tomcat 5, j-t-catalina is actually the Servlet 2.4 facade.

Right, I am aware of that. There isn't that much difference between Servlet 2.3
and Servlet 2.4. Having a common codebase for both would make addition of new
non spec related features easier and bug fix patching easier.

I'd like to point out that Jasper 2 from TC 5 is diverging from Jasper 2
from TC 4.1 very very quickly. Do you want a common codebase and some
facades for that too ? ;-)

No. The JSP 2 spec changes from JSP 1.2 are so extensive it doesn't make
sense to do so, also jasper is primarily implementing the JSP spec.
Whereas the core of catalina is where all the non spec related features get added.

Connectors is in common, because of the set of facades used in Coyote.

I have no interest in that project, and see no point in trying to extend
the life of the old API (given that the new one is quite similar).

-0 from me (ie, go ahead if there's some developer interest; of course,
implementation details will need to be discussed further).

Remy

There needs to be someplace where new features can be added to the Tocmat 4 branch.
You have been against adding new features to Tomcat 4 head, creating a Tocmat 4.2 branch for
developement, and now against making j-t-catalina common to both Tomcat 4 & 5.

If this is what you want then perhaps you should propose a VOTE to freeze all work on
Tomcat 4 except for bug fixes. And I mean all work. If the community votes to do that
then I will stop asking and perhaps go review the rules for revolutionaries.

Regards,

Glenn

--
To unsubscribe, e-mail:
For additional commands, e-mail:

Re: [RFC] Make jakarta-tomcat-catalina codebase common for both Tomcat4 and Tomcat 5

Remy Maucherat wrote:

Glenn Nielsen wrote:


With Tomcat 4.1 released many tomcat developers have been reticent to 
add new features
to its codebase for a number of reasons.  All the development going on 
in Tomcat 5 and
wanting to keep the number of codebase's where bug fix patches have to 
be applied to a
minimum.

There are alot of ideas for new features that I would like to see end 
up in a Tomcat 4.2
release. Especially since we don't know when the Servlet 2.4/JSP 2.0 
specs will be finalized
so that Tomcat 5 can be released.

There isn't that much difference in the core of catalina between the 
Servlet 2.3 and
Servlet 2.4 specs. It might be possible to change the 
jakarta-tomcat-catalina codebase
to make it neutral to what Servlet spec is implemented.  Then this 
codebase could be
used for future Tomcat 4 and Tomcat 5 development.  And we then have a 
common codebase
for applying bug fix patches.

This seems to fit in with the direction we have been going where 
different components
are kept in different code bases. naming, connectors, jasper, etc.

Comments?


This is hard to do (Catalina has never been written to allow facades). 
Also, for Tomcat 5, j-t-catalina is actually the Servlet 2.4 facade.

I'd like to point out that Jasper 2 from TC 5 is diverging from Jasper 2 
from TC 4.1 very very quickly. Do you want a common codebase and some 
facades for that too ? ;-)

Connectors is in common, because of the set of facades used in Coyote.

I have no interest in that project, and see no point in trying to extend 
the life of the old API (given that the new one is quite similar).

-0 from me (ie, go ahead if there's some developer interest; of course, 
implementation details will need to be discussed further).

I'd like to add that these comments only apply to a portion of the code 
in j-t-catalina. A significant amount of code is independent (the 
stores, the auth, the realms, etc, etc), and could be put in that 
legendary j-t-modules repository ;-)

I don't see how j-t-jasper could be independent of the API (nor the rest 
of j-t-catalina); at least not without a prohibitive amount of work.

Remy


--
To unsubscribe, e-mail:   
For additional commands, e-mail:

Re: [RFC] Make jakarta-tomcat-catalina codebase common for both Tomcat4 and Tomcat 5

Glenn Nielsen wrote:

With Tomcat 4.1 released many tomcat developers have been reticent to 
add new features
to its codebase for a number of reasons.  All the development going on 
in Tomcat 5 and
wanting to keep the number of codebase's where bug fix patches have to 
be applied to a
minimum.

There are alot of ideas for new features that I would like to see end up 
in a Tomcat 4.2
release. Especially since we don't know when the Servlet 2.4/JSP 2.0 
specs will be finalized
so that Tomcat 5 can be released.

There isn't that much difference in the core of catalina between the 
Servlet 2.3 and
Servlet 2.4 specs. It might be possible to change the 
jakarta-tomcat-catalina codebase
to make it neutral to what Servlet spec is implemented.  Then this 
codebase could be
used for future Tomcat 4 and Tomcat 5 development.  And we then have a 
common codebase
for applying bug fix patches.

This seems to fit in with the direction we have been going where 
different components
are kept in different code bases. naming, connectors, jasper, etc.

Comments?

This is hard to do (Catalina has never been written to allow facades). 
Also, for Tomcat 5, j-t-catalina is actually the Servlet 2.4 facade.

I'd like to point out that Jasper 2 from TC 5 is diverging from Jasper 2 
from TC 4.1 very very quickly. Do you want a common codebase and some 
facades for that too ? ;-)

Connectors is in common, because of the set of facades used in Coyote.

I have no interest in that project, and see no point in trying to extend 
the life of the old API (given that the new one is quite similar).

-0 from me (ie, go ahead if there's some developer interest; of course, 
implementation details will need to be discussed further).

Remy


--
To unsubscribe, e-mail:   
For additional commands, e-mail:

Re: [5.0] Cluster features

Costin Manolache wrote:

Remy Maucherat wrote:



Hi,

I think the clustering features in Tomcat 5 should get an overhaul.
Despite some licensing dicrepancies, I plan to use JavaGroups for the
task (LGPL license), as well as some code which was donated a while ago
by Filip Hanik. Based on what is already done, the amount of work that
will have to be done to have quality clustering features seems small.

Most of the current clustering API will be removed in the process, since
it doesn't seem to be maintained anymore, and didn't evolve past
experimental stage (if I am wrong on that, let me know).

I also plan to bundle JavaGroups with Tomcat 5, as it only adds a 1MB
standalone JAR. Configuring Tomcat for clustering will be quite easy
once all the code is in place.

I don't know if that plan is acceptable for everyone. Originally,
I -1ed the code submission because of licensing and absence of
integration with the existing Cluster API. The licensing issue is still
there, but since the Cluster API now seems sort of dead, another
solution has to be found (IMO, of course there's JK available).

Comments ?



+1 if all new code goes in a separate module ( instead of catalina ), 
and is built as separate .jar(s).

I think it is time to stop bloating the base tomcat source and binaries.

BTW, it may be a good time to move some of the current features in separate
modules as well. ( SSI, WebDAV, etc ). For webdav - I would rather see slide
bundled with tomcat and the current code deprecated.

I'm not talking ( for now ) about a real module with descriptors or 
anything, just separate dirs in the CVS and a .jar target that can be 
included or not. 

It may be worth reopening the "minimal tomcat" discussion :-)

Costin
 

+1 to Costin's comments




--
To unsubscribe, e-mail:   
For additional commands, e-mail:

[RFC] Make jakarta-tomcat-catalina codebase common for both Tomcat4 and Tomcat 5

With Tomcat 4.1 released many tomcat developers have been reticent to add new features
to its codebase for a number of reasons.  All the development going on in Tomcat 5 and
wanting to keep the number of codebase's where bug fix patches have to be applied to a
minimum.

There are alot of ideas for new features that I would like to see end up in a Tomcat 4.2
release. Especially since we don't know when the Servlet 2.4/JSP 2.0 specs will be finalized
so that Tomcat 5 can be released.

There isn't that much difference in the core of catalina between the Servlet 2.3 and
Servlet 2.4 specs. It might be possible to change the jakarta-tomcat-catalina codebase
to make it neutral to what Servlet spec is implemented.  Then this codebase could be
used for future Tomcat 4 and Tomcat 5 development.  And we then have a common codebase
for applying bug fix patches.

This seems to fit in with the direction we have been going where different components
are kept in different code bases. naming, connectors, jasper, etc.

Comments?

Regards,

Glenn


--
To unsubscribe, e-mail:   
For additional commands, e-mail:

Re: [VOTE] Making JMX required in tomcat5

+1

Costin Manolache wrote:

The subject should be clear. The benefit is that we'll be able 
to build more JMX awareness in the code without doing tricks - 
each component will know about its ObjectName and will be 
able to return ObjectName[].

I'm not proposing MBeans all over tomcat - modeler works very
well in transforming our components into model mbeans. 

We already have 3 +1 votes ( costin, Remy and Jean Francois ).

The only possible problem is the classical licensing issue
( we must use mx4j - but I don't know if they passed the TCK
or if they will or if the TCK is available yet, etc ).  

Costin



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 




--
To unsubscribe, e-mail:   
For additional commands, e-mail:

Jasper 2 Synchronized JSP compiles

I have some ideas on how invoking the javac compiler for compiling JSP pages can be
improved.  Currently Jasper 2 uses ant to do compiles from within Tomcat which are
synchronized.

There are currently several problems.

1. The known javac memory leak.

2. JSP page compiles are synchronized.

3. Jikes currently can't be configured for windows because the windows build of
   jikes doesn't support -encoding.

4. We may be getting some bug reports related to this problem noted in the Ant
   documentation for the javac task:

Windows Note:When the modern compiler is used in unforked mode on Windows, it locks up the files present in the 
classpath of the  task, and does not release them. The side effect of this is that you will not be able to delete 
or move those files later on in the build. The workaround is to fork when invoking the compiler.

Recommendation:

Change Jasper 2 so that it tells ant to fork the javac compile.  This should remove the need
to synchronize the compiles.  It will also move java compilation outside of the JVM process
Tomcat is running in saving JVM heap memory and reducing GC overhead from objects created for
JSP compiles.  This could be done by just adding another parameter called "fork" to the
JspServlet paramters. If fork=true ant forks the javac compile and no synchronization is done.
The default for fork would be false.

Comments?

Regards,

Glenn


--
To unsubscribe, e-mail:   
For additional commands, e-mail:

pushBody()/popBody() error on tomcat 4.1.12

2002-12-04 Thread Ismael Blesa Part

How it should work:

I am using bodytag that calls a pushBody(), then the current body writer
sould be kept and it should be createa a new one, later when I call the
popBody() the system should get the previous body (that is, the body
that has been kept on the call to pushBody())

What it does now:

All works as expected, but  after I call popBody() the new body writer
that has been created on the call to pushBody() writes its contents to
the previous body writer (that is, the body that has been kept on the
call to pushBody()). I think that the content should not been copied on
the other body writer.

It fails on Tomcat 4.1.12 and it works fine on Tomcat 4.0.X.


Cheers



--
To unsubscribe, e-mail:   
For additional commands, e-mail:

Re: [5] [Proposal] Adding an authorization interface

Sorry to be late commenting on this.  I have been busy with non Tomcat stuff.  I have
read most of the thread and just picked the original proposal to reply to.

I agree that authentication and authorization should be split out into separate
interfaces.

I also think it would be nice if the web server (especially Apache) could work
seemlessly with Tomcat realm based authentication for when you use Apache to
serve static content.  I think Costin raised this point.

I have some other issues with realm based authentication as currently implemented.

There are a number of different types of realm implementations in org.apache.catalina.realm.
These are all solely used for web application realm based authentication except for those
which implement the UserDatabase which understands users, groups, and roles and has methods
for managing these.  Also a UserDatabase can be instantiated as a JNDI resource.

It would be nice if all realm implementations could support not only authentication
and authorization but also management of users, groups, and roles.  And be instantiated
as a JNDI resource so it can be provided by the container as a resource to a virtual host.

This would allow adding support to the web application manager for user management so
that a virtual host could manage their own universe of users. Or even integrate this
into their own web application.

This would require extending the JndiPermission custom SecurityManager permission to
support read/write of a realm JNDI resource.  And putting the interfaces for using the
realms in a package such as org.apache.realm so that web applications can use the interface
for managing users without having to grant a RuntimePermission accessClassInPackage for
org.apache.catalina.realm.

Regards,

Glenn

Jeanfrancois Arcand wrote:

Hi,

I would like to propose the following re-factorisation of the current 
Realm interface. Righ now, Realm contains 3 methods related to 
authorization:

hasRole
hasUserDataPermission
hasResourcePermission

I would like to create a new interface called Authorizator(and a default 
AuthorizatorBase) that will take care of those methods. I just think 
those methods should be grouped together, and I think they are not 
directly related to the Realm "concepts" (better separation of 
concepts). It will allows peoples to change the current resource 
authorization mechanism without having to modify the Realm interface.

Precisely, the method will have the following signature:

   public boolean hasResourcePermission(HttpRequest request,
   
HttpResponse response,
   
SecurityConstraint constraint,
   Context 
context)
 public boolean hasRolePermission(HttpRequest request,
   HttpResponse 
response,
   String role);

   public boolean hasUserDataPermission(HttpRequest request,
HttpResponse response,
SecurityConstraint constraint,
Context context)

In the current implementation, those methods  will get invoked by the 
AuthenticatorBase and when the user call isUserInRole().

This factorisation will provide the ability to replace/extend the 
default AuthorizatorBase (that implement the Servlet 
 stuffs...section SRV 12.7) by another mechanism: 
LDAP, NFS, Database, File base, JSR 115, etc. This way peoples will be 
able to grant/denied permissions not only based on the web.xml content, 
but also using other technologies. Althrough it is possible to do that 
with the current Tomcat 5 codebase, I recommend we create this extra 
interface. For J2EE 1.4, I was able to implement JSR 115 without having 
to much problems, but I'm sure having a specialized interface will make 
implementation easier.

The Realm.hasRole will be deprecated in order to achieve that 
re-factorisation.

What do you think?

Thanks,

-- Jeanfrancois














--
To unsubscribe, e-mail:   

For additional commands, e-mail: 





--
To unsubscribe, e-mail:   
For additional commands, e-mail:

Re: Strange Tomcat 4.1.x release versions

I also had some questions about how releases are made a few weeks ago.
Since we voted to pattern the releases after httpd, then I guess we are
using this document as a guideline on how to release:

http://httpd.apache.org/dev/release.html

Glenn

Jon Scott Stevens wrote:

on 2002/12/3 11:51 AM, "Craig R. McClanahan" <[EMAIL PROTECTED]> wrote:



http://nagoya.apache.org/eyebrowse/ReadMsg?[EMAIL PROTECTED].
org&msgNo=52475

Someone obviously hasn't been keeping up on TOMCAT-DEV mail :-).

See the discussions and vote that took place in April 2003, where the
Tomcat developers agreed to adopt the version numbering approach that
Apache 2.0 (and several other projects) use.  A good starting point:

http://nagoya.apache.org/eyebrowse/ReadMsg?[EMAIL PROTECTED].
org&msgNo=39859



Ok, I understand the version number part now. I actually read those
discussions but forgot about them. Full brain.

But are you also saying that the HTTPd project doesn't announce on the list
in advance when a new release is going to happen?

-jon






--
To unsubscribe, e-mail:   
For additional commands, e-mail:

DO NOT REPLY [Bug 15032] - Headers get corrupted when used with mod_jk/mod_jk2 and apache 2.0.43

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://nagoya.apache.org/bugzilla/show_bug.cgi?id=15032

Headers get corrupted when used with mod_jk/mod_jk2 and apache 2.0.43





--- Additional Comments From [EMAIL PROTECTED]  2002-12-04 14:27 ---
Thanks to check with latest releases :

jk 1.2.1 or jk 2.0.2

--
To unsubscribe, e-mail:   
For additional commands, e-mail:

DO NOT REPLY [Bug 15065] - reuse of variables

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://nagoya.apache.org/bugzilla/show_bug.cgi?id=15065

reuse of variables

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID



--- Additional Comments From [EMAIL PROTECTED]  2002-12-04 13:49 ---
pressed tab-enter to fast

--
To unsubscribe, e-mail:   
For additional commands, e-mail:

DO NOT REPLY [Bug 15066] New: - reuse of variables

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://nagoya.apache.org/bugzilla/show_bug.cgi?id=15066

reuse of variables

   Summary: reuse of variables
   Product: Tomcat 4
   Version: 4.1.16
  Platform: Other
OS/Version: Other
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Servlet & JSP API
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Using a code like this in jsp results in compile-errors:
---cut---
<%
if (bAnyVar == true)
{
%><%
%>TEST TRUE<%
}
else
{
%><%
%>TEST FALSE<%
}
%>
---cut---

For the first condition a "String sHrefString" declaration is generated in the 
Servlet.
For the second condition this declaration is missing (wrong reuse??)

--
To unsubscribe, e-mail:   
For additional commands, e-mail:

DO NOT REPLY [Bug 15065] New: - reuse of variables

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://nagoya.apache.org/bugzilla/show_bug.cgi?id=15065

reuse of variables

   Summary: reuse of variables
   Product: Tomcat 4
   Version: 4.1.16
  Platform: Other
OS/Version: Other
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Servlet & JSP API
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Using a code like this in jsp results in compile-errors:
...
<%

--
To unsubscribe, e-mail:   
For additional commands, e-mail:

patches to remove calls to setenv

2002-12-04 Thread Phil Hanna

Unless I'm mistaken, setenv.bat and setenv.sh were retired long ago. There are still 
calls to them in the following .bat and shell files:
 
catalina.bat
catalina.sh
jasper.bat
jasper.sh
jspc-using-launcher.bat
jspc-using-launcher.sh
shutdown-using-launcher.bat
shutdown-using-launcher.sh
startup-using-launcher.bat
startup-using-launcher.sh
tool-wrapper-using-launcher.bat
tool-wrapper-using-launcher.sh
tool-wrapper.bat
tool-wrapper.sh

The attached zip files contain diff -u patches for all these files.
 
 
 
 



catalina-setenv-diffs.zip
Description: catalina-setenv-diffs.zip


jasper-setenv-diffs.zip
Description: jasper-setenv-diffs.zip
--
To unsubscribe, e-mail:   
For additional commands, e-mail:

DO NOT REPLY [Bug 13040] - can't retrieve external context who's uri is a sub-dir of current context

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://nagoya.apache.org/bugzilla/show_bug.cgi?id=13040

can't retrieve external context who's uri is a sub-dir of current context





--- Additional Comments From [EMAIL PROTECTED]  2002-12-04 12:29 ---
This is a serious bug that needs to be fixed.
I agree that the last patch submited by Martin Algesten lookes nice.

Please add it yo the CVS tree.
Thanks!

Christer Grimsæth

--
To unsubscribe, e-mail:   
For additional commands, e-mail:

pushBody()/popBody() error

2002-12-04 Thread Ismael Blesa Part

How it should work:

I am using bodytag that calls a pushBody(), then the current body writer 
sould be kept and it should be createa a new one, later when I call the 
popBody() the system should get the previous body (that is, the body 
that has been kept on the call to pushBody())

What it does now:

All works as expected, but  after I call popBody() the new body writer 
that has been created on the call to pushBody() writes its contents to 
the previous body writer (that is, the body that has been kept on the 
call to pushBody()). I think that the content should not been copied on 
the other body writer.

It fails on Tomcat 4.1.12 and it works fine on Tomcat 4.0.X.


Cheers


--
To unsubscribe, e-mail:   
For additional commands, e-mail:

DO NOT REPLY [Bug 15054] - un able to update CONTEXT in webapps/admin

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://nagoya.apache.org/bugzilla/show_bug.cgi?id=15054

un able to update CONTEXT in webapps/admin

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WORKSFORME



--- Additional Comments From [EMAIL PROTECTED]  2002-12-04 10:22 ---
Editing contexts works fine for me with more recent builds. I don't know for
sure about 4.1.12.

--
To unsubscribe, e-mail:   
For additional commands, e-mail:

cvs commit: jakarta-tomcat-connectors/jk/native/apache-2.0 bldjk.qclsrc

2002-12-04 Thread hgomez

hgomez  2002/12/04 02:12:04

  Modified:jk/native/apache-2.0 bldjk.qclsrc
  Log:
  Link phase should also use the TERASPACE model
  
  Revision  ChangesPath
  1.4   +1 -0  jakarta-tomcat-connectors/jk/native/apache-2.0/bldjk.qclsrc
  
  Index: bldjk.qclsrc
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/apache-2.0/bldjk.qclsrc,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- bldjk.qclsrc  3 Dec 2002 17:50:29 -   1.3
  +++ bldjk.qclsrc  4 Dec 2002 10:12:04 -   1.4
  @@ -280,6 +280,7 @@
 SRCFILE(MOD_JK/QSRVSRC)+
 SRCMBR(MOD_JK) +
 DETAIL(*BASIC) +
  +  STGMDL(*TERASPACE) +
 BNDSRVPGM(QHTTPSVR/QZSRAPR QHTTPSVR/QZSRCORE   +
   QHTTPSVR/QZSRXMLP QHTTPSVR/QZSRSDBM) +
 TEXT('Apache mod_jk tomcat connector module')
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail:

DO NOT REPLY [Bug 15054] New: - un able to update CONTEXT in webapps/admin

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://nagoya.apache.org/bugzilla/show_bug.cgi?id=15054

un able to update CONTEXT in webapps/admin

   Summary: un able to update CONTEXT in webapps/admin
   Product: Tomcat 4
   Version: 4.1.12
  Platform: PC
OS/Version: Windows XP
Status: NEW
  Severity: Major
  Priority: Other
 Component: Webapps:Administration
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


when i log into my "admin" page, i cannot change some of the default CONTEXT 
settings because they are blank, and the XML/XSL transformer doesn't seem to 
create a text field if there is no NODE for it in the XML.  as well, once i go 
into the ADMIN page, i can no longer modify my XML setting files.  meaning i 
cannot manually correct for this problem.  as well, i cannot seem to 
add/remove contexts.  it had some contexts that it ported from my old 
Tomcat/WebApps (4.0.40), but i could not delete unwanted ones and coule not 
create new ones (mostly because i could not modify XML anymore).  good luck 
with that.

--
To unsubscribe, e-mail:   
For additional commands, e-mail:

DO NOT REPLY [Bug 15053] - Examples must be installed

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://nagoya.apache.org/bugzilla/show_bug.cgi?id=15053

Examples must be installed

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID



--- Additional Comments From [EMAIL PROTECTED]  2002-12-04 09:51 ---
It has been fixed in 4.1.16. Please do not file duplicates.
You can also easily work around this by removing the section in server.xml about
the examples webapp.

--
To unsubscribe, e-mail:   
For additional commands, e-mail:

DO NOT REPLY [Bug 15053] New: - Examples must be installed

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://nagoya.apache.org/bugzilla/show_bug.cgi?id=15053

Examples must be installed

   Summary: Examples must be installed
   Product: Tomcat 4
   Version: 4.1.12
  Platform: PC
OS/Version: Windows XP
Status: UNCONFIRMED
  Severity: Blocker
  Priority: Other
 Component: Webapps:Examples
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


under the installation options, you have to accept the examples installer, or 
the default (server.xml) cannot run catalina.  it crashes complaining that 
there is no example folder.  hmmm, well, i chose not to install it for a 
reason.  anyway, good luck with that.  works on my previous version of tomcat 
(4.0.40).

--
To unsubscribe, e-mail:   
For additional commands, e-mail:

DO NOT REPLY [Bug 15052] New: - ODBC bridge corrupt under NT service