date:20020826

DO NOT REPLY [Bug 12017] - Use of JNI in beans leads to an invalid state, requires Tomcat restart

2002-08-26 Thread bugzilla


DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12017.
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=12017

Use of JNI in beans leads to an invalid state, requires Tomcat restart

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WONTFIX



--- Additional Comments From [EMAIL PROTECTED]  2002-08-26 07:40 ---
It is your responability to only load the library once.

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

cvs commit: jakarta-tomcat-5 build.properties.default

2002-08-26 Thread remm


remm2002/08/26 01:12:11

  Modified:.build.properties.default
  Log:
  - Update to beanutils 1.4.1.
  
  Revision  ChangesPath
  1.33  +3 -3  jakarta-tomcat-5/build.properties.default
  
  Index: build.properties.default
  ===
  RCS file: /home/cvs/jakarta-tomcat-5/build.properties.default,v
  retrieving revision 1.32
  retrieving revision 1.33
  diff -u -r1.32 -r1.33
  --- build.properties.default  25 Aug 2002 19:34:55 -  1.32
  +++ build.properties.default  26 Aug 2002 08:12:11 -  1.33
  @@ -49,10 +49,10 @@
   
   
   # - Commons Beanutils, version 1.4 or later -
  -commons-beanutils.home=${base.path}/commons-beanutils-1.4
  +commons-beanutils.home=${base.path}/commons-beanutils-1.4.1
   commons-beanutils.lib=${commons-beanutils.home}
   commons-beanutils.jar=${commons-beanutils.lib}/commons-beanutils.jar
  
-commons-beanutils.loc=http://jakarta.apache.org/builds/jakarta-commons/release/commons-beanutils/v1.4/commons-beanutils-1.4.tar.gz
  
+commons-beanutils.loc=http://jakarta.apache.org/builds/jakarta-commons/release/commons-beanutils/v1.4.1/commons-beanutils-1.4.1.tar.gz
   
   
   # - Commons Collections, version 2.0 or later -
  
  
  

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

cvs commit: jakarta-tomcat-connectors/jk/native2/include jk_service.h

2002-08-26 Thread remm


remm2002/08/26 02:54:35

  Modified:jk/java/org/apache/ajp RequestHandler.java
   jk/java/org/apache/jk/common HandlerRequest.java
   jk/native/common jk_ajp_common.c jk_ajp_common.h
   jk/native2/common jk_requtil.c
   jk/native2/include jk_service.h
  Log:
  - Add JK and JK 2 support for advanced Delta V methods (no logic change, but
let me know if it causes problems) needed for Slide 2.0.
  - Patch submitted by Peter Nevermann Peter.Nevermann at softwareag.com
  
  Revision  ChangesPath
  1.16  +7 -1  
jakarta-tomcat-connectors/jk/java/org/apache/ajp/RequestHandler.java
  
  Index: RequestHandler.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/jk/java/org/apache/ajp/RequestHandler.java,v
  retrieving revision 1.15
  retrieving revision 1.16
  diff -u -r1.15 -r1.16
  --- RequestHandler.java   15 Jun 2002 01:52:47 -  1.15
  +++ RequestHandler.java   26 Aug 2002 09:54:34 -  1.16
  @@ -154,7 +154,13 @@
   CHECKIN,
   CHECKOUT,
   UNCHECKOUT,
  -SEARCH
  +SEARCH,
  +MKWORKSPACE,
  +UPDATE,
  +LABEL,
  +MERGE,
  +BASELINE-CONTROL,
  +MKACTIVITY
   };
   
   // id's for common request headers
  
  
  
  1.15  +7 -1  
jakarta-tomcat-connectors/jk/java/org/apache/jk/common/HandlerRequest.java
  
  Index: HandlerRequest.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/jk/java/org/apache/jk/common/HandlerRequest.java,v
  retrieving revision 1.14
  retrieving revision 1.15
  diff -u -r1.14 -r1.15
  --- HandlerRequest.java   1 Jun 2002 08:29:34 -   1.14
  +++ HandlerRequest.java   26 Aug 2002 09:54:34 -  1.15
  @@ -165,7 +165,13 @@
   CHECKIN,
   CHECKOUT,
   UNCHECKOUT,
  -SEARCH
  +SEARCH,
  +MKWORKSPACE,
  +UPDATE,
  +LABEL,
  +MERGE,
  +BASELINE-CONTROL,
  +MKACTIVITY
   };
   
   // id's for common request headers
  
  
  
  1.28  +13 -1 jakarta-tomcat-connectors/jk/native/common/jk_ajp_common.c
  
  Index: jk_ajp_common.c
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/common/jk_ajp_common.c,v
  retrieving revision 1.27
  retrieving revision 1.28
  diff -u -r1.27 -r1.28
  --- jk_ajp_common.c   2 Jul 2002 16:51:08 -   1.27
  +++ jk_ajp_common.c   26 Aug 2002 09:54:34 -  1.28
  @@ -142,6 +142,18 @@
   *sc = SC_M_UNCHECKOUT;
   } else if(0 == strcmp(method, SEARCH)) {
   *sc = SC_M_SEARCH;
  +} else if(0 == strcmp(method, MKWORKSPACE)) {
  +*sc = SC_M_MKWORKSPACE;
  +} else if(0 == strcmp(method, UPDATE)) {
  +*sc = SC_M_UPDATE;
  +} else if(0 == strcmp(method, LABEL)) {
  +*sc = SC_M_LABEL;
  +} else if(0 == strcmp(method, MERGE)) {
  +*sc = SC_M_MERGE;
  +} else if(0 == strcmp(method, BASELINE-CONTROL)) {
  +*sc = SC_M_BASELINE_CONTROL;
  +} else if(0 == strcmp(method, MKACTIVITY)) {
  +*sc = SC_M_MKACTIVITY;
   } else {
   rc = JK_FALSE;
   }
  
  
  
  1.16  +14 -2 jakarta-tomcat-connectors/jk/native/common/jk_ajp_common.h
  
  Index: jk_ajp_common.h
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/common/jk_ajp_common.h,v
  retrieving revision 1.15
  retrieving revision 1.16
  diff -u -r1.15 -r1.16
  --- jk_ajp_common.h   25 Jun 2002 07:07:31 -  1.15
  +++ jk_ajp_common.h   26 Aug 2002 09:54:34 -  1.16
  @@ -116,6 +116,12 @@
*| CHECKOUT
*| UNCHECKOUT
*| SEARCH
  + *| MKWORKSPACE
  + *| UPDATE
  + *| LABEL
  + *| MERGE
  + *| BASELINE-CONTROL
  + *| MKACTIVITY
* 
*/
   #define SC_M_OPTIONS(unsigned char)1
  @@ -132,13 +138,19 @@
   #define SC_M_MOVE   (unsigned char)12
   #define SC_M_LOCK   (unsigned char)13
   #define SC_M_UNLOCK (unsigned char)14
  -#define SC_M_ACL(unsigned char)15
  +#define SC_M_ACL(unsigned char)15
   #define SC_M_REPORT (unsigned char)16
   #define SC_M_VERSION_CONTROL(unsigned char)17
   #define SC_M_CHECKIN(unsigned char)18
   #define SC_M_CHECKOUT   (unsigned char)19
   #define SC_M_UNCHECKOUT (unsigned char)20
   #define SC_M_SEARCH (unsigned char)21
  +#define SC_M_MKWORKSPACE(unsigned char)22
  +#define SC_M_UPDATE

cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core StandardContext.java

2002-08-26 Thread glenn


glenn   2002/08/26 05:15:59

  Modified:catalina/src/share/org/apache/catalina/connector
RequestBase.java
   catalina/src/share/org/apache/catalina/core
StandardContext.java
  Log:
  Fix for BUG 11947.  Change where startCapture/stopCapture is invoked to
  prevent memory leaks from the SystemLogHandler.
  
  Revision  ChangesPath
  1.21  +4 -10 
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/RequestBase.java
  
  Index: RequestBase.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/RequestBase.java,v
  retrieving revision 1.20
  retrieving revision 1.21
  diff -u -r1.20 -r1.21
  --- RequestBase.java  27 May 2002 13:34:34 -  1.20
  +++ RequestBase.java  26 Aug 2002 12:15:58 -  1.21
  @@ -91,7 +91,6 @@
   import org.apache.catalina.util.Enumerator;
   import org.apache.catalina.util.RequestUtil;
   import org.apache.catalina.util.StringManager;
  -import org.apache.tomcat.util.log.SystemLogHandler;
   
   
   /**
  @@ -340,7 +339,6 @@
   
   this.context = context;
   
  -SystemLogHandler.startCapture();
   }
   
   
  @@ -559,10 +557,6 @@
*/
   public void recycle() {
   
  -String log = SystemLogHandler.stopCapture();
  -if (log != null  log.length()  0) {
  -context.getServletContext().log(log);
  -}
   attributes.clear();
   authorization = null;
   characterEncoding = null;
  
  
  
  1.110 +15 -5 
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/StandardContext.java
  
  Index: StandardContext.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/StandardContext.java,v
  retrieving revision 1.109
  retrieving revision 1.110
  diff -u -r1.109 -r1.110
  --- StandardContext.java  28 Jun 2002 16:09:57 -  1.109
  +++ StandardContext.java  26 Aug 2002 12:15:59 -  1.110
  @@ -138,6 +138,7 @@
   import org.apache.catalina.session.StandardManager;
   import org.apache.catalina.util.CharsetMapper;
   import org.apache.catalina.util.RequestUtil;
  +import org.apache.tomcat.util.log.SystemLogHandler;
   
   
   /**
  @@ -2347,7 +2348,16 @@
   }
   
   // Normal request processing
  -super.invoke(request, response);
  +try {
  +SystemLogHandler.startCapture();
  +super.invoke(request, response);
  +} finally {
  +String log = SystemLogHandler.stopCapture();
  +if (log != null  log.length()  0) {
  +log(log);
  +}
  +
  +}
   
   }
   
  
  
  

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

DO NOT REPLY [Bug 12017] - Use of JNI in beans leads to an invalid state, requires Tomcat restart

2002-08-26 Thread bugzilla


DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12017.
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=12017

Use of JNI in beans leads to an invalid state, requires Tomcat restart





--- Additional Comments From [EMAIL PROTECTED]  2002-08-26 13:02 ---
Request for clarification: how is this accomplished?

All I have in my code is:

static
{
  System.loadLibrary()
}

  Why would this ever execute more than once per JVM session? What is the
correct way of doing this?

Thanks,
Gili

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

DO NOT REPLY [Bug 12041] New: - CGIServlet can block on input

2002-08-26 Thread bugzilla


DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12041.
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=12041

CGIServlet can block on input

   Summary: CGIServlet can block on input
   Product: Tomcat 4
   Version: 4.1.9
  Platform: Sun
OS/Version: Solaris
Status: NEW
  Severity: Major
  Priority: Other
 Component: Servlets:CGI
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


I've got some legacy Perl CGI scripts which I wanted to run under Tomcat 4.1.x. 
After some debugging I discovered that the CGIServlet code would first try to
read all the stderr input before trying to read stdout.

This doesn't work on at least Solaris 7 under JDK 1.3, because the stderr handle
doesn't seem to get closed, so the code hangs trying to read stderr.

However, this approach seems like it would have problems in the case of a CGI
script which prints a large amount of data to stdout; while the CGIServlet was
waiting for the end of stderr, the CGI script would fill up the stdout buffer
and then wait for it to be drained, causing a deadlock between the two
processes.

The patch below seems to get around this problem by having a single loop which
reads stderr if it's ready, or stdout if ready.  If neither handle has queued
data and the CGI script has exited, the servlet pauses a couple of times for
half a second to make sure that all output has been delivered, then it exits.

Here's the patch:

Index: CGIServlet.java
===
RCS file: /home/cvspublic/jakarta-tomcat-4.0/catalina/src/share/org/apache/catal
ina/servlets/CGIServlet.java,v
retrieving revision 1.7
diff -u -3 -p -r1.7 CGIServlet.java
--- CGIServlet.java 20 Sep 2001 23:48:13 -  1.7
+++ CGIServlet.java 26 Aug 2002 14:27:27 -
@@ -1663,7 +1663,6 @@ public class CGIServlet extends HttpServ
  *   bugParade/bugs/4223650.html
  */
 
-boolean isRunning = true;
 commandsStdOut = new BufferedReader
 (new InputStreamReader(proc.getInputStream()));
 commandsStdErr = new BufferedReader
@@ -1680,64 +1679,94 @@ public class CGIServlet extends HttpServ
 //NOOP: no output will be written
 }
 
