[GUMP@lsd]: jakarta-tomcat-5/jakarta-tomcat-5 failed

2004-02-11 Thread bobh
Project: jakarta-tomcat-5
State: Failed
URL: http://lsd.student.utwente.nl/gump/jakarta-tomcat-5/jakarta-tomcat-5.html
- G U M P Y


Annotations:
 - Warning - Set jar 
[/data/gump/jakarta-tomcat-5/dist/server/lib/servlets-default.jar] identifier to jar 
basename: [servlets-default.jar]
 - Warning - Set jar [/data/gump/jakarta-tomcat-5/dist/common/lib/naming-common.jar] 
identifier to jar basename: [naming-common.jar]
 - Warning - Set jar 
[/data/gump/jakarta-tomcat-5/dist/common/lib/naming-resources.jar] identifier to jar 
basename: [naming-resources.jar]
 - Warning - Set jar [/data/gump/jakarta-tomcat-5/dist/server/lib/catalina.jar] 
identifier to jar basename: [catalina.jar]
 - Warning - Set jar [/data/gump/jakarta-tomcat-5/dist/bin/bootstrap.jar] identifier 
to jar basename: [bootstrap.jar]
 - Warning - Set jar 
[/data/gump/jakarta-tomcat-5/dist/server/lib/servlets-common.jar] identifier to jar 
basename: [servlets-common.jar]
 - Warning - Set jar 
[/data/gump/jakarta-tomcat-5/dist/server/lib/servlets-invoker.jar] identifier to jar 
basename: [servlets-invoker.jar]
 - Info - Dependency on javamail exists, no need to add for property mail.jar.
 - Info - Dependency on jaf exists, no need to add for property activation.jar.
 - Info - Dependency on jakarta-servletapi-5-servlet exists, no need to add for 
property servlet-api.jar.
 - Info - Dependency on jakarta-servletapi-5-jsp exists, no need to add for property 
jsp-api.jar.
 - Info - Dependency on xml-xerces exists, no need to add for property xercesImpl.jar.
 - Info - Dependency on xml-xerces exists, no need to add for property 
xmlParserAPIs.jar.
 - Info - Dependency on jakarta-tomcat-util exists, no need to add for property 
tomcat-util.jar.
 - Info - Dependency on commons-el exists, no need to add for property commons-el.jar.
 - Info - Dependency on commons-logging exists, no need to add for property 
commons-logging-api.jar.
 - Info - Dependency on commons-modeler exists, no need to add for property 
commons-modeler.jar.
 - Info - Dependency on ant exists, no need to add for property ant.home.
 - Info - Dependency on jsse exists, no need to add for property jsse.home.
 - Info - Dependency on jmx exists, no need to add for property jmx.home.
 - Info - Dependency on jmx exists, no need to add for property jmx.jar.
 - Info - Dependency on jmx exists, no need to add for property jmx-tools.jar.
 - Info - Dependency on jndi exists, no need to add for property jndi.home.
 - Info - Dependency on jakarta-regexp exists, no need to add for property regexp.home.
 - Info - Dependency on jakarta-regexp exists, no need to add for property regexp.jar.
 - Info - Dependency on javamail exists, no need to add for property mail.home.
 - Info - Dependency on jakarta-tomcat-coyote exists, no need to add for property 
tomcat-coyote.home.
 - Info - Dependency on jakarta-tomcat-jasper_tc5 exists, no need to add for property 
jasper.home.
 - Info - Dependency on jaf exists, no need to add for property activation.home.
 - Info - Dependency on commons-modeler exists, no need to add for property 
commons-modeler.home.
 - Info - Dependency on commons-daemon exists, no need to add for property 
commons-daemon.jsvc.tar.gz.
 - Error - Failed with reason build failed


- G U M P Y
Work Name: build_jakarta-tomcat-5_jakarta-tomcat-5 (Type: Build)
State: Failed
Elapsed: 0 hours, 1 minutes, 27 seconds
Command Line: java -Djava.awt.headless=true 
-Xbootclasspath/p:/data/gump/xml-xerces2/java/build/xercesImpl.jar:/data/gump/xml-xerces2/java/build/xmlParserAPIs.jar:/data/gump/xml-xalan/java/build/xalan-unbundled.jar:/data/gump/xml-commons/java/external/build/xml-apis.jar
 org.apache.tools.ant.Main -Dbuild.clonevm=true 
-Dgump.merge=/data/gump/gump/work/merge.xml -Dbuild.sysclasspath=only 
-Dtomcat33.home=*Unset* 
-Djsp-api.jar=/data/gump/jakarta-servletapi-5/jsr152/dist/lib/jsp-api.jar 
-Dtomcat-coyote.home=/data/gump/jakarta-tomcat-connectors/coyote 
-Djndi.jar=/data/gump/opt/jndi1_2_1/lib/jndi.jar -Dsite2.home=/data/gump/jakarta-site2 
-DxmlParserAPIs.jar=/data/gump/xml-xerces2/java/build/xercesImpl.jar 
-Dactivation.home=/data/gump/opt/jaf-1.0.1 -Djmx.home=/data/gump/opt/jmx-1_2-ri 
-Djdbc20ext.jar=/data/gump/opt/jdbc2_0/jdbc2_0-stdext.jar 
-Djmx-tools.jar=/data/gump/opt/jmx-1_2-ri/lib/jmxtools.jar 
-Dregexp.jar=/data/gump/jakarta-regexp/build/jakarta-regexp-20040211.jar 
-Dmail.home=/data/gump/opt/javamail-1.3 -Dant.home=/data/gump/ant/dist 
-Dcommons-modeler.home=/data/gump/jakarta-commons/modeler 
-Dcommons-launcher.jar=/data/gump/jakarta-commons/launcher/dist/bin/commons-launcher.jar
 
-Dcommons-collections.jar=/data/gump/jakarta-commons/collections/build/commons-collections-20040211.jar
 -Dldap.jar=/data/gump/opt/ldap-1_2_4/lib/ldap.jar 
-Djsse.home=/data/gump/opt/jsse1.0.3 
-Dcommons-beanutils.jar=/data/gump/jakarta-commons/beanutils/dist/commons-beanutils.jar
 -DxercesImpl.jar=/data

cvs commit: jakarta-tomcat-connectors/jk/native/netscape nsapi.dsw

2004-02-11 Thread hgomez
hgomez  2004/02/11 01:08:41

  Removed: jk/native/jni jni_connect.dsw
   jk/native/netscape nsapi.dsw
  Log:
  Remove unneeded .dsw, MSVC will recreate them

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



Re: [PATCH] ./native/netscape/nsapi.dsp - remove obsolete files

2004-02-11 Thread Henri Gomez
Mike Anderson a écrit :
It's fine by me.  Günter is correct that MSVC will create these as necessary and you can build without them.  
I'd do it, but I'm clueless about the proper procedure in CVS (being a Windows/NetWare weenie:-)  I'm learning though.
I'm using Eclipse and it rocks in the CVS area :)

Mike Anderson


[EMAIL PROTECTED] 2/9/2004 5:05:53 AM 
Günter Knauf a écrit :


Hi,
the patch below removes the obsolete files from the project file; 
in addition I'd suggest to remove both *.dsw files from ./jk/native/netscape and ./jk/native/jni folders cause they are not needed - MSVC creates then self.


removed, should I do the same for isapi ?

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


Re: failover-problem and session mixup: jakarta-tomcat-connectors/mod_jk: jk_ajp_common.c

2004-02-11 Thread Henri Gomez
Alexander Schwartz a écrit :

Am Di, den 10.02.2004 schrieb Henri Gomez um 15:52:


To fix this serious bug we should modify the current service API.

We should store the POSTED datas in the jk_ws_service_t area and
not in ajp_operation_t, as such the first worker will feed the POST
datas in an area which will be available to the second one.
Aternate idea are of course more than welcome;


As I understand it mod_jk is stable, almost deprecated, and mod_jk2
is the future. Therefore I suggest: 

   * no API change in mod_jk
   * mark the operation as unrecoverable when an error occurs after
 the headers have been sent to the tomcat, that is only fixing
 bugs and trying not to do big changes 
   * concentrate your efforts on mod_jk2 and give people a reason to 
 upgrade :)

Marking the operation as unrecoverable might also solve the other
(lb-)problem: when you shut down the first tomcat after it has already
sent some data to the client mod_jk forwards the request to the second
tomcat and appends the response of the second tomcat to the response of
the first tomcat. I'll deliver a sample jk.log soon. 

I have prepared a patch for 1.2.4/1.2.5, and I am happy to port it to
HEAD -- if someone checks that it leaves no loose ends.
Thanks for taking this serious.

Alex.

PS: this empty POST bug is not the explanation for the session mixup
(yet)? Any ideas on that one?
Well I'm sure we could update the API to have this problem fixed.

The post buffer used for recovery should be create in service and
passed to the differents workers, making the POST recovery working
for ajp and lb workers.
If nobody have objections I'll take a look at this since I don't like
the idea of having something working for only HALF of HTTP protocol.


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


cvs commit: jakarta-tomcat-connectors/jk/native/common jk_ajp_common.c jk_global.h jk_lb_worker.c jk_msg_buff.c jk_msg_buff.h jk_service.h

2004-02-11 Thread hgomez
hgomez  2004/02/11 01:49:49

  Modified:jk/native/common jk_ajp_common.c jk_global.h jk_lb_worker.c
jk_msg_buff.c jk_msg_buff.h jk_service.h
  Log:
  Fix the POST recovery in LB mode.
  
  Revision  ChangesPath
  1.47  +22 -2 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.46
  retrieving revision 1.47
  diff -u -r1.46 -r1.47
  --- jk_ajp_common.c   6 Feb 2004 08:37:46 -   1.46
  +++ jk_ajp_common.c   11 Feb 2004 09:49:49 -  1.47
  @@ -1091,7 +1091,20 @@
   }
   else