+boolean inHeader = true;
+int pauseCount = 0;
+
+boolean isRunning = true;
 while (isRunning) {
 
-try {
-//read stderr first
-cBuf = new char[1024];
-while ((bufRead = commandsStdErr.read(cBuf)) != -1) {
+if (commandsStdErr != null  commandsStdErr.ready()) {
+// about to read something; reset pause count
+pauseCount = 0;
+
+bufRead = commandsStdErr.read(cBuf);
+if (bufRead == -1) {
+commandsStdErr.close();
+commandsStdErr = null;
+isRunning = (commandsStdOut != null);
+} else {
 if (servletContainerStdout != null) {
-servletContainerStdout.write(cBuf, 0, bufRead);
+if (inHeader) {
+servletContainerStdout.write(cBuf, 0, bufRead);
+} else {
+log(runCGI: Throwing away StdErr \ +
+new String(cBuf, 0, bufRead) + \);
+}
 }
 }
-
-//set headers
-String line = null;
-while (((line = commandsStdOut.readLine()) != null)
-!(.equals(line))) {
-if (debug = 2) {
-log(runCGI: addHeader(\ + line + \));
+} else if (commandsStdOut != null  commandsStdOut.ready()) {
+// about to read something; reset pause count
+pauseCount = 0;
+
+if (inHeader) {
+//set headers
+String line = commandsStdOut.readLine();
+if (line == null || .equals(line)) {
+inHeader = false;
+} else {
+if (debug = 2) {
+log(runCGI: addHeader(\ + line + \));
+}
+if (line.startsWith(HTTP)) {
+//TODO: should set status codes (NPH support)
+/*
+

cvs commit: jakarta-servletapi-5/jsr154/src/share/javax/servlet ServletRequestEvent.java

2002-08-26 Thread patrickl


patrickl2002/08/26 09:05:56

  Modified:jsr154/src/share/javax/servlet ServletRequestEvent.java
  Log:
  Correct method name to match current specification draft
  
  Revision  ChangesPath
  1.2   +1 -1  
jakarta-servletapi-5/jsr154/src/share/javax/servlet/ServletRequestEvent.java
  
  Index: ServletRequestEvent.java
  ===
  RCS file: 
/home/cvs/jakarta-servletapi-5/jsr154/src/share/javax/servlet/ServletRequestEvent.java,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- ServletRequestEvent.java  13 Aug 2002 16:21:42 -  1.1
  +++ ServletRequestEvent.java  26 Aug 2002 16:05:56 -  1.2
  @@ -86,7 +86,7 @@
 *
 * @return the ServletRequest that sent the event.
 */
  -public ServletRequest getServletRequest () { 
  +public ServletRequest getRequest () { 
   return this.request;
   }
   
  
  
  

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

DO NOT REPLY [Bug 11197] - Filters and JSP.3.2

2002-08-26 Thread bugzilla


DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11197.
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=11197

Filters and JSP.3.2

[EMAIL PROTECTED] changed:

   What|Removed |Added

  Component|Jasper  |Catalina

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

DO NOT REPLY [Bug 11271] - Filter was ignored while using FORM authentication?

2002-08-26 Thread bugzilla


DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11271.
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=11271

Filter was ignored while using FORM authentication?

[EMAIL PROTECTED] changed:

   What|Removed |Added

  Component|Jasper  |Catalina

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

DO NOT REPLY [Bug 12046] New: - Reloading of tag files when modified

2002-08-26 Thread bugzilla


DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12046.
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=12046

Reloading of tag files when modified

   Summary: Reloading of tag files when modified
   Product: Tomcat 5
   Version: Unknown
  Platform: All
OS/Version: Other
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Jasper2
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


If a jsp  ( foo.jsp) refers to a tag defined by a tag file (footag.tag) , and
footag.tag is modified after foo.jsp has been compiled ,the footag.tag is not
recompiled and loaded again.
The foo.jsp needs to be recompiled again for these changes to take effect.

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

DO NOT REPLY [Bug 12049] New: - jsp:include does not resolve symlinked directory

2002-08-26 Thread bugzilla


DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12049.
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=12049

jsp:include does not resolve symlinked directory

   Summary: jsp:include does not resolve symlinked directory
   Product: Tomcat 4
   Version: 4.1.9
  Platform: PC
OS/Version: Linux
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Jasper 2
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


We have some shared pages under a centralized directory, which is symlinked.
It seems jsp:include does not see pages under a symlinked dir, not exception
is thrown, it simply ignores the include. Change the directory to a usual
file directory makes it work.

This is probably due to the fact that jasper2 does not properly resolve
canonical path and claimed to be fixed, but does not seem so.

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

DO NOT REPLY [Bug 11822] - Spaces in url causes Jasper to fail.

2002-08-26 Thread bugzilla


DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11822.
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=11822

Spaces in url causes Jasper to fail.

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID



--- Additional Comments From [EMAIL PROTECTED]  2002-08-26 17:32 ---
Space is not allowed in url.

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

DO NOT REPLY [Bug 11953] - scratchdir cannot be relative

2002-08-26 Thread bugzilla


DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11953.
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=11953

scratchdir cannot be relative

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WONTFIX



--- Additional Comments From [EMAIL PROTECTED]  2002-08-26 17:37 ---
By design, scratchdir has to be absolute.  The classloader in jasper won;t work
otherwise.

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

DO NOT REPLY [Bug 12052] New: - mod_jk sets wrong port (uses socket port, not user specified port)

2002-08-26 Thread bugzilla


DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12052.
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=12052

mod_jk sets wrong port (uses socket port, not user specified port)

   Summary: mod_jk sets wrong port (uses socket port, not user
specified port)
   Product: Tomcat 4
   Version: 4.0.4 Final
  Platform: All
OS/Version: All
Status: NEW
  Severity: Major
  Priority: Other
 Component: Connector:JK/AJP (deprecated)
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


request.getServerPort() currently returns the socket port instead
of the port specified by the user.  (These can be different if a 
load balancer or firewall is redirecting ports.)


See line 465 of mod_jk.c (Revision 1.26)

My C code is a bit rusty, but I replaced that line:

s-server_port = htons( r-connection-local_addr.sin_port );

with:

/* Pick default values for port of 80/443.  */
/* Then use the values from HOST header if they are available. */

{
const char *host_header;
int port = 80;  /* good default if no HOST header */
int is_ssl = 0;
char parsed_server[256];
int parsed=0;
host_header = ap_table_get(r-headers_in, Host);
if(conf-ssl_enable) {
char *ssl_temp;
ssl_temp = (char *)ap_table_get(r-subprocess_env,
conf-https_indicator);
if(ssl_temp  !strcasecmp(ssl_temp, on)) {
is_ssl = 1;
port = 443;   /* good default if no HOST hdr and ssl */
}
}

if (host_header)/* get the port from Host: if possible */
{
int tmp_port;
const char *s = strchr(host_header, ':');
if (s != NULL) {
++s;/* past the colon */
if (sscanf (s,%d, tmp_port) == 1) port = tmp_port;
}
}

/** set the good port value */
s-server_port = port;
}

By the way, I believe the Apache VirtualHost logic has the same problem.

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

DO NOT REPLY [Bug 11942] - reassignment of variables to pagecontext attributes in body loop

2002-08-26 Thread bugzilla


DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11942.
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=11942

reassignment of variables to pagecontext attributes in body loop

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID



--- Additional Comments From [EMAIL PROTECTED]  2002-08-26 20:07 ---
Note that the body is evaluated, and doAfterBody() is called (to determine
whether the body needs to be reevaluated), *only if* if a body present. 

Therefore, the servlet code fragment you listed below is generated only if the
tag handler in question implements IterationTag (this condition is true if the
tag handler extends TagSupport or any of its subclasses, such as BodyTagSupport)
*and* is non-empty.

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

DO NOT REPLY [Bug 11947] - Memory leak of CaptureLog objects

2002-08-26 Thread bugzilla


DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11947.
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=11947

Memory leak of CaptureLog objects

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2002-08-26 20:28 ---
I have committed a patch to CVS for this bug.  It should be available
tomorrow after the nightly build.

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

DO NOT REPLY [Bug 11942] - reassignment of variables to pagecontext attributes in body loop

2002-08-26 Thread bugzilla


DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11942.
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=11942

reassignment of variables to pagecontext attributes in body loop

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|INVALID |



--- Additional Comments From [EMAIL PROTECTED]  2002-08-26 20:32 ---
Actually, I just realized the issue you brought up is valid, and is a duplicate
of http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11552 (Iteration tags do
not resynchronize scripting variables after doAfterBody()). See my evaluation
of the second part of that bug.

I am still trying to seek clarification on this issue from the spec leads.

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

DO NOT REPLY [Bug 12053] New: - Manager is not allowed to reset/start/stop the root context

2002-08-26 Thread bugzilla


DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12053.
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=12053

Manager is not allowed to reset/start/stop the root context

   Summary: Manager is not allowed to reset/start/stop the root
context
   Product: Tomcat 4
   Version: 4.1.9
  Platform: PC
OS/Version: Linux
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


The manager cannot reset/start/stop the root context

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

cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/mbeans MBeanFactory.java

2002-08-26 Thread amyroh


amyroh  2002/08/26 14:06:27

  Modified:catalina/src/share/org/apache/catalina/mbeans
MBeanFactory.java
  Log:
  Update createConnector methods to work with Tomcat 5 connectors.
  
  Revision  ChangesPath
  1.3   +8 -8  
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/mbeans/MBeanFactory.java
  
  Index: MBeanFactory.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/mbeans/MBeanFactory.java,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- MBeanFactory.java 21 Aug 2002 08:18:20 -  1.2
  +++ MBeanFactory.java 26 Aug 2002 21:06:27 -  1.3
  @@ -254,7 +254,7 @@
   
   // Create a new CoyoteConnector instance for AJP
   // use reflection to avoid j-t-c compile-time circular dependencies
  -Class cls = Class.forName(org.apache.coyote.tomcat4.CoyoteConnector);
  +Class cls = Class.forName(org.apache.coyote.tomcat5.CoyoteConnector);
   Constructor ct = cls.getConstructor(null);
   retobj = ct.newInstance(null);
   Class partypes1 [] = new Class[1];
  @@ -393,7 +393,7 @@
   
   // Create a new CoyoteConnector instance
   // use reflection to avoid j-t-c compile-time circular dependencies
  -Class cls = Class.forName(org.apache.coyote.tomcat4.CoyoteConnector);
  +Class cls = Class.forName(org.apache.coyote.tomcat5.CoyoteConnector);
   Constructor ct = cls.getConstructor(null);
   retobj = ct.newInstance(null);
   Class partypes1 [] = new Class[1];
  @@ -448,7 +448,7 @@
   
   // Create a new CoyoteConnector instance
   // use reflection to avoid j-t-c compile-time circular dependencies
  -Class cls = Class.forName(org.apache.coyote.tomcat4.CoyoteConnector);
  +Class cls = Class.forName(org.apache.coyote.tomcat5.CoyoteConnector);
   Constructor ct = cls.getConstructor(null);
   retobj = ct.newInstance(null);
   Class partypes1 [] = new Class[1];
  @@ -484,7 +484,7 @@
   Class serverSocketFactoryCls =
   Class.forName(org.apache.catalina.net.ServerSocketFactory);
   Class coyoteServerSocketFactoryCls =
  -
Class.forName(org.apache.coyote.tomcat4.CoyoteServerSocketFactory);
  +
Class.forName(org.apache.coyote.tomcat5.CoyoteServerSocketFactory);
   Constructor factoryConst =
   coyoteServerSocketFactoryCls.getConstructor(null);
   Object factoryObj = factoryConst.newInstance(null);
  
  
  

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

DO NOT REPLY [Bug 11485] - Jasper2 caches tag library descriptors too long

2002-08-26 Thread bugzilla


DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11485.
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=11485

Jasper2 caches tag library descriptors too long

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WORKSFORME



--- Additional Comments From [EMAIL PROTECTED]  2002-08-26 21:27 ---
Craig,

If the tld mapping is defined in web.xml, and the mapping is changed, then
tomcat needs to be restarted; but that's because any change in web.xml requires
a restart of tomcat for it to take effect.  However, if web.xml is not modified,
or if the tld is specified in uri attribute of the taglib directive, then any
change in tld, as well as any change in the tag handlers referenced there, will
take effect when the page is recompiled.  Jasper only caches the tld mappings
defined in web.xml, and never the tlds themselves.  I have verified that with
some simple examples.

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

DO NOT REPLY [Bug 12056] New: - Startup scripts test for invalid permissions.

2002-08-26 Thread bugzilla


DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12056.
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=12056

Startup scripts test for invalid permissions.

   Summary: Startup scripts test for invalid permissions.
   Product: Tomcat 4
   Version: 4.0 Beta 3
  Platform: PC
OS/Version: Linux
Status: NEW
  Severity: Minor
  Priority: Other
 Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


In the file $CATALINA_HOME/bin/setclasspath.sh on line 13, and again on line 24 
the script incorrectly test for read permissions instead of execute.  Catalina 
should not at all be interrested in whether these files can be read, but 
rather, can they be executed.  As such -r should be replaced with -x.

For what it's worth, I'm running debian 3.0 (woody) and are using the tomcat4 
package thereof:
ii  tomcat44.0.3-3Java Servlet 2.3 engine with JSP 1.2 support

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

DO NOT REPLY [Bug 11485] - Jasper2 caches tag library descriptors too long

2002-08-26 Thread bugzilla


DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11485.
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=11485

Jasper2 caches tag library descriptors too long

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|WORKSFORME  |



--- Additional Comments From [EMAIL PROTECTED]  2002-08-26 21:53 ---
A particular use case that still fails for me is when you use the Manager webapp
(via the custom Ant tasks in my case) to remove a running app, change the TLD,
and then install that app again.  The changes in the TLD are not reflected
unless Tomcat is physically restarted.  This is not acceptable from a usability
point of view -- removing and re-installing an app should cause any existing TLD
information for that webapp to be flushed and reloaded, even if none of the JSP
pages that use it have changed.

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

Chuid - merging code from daemon into jk2

2002-08-26 Thread costinm



I would like to add the code dealing with 'chuid' from daemon into jk2. 
That will involve jk_user.c and a JkUser.java, using the regular jk 
communication. 

In order to change the uid from root to a regular user, you will add
 user.name=...
 user.group=...
in jk2.properties. 


I would also like to merge the code related with the services from
daemon - and combine it with the .properties-style used by the current
service code.  The 'launch jvm from C' code is very similar with what 
we already have, but it needs to be reviewed in case some feature
is not yet implemented. 

Comments ?

BTW, my vacation starts next week, and I'll have little or no email for 3 
weeks - but a lot of plane traveling. 

Costin



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

DO NOT REPLY [Bug 12059] New: - Resources tag causes startup to fail

2002-08-26 Thread bugzilla


DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12059.
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=12059

Resources tag causes startup to fail

   Summary: Resources tag causes startup to fail
   Product: Tomcat 4
   Version: 4.1.8
  Platform: Sun
OS/Version: Solaris
Status: NEW
  Severity: Major
  Priority: Other
 Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Entry in server.xml:
!-- tomcat root context --
  context path= docbase=root debug=9
  resources classname=org.apache.naming.resources.filedircontext 
cached=false/
  /context

Causes Catalina to look for a bogus docbase that does not and should not exist.

catalina.out log entry is:
java.lang.reflect.InvocationTargetException: 
java.lang.IllegalArgumentException: Document 
base /tilde/pier/asd/CopyOf11Jun02_4.1.8/tomcat/ROOT does not exist or is not a 
readable directory
at org.apache.naming.resources.FileDirContext.setDocBase
(FileDirContext.java:187)
at org.apache.catalina.core.StandardContext.setResources
(StandardContext.java:1113)
at java.lang.reflect.Method.invoke(Native Method)
at org.apache.commons.beanutils.MethodUtils.invokeMethod
(MethodUtils.java:216)
at org.apache.commons.digester.SetNextRule.end(SetNextRule.java:260)
at org.apache.commons.digester.Digester.endElement(Digester.java:830)
at org.apache.xerces.parsers.AbstractSAXParser.endElement
(AbstractSAXParser.java:559)
at org.apache.xerces.parsers.AbstractXMLDocumentParser.emptyElement
(AbstractXMLDocumentParser.java:217)
at org.apache.xerces.impl.XMLNamespaceBinder.emptyElement
(XMLNamespaceBinder.java:594)
at org.apache.xerces.impl.dtd.XMLDTDValidator.emptyElement
(XMLDTDValidator.java:817)
at 
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanStartElement
(XMLDocumentFragmentScannerImpl.java:748)
at 
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.
dispatch(XMLDocumentFragmentScannerImpl.java:1454)
at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument
(XMLDocumentFragmentScannerImpl.java:333)
at org.apache.xerces.parsers.StandardParserConfiguration.parse
(StandardParserConfiguration.java:529)
at org.apache.xerces.parsers.StandardParserConfiguration.parse
(StandardParserConfiguration.java:585)
at org.apache.xerces.parsers.XMLParser.parse(XMLParser.java:147)
at org.apache.xerces.parsers.AbstractSAXParser.parse
(AbstractSAXParser.java:1148)
at org.apache.commons.digester.Digester.parse(Digester.java:1284)
at org.apache.catalina.startup.Catalina.start(Catalina.java:449)
at org.apache.catalina.startup.Catalina.execute(Catalina.java:400)
at org.apache.catalina.startup.Catalina.process(Catalina.java:180)
at java.lang.reflect.Method.invoke(Native Method)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:203)
[ERROR] Digester - -End event threw exception 
java.lang.reflect.InvocationTargetException
Catalina.start: java.lang.reflect.InvocationTargetException
java.lang.reflect.InvocationTargetException
at org.apache.commons.digester.Digester.createSAXException
(Digester.java:2033)
at org.apache.commons.digester.Digester.createSAXException
(Digester.java:2053)
at org.apache.commons.digester.Digester.endElement(Digester.java:833)
at org.apache.xerces.parsers.AbstractSAXParser.endElement
(AbstractSAXParser.java:559)
at org.apache.xerces.parsers.AbstractXMLDocumentParser.emptyElement
(AbstractXMLDocumentParser.java:217)
at org.apache.xerces.impl.XMLNamespaceBinder.emptyElement
(XMLNamespaceBinder.java:594)
at org.apache.xerces.impl.dtd.XMLDTDValidator.emptyElement
(XMLDTDValidator.java:817)
at 
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanStartElement
(XMLDocumentFragmentScannerImpl.java:748)
at 
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.
dispatch(XMLDocumentFragmentScannerImpl.java:1454)
at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument
(XMLDocumentFragmentScannerImpl.java:333)
at org.apache.xerces.parsers.StandardParserConfiguration.parse
(StandardParserConfiguration.java:529)
at org.apache.xerces.parsers.StandardParserConfiguration.parse
(StandardParserConfiguration.java:585)
at org.apache.xerces.parsers.XMLParser.parse(XMLParser.java:147)
at org.apache.xerces.parsers.AbstractSAXParser.parse
(AbstractSAXParser.java:1148)
at org.apache.commons.digester.Digester.parse(Digester.java:1284)
at

cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets CGIServlet.java

2002-08-26 Thread amyroh


amyroh  2002/08/26 15:38:35

  Modified:catalina/src/share/org/apache/catalina/servlets
CGIServlet.java
  Log:
  CGIServlet had problems in the case of a CGI script which prints a large
  amount of data to stdout; while the CGIServlet was waiting for the end of
  stderr, the CGI script would fill up the stdout buffer and then wait for it to be
  drained, causing a deadlock between the two processes.
  
  This patch solves this problem by having a single loop which
  reads stderr if it's ready, or stdout if ready.  If neither handle has queued
  data and the CGI script has exited, the servlet pauses a couple of times for
  half a second to make sure that all output has been delivered, then it exits.
  
  Fixes Bug 12041.  Patch submitted by Dave Glowacki ([EMAIL PROTECTED])
  
  Revision  ChangesPath
  1.8   +84 -51
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.7
  retrieving revision 1.8
  diff -u -r1.7 -r1.8
  --- CGIServlet.java   20 Sep 2001 23:48:13 -  1.7
  +++ CGIServlet.java   26 Aug 2002 22:38:35 -  1.8
  @@ -1507,9 +1507,9 @@
* /UL
* /p
*
  - * For more information, see java.lang.Runtime#exec(String command, 
  + * For more information, see java.lang.Runtime#exec(String command,
* String[] envp, File dir)
  - * 
  + *
* @exception IOException if problems during reading/writing occur
*
*/
  @@ -1663,7 +1663,6 @@
*   bugParade/bugs/4223650.html
*/
   
  -boolean isRunning = true;
   commandsStdOut = new BufferedReader
   (new InputStreamReader(proc.getInputStream()));
   commandsStdErr = new BufferedReader
  @@ -1680,63 +1679,97 @@
   //NOOP: no output will be written
   }
   
  +boolean inHeader = true;
  +int pauseCount = 0;
  +
  +boolean isRunning = true;
  +
   while (isRunning) {
   
  -try {
  -//read stderr first
  -cBuf = new char[1024];
  -while ((bufRead = commandsStdErr.read(cBuf)) != -1) {
  +if (commandsStdErr != null  commandsStdErr.ready()) {
  +// about to read something; reset pause count
  +pauseCount = 0;
  +
  +bufRead = commandsStdErr.read(cBuf);
  +if (bufRead == -1) {
  +commandsStdErr.close();
  +commandsStdErr = null;
  +isRunning = (commandsStdOut != null);
  +} else {
   if (servletContainerStdout != null) {
  -servletContainerStdout.write(cBuf, 0, bufRead);
  +if (inHeader) {
  +servletContainerStdout.write(cBuf, 0, bufRead);
  +} else {
  +log(runCGI: Throwing away StdErr \ +
  +new String(cBuf, 0, bufRead) + \);
  +}
   }
   }
  -
  -//set headers
  -String line = null;
  -while (((line = commandsStdOut.readLine()) != null)
  -!(.equals(line))) {
  -if (debug = 2) {
  -log(runCGI: addHeader(\ + line + \));
  -}
  -if (line.startsWith(HTTP)) {
  -//TODO: should set status codes (NPH support)
  -/*
  - * response.setStatus(getStatusCode(line));
  - */
  +} else if (commandsStdOut != null  commandsStdOut.ready()) {
  +// about to read something; reset pause count
  +pauseCount = 0;
  +
  +if (inHeader) {
  +//set headers
  +String line = commandsStdOut.readLine();
  +if (line == null || .equals(line)) {
  +inHeader = false;
   } else {
  -response.addHeader
  -(line.substring(0, line.indexOf(:)).trim(),
  - line.substring(line.indexOf(:) + 1).trim());
  +if (debug = 2) {
  +

DO NOT REPLY [Bug 11485] - Jasper2 caches tag library descriptors too long

2002-08-26 Thread bugzilla


DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11485.
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=11485

Jasper2 caches tag library descriptors too long





--- Additional Comments From [EMAIL PROTECTED]  2002-08-26 22:39 ---
The problem is not with caching of TLD's or tag handler classes, because they
are not cached.  The problem is that the page that uses the modified TLD or tag
handler is not recompiled.  TLD, and indirectly the tag handlers are only
processed at translation time, and when they change, the page that uses them
need to be recompiled.  This is because the codes that are generated for the JSP
page depends on the properties of the tag handlers and would become invalid when
the tag handlers are modified.  This is analogous to class dependency in Java:
if Foo references Bar and Bar.java is modified, then Foo.java needs to be
recompiled, otherwise you'll get a ClassChangedException at runtime.

The simple workaround in this case is to either touch the JSP page or remove its
.class file, just to force a recompilation of that page.

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

DO NOT REPLY [Bug 12041] - CGIServlet can block on input

2002-08-26 Thread bugzilla


DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12041.
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=12041

CGIServlet can block on input

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2002-08-26 22:51 ---
Thanks for the patch.

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

cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/servlets CGIServlet.java

2002-08-26 Thread amyroh


amyroh  2002/08/26 16:01:31

  Modified:catalina/src/share/org/apache/catalina/servlets
CGIServlet.java
  Log:
  CGIServlet had problems in the case of a CGI script which prints a large
  amount of data to stdout; while the CGIServlet was waiting for the end of
  stderr, the CGI script would fill up the stdout buffer and then wait for it to be
  drained, causing a deadlock between the two processes.
  
  This patch solves this problem by having a single loop which
  reads stderr if it's ready, or stdout if ready.  If neither handle has queued
  data and the CGI script has exited, the servlet pauses a couple of times for
  half a second to make sure that all output has been delivered, then it exits.
  
  Fixes Bug 12041.  Patch submitted by Dave Glowacki ([EMAIL PROTECTED])
  
  Revision  ChangesPath
  1.2   +85 -51
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/servlets/CGIServlet.java
  
  Index: CGIServlet.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/servlets/CGIServlet.java,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- CGIServlet.java   18 Jul 2002 16:47:39 -  1.1
  +++ CGIServlet.java   26 Aug 2002 23:01:31 -  1.2
  @@ -686,6 +686,7 @@
   /** For future testing use only; does nothing right now */
   public static void main(String[] args) {
   System.out.println($Header$);
  +
   }
   
   
  @@ -1507,9 +1508,9 @@
* /UL
* /p
*
  - * For more information, see java.lang.Runtime#exec(String command, 
  + * For more information, see java.lang.Runtime#exec(String command,
* String[] envp, File dir)
  - * 
  + *
* @exception IOException if problems during reading/writing occur
*
*/
  @@ -1663,7 +1664,6 @@
*   bugParade/bugs/4223650.html
*/
   
  -boolean isRunning = true;
   commandsStdOut = new BufferedReader
   (new InputStreamReader(proc.getInputStream()));
   commandsStdErr = new BufferedReader
  @@ -1680,63 +1680,97 @@
   //NOOP: no output will be written
   }
   
  +boolean inHeader = true;
  +int pauseCount = 0;
  +
  +boolean isRunning = true;
  +
   while (isRunning) {
   
  -try {
  -//read stderr first
  -cBuf = new char[1024];
  -while ((bufRead = commandsStdErr.read(cBuf)) != -1) {
  +if (commandsStdErr != null  commandsStdErr.ready()) {
  +// about to read something; reset pause count
  +pauseCount = 0;
  +
  +bufRead = commandsStdErr.read(cBuf);
  +if (bufRead == -1) {
  +commandsStdErr.close();
  +commandsStdErr = null;
  +isRunning = (commandsStdOut != null);
  +} else {
   if (servletContainerStdout != null) {
  -servletContainerStdout.write(cBuf, 0, bufRead);
  +if (inHeader) {
  +servletContainerStdout.write(cBuf, 0, bufRead);
  +} else {
  +log(runCGI: Throwing away StdErr \ +
  +new String(cBuf, 0, bufRead) + \);
  +}
   }
   }
  -
  -//set headers
  -String line = null;
  -while (((line = commandsStdOut.readLine()) != null)
  -!(.equals(line))) {
  -if (debug = 2) {
  -log(runCGI: addHeader(\ + line + \));
  -}
  -if (line.startsWith(HTTP)) {
  -//TODO: should set status codes (NPH support)
  -/*
  - * response.setStatus(getStatusCode(line));
  - */
  +} else if (commandsStdOut != null  commandsStdOut.ready()) {
  +// about to read something; reset pause count
  +pauseCount = 0;
  +
  +if (inHeader) {
  +//set headers
  +String line = commandsStdOut.readLine();
  +if (line == null || .equals(line)) {
  +inHeader = false;
   } else {
  -response.addHeader
  -

cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler Generator.java

2002-08-26 Thread luehe


luehe   2002/08/26 16:47:47

  Modified:jasper2/src/share/org/apache/jasper/compiler Generator.java
  Log:
  Fixed 11942: reassignment of variables to pagecontext attributes in body loop
  Fixed 11552: Iteration tags do not resynchronize scripting variables after
   doAfterBody()
  
  Revision  ChangesPath
  1.80  +27 -29
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Generator.java
  
  Index: Generator.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Generator.java,v
  retrieving revision 1.79
  retrieving revision 1.80
  diff -u -r1.79 -r1.80
  --- Generator.java24 Aug 2002 21:42:34 -  1.79
  +++ Generator.java26 Aug 2002 23:47:47 -  1.80
  @@ -1999,7 +1999,7 @@
out.print(tagHandlerVar);
out.println(.doStartTag(););
   
  - if (!n.implementsBodyTag()) {
  + if (!n.implementsIterationTag()) {
// Synchronize AT_BEGIN scripting variables
syncScriptingVars(n, VariableInfo.AT_BEGIN);
// Declare and synchronize NESTED scripting variables
  @@ -2013,30 +2013,30 @@
out.println( != javax.servlet.jsp.tagext.Tag.SKIP_BODY) {);
out.pushIndent();

  - if (n.implementsBodyTag()) {
  + if (n.implementsIterationTag()) {
// Declare NESTED scripting variables
declareScriptingVars(n, VariableInfo.NESTED);
   
  - out.printin(if ();
  - out.print(tagEvalVar);
  - out.println( != javax.servlet.jsp.tagext.Tag.EVAL_BODY_INCLUDE) 
{);
  - // Assume EVAL_BODY_BUFFERED
  - out.pushIndent();
  -out.printil(out = pageContext.pushBody(););
  - out.printin(tagHandlerVar);
  - 
out.println(.setBodyContent((javax.servlet.jsp.tagext.BodyContent) out););
  - out.printin(tagHandlerVar);
  - out.println(.doInitBody(););
  -
  - // Synchronize AT_BEGIN and NESTED scripting variables
  - syncScriptingVars(n, VariableInfo.AT_BEGIN);
  - syncScriptingVars(n, VariableInfo.NESTED);
  - 
  - out.popIndent();
  - out.printil(});
  - }
  - 
  - if (n.implementsIterationTag()) {
  + if (n.implementsBodyTag()) {
  + out.printin(if ();
  + out.print(tagEvalVar);
  + out.println( != 
javax.servlet.jsp.tagext.Tag.EVAL_BODY_INCLUDE) {);
  + // Assume EVAL_BODY_BUFFERED
  + out.pushIndent();
  + out.printil(out = pageContext.pushBody(););
  + out.printin(tagHandlerVar);
  + 
out.println(.setBodyContent((javax.servlet.jsp.tagext.BodyContent) out););
  + out.printin(tagHandlerVar);
  + out.println(.doInitBody(););
  +
  + // Synchronize AT_BEGIN and NESTED scripting variables
  + syncScriptingVars(n, VariableInfo.AT_BEGIN);
  + syncScriptingVars(n, VariableInfo.NESTED);
  +
  + out.popIndent();
  + out.printil(});
  + }
  +
out.printil(do {);
out.pushIndent();
}
  @@ -2056,10 +2056,8 @@
out.println(.doAfterBody(););
   
// Synchronize AT_BEGIN and NESTED scripting variables
  - if (n.implementsBodyTag()) {
  - syncScriptingVars(n, VariableInfo.AT_BEGIN);
  - syncScriptingVars(n, VariableInfo.NESTED);
  - }
  + syncScriptingVars(n, VariableInfo.AT_BEGIN);
  + syncScriptingVars(n, VariableInfo.NESTED);
   
out.printil(if (evalDoAfterBody != 
javax.servlet.jsp.tagext.BodyTag.EVAL_BODY_AGAIN));
out.pushIndent();
  
  
  

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

DO NOT REPLY [Bug 11552] - Iteration tags do not resynchronize scripting variables after doAfterBody()

2002-08-26 Thread bugzilla


DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11552.
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=11552

Iteration tags do not resynchronize scripting variables after doAfterBody()

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2002-08-27 00:03 ---
Fixed.

AT_BEGIN and NESTED scripting vars now get synchronized after
IterationTag.doAfterBody() (they used to get synchronized after doAfterBody()
only if the tag handler implemented BodyTag, which was in violation of the
spec).

They continue to be synchronized after doInitBody() only if the tag handler
implements BodyTag.

David wrote:

 In This Case The First Time The Variable Would Be Synchronized Would Be
 After Doafterbody(). On The First Iteration Of The Loop This Would Probably
 Throw A Nullpointerexception If You Tried To Use Varatbegin Or Varnested
 Inside The Body Of The Tag.

In that case it would be the page author's responsibility to check the scripting
vars for null, knowing that the scripting vars will be set only after the first
body evaluation. I don't think it would make any sense to synchronize a
scripting var at the start of the loop, since the scoped variable to synchronize
with may not even exist at that point of the tag execution (it may only get
defined by IteratorTag.doAfterBody()).

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

DO NOT REPLY [Bug 11942] - reassignment of variables to pagecontext attributes in body loop

2002-08-26 Thread bugzilla


DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11942.
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=11942

reassignment of variables to pagecontext attributes in body loop

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2002-08-27 00:06 ---
Fixed. AT_BEGIN and NESTED scripting vars now get synchronized after
IterationTag.doAfterBody() (they used to get synchronized after doAfterBody()
only if the tag handler implemented BodyTag).

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

DO NOT REPLY [Bug 11849] - Nested includes with JSTL1.0EA do not work

2002-08-26 Thread bugzilla


DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11849.
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=11849

Nested includes with JSTL1.0EA do not work





--- Additional Comments From [EMAIL PROTECTED]  2002-08-27 00:16 ---
Why are you using JSTL 1.0 EA instead of the latest (1.0.1) release available at
http://jakarta.apache.org/builds/jakarta-taglibs/releases/standard/?

Please let me know if your problem still exists with this release, and I will
investigate.

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

DO NOT REPLY [Bug 12059] - Resources tag causes startup to fail

2002-08-26 Thread bugzilla


DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12059.
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=12059

Resources tag causes startup to fail





--- Additional Comments From [EMAIL PROTECTED]  2002-08-27 00:52 ---
SOMEHOW the Resources tag shown below got forced to lower case.  The classname 
is actually org.apache.naming.resources.FileDirContext, not what is shown in the 
Description below.

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

User Defined Realm. How to register MBean in Tomcat 4.1.x

2002-08-26 Thread Roytman, Alex


Dear Catalina developers,

I am trying to port my LDAP realm from tomcat 4.0.x to tomcat 4.1.9.
I was unable to find any information on how to make my custom Realm work =
in Catalina's JMX environment. The problem is I do not know how to =
register (do I need to) a MBean for my realm. Please pardon me if my =
questions seems to be naive but I had no chance to learn JMX.

When I try to use my realm Tomcat starts fine, the Realm itself works =
just fine too but tomcat reports error that MBean for my Realm is not =
found.=20
Well it can't be found - it is not registered. So my question is:
1. Does tomcat 4.1.x have any way to register custom MBeans ? As far as =
I understand, right now they are defined in mbeans-descriptors.xml file =
which is not meant to be modified by deployers. Also how should I supply =
a factory method for my MBean and do I need it at all.=20
I tried to fool tomcat by providing modified copy of the =
mbeans-descriptors.xml and MBeanFactory.class  in =
$CATALINA_HOME/server/classes and it seems to take it but of course it =
is just a dirty hack.
2. Is it a crime to not to have a MBean for one of the tomcat components =
(i.e. registering realm with no appropriate MBean)? If MBean is not =
mandatory can error message be suppressed?


Your advice is greatly appreciated

Thank you

Alex

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

Re: Chuid - merging code from daemon into jk2

2002-08-26 Thread Bojan Smojver


Quoting [EMAIL PROTECTED]:

 In order to change the uid from root to a regular user, you will add
  user.name=...
  user.group=...
 in jk2.properties. 

I'm not too familiar with this - which part here is running as root?

Bojan

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

Re: Chuid - merging code from daemon into jk2

2002-08-26 Thread Costin Manolache


Bojan Smojver wrote:

 Quoting [EMAIL PROTECTED]:
 
 In order to change the uid from root to a regular user, you will add
  user.name=...
  user.group=...
 in jk2.properties.
 
 I'm not too familiar with this - which part here is running as root?

If you want to start tomcat on port 80, you need to start it as root
so it can open the socket - but need to drop the priviledges for
security. 

Costin






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

DO NOT REPLY [Bug 11919] - Can't create servlet-mapping of / (not /*)

2002-08-26 Thread bugzilla


DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11919.
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=11919

Can't create servlet-mapping of / (not /*)





--- Additional Comments From [EMAIL PROTECTED]  2002-08-27 03:53 ---
Then, how can I map / only (not /*) to a particular Servlet?  By use filter?
Thanks.

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

Re: User Defined Realm. How to register MBean in Tomcat 4.1.x

2002-08-26 Thread Amy Roh


Hi Alex,

Roytman, Alex wrote:
 Dear Catalina developers,
 
 I am trying to port my LDAP realm from tomcat 4.0.x to tomcat 4.1.9.
 I was unable to find any information on how to make my custom Realm work =
 in Catalina's JMX environment. The problem is I do not know how to =
 register (do I need to) a MBean for my realm. Please pardon me if my =
 questions seems to be naive but I had no chance to learn JMX.
 
 When I try to use my realm Tomcat starts fine, the Realm itself works =
 just fine too but tomcat reports error that MBean for my Realm is not =
 found.=20
 Well it can't be found - it is not registered. So my question is:
 1. Does tomcat 4.1.x have any way to register custom MBeans ? As far as =
 I understand, right now they are defined in mbeans-descriptors.xml file =
 which is not meant to be modified by deployers. Also how should I supply =
 a factory method for my MBean and do I need it at all.=20
 I tried to fool tomcat by providing modified copy of the =
 mbeans-descriptors.xml and MBeanFactory.class  in =
 $CATALINA_HOME/server/classes and it seems to take it but of course it =
 is just a dirty hack.

You can just add a mbean description for your custom Realm in 
mbeans-descriptors.xml file.  The following would be an example mbean 
description for a custom Realm.

   mbean name=MyLDAPRealm
 className=org.apache.catalina.mbeans.ClassNameMBean
   description=MyLDAPRealm
domain=Catalina
 group=Realm
  type=org.apache.catalina.realm.MyLDAPRealm

 attribute   name=className
   description=Fully qualified class name of the managed object
  type=java.lang.String
 writeable=false/
   /mbean




 2. Is it a crime to not to have a MBean for one of the tomcat components =
 (i.e. registering realm with no appropriate MBean)? If MBean is not =
 mandatory can error message be suppressed?

No, it is not a crime. ;-)  Like you said, Tomcat(except admin webapp) 
and your custom components will work fine without registering MBean for 
it.  Also, You can turn off MBean support by commenting out two 
Listeners (ServerLifecycleListener and GlobalResourcesLifecycleListener) 
in server.xml if you want to avoid seeing the mbean errors.  However, 
you need those Listeners if you want to run admin webapp.

Amy

 
 
 Your advice is greatly appreciated
 
 Thank you
 
 Alex
 
 --
 To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
 For additional commands, e-mail: mailto:[EMAIL PROTECTED]
 




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

DO NOT REPLY [Bug 11963] - Still cann't auto recompile jsp page

2002-08-26 Thread bugzilla


DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11963.
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=11963

Still cann't auto recompile jsp page





--- Additional Comments From [EMAIL PROTECTED]  2002-08-27 04:07 ---
It sounds like samba isn't playing nicely.  It definetly sounds like
it's now not a tomcat issue, but an issue with how samba saves files
(not resetting an attribute?).  You should close your bug, marking it
invalid.


- Andrew

 -Original Message-
 From: koktsing [mailto:[EMAIL PROTECTED]] 
 Sent: Monday, August 26, 2002 10:24 PM
 To: Andrew Conrad
 Subject: Re: DO NOT REPLY [Bug 11963] New: - Still cann't 
 auto recompile jsp page
 
 
 hai,
 
 Don't know good news or bad news.
 i found the actual cause of the bug already.
 it is the linux samba problem most propably. may be it is my 
 fault for not state clearly that i install tomcat on linux 
 but using samba to mount and do development on windows 
 machine. i tried edit the jsp file using vi (linux), and it 
 really give me instance changing in the browser(windows). but 
 when i edit the file on windows machine (using samba), it 
 doesn't!!! then i use vi to check the file again, the changes 
 made by window is there. so is this mean that the tomcat 
 cannot get the changes passing from samba?
 
 
 koktsing
 
 
 Andrew Conrad wrote:
 
  For a temporary work around, define a context for your 
 webapp in your 
  server.xml and set the reloadable attribute to true
 
  Context path=/product reloadable=true ... /
 
  Or for more precise control
 
  Context path=/product ... 
  Loader reloadable=true checkInterval=15 / /Context
 
  The web.xml settings may no longer be used.  I'll look into it some 
  more.
 
  - Andrew
 
   -Original Message-
   From: koktsing [mailto:[EMAIL PROTECTED]]
   Sent: Sunday, August 25, 2002 8:10 PM
   To: Andrew Conrad
   Subject: Re: DO NOT REPLY [Bug 11963] New: - Still cann't auto 
   recompile jsp page
  
  
   my webapp name is product, actually i just use the 
 struts-blank as 
   the template, and start work from the index.jsp. but so 
 happen the 
   jsp file doesn't autocompile everytime i change it (eg
   wording)
  
   Thanks,
   koktsing
  
   Andrew Conrad wrote:
  
Send me a copy of your server.xml file, and I will take a
   look.  And
what is your webapp name?
   
- Andrew
   
 -Original Message-
 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
 Sent: Friday, August 23, 2002 6:00 AM
 To: [EMAIL PROTECTED]
 Subject: DO NOT REPLY [Bug 11963] New: - Still cann't
   auto recompile
 jsp page


 DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED 
 COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT 
 http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11963.
 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=11963
   
Still cann't auto recompile jsp page
   
   Summary: Still cann't auto recompile jsp page
   Product: Tomcat 4
   Version: 4.1.9
  Platform: PC
OS/Version: Linux
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Jasper 2
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
   
i have tried tomcat 4.0.4 on a linux server, but it has the
   problem of
auto- recompile jsp. then, i found out that this is a known bug 
and downloaded the latest 4.1.9 milestone build (which said
   that the bug
ix fixed). unfortunately, i still facing this bug. FYI, 
 I have set 
development and reloading flag to 'true' already. as below:
servlet
servlet-namejsp/servlet-name
   

 servlet-classorg.apache.jasper.servlet.JspServlet/servlet-class
init-param
param-namelogVerbosityLevel/param-name
param-valueWARNING/param-value
/init-param
init-param
param-namedevelopment/param-name
param-valuetrue/param-value
/init-param
init-param
param-namereloading/param-name
param-valuetrue/param-value
/init-param
load-on-startup3/load-on-startup
/servlet
   
Can you help me to check on this?
   
--
To unsubscribe, e-mail: 
mailto:[EMAIL PROTECTED]
For additional commands, e-mail: 
mailto:[EMAIL PROTECTED]
  


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

DO NOT REPLY [Bug 11963] - Still cann't auto recompile jsp page

2002-08-26 Thread bugzilla


DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11963.
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=11963

Still cann't auto recompile jsp page

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID

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

Re: Chuid - merging code from daemon into jk2

2002-08-26 Thread Bojan Smojver


Quoting Costin Manolache [EMAIL PROTECTED]:

 Bojan Smojver wrote:
 
  Quoting [EMAIL PROTECTED]:
  
  In order to change the uid from root to a regular user, you will add
   user.name=...
   user.group=...
  in jk2.properties.
  
  I'm not too familiar with this - which part here is running as root?
 
 If you want to start tomcat on port 80, you need to start it as root
 so it can open the socket - but need to drop the priviledges for
 security. 

OK, thanks. It obviously doesn't affect me as I never run Tomcat as the web
server on port 80.

Bojan

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

DO NOT REPLY [Bug 11849] - Nested includes with JSTL1.0EA do not work

2002-08-26 Thread bugzilla


DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11849.
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=11849

Nested includes with JSTL1.0EA do not work





--- Additional Comments From [EMAIL PROTECTED]  2002-08-27 05:55 ---

I am using the EA, because switching to the release version would require a 
substantial amount of effort, due to the changes between the EA and the final 
release (the app contains about 100 pages, that need to be touched).

But if this is a problem with JSTL1.0EA and it is fixed in the final release, 
it's still good news.

Thanks for investigating.

Regards
Georg

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

42 matches

Mail list logo