jk_log(l, JK_LOG_DEBUG, Resent the request body (%d)\n, postlen);
  - 
  +}
  +else if (s-reco_status == RECO_FILLED)
  +{
  + /* Recovery in LB MODE */
  + postlen = jk_b_get_len(s-reco_buf);
  +
  + if (postlen  AJP_HEADER_LEN) {
  + if(!ajp_connection_tcp_send_message(ae, s-reco_buf, l)) {
  + jk_log(l, JK_LOG_ERROR, Error resending request body (lb 
mode) (%d)\n, postlen);
  + return JK_FALSE;
  + }
  + }
  + else
  + jk_log(l, JK_LOG_DEBUG, Resent the request body (lb mode) (%d)\n, 
postlen);
   }
   else {
   /* We never sent any POST data and we check if we have to send at
  @@ -1117,6 +1130,13 @@
   op-recoverable = JK_FALSE;
   return JK_CLIENT_ERROR;
   }
  +
  +/* If a RECOVERY buffer is available in LB mode, fill it */
  +if (s-reco_status == RECO_INITED) {
  + jk_b_copy(op-post, s-reco_buf);
  + s-reco_status = RECO_FILLED;
  +}
  +
   s-content_read = len;
   if (!ajp_connection_tcp_send_message(ae, op-post, l)) {
   jk_log(l, JK_LOG_ERROR, Error sending request body\n);
  
  
  
  1.27  +9 -1  jakarta-tomcat-connectors/jk/native/common/jk_global.h
  
  Index: jk_global.h
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/common/jk_global.h,v
  retrieving revision 1.26
  retrieving revision 1.27
  diff -u -r1.26 -r1.27
  --- jk_global.h   5 Jan 2004 22:41:53 -   1.26
  +++ jk_global.h   11 Feb 2004 09:49:49 -  1.27
  @@ -163,6 +163,14 @@
   #endif
   
   /*
  + * RECO STATUS
  + */
  +
  +#define RECO_NONE0x00
  +#define RECO_INITED  0x01
  +#define RECO_FILLED  0x02
  +
  +/*
* JK options
*/
   
  
  
  
  1.16  +6 -2  jakarta-tomcat-connectors/jk/native/common/jk_lb_worker.c
  
  Index: jk_lb_worker.c
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/common/jk_lb_worker.c,v
  retrieving revision 1.15
  retrieving revision 1.16
  diff -u -r1.15 -r1.16
  --- jk_lb_worker.c6 Feb 2004 08:37:59 -   1.15
  +++ jk_lb_worker.c11 Feb 2004 09:49:49 -  1.16
  @@ -323,7 +323,11 @@
   /* you can not recover on another load balancer */
   *is_recoverable_error = JK_FALSE;
   
  -
  +/* set the recovery post, for LB mode */
  +s-reco_buf = jk_b_new(s-pool);
  +jk_b_set_buffer_size(s-reco_buf, DEF_BUFFER_SZ);
  +jk_b_reset(s-reco_buf);
  +s-reco_status = RECO_INITED;   
 
   while(1) {
   worker_record_t *rec = get_most_suitable_worker(p-worker, s, 
attempt++);
   int rc;
  
  
  
  1.15  +17 -1 jakarta-tomcat-connectors/jk/native/common/jk_msg_buff.c
  
  Index: jk_msg_buff.c
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/common/jk_msg_buff.c,v
  retrieving revision 1.14
  retrieving revision 1.15
  diff -u -r1.14 -r1.15
  --- jk_msg_buff.c 5 Nov 2003 09:15:39 -   1.14
  +++ jk_msg_buff.c 11 Feb 2004 09:49:49 -  1.15
  @@ -476,3 +476,19 @@
   #endif
   }
   
  +
  +int jk_b_copy(jk_msg_buf_t *smsg,
  +  jk_msg_buf_t *dmsg)
  +{
  + if (smsg == NULL || dmsg == NULL)
  + return (-1);
  +
  + if (dmsg-maxlen  smsg-len)
  + return (-2);
  +
  + memcpy(dmsg-buf, smsg-buf, smsg-len);
  + dmsg-len = smsg-len;
  +
  + return (smsg-len);
  +}
  +
  
  
  
  1.8   +6 -1  jakarta-tomcat-connectors/jk/native/common/jk_msg_buff.h
  
  Index: jk_msg_buff.h
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/common/jk_msg_buff.h,v
  retrieving revision 1.7
  retrieving revision 1.8
  diff -u 

cvs commit: jakarta-tomcat-connectors/jk/native/apache-2.0 mod_jk.c

2004-02-11 Thread hgomez
hgomez  2004/02/11 01:50:19

  Modified:jk/native/apache-2.0 mod_jk.c
  Log:
  Initialize the reco status
  
  Revision  ChangesPath
  1.92  +4 -1  jakarta-tomcat-connectors/jk/native/apache-2.0/mod_jk.c
  
  Index: mod_jk.c
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/apache-2.0/mod_jk.c,v
  retrieving revision 1.91
  retrieving revision 1.92
  diff -u -r1.91 -r1.92
  --- mod_jk.c  2 Feb 2004 17:38:04 -   1.91
  +++ mod_jk.c  11 Feb 2004 09:50:19 -  1.92
  @@ -490,6 +490,9 @@
   s-read = ws_read;
   s-write= ws_write;
   
  +/* Clear RECO status */
  +s-reco_status  = RECO_NONE;
  +
   s-auth_type= NULL_FOR_EMPTY(r-ap_auth_type);
   s-remote_user  = NULL_FOR_EMPTY(r-user);
   
  
  
  

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



cvs commit: jakarta-tomcat-connectors/jk/native/apache-1.3 mod_jk.c

2004-02-11 Thread hgomez
hgomez  2004/02/11 01:50:39

  Modified:jk/native/apache-1.3 mod_jk.c
  Log:
  Initialise the reco status
  
  Revision  ChangesPath
  1.46  +4 -1  jakarta-tomcat-connectors/jk/native/apache-1.3/mod_jk.c
  
  Index: mod_jk.c
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/apache-1.3/mod_jk.c,v
  retrieving revision 1.45
  retrieving revision 1.46
  diff -u -r1.45 -r1.46
  --- mod_jk.c  21 Nov 2003 06:51:45 -  1.45
  +++ mod_jk.c  11 Feb 2004 09:50:38 -  1.46
  @@ -467,6 +467,9 @@
   s-read = ws_read;
   s-write= ws_write;
   
  +/* Clear RECO status */
  +s-reco_status  = RECO_NONE;
  +
   s-auth_type= NULL_FOR_EMPTY(r-connection-ap_auth_type);
   s-remote_user  = NULL_FOR_EMPTY(r-connection-user);
   
  
  
  

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



cvs commit: jakarta-tomcat-connectors/jk/native/iis jk_isapi_plugin.c

2004-02-11 Thread hgomez
hgomez  2004/02/11 01:52:03

  Modified:jk/native/iis jk_isapi_plugin.c
  Log:
  Initalize the reco status
  
  Revision  ChangesPath
  1.21  +4 -1  jakarta-tomcat-connectors/jk/native/iis/jk_isapi_plugin.c
  
  Index: jk_isapi_plugin.c
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/iis/jk_isapi_plugin.c,v
  retrieving revision 1.20
  retrieving revision 1.21
  diff -u -r1.20 -r1.21
  --- jk_isapi_plugin.c 5 Nov 2003 09:15:41 -   1.20
  +++ jk_isapi_plugin.c 11 Feb 2004 09:52:03 -  1.21
  @@ -1273,6 +1273,9 @@
   s-read = read;
   s-write = write;
   
  +/* Clear RECO status */
  +s-reco_status  = RECO_NONE;
  +
   GET_SERVER_VARIABLE_VALUE(HTTP_WORKER_HEADER_NAME, (*worker_name));   
   GET_SERVER_VARIABLE_VALUE(HTTP_URI_HEADER_NAME, s-req_uri); 
   GET_SERVER_VARIABLE_VALUE(HTTP_QUERY_HEADER_NAME, s-query_string); 
  
  
  

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



cvs commit: jakarta-tomcat-connectors/jk/native/isapi jk_isapi_plugin.c

2004-02-11 Thread hgomez
hgomez  2004/02/11 01:57:42

  Modified:jk/native/isapi jk_isapi_plugin.c
  Log:
  Initialize reco status
  
  Revision  ChangesPath
  1.4   +4 -1  jakarta-tomcat-connectors/jk/native/isapi/jk_isapi_plugin.c
  
  Index: jk_isapi_plugin.c
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/isapi/jk_isapi_plugin.c,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- jk_isapi_plugin.c 5 Nov 2003 09:15:38 -   1.3
  +++ jk_isapi_plugin.c 11 Feb 2004 09:57:42 -  1.4
  @@ -777,6 +777,9 @@
const char *name, *nameEnd;
const char *value, *valueEnd;
   
  + /* Clear RECO status */
  + s-reco_status  = RECO_NONE;
  +
while (hdrs  limit)
{
/* Skip line *before* doing anything, cos we want to lose the first 
line which
  
  
  

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



Re: failover-problem and session mixup: jakarta-tomcat-connectors/mod_jk: jk_ajp_common.c

2004-02-11 Thread Henri Gomez
Alexander Schwartz a écrit :

Am Di, den 10.02.2004 schrieb Henri Gomez um 15:52:


To fix this serious bug we should modify the current service API.

We should store the POSTED datas in the jk_ws_service_t area and
not in ajp_operation_t, as such the first worker will feed the POST
datas in an area which will be available to the second one.
Aternate idea are of course more than welcome;


As I understand it mod_jk is stable, almost deprecated, and mod_jk2
is the future. Therefore I suggest: 

   * no API change in mod_jk
   * mark the operation as unrecoverable when an error occurs after
 the headers have been sent to the tomcat, that is only fixing
 bugs and trying not to do big changes 
   * concentrate your efforts on mod_jk2 and give people a reason to 
 upgrade :)

Marking the operation as unrecoverable might also solve the other
(lb-)problem: when you shut down the first tomcat after it has already
sent some data to the client mod_jk forwards the request to the second
tomcat and appends the response of the second tomcat to the response of
the first tomcat. I'll deliver a sample jk.log soon. 
Ok, I commited changes in CVS which should fix problem in POST recovery.

Thanks to take a look at it

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


cvs commit: jakarta-tomcat-connectors/jk/native/netscape jk_nsapi_plugin.c

2004-02-11 Thread hgomez
hgomez  2004/02/11 01:58:45

  Modified:jk/native/netscape jk_nsapi_plugin.c
  Log:
  Initialize reco status
  
  Revision  ChangesPath
  1.10  +4 -1  jakarta-tomcat-connectors/jk/native/netscape/jk_nsapi_plugin.c
  
  Index: jk_nsapi_plugin.c
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/netscape/jk_nsapi_plugin.c,v
  retrieving revision 1.9
  retrieving revision 1.10
  diff -u -r1.9 -r1.10
  --- jk_nsapi_plugin.c 5 Nov 2003 09:15:41 -   1.9
  +++ jk_nsapi_plugin.c 11 Feb 2004 09:58:45 -  1.10
  @@ -404,6 +404,9 @@
   s-read = ws_read;
   s-write = ws_write;
   
  +/* Clear RECO status */
  +s-reco_status  = RECO_NONE;
  +
   s-auth_type= pblock_findval(auth-type, private_data-rq-vars);
   s-remote_user  = pblock_findval(auth-user, private_data-rq-vars);
   
  
  
  

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



[VOTE] 4.1.30 release vote

2004-02-11 Thread Tim Funk

 ballot
 Release 4.1.30 as Stable:
 [x] Yes
 [ ] No
 /ballot

-Tim

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


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

2004-02-11 Thread remm
remm2004/02/11 04:07:23

  Modified:catalina/src/share/org/apache/catalina/core
ApplicationDispatcher.java
  Log:
  - The forward request attributes must reflect the original request. So only set them
if the request being passed doesn't have them.
  
  Revision  ChangesPath
  1.29  +17 -15
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/ApplicationDispatcher.java
  
  Index: ApplicationDispatcher.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/ApplicationDispatcher.java,v
  retrieving revision 1.28
  retrieving revision 1.29
  diff -u -r1.28 -r1.29
  --- ApplicationDispatcher.java26 Jan 2004 19:47:03 -  1.28
  +++ ApplicationDispatcher.java11 Feb 2004 12:07:23 -  1.29
  @@ -423,17 +423,19 @@
   wrequest.setRequestURI(requestURI);
   wrequest.setServletPath(servletPath);
   wrequest.setPathInfo(pathInfo);
  -
  -wrequest.setAttribute(Globals.FORWARD_REQUEST_URI_ATTR,
  -  hrequest.getRequestURI());
  -wrequest.setAttribute(Globals.FORWARD_CONTEXT_PATH_ATTR,
  -  hrequest.getContextPath());
  -wrequest.setAttribute(Globals.FORWARD_SERVLET_PATH_ATTR,
  -  hrequest.getServletPath());
  -wrequest.setAttribute(Globals.FORWARD_PATH_INFO_ATTR,
  -  hrequest.getPathInfo());
  -wrequest.setAttribute(Globals.FORWARD_QUERY_STRING_ATTR,
  -  hrequest.getQueryString());
  +
  +if (hrequest.getAttribute(Globals.FORWARD_REQUEST_URI_ATTR) == null) {
  +wrequest.setAttribute(Globals.FORWARD_REQUEST_URI_ATTR,
  +  hrequest.getRequestURI());
  +wrequest.setAttribute(Globals.FORWARD_CONTEXT_PATH_ATTR,
  +  hrequest.getContextPath());
  +wrequest.setAttribute(Globals.FORWARD_SERVLET_PATH_ATTR,
  +  hrequest.getServletPath());
  +wrequest.setAttribute(Globals.FORWARD_PATH_INFO_ATTR,
  +  hrequest.getPathInfo());
  +wrequest.setAttribute(Globals.FORWARD_QUERY_STRING_ATTR,
  +  hrequest.getQueryString());
  +}

   if (queryString != null) {
   wrequest.setQueryString(queryString);
  
  
  

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



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

2004-02-11 Thread remm
remm2004/02/11 04:09:29

  Modified:catalina/src/share/org/apache/catalina/core
ApplicationHttpRequest.java
  Log:
  - Bug 26838: refactor once again the enum algorithm.
  - Delegate special getAttribute only if we're not in a forward.
  
  Revision  ChangesPath
  1.18  +30 -9 
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/ApplicationHttpRequest.java
  
  Index: ApplicationHttpRequest.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/ApplicationHttpRequest.java,v
  retrieving revision 1.17
  retrieving revision 1.18
  diff -u -r1.17 -r1.18
  --- ApplicationHttpRequest.java   2 Feb 2004 19:38:39 -   1.17
  +++ ApplicationHttpRequest.java   11 Feb 2004 12:09:29 -  1.18
  @@ -71,6 +71,7 @@
   import java.util.HashMap;
   import java.util.Iterator;
   import java.util.Map;
  +import java.util.NoSuchElementException;
   
   import javax.servlet.RequestDispatcher;
   import javax.servlet.http.HttpServletRequest;
  @@ -265,7 +266,8 @@
   if (pos == -1) {
   return getRequest().getAttribute(name);
   } else {
  -if ((specialAttributes[pos] == null)  (pos = 5)) {
  +if ((specialAttributes[pos] == null) 
  + (specialAttributes[5] == null)  (pos = 5)) {
   // If it's a forward special attribute, and null, it means this
   // is an include, so we check the wrapped request since 
   // the request could have been forwarded before the include
  @@ -881,30 +883,49 @@
   protected int pos = -1;
   protected int last = -1;
   protected Enumeration parentEnumeration = null;
  +protected String next = null;
   
   public AttributeNamesEnumerator() {
   parentEnumeration = getRequest().getAttributeNames();
   for (int i = 0; i  specialAttributes.length; i++) {
  -if (specialAttributes[i] != null) {
  +if (getAttribute(specials[i]) != null) {
   last = i;
   }
   }
   }
   
   public boolean hasMoreElements() {
  -return ((pos != last) || (parentEnumeration.hasMoreElements()));
  +return ((pos != last) || (next != null) 
  +|| ((next = findNext()) != null));
   }
   
   public Object nextElement() {
   if (pos != last) {
   for (int i = pos + 1; i = last; i++) {
  -if (specialAttributes[i] != null) {
  +if (getAttribute(specials[i]) != null) {
   pos = i;
   return (specials[i]);
   }
   }
   }
  -return parentEnumeration.nextElement();
  +String result = next;
  +if (next != null) {
  +next = findNext();
  +} else {
  +throw new NoSuchElementException();
  +}
  +return result;
  +}
  +
  +protected String findNext() {
  +String result = null;
  +while ((result == null)  (parentEnumeration.hasMoreElements())) {
  +String current = (String) parentEnumeration.nextElement();
  +if (!isSpecial(current)) {
  +result = current;
  +}
  +}
  +return result;
   }
   
   }
  
  
  

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



DO NOT REPLY [Bug 26838] - Improper handling of javax.servlet.include.query_string during a nested include with parameters

2004-02-11 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=26838.
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=26838

Improper handling of javax.servlet.include.query_string during a nested include with 
parameters

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2004-02-11 12:10 ---
This is now fixed.

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



cvs commit: jakarta-tomcat-5 tomcat.nsi

2004-02-11 Thread remm
remm2004/02/11 04:54:30

  Modified:.tomcat.nsi
  Log:
  - Add support for silent installations.
  
  Revision  ChangesPath
  1.42  +23 -1 jakarta-tomcat-5/tomcat.nsi
  
  Index: tomcat.nsi
  ===
  RCS file: /home/cvs/jakarta-tomcat-5/tomcat.nsi,v
  retrieving revision 1.41
  retrieving revision 1.42
  diff -u -r1.41 -r1.42
  --- tomcat.nsi1 Feb 2004 18:27:28 -   1.41
  +++ tomcat.nsi11 Feb 2004 12:54:30 -  1.42
  @@ -105,6 +105,7 @@
   
 SectionIn 1 2 3
   
  +  IfSilent +2 0
 Call checkJvm
   
 SetOutPath $INSTDIR
  @@ -122,7 +123,13 @@
 File /r webapps\balancer
 File /r webapps\ROOT
   
  +  IfSilent 0 +3
  +  Call findJavaPath
  +  Pop $2
  +
  +  IfSilent +2 0
 !insertmacro MUI_INSTALLOPTIONS_READ $2 jvm.ini Field 2 State
  +
 CopyFiles /SILENT $2\lib\tools.jar $INSTDIR\common\lib 4500
 ClearErrors
   
  @@ -136,7 +143,13 @@
   
 SectionIn 3
   
  +  IfSilent 0 +3
  +  Call findJavaPath
  +  Pop $2
  +
  +  IfSilent +2 0
 !insertmacro MUI_INSTALLOPTIONS_READ $2 jvm.ini Field 2 State
  +
 Push $2
 Call findJVMPath
 Pop $2
  @@ -392,7 +405,16 @@
 !insertmacro MUI_INSTALLOPTIONS_READ $R1 config.ini Field 5 State
 !insertmacro MUI_INSTALLOPTIONS_READ $R2 config.ini Field 7 State
   
  +  IfSilent 0 +2
  +  StrCpy $R4 'port=8080'
  +
  +  IfSilent +2 0
 StrCpy $R4 'port=$R0'
  +
  +  IfSilent 0 +2
  +  StrCpy $R5 ''
  +
  +  IfSilent +2 0
 StrCpy $R5 'user name=$R1 password=$R2 roles=admin,manager /'
   
 DetailPrint 'HTTP/1.1 Connector configured on port $R0'
  
  
  

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



Re: [VOTE] 4.1.30 release vote

2004-02-11 Thread Remy Maucherat
Tim Funk wrote:
  ballot
  Release 4.1.30 as Stable:
  [x] Yes
  [ ] No
  /ballot
You're my friend now :)
Any other votes ?
Rémy

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


Re: [PATCH] ./native/netscape/nsapi.dsp - remove obsolete files

2004-02-11 Thread Guenter Knauf
Hi Henri,
the patch below removes the obsolete files from the project file;
in addition I'd suggest to remove both *.dsw files from
./jk/native/netscape and ./jk/native/jni folders cause they are not
needed - MSVC creates then self.



 removed, should I do the same for isapi ?
yes, the *.dsw are all obsolete and useless - *.dsp are the single projects while 
*.dsw is normally the master work bench; so a *.dsw would only make sense if it would 
be in a higher level directory, and then include all other *.dsp so that they are 
compilable from one place; look for Apache as sample, there you have one Apache.dsw in 
the top-level dir which contains all other *.dsp

Guenter.


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



DO NOT REPLY [Bug 21502] - [PATCH]Manager doesn't use correct method to get number of active sessions

2004-02-11 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=21502.
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=21502

[PATCH]Manager doesn't use correct method to get number of active sessions

[EMAIL PROTECTED] changed:

   What|Removed |Added

Summary|[PATCH]Manager doesn't use  |[PATCH]Manager doesn't use
   |correct method to get number|correct method to get number
   |of active sessions  |of active sessions



--- Additional Comments From [EMAIL PROTECTED]  2004-02-11 13:58 ---
Anyone care about this?  I submitted it the middle of last year.

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



cvs commit: jakarta-tomcat-connectors/jk/support jk_apr.m4

2004-02-11 Thread jfclere
jfclere 2004/02/11 06:24:20

  Modified:jk/support jk_apr.m4
  Log:
  Add SHELL otherwise I get on ReliantUnix:
  ./configure[9038]: ./configure:  not found
  
  Revision  ChangesPath
  1.10  +2 -2  jakarta-tomcat-connectors/jk/support/jk_apr.m4
  
  Index: jk_apr.m4
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/support/jk_apr.m4,v
  retrieving revision 1.9
  retrieving revision 1.10
  diff -u -r1.9 -r1.10
  --- jk_apr.m4 6 Feb 2004 12:14:53 -   1.9
  +++ jk_apr.m4 11 Feb 2004 14:24:20 -  1.10
  @@ -129,7 +129,7 @@
   tempret=0
   JK_EXEC(
 [tempret],
  -  [./configure --enable-static --disable-shared ${APR_CONFIGURE_ARGS}],
  +  [${SHELL} ./configure --enable-static --disable-shared 
${APR_CONFIGURE_ARGS}],
 [apr],
 [${APR_DIR}])
   if ${TEST} ${tempret} = 0; then
  
  
  

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



cvs commit: jakarta-tomcat-connectors/jk/support jk_apr.m4

2004-02-11 Thread jfclere
jfclere 2004/02/11 07:08:14

  Modified:jk/support jk_apr.m4
  Log:
  Oops I missed this one.
  
  Revision  ChangesPath
  1.11  +2 -2  jakarta-tomcat-connectors/jk/support/jk_apr.m4
  
  Index: jk_apr.m4
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/support/jk_apr.m4,v
  retrieving revision 1.10
  retrieving revision 1.11
  diff -u -r1.10 -r1.11
  --- jk_apr.m4 11 Feb 2004 14:24:20 -  1.10
  +++ jk_apr.m4 11 Feb 2004 15:08:14 -  1.11
  @@ -195,7 +195,7 @@
   tempret=0
   JK_EXEC(
 [tempret],
  -  [./configure --with-apr=${APR_DIR}],
  +  [${SHELL} ./configure --with-apr=${APR_DIR}],
 [apr-util],
 [${APR_UTIL_DIR}])
   if ${TEST} ${tempret} = 0; then
  
  
  

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



performace tips

2004-02-11 Thread EBRARD Loic
Title: performace tips





Hi, 
I'm actually using tomcat 4.1 with apache 2.0 connected using mod_jk,
i use mod_deflate too,


and i'm searching any tips or modules or other to accelerate speed, improve performance, and so on


any idea welcome
regards



Loïc




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

Jboss + Tomcat and Database Stored Sessions

2004-02-11 Thread Hugo Kotsubo
Hi!

I'm using Jboss  3.2.1 with Tomcat 4.1.24, and Tomcat is running as a 
Jboss MBean.

I want to control the number of sessions each application can have. To 
do this, I'm trying to store
sessions in a postgresql database, and use the Tomcat PersistentManager 
Implementation.

The tomcat configuration is under the Jboss deploy directory, at the 
following path:

/opt/jboss/server/default/deploy/jbossweb-tomcat.sar/

In this directory I have all the jar files needed by tomcat, a web.xml 
file (shown below) and a META-INF directory,
with a manifest file and a jboss-service.xml file (shown below)

I guess that something is wrong with one of the xml files.
Can anyone help me?
thanks
Hugo Kotsubo
[EMAIL PROTECTED]

jboss-service.xml contents:
?xml version=1.0 encoding=UTF-8?
!-- The service configuration for the embedded Tomcat4.1.x web container
--
server
 mbean code=org.jboss.web.catalina.EmbeddedCatalinaService41
   name=jboss.web:service=WebServer
   attribute name=Java2ClassLoadingCompliancetrue/attribute

   !--
 ***
 ** CLUSTERING *
 ***
 In order to activate HTTP Session clustering for Tomcat
 make sure you run JBoss's all configuration i.e.
 run -c all
 (the default configuration doesn't contain clustering)

 Furthermore, you may change SnapshotMode and
 SnapshotInterval attributes below to indicate when to
 synchronize changes with the other node(s).

 If you use Apache+mod_jk(2) you will most probably use
 the AJP1.3 connector below. Thus, if you so wish,
 you may comment (i.e. deactivate) the HTTP connector
 as it won't be used anymore.
 ***
 ***
 ***
--

   !--
 If you are using clustering, the following two attributes
 define when the sessions are replicated to the other nodes.
 The default value, instant, synchronously replicates changes
 to the other nodes. In this case, the SnapshotInterval attribute
 is not used.
 The interval mode, in association with the SnapshotInterval
 attribute, indicates that Tomcat will only replicates modified
 sessions every SnapshotInterval miliseconds at most.
   --
   attribute name=SnapshotModeinstant/attribute !-- you may 
switch to interval --
   attribute name=SnapshotInterval2000/attribute

   attribute name=Config
 Server
Service name = JBoss-Tomcat
   Engine name=MainEngine defaultHost=localhost
  Logger className = org.jboss.web.catalina.Log4jLogger
 verbosityLevel = debug category = 
org.jboss.web.localhost.Engine/
  Host name=localhost

 !-- Access logger --
 Valve className = 
org.apache.catalina.valves.AccessLogValve
prefix = localhost_access suffix = .log
pattern = common directory = 
${jboss.server.home.dir}/log /

 !-- Default context parameters --
 DefaultContext cookies = true crossContext = true 
override = true
 Manager 
className=org.apache.catalina.session.PersistentManager
  debug=0 saveOnRestart=true 
maxActiveSessions=-1
  minIdleSwap=-1 maxIdleSwap=-1 
maxIdleBackup=-1
   Store 
className=org.apache.catalina.session.JDBCStore 
driverName=org.postgresql.Driver
  
connectionURL=jdbc:postgresql://localhost:5432/hugo-bi?user=hugoamp;password=hugo
  sessionTable=tomcatsessions sessionIdCol=id
  sessionDataCol=data sessionValidCol=valid 
sessionAppCol=appname
  sessionMaxInactiveCol=maxinactive 
sessionLastAccessedCol=lastaccess
  checkInterval=60 debug=99 /
 /Manager
 /DefaultContext
  /Host
   /Engine

   !-- A HTTP/1.1 Connector on port 8080 --
   Connector className=org.apache.coyote.tomcat4.CoyoteConnector
  port=8080 minProcessors=3 maxProcessors=10
  enableLookups=true acceptCount=10 debug=0
  connectionTimeout=2 useURIValidationHack=false /
   !-- A AJP 1.3 Connector on port 8009 --
   Connector className=org.apache.coyote.tomcat4.CoyoteConnector
  port=8009 minProcessors=5 maxProcessors=75
  enableLookups=true redirectPort=8443
  acceptCount=10 debug=0 connectionTimeout=2
  useURIValidationHack=false
  
protocolHandlerClassName=org.apache.jk.server.JkCoyoteHandler/


cvs commit: jakarta-tomcat/proposals/JmxSupport build.xml

2004-02-11 Thread larryi
larryi  2004/02/11 08:24:14

  Modified:proposals/JmxSupport build.xml
  Log:
  Include the jmxtools jar in the classpath so this add-on can build.
  
  Revision  ChangesPath
  1.3   +1 -0  jakarta-tomcat/proposals/JmxSupport/build.xml
  
  Index: build.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat/proposals/JmxSupport/build.xml,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- build.xml 13 Oct 2003 09:45:05 -  1.2
  +++ build.xml 11 Feb 2004 16:24:14 -  1.3
  @@ -60,6 +60,7 @@
  destdir=${tomcat.build.modules}/JmxSupport/WEB-INF/classes
  classpath path=${tomcat.classes}/
  classpath location=${jmx.jar}/
  +   classpath location=${jmxtools.jar}/
  classpath location=${commons-logging.jar}/
   /javac
   
  
  
  

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



Re: [PATCH] ./native/netscape/nsapi.dsp - remove obsolete files

2004-02-11 Thread Mike Anderson
 [EMAIL PROTECTED] 2/11/2004 2:11:08 AM 
Mike Anderson a écrit :
 It's fine by me.  Günter is correct that MSVC will create these as necessary and 
 you can build without them.  
I'd do it, but I'm clueless about the proper procedure in CVS (being a 
Windows/NetWare weenie:-)  I'm learning though.

I'm using Eclipse and it rocks in the CVS area :)

I better get it and try it then, especially since Novell (my paycheck :-) is now 
joined Eclipse.

 
 Mike Anderson
 
 
[EMAIL PROTECTED] 2/9/2004 5:05:53 AM 
 
 Günter Knauf a écrit :
 
 
Hi,
the patch below removes the obsolete files from the project file; 
in addition I'd suggest to remove both *.dsw files from ./jk/native/netscape and 
./jk/native/jni folders cause they are not needed - MSVC creates then self.
 
 

removed, should I do the same for isapi ?

I think that would be appropriate.  These files are basically just the workspace 
settings and they aren't needed to build the project.

Mike Anderson


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



DO NOT REPLY [Bug 13983] - RMI call from Web Application throws SocketException if CATALINA_HOME has a space in it

2004-02-11 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=13983.
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=13983

RMI call from Web Application throws SocketException if CATALINA_HOME has a space in it





--- Additional Comments From [EMAIL PROTECTED]  2004-02-11 18:19 ---
I was able to fix this problem by changing the getURL method in the 
Webappclassloader. Also, i've only tested this with 4.1.29 so, even though i 
think this will work with other versions, its not been tested with those.

Here is the new getURL method

protected URL getURL(File file)
throws MalformedURLException {

File realFile = file;
try {
realFile = realFile.getCanonicalFile();
} catch (IOException e) {
// Ignore
}

String fileStr = file: + realFile.getPath();
StringBuffer sb = new StringBuffer(fileStr.length());
for(int i=0; i fileStr.length();i++)
{
char c = fileStr.charAt(i);
if(c != ' ')
{
sb.append(c);
}
else
{
sb.append(%20);
}
}
return new URL(sb.toString());
}

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



cvs commit: jakarta-tomcat-connectors/jk/support jk_java.m4

2004-02-11 Thread truk
truk2004/02/11 10:40:58

  Modified:jk/support jk_java.m4
  Log:
  make sure JAVA_HOME is not picked up from env when use_jni is false
  
  Revision  ChangesPath
  1.6   +5 -1  jakarta-tomcat-connectors/jk/support/jk_java.m4
  
  Index: jk_java.m4
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/support/jk_java.m4,v
  retrieving revision 1.5
  retrieving revision 1.6
  diff -u -r1.5 -r1.6
  --- jk_java.m45 Nov 2003 09:14:28 -   1.5
  +++ jk_java.m411 Feb 2004 18:40:58 -  1.6
  @@ -213,6 +213,10 @@
  AC_MSG_RESULT(${JAVA_PLATFORM})
   
 unset tempval
  +else
  +  # no jni, then make sure JAVA_HOME is not picked up from env
  +  JAVA_HOME=
  +  JAVA_PLATFORM=
   fi
 ])
   
  
  
  

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



{Virus?} test

2004-02-11 Thread craigmcc
Warning: This message has had one or more attachments removed
Warning: (doc.zip).
Warning: Please read the VirusWarning.txt attachment(s) for more information.

The message contains Unicode characters and has been sent as a binary attachment.

This is a message from the MailScanner E-Mail Virus Protection Service
--
The original e-mail attachment doc.zip
was believed to be infected by a virus and has been replaced by this warning
message.

If you wish to receive a copy of the *infected* attachment, please

message in your request. Alternatively, you can call them, with the
contents of this message to hand when you call.

At Wed Feb 11 18:48:57 2004 the virus scanner said:
   doc.zipFound the W32/[EMAIL PROTECTED] virus !!!

Note to Help Desk: Look on yttrium in /var/spool/MailScanner/quarantine/20040211 
(message i1BImp3U004846).
-- 

MailScanner thanks transtec Computers for their support

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

DO NOT REPLY [Bug 14228] - Environment entries inaccessible to servlet init()

2004-02-11 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=14228.
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=14228

Environment  entries inaccessible to servlet init()

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|WORKSFORME  |



--- Additional Comments From [EMAIL PROTECTED]  2004-02-11 20:32 ---
Sorry, closed this one too quickly. The test case doesn't work for me. I'll 
look into this some more.

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



[PROPOSED PATCH] Bugs 13833 and 14228

2004-02-11 Thread Mark Thomas
All,

The patch below fixes (I believe) the following bugs:
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13833
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14228

I am not 100% confident about this patch and would therefore appreciate some
feedback before I commit it.

The reasoning behind the patch is that some of the context initialisation (for
bug 14228 the environment entries defined in the default context) occurs as a
result of firing the AFTER_START_EVENT. Therefore, the load on startup
servlets should only be loaded after this initialisation has taken place. The
additional exception addresses bug 13833.

Thanks in advance for your feedback,

Mark

Index: catalina/src/share/org/apache/catalina/core/StandardContext.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/Standar
dContext.java,v
retrieving revision 1.122
diff -u -r1.122 StandardContext.java
--- catalina/src/share/org/apache/catalina/core/StandardContext.java27 Dec
2003 20:37:58 - 1.122
+++ catalina/src/share/org/apache/catalina/core/StandardContext.java11 Feb
2004 23:24:44 -
@@ -3623,10 +3623,6 @@
 ok = false;
 }
 
-// Load and initialize all load on startup servlets
-if (ok)
-loadOnStartup(findChildren());
-
 // Unbinding thread
 unbindThread(oldCCL);
 
@@ -3643,11 +3639,16 @@
 log(sm.getString(standardContext.startCleanup), t);
 }
 setAvailable(false);
+throw new
LifecycleException(sm.getString(standardContext.startFailed));
 }
 
 // Notify our interested LifecycleListeners
 lifecycle.fireLifecycleEvent(AFTER_START_EVENT, null);
 
+// Load and initialize all load on startup servlets
+oldCCL = bindThread();
+loadOnStartup(findChildren());
+unbindThread(oldCCL);
 }



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



DO NOT REPLY [Bug 26760] - bean:define / issue.

2004-02-11 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=26760.
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=26760

bean:define / issue.

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID



--- Additional Comments From [EMAIL PROTECTED]  2004-02-11 23:56 ---
Closing for same reason as BZ 26761

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26761

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



Re: Mod_Jk2 - Default Worker

2004-02-11 Thread NormW
Good morning Costin.
Apologies for the silence. I had hoped there might have been a little more
input from others on this topic.

 NormW wrote:
  Good morning Costin.
  Thanks for the time given to replying.
  I agree with the ideas you have given, of decoupling URI's from workers
  explicitly tied to a communications protocol, but in reality this
  connectivity is supported and actually gives the minimum workable
  configuration. But given that a default architecture is but a 'guess', I
see
  the programming to be 'cleaner' without such defaults and rather provide
a
  'default' configuration file that would achieve the same end. The
present
  situation hides the basic building blocks of Mod_Jk2 and leads to the
  majority of questions in regard to how to reconfigure the module. Remove
the
  ability of 'workers' to directly accept requests and force all URI's
through
  an lb type, and the current default approach would be entirely
appropriate.

 Yes, it would be nice to make a clean cut and use a different interface
 for protocol workers ( channels ) and lb and similar request processors.

 Lb is not only load balancing - it also implements fail over and can
 be used to accept registration for tomcat instances - i.e. a sort of
 zero config, with tomcat instance(s) announcing themself to lb.

 nameurigroup   context
  * null   null   null
  *//   lb:lb  /
 
  Given the present arrangement, I can understand (if not support) the
lb:lb
  uri entry above but the one assigned to a 'null' group with a uri of
'null'
  seems to be a bug.

 It is a bug. Even the second can be considered a bug - if no tomcat
 instance is present there is no need for an lb:lb.
* With a release of mod_jk2 imminent, someone might look at this perhaps?

 However the most common case is to have at least one tomcat, and there
 is no real benefit in supporting an arbitrary name for the worker (
 lb:lb ) or in mapping the request directly to the protocol. I think the
 goal should be to have the protocol ( ajp worker ) register itself
 automatically with the lb:lb.
That mapping only exists now because it is implemented by the worker. The
worker is the logical recipient if the functionality offered by the lb
worker was not required. (There is enough for a worker to manage, even
without the protocol, to justify its existence as an object.). All that is
missing from the scenario is the protocol to be a part of the channel or
perhaps an intermediate layer.

 In the advanced case, of multiple pools or instances handling different
 webapps - there is no harm in having a default ( lb:lb ) and explicitely
 mapping the webapps that don't fall into the default with lb:GROUP
 names. This case can be zero-configured by having each tomcat instance
 self-register with ajp URI and GROUP ( plus the webapps )
Given the diversity of structures that mod_jk2 can implement, having a
default configuration only caters for a portion of them. Catering for none
forces 'exposure' of the few building blocks that mod_jk2 actually has
available, and would help to remove a lot of the mod_jk/jk2 mystique.

 IMO getting to this point requires removing some of the (arbitrary )
 flexibility in naming workers or bypassing the lb.
From an 'objects' perspective, it is inconsistent with current practice to
'parse' object names (CN in ldap parlence) for properties of the object,
when those properties have unique identifiers such as port and host. Hence I
support arbitrary naming ;-(


 
  As noted, the proposed patch subtracts nothing from the present
position,
  while allowing access to the parameter if required.


 That's a very common problem - having additional configuration
 flexibility, but without any immediate benefit. It doesn't substract
 anything, but it may prevent future simplifications.
Point taken. Equally, it's absence today shouldn't automatically mitigated
against its existence tomorrow. If 'mod_jk3' should evolve perhaps



 I'm ok with any renaming or clarification or defaults - as long as we
keep
 or increase the current separation between protocols ( i.e. ajp-like
 workers ) and clusters/instances - or however you want to call the
 lb-like workers.
 
  That tie-up exists because the worker name was derived from the
protocol.
  Ideally the protocol should have been in the channel, leaving the
'worker'
  to handle _a_ request, and lb to decide which worker to get it...
assuming
  there is more than one Tomcat to receive it. However, it still doesn't
make
  much sense to have a balancer capability in front of a single worker.

 I think we discussed this a lot in the past - and my proposal was to
 stop using the term worker :-)  The request is mapped by a mapper that
 decides if it's a servlet and to which group it should go ( with
 lb:lb as a clear default ), then the lb decides on a particular channel.

 mod_jk1 does this using a single concept - worker, in jk2 I think a lot
 have changed to split things into 

Re: Mod_Jk2 - Default Worker

2004-02-11 Thread Costin Manolache
NormW wrote:
Good morning Costin.
Apologies for the silence. I had hoped there might have been a little more
input from others on this topic.
Same here :-)


However the most common case is to have at least one tomcat, and there
is no real benefit in supporting an arbitrary name for the worker (
lb:lb ) or in mapping the request directly to the protocol. I think the
goal should be to have the protocol ( ajp worker ) register itself
automatically with the lb:lb.
That mapping only exists now because it is implemented by the worker. The
worker is the logical recipient if the functionality offered by the lb
worker was not required. (There is enough for a worker to manage, even
without the protocol, to justify its existence as an object.). All that is
missing from the scenario is the protocol to be a part of the channel or
perhaps an intermediate layer.
Not sure what you mean - the worker name is very overloaded, there are 
many ways to interpret.

My point was that the mapping is done between a URI and a tomcat ( 
either a standalone instance or a group ). This is represented by lb - 
which should be the only target for the mapping.

The lb will then use a channel ( ajp object ) to connect to the tomcat. 
The role of lb is to implement the forwarding of the request via the 
ajp object, with load balancing or failover ( if multiple channel/ajp 
objects exist ).

The fact that both the channel ( ajp ) and the lb are implementing the 
worker interface is IMO confusing. I think it's better to have an lb 
that can dynamically be configured with more channels, does retry, 
balancing and failover - as a separate entity- separated from the 
channel ( that just forwards a request ).



IMO getting to this point requires removing some of the (arbitrary )
flexibility in naming workers or bypassing the lb.

From an 'objects' perspective, it is inconsistent with current practice to
'parse' object names (CN in ldap parlence) for properties of the object,
when those properties have unique identifiers such as port and host. Hence I
support arbitrary naming ;-(
CN ( and distinguished names in JNDI as well as jmx object names ) is 
the source for the object names in jk2.

I know it's a religious issue if the name should mean something or not - 
 and probably that's a reason we'll have to keep supporting the 
arbitrary names.

IMO we should deprecate the arbitrary names and only support JMX-like 
object names, with using the properties to extract information like 
host, etc.

In any case - it's Henri and the other people actively involved in this 
release you need to convince :-)

Costin

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


DO NOT REPLY [Bug 26879] New: - java.net.MalformedURLException: java.lang.NullPointerException: invalid url: jndi:/localhost/WEB-INF/lib/webclient-topo.jar!/ (java.net.MalformedURLException: unknown protocol: jndi)

2004-02-11 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=26879.
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=26879

java.net.MalformedURLException: java.lang.NullPointerException: invalid url: 
jndi:/localhost/WEB-INF/lib/webclient-topo.jar!/ (java.net.MalformedURLException: 
unknown protocol: jndi)

   Summary: java.net.MalformedURLException:
java.lang.NullPointerException: invalid url:
jndi:/localhost/WEB-INF/lib/webclient-topo.jar!/
(java.net.MalformedURLException: unknown protocol: jndi)
   Product: Tomcat 4
   Version: 4.1.27
  Platform: Other
OS/Version: Windows NT/2K
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
CC: [EMAIL PROTECTED]


Hi,

I have a java application which uses tomcat(version 4.1.27). If I run my 
application as a standalone there is no problem. Everything works fine.

If I invoke my application through weblogic server(version 6.1), I am getting 
problem in startup of tomcat. The following is the error message I am getting 
in the tomcat logs. Anyone aware of this issue?. Please let me know what is 
going wrong here.




jndi:/localhost/WEB-INF/lib/webclient-topo.jar
2004-02-12 11:18:18 ContextConfig[] Exception processing JAR at resource 
path /WEB-INF/lib/webclient-topo.jar
javax.servlet.ServletException: Exception processing JAR at resource path /WEB-
INF/lib/webclient-topo.jar
at org.apache.catalina.startup.ContextConfig.tldScanJar
(ContextConfig.java:949)
at org.apache.catalina.startup.ContextConfig.tldScan
(ContextConfig.java:869)
at org.apache.catalina.startup.ContextConfig.start
(ContextConfig.java:648)
at org.apache.catalina.startup.ContextConfig.lifecycleEvent
(ContextConfig.java:244)
at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent
(LifecycleSupport.java:166)
at org.apache.catalina.core.StandardContext.start
(StandardContext.java:3568)
at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1188)
at org.apache.catalina.core.StandardHost.start(StandardHost.java:738)
at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1188)
at org.apache.catalina.core.StandardEngine.start
(StandardEngine.java:347)
at org.apache.catalina.core.StandardService.start
(StandardService.java:497)
at org.apache.catalina.core.StandardServer.start
(StandardServer.java:2229)
at org.apache.catalina.startup.Catalina.start(Catalina.java:526)
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:210)
at java.lang.reflect.Method.invoke(Native Method)
at com.adventnet.nms.util.RunJSPModule.startJSPModule
(RunJSPModule.java:89)
at com.adventnet.nms.util.RunJSPModule$1.run(RunJSPModule.java:141)
at java.lang.Thread.run(Thread.java:484)
- Root Cause -
java.net.MalformedURLException: java.lang.NullPointerException: invalid url: 
jndi:/localhost/WEB-INF/lib/webclient-topo.jar!/ 
(java.net.MalformedURLException: unknown protocol: jndi)
at java.net.URL.init(URL.java:496)
at java.net.URL.init(URL.java:376)
at java.net.URL.init(URL.java:330)
at org.apache.catalina.startup.ContextConfig.tldScanJar
(ContextConfig.java:921)
at org.apache.catalina.startup.ContextConfig.tldScan
(ContextConfig.java:869)
at org.apache.catalina.startup.ContextConfig.start
(ContextConfig.java:648)
at org.apache.catalina.startup.ContextConfig.lifecycleEvent
(ContextConfig.java:244)
at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent
(LifecycleSupport.java:166)
at org.apache.catalina.core.StandardContext.start
(StandardContext.java:3568)
at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1188)
at org.apache.catalina.core.StandardHost.start(StandardHost.java:738)
at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1188)
at org.apache.catalina.core.StandardEngine.start
(StandardEngine.java:347)
at org.apache.catalina.core.StandardService.start
(StandardService.java:497)
at org.apache.catalina.core.StandardServer.start
(StandardServer.java:2229)
at org.apache.catalina.startup.Catalina.start(Catalina.java:526)
at org.apache.catalina.startup.Catalina.execute(Catalina.java:400)
at 

[GUMP@lsd]: jakarta-tomcat-5/jakarta-tomcat-5 failed

2004-02-11 Thread bobh
To whom is may concern,

This is an automated request, but not an unsolicited one. Please see: 
http://jakarta.apache.org/gump/nagged.html

Project: jakarta-tomcat-5 has an issue affecting it's community integration.
State: Failed

The URL for full details is: 
http://lsd.student.utwente.nl/gump/jakarta-tomcat-5/jakarta-tomcat-5.html

- - - - - G U M P Y


Gump provided these annotations:

 - Warning - Jar [/data/gump/jakarta-tomcat-5/dist/server/lib/servlets-default.jar] 
identifier set to jar basename: [servlets-default.jar]
 - Warning - Jar [/data/gump/jakarta-tomcat-5/dist/common/lib/naming-common.jar] 
identifier set to jar basename: [naming-common.jar]
 - Warning - Jar [/data/gump/jakarta-tomcat-5/dist/common/lib/naming-resources.jar] 
identifier set to jar basename: [naming-resources.jar]
 - Warning - Jar [/data/gump/jakarta-tomcat-5/dist/server/lib/catalina.jar] identifier 
set to jar basename: [catalina.jar]
 - Warning - Jar [/data/gump/jakarta-tomcat-5/dist/bin/bootstrap.jar] identifier set 
to jar basename: [bootstrap.jar]
 - Warning - Jar [/data/gump/jakarta-tomcat-5/dist/server/lib/servlets-common.jar] 
identifier set to jar basename: [servlets-common.jar]
 - Warning - Jar [/data/gump/jakarta-tomcat-5/dist/server/lib/servlets-invoker.jar] 
identifier set to jar basename: [servlets-invoker.jar]
 - Info - Dependency on javamail exists, no need to add for property mail.jar.
 - Info - Dependency on jaf exists, no need to add for property activation.jar.
 - Info - Dependency on jakarta-servletapi-5-servlet exists, no need to add for 
property servlet-api.jar.
 - Info - Dependency on jakarta-servletapi-5-jsp exists, no need to add for property 
jsp-api.jar.
 - Info - Dependency on xml-xerces exists, no need to add for property xercesImpl.jar.
 - Info - Dependency on xml-xerces exists, no need to add for property 
xmlParserAPIs.jar.
 - Info - Dependency on jakarta-tomcat-util exists, no need to add for property 
tomcat-util.jar.
 - Info - Dependency on commons-el exists, no need to add for property commons-el.jar.
 - Info - Dependency on commons-logging exists, no need to add for property 
commons-logging-api.jar.
 - Info - Dependency on commons-modeler exists, no need to add for property 
commons-modeler.jar.
 - Info - Dependency on ant exists, no need to add for property ant.home.
 - Info - Dependency on jsse exists, no need to add for property jsse.home.
 - Info - Dependency on jmx exists, no need to add for property jmx.home.
 - Info - Dependency on jmx exists, no need to add for property jmx.jar.
 - Info - Dependency on jmx exists, no need to add for property jmx-tools.jar.
 - Info - Dependency on jndi exists, no need to add for property jndi.home.
 - Info - Dependency on jakarta-regexp exists, no need to add for property regexp.home.
 - Info - Dependency on jakarta-regexp exists, no need to add for property regexp.jar.
 - Info - Dependency on javamail exists, no need to add for property mail.home.
 - Info - Dependency on jakarta-tomcat-coyote exists, no need to add for property 
tomcat-coyote.home.
 - Info - Dependency on jakarta-tomcat-jasper_tc5 exists, no need to add for property 
jasper.home.
 - Info - Dependency on jaf exists, no need to add for property activation.home.
 - Info - Dependency on commons-modeler exists, no need to add for property 
commons-modeler.home.
 - Info - Dependency on commons-daemon exists, no need to add for property 
commons-daemon.jsvc.tar.gz.
 - Error - Failed with reason build failed


- - - - - G U M P Y

Gump performed this work:

Work Name: build_jakarta-tomcat-5_jakarta-tomcat-5 (Type: Build)
State: Failed
Elapsed: 0 hours, 2 minutes, 1 seconds
Command Line: java -Djava.awt.headless=true 
-Xbootclasspath/p:/data/gump/xml-xerces2/java/build/xercesImpl.jar:/data/gump/xml-xerces2/java/build/xmlParserAPIs.jar:/data/gump/xml-xalan/java/build/xalan-unbundled.jar:/data/gump/xml-commons/java/external/build/xml-apis.jar
 org.apache.tools.ant.Main -Dbuild.clonevm=true 
-Dgump.merge=/data/gump/gump/work/merge.xml -Dbuild.sysclasspath=only 
-Dtomcat33.home=*Unset* 
-Djsp-api.jar=/data/gump/jakarta-servletapi-5/jsr152/dist/lib/jsp-api.jar 
-Dtomcat-coyote.home=/data/gump/jakarta-tomcat-connectors/coyote 
-Djndi.jar=/data/gump/opt/jndi1_2_1/lib/jndi.jar -Dsite2.home=/data/gump/jakarta-site2 
-DxmlParserAPIs.jar=/data/gump/xml-xerces2/java/build/xercesImpl.jar 
-Dactivation.home=/data/gump/opt/jaf-1.0.1 -Djmx.home=/data/gump/opt/jmx-1_2-ri 
-Djdbc20ext.jar=/data/gump/opt/jdbc2_0/jdbc2_0-stdext.jar 
-Djmx-tools.jar=/data/gump/opt/jmx-1_2-ri/lib/jmxtools.jar 
-Dregexp.jar=/data/gump/jakarta-regexp/build/jakarta-regexp-20040212.jar 
-Dmail.home=/data/gump/opt/javamail-1.3 -Dant.home=/data/gump/ant/dist 
-Dcommons-modeler.home=/data/gump/jakarta-commons/modeler 
-Dcommons-launcher.jar=/data/gump/jakarta-commons/launcher/dist/bin/commons-launcher.jar