Re: cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasperEmbededServletOptions.java

[Glenn Nielsen]

Will this be ported to the tomcat_4_branch of jasper and Tomcat 4.1?

[EMAIL PROTECTED] wrote:

remm2003/01/01 07:21:01

  Modified:jasper2/src/share/org/apache/jasper
EmbededServletOptions.java
  Log:
  - Due to continued problems with javac, I think fork should default to true.
  
  Revision  ChangesPath
  1.17  +4 -4  jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/EmbededServletOptions.java
  
  Index: EmbededServletOptions.java
  ===
  RCS file: /home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/EmbededServletOptions.java,v
  retrieving revision 1.16
  retrieving revision 1.17
  diff -u -r1.16 -r1.17
  --- EmbededServletOptions.java	31 Dec 2002 14:01:17 -	1.16
  +++ EmbededServletOptions.java	1 Jan 2003 15:21:01 -	1.17
  @@ -93,7 +93,7 @@
   /**
* Should Ant fork its java compiles of JSP pages.
*/
  -public boolean fork = false;
  +public boolean fork = true;
   
   /**
* Do you want to keep the generated Java files around?
  
  
  

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




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

DO NOT REPLY [Bug 15758] New: - When the login authentication is null, Tomcat bombs out with a NullPointerException

[bugzilla]

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

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

When the login authentication is null, Tomcat bombs out with a NullPointerException

   Summary: When the login authentication is null, Tomcat bombs out
with a NullPointerException
   Product: Tomcat 4
   Version: 4.1.18
  Platform: PC
OS/Version: Windows 9x
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


The line of code that goes wrong is:
authenticatorName =  authenticators.getString(loginConfig.getAuthMethod());

The error reported is
java.lang.NullPointerException
at java.util.PropertyResourceBundle.handleGetObject
(PropertyResourceBundle.java:103)
at java.util.ResourceBundle.getObject(ResourceBundle.java:308)
at java.util.ResourceBundle.getString(ResourceBundle.java:274)
at org.apache.catalina.startup.ContextConfig.authenticatorConfig
(ContextConfig.java:365)
at org.apache.catalina.startup.ContextConfig.start
(ContextConfig.java:661)
at org.apache.catalina.startup.ContextConfig.lifecycleEvent
(ContextConfig.java:243)
at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent
(LifecycleSupport.java:166)
...

The relevant (I think) bit of web.xml is
  

  /Login/Login.jsp
  /Login/FailedLogin.jsp

  

This is my first bug report to the Jakarta project, so any feedback on what you 
expect would be appreciated

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

DO NOT REPLY [Bug 15759] New: - CGI Servlet does not preserve the POST data encoding

[bugzilla]

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

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

CGI Servlet does not preserve the POST data encoding

   Summary: CGI Servlet does not preserve the POST data encoding
   Product: Tomcat 4
   Version: 4.1.18
  Platform: PC
OS/Version: Windows XP
Status: NEW
  Severity: Minor
  Priority: Other
 Component: Servlets:CGI
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


When I submit "http://./test.cgi?name=XXX"; where XXX is encoded using
Shift_JIS(Japanese), CGI Servlet re-encodes XXX using ISO-8859-01. As a result,
the cgi script does not function properly.

For example, while XXX should be "%82%B1%82%F1%82%C9%82%BF%82%CD" ("hello" in
Japanese using Shift_JIS encoding), CGI Servlet gives "%3F%3F%3F%3F%3F" instead.

I had a quick look at org.apache.catalina.servlets.CGIServlet.java and I think
the problem comes from the constructor of CGIEnvironment. It uses
java.net.URLEncoder#Encode(String) which will encode the string inappropriately.
(Although I have not tested yet.)

Thanks.

Tomcat: 4.1.18-LE-jdk14 (Standalone)
SDK: 1.4.1_01-b01
Platform: Windows XP(English version) + Multi Language Pack

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

cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/ajp/tomcat4 Ajp13Processor.java

[glenn]

glenn   2003/01/02 04:57:53

  Modified:jk/java/org/apache/ajp/tomcat4 Ajp13Processor.java
  Log:
  Make sure Ajp never gets hung due to an Exception
  
  Revision  ChangesPath
  1.11  +28 -11
jakarta-tomcat-connectors/jk/java/org/apache/ajp/tomcat4/Ajp13Processor.java
  
  Index: Ajp13Processor.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/jk/java/org/apache/ajp/tomcat4/Ajp13Processor.java,v
  retrieving revision 1.10
  retrieving revision 1.11
  diff -u -r1.10 -r1.11
  --- Ajp13Processor.java   30 Dec 2002 16:00:32 -  1.10
  +++ Ajp13Processor.java   2 Jan 2003 12:57:53 -   1.11
  @@ -462,9 +462,23 @@
   }
   
   if (!bad_request) {
  -connector.getContainer().invoke(request, response);
  +try {
  +connector.getContainer().invoke(request, response);
  +} catch (IOException ioe) {
  +// Pass the IOException through
  +throw ioe;
  +} catch (Throwable e) {
  +// A throwable here could be caused by a Valve,
  +// Filter, or other component in the chain.
  +// Processing of the request failed, return an
  +// Internal Server Error
  +logger.log("process: invoke", e);
  +response.sendError
  +(HttpServletResponse.SC_INTERNAL_SERVER_ERROR);
  +}
   } else {
  -response.sendError(400);
  +response.sendError
  +(HttpServletResponse.SC_BAD_REQUEST);
   }
   
   if (debug > 0) {
  @@ -480,13 +494,16 @@
   
   } catch (IOException ioe) {
   // Normally this catches a socket Broken Pipe caused by the
  -// remote client aborting the request. mod_jk will close the
  -// socket on its side and the processor will get a socket EOF
  -// when it next tries to read from mod_jk, then recycle itself
  -// normally. Don't print the stack trace in this case.
  +// remote client aborting the request. Don't print the stack
  +// trace in this case. Then let the Processor recycle.
   logger.log("process: IOException " + ioe.getMessage());
  +moreRequests = false;
   } catch (Throwable e) {
  -logger.log("process: invoke", e);
  +// Processing the request and sending the response failed.
  +// We don't know what the state of the Ajp Connector socket
  +// is in. Bail out and recycle the Processor.
  +logger.log("process: finish", e);
  +moreRequests = false;
   }
   
   // Recycling the request and the response objects
  
  
  

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

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

[glenn]

glenn   2003/01/02 04:58:58

  Modified:jk/native/apache-1.3 mod_jk.c
   jk/native/apache-2.0 mod_jk.c
  Log:
  Make sure http errors are handled by Apache if not handled by Tomcat
  
  Revision  ChangesPath
  1.34  +6 -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.33
  retrieving revision 1.34
  diff -u -r1.33 -r1.34
  --- mod_jk.c  16 Dec 2002 08:54:55 -  1.33
  +++ mod_jk.c  2 Jan 2003 12:58:57 -   1.34
  @@ -1609,6 +1609,11 @@
   jk_close_pool(&private_data.p);
   
   if(rc) {
  +/* If tomcat returned no body and the status is not OK,
  +   let apache handle the error code */
  +if( !r->sent_bodyct && r->status != HTTP_OK ) {
  +return r->status;
  +}
   return OK;  /* NOT r->status, even if it has changed. */
   }
   }
  
  
  
  1.64  +6 -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.63
  retrieving revision 1.64
  diff -u -r1.63 -r1.64
  --- mod_jk.c  30 Dec 2002 04:05:39 -  1.63
  +++ mod_jk.c  2 Jan 2003 12:58:57 -   1.64
  @@ -1834,6 +1834,11 @@
   jk_close_pool(&private_data.p);
   
   if(rc) {
  +/* If tomcat returned no body and the status is not OK,
  +   let apache handle the error code */
  +if( !r->sent_bodyct && r->status != HTTP_OK ) {
  +return r->status;
  +}
   return OK;/* NOT r->status, even if it has changed. */
   } else
   return HTTP_INTERNAL_SERVER_ERROR;
  
  
  

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

cvs commit: jakarta-tomcat-connectors/jk/native CHANGES.txt

[glenn]

glenn   2003/01/02 05:00:59

  Modified:jk/native CHANGES.txt
  Log:
  Update changes
  
  Revision  ChangesPath
  1.8   +3 -1  jakarta-tomcat-connectors/jk/native/CHANGES.txt
  
  Index: CHANGES.txt
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/CHANGES.txt,v
  retrieving revision 1.7
  retrieving revision 1.8
  diff -u -r1.7 -r1.8
  --- CHANGES.txt   30 Dec 2002 14:10:20 -  1.7
  +++ CHANGES.txt   2 Jan 2003 13:00:59 -   1.8
  @@ -4,6 +4,8 @@
   Changes with JK 1.2.3:
   * Add JkAutoAlias to Apache 2.0
 [glenn]
  +* Apache 2/1.3, if Tomcat returns an error but not content,
  +  let Apache handle processing the error returned by Tomcat.
   
   Changes with JK 1.2.2:
   * tomcat_trend.pl updated script to support changed logging of 
  
  
  

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

cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/valves RequestFilterValve.java

[glenn]

glenn   2003/01/02 05:03:16

  Modified:catalina/src/share/org/apache/catalina/valves
RequestFilterValve.java
  Log:
  Catch null pointer property to match on, deny by default if found
  
  Revision  ChangesPath
  1.5   +16 -4 
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/valves/RequestFilterValve.java
  
  Index: RequestFilterValve.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/valves/RequestFilterValve.java,v
  retrieving revision 1.4
  retrieving revision 1.5
  diff -u -r1.4 -r1.5
  --- RequestFilterValve.java   22 Jul 2001 20:25:15 -  1.4
  +++ RequestFilterValve.java   2 Jan 2003 13:03:16 -   1.5
  @@ -306,6 +306,18 @@
  ValveContext context)
   throws IOException, ServletException {
   
  +// Default to deny request if property is null
  +if (property == null) {
  +ServletResponse sres = response.getResponse();
  +if (sres instanceof HttpServletResponse) {
  +HttpServletResponse hres = (HttpServletResponse) sres;
  +hres.sendError(HttpServletResponse.SC_FORBIDDEN);
  +}
  +Exception e = new IllegalArgumentException();
  +getContainer().getLogger().log(e,"Request Denied, no property to filter 
on");
  +return;
  +}
  +
   // Check the deny patterns, if any
   for (int i = 0; i < denies.length; i++) {
   if (denies[i].match(property)) {
  
  
  

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

cvs commit: jakarta-tomcat-4.0/webapps/tomcat-docs/config coyote.xml http11.xml jk.xml jk2.xml webapp.xml

[glenn]

glenn   2003/01/02 05:05:08

  Modified:webapps/tomcat-docs/config coyote.xml http11.xml jk.xml
jk2.xml webapp.xml
  Log:
  In the source, enableLookups is false by default, update docs
  
  Revision  ChangesPath
  1.3   +1 -1  jakarta-tomcat-4.0/webapps/tomcat-docs/config/coyote.xml
  
  Index: coyote.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-4.0/webapps/tomcat-docs/config/coyote.xml,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- coyote.xml16 Apr 2002 17:48:56 -  1.2
  +++ coyote.xml2 Jan 2003 13:05:08 -   1.3
  @@ -68,7 +68,7 @@
 order to return the actual host name of the remote client.  Set
 to false to skip the DNS lookup and return the IP
 address in String form instead (thereby improving performance).
  -  By default, DNS lookups are enabled.
  +  By default, DNS lookups are disabled.
   
   
   
  
  
  
  1.5   +1 -1  jakarta-tomcat-4.0/webapps/tomcat-docs/config/http11.xml
  
  Index: http11.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-4.0/webapps/tomcat-docs/config/http11.xml,v
  retrieving revision 1.4
  retrieving revision 1.5
  diff -u -r1.4 -r1.5
  --- http11.xml4 Apr 2002 18:16:07 -   1.4
  +++ http11.xml2 Jan 2003 13:05:08 -   1.5
  @@ -71,7 +71,7 @@
 order to return the actual host name of the remote client.  Set
 to false to skip the DNS lookup and return the IP
 address in String form instead (thereby improving performance).
  -  By default, DNS lookups are enabled.
  +  By default, DNS lookups are disabled.
   
   
   
  
  
  
  1.10  +1 -1  jakarta-tomcat-4.0/webapps/tomcat-docs/config/jk.xml
  
  Index: jk.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-4.0/webapps/tomcat-docs/config/jk.xml,v
  retrieving revision 1.9
  retrieving revision 1.10
  diff -u -r1.9 -r1.10
  --- jk.xml29 Aug 2002 00:32:39 -  1.9
  +++ jk.xml2 Jan 2003 13:05:08 -   1.10
  @@ -59,7 +59,7 @@
 order to return the actual host name of the remote client.  Set
 to false to skip the DNS lookup and return the IP
 address in String form instead (thereby improving performance).
  -  By default, DNS lookups are enabled.
  +  By default, DNS lookups are disabled.
   
   
   
  
  
  
  1.4   +1 -1  jakarta-tomcat-4.0/webapps/tomcat-docs/config/jk2.xml
  
  Index: jk2.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-4.0/webapps/tomcat-docs/config/jk2.xml,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- jk2.xml   10 Sep 2002 08:49:05 -  1.3
  +++ jk2.xml   2 Jan 2003 13:05:08 -   1.4
  @@ -57,7 +57,7 @@
 order to return the actual host name of the remote client.  Set
 to false to skip the DNS lookup and return the IP
 address in String form instead (thereby improving performance).
  -  By default, DNS lookups are enabled.
  +  By default, DNS lookups are disabled.
   
   
   
  
  
  
  1.5   +1 -1  jakarta-tomcat-4.0/webapps/tomcat-docs/config/webapp.xml
  
  Index: webapp.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-4.0/webapps/tomcat-docs/config/webapp.xml,v
  retrieving revision 1.4
  retrieving revision 1.5
  diff -u -r1.4 -r1.5
  --- webapp.xml28 Apr 2002 07:32:57 -  1.4
  +++ webapp.xml2 Jan 2003 13:05:08 -   1.5
  @@ -56,7 +56,7 @@
 order to return the actual host name of the remote client.  Set
 to false to skip the DNS lookup and return the IP
 address in String form instead (thereby improving performance).
  -  By default, DNS lookups are enabled.
  +  By default, DNS lookups are disabled.
   
   
   
  
  
  

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

DO NOT REPLY [Bug 15762] New: - Special character '&' in Data Source URL causes Tomcat to crash on restart

[bugzilla]

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

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

Special character '&' in Data Source URL causes Tomcat to crash on restart

   Summary: Special character '&' in Data Source URL causes Tomcat
to crash on restart
   Product: Tomcat 4
   Version: 4.1.18
  Platform: PC
OS/Version: Windows XP
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Webapps:Administration
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


I configure a Data Source with the Administration webapp, the "Data Source URL" 
field contains the special character &, for example:

jdbc:sybase:Tds:host.domain:4100/db?APPLICATIONNAME=Tomcat&HOSTNAME=myserver

I save and commit changes, all is well.

When I try to restart Tomcat, it will not start, there is an exception while 
parsing server.xml:

Catalina.start: org.xml.sax.SAXParseException: Next character must be ";" 
terminating reference to entity "HOSTNAME".


The problem is that the data source's url resource parameter's value is stored 
literally in server.xml (the & character is not escaped to &) which makes 
it invalid XML.

server.xml:


  ...
  
url
jdbc:sybase:Tds:host.domain:4100/db?
APPLICATIONNAME=Tomcat&HOSTNAME=myserver
  
  ...


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

mod_jk/Ajp enableLookups

[Glenn Nielsen]

While looking into another problem I found that the enableLookups attribute for the Ajp13Connector
has no effect. (The docs say differently) All the Ajp13Connector does is pass through the remote
host from the web server.  So to have a working request.getRemoteHost() you have to
turn HostnameLookups on for Apache.  I don't know how this works in the other web servers supported.

Either the docs need to be changed to reflect that enableLookups has no effect with the
Ajp13Connector and you have to turn on hostname lookups in the web server.

Or request.getRemoteHost() needs to resolve the IP to the hostname if enableLookups=true and
the hostname hasn't been resolved yet.

Comments?

Glenn


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

DO NOT REPLY [Bug 15762] - Special character '&' in Data Source URL causes Tomcat to crash on restart

[bugzilla]

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

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

Special character '&' in Data Source URL causes Tomcat to crash on restart





--- Additional Comments From [EMAIL PROTECTED]  2003-01-02 13:35 ---
Created an attachment (id=4320)
patch to org.apache.catalina.core.StandardServer to escape resource parameter values 
in storeNamingResources

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

DO NOT REPLY [Bug 15682] - Java downward comaptibilty gives method signature errors

[bugzilla]

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

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

Java downward comaptibilty gives method signature errors





--- Additional Comments From [EMAIL PROTECTED]  2003-01-02 15:05 ---
Created an attachment (id=4322)
i get the same error changing from 4.1.12 to 4.1.18(see the stacktrace)

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

DO NOT REPLY [Bug 15682] - Java downward comaptibilty gives method signature errors

[bugzilla]

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

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

Java downward comaptibilty gives method signature errors





--- Additional Comments From [EMAIL PROTECTED]  2003-01-02 15:08 ---
I have the same Problem changing from 4.1.12 to 4.1.18

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

RE: error-page status codes broken, no response to bugzilla report

[Donald Ball]

On 12/23/2002 at 9:40 AM Costin Manolache wrote:

>It is on my todo list ( I also need this to work, at least for 500 ).
>Do you have a patch ?

I have attached an erstwhile patch to the bug in bugzilla. It assumes the
content type of the error-page resource to be text/html and uses rd.include
instead of rd.forward to get the content body. I have a feeling that
someone more well-versed with catalina's internals could write a better
patch that gets both the http status code _and_ the content type correct,
but I am not that person.

Nonetheless, I think the patched behavior is much more correct than the
current behavior and should be applied to cvs.

- donald


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

cvs commit: jakarta-tomcat-connectors/jk/xdocs/jk workershowto.xml

[glenn]

glenn   2003/01/02 09:12:55

  Modified:jk/native CHANGES.txt
   jk/native/common jk_lb_worker.c jk_util.c jk_util.h
   jk/xdocs/jk workershowto.xml
  Log:
  Add new lb property sticky_session.  If set to 0, requests with session
  id's do not have to be routed back to the same Tomcat worker.  This is
  to support the new Tomcat Session Manager code which supports persistance
  of session data across multiple Tomcat instances, such as JavaGroup's.
  
  Revision  ChangesPath
  1.9   +4 -1  jakarta-tomcat-connectors/jk/native/CHANGES.txt
  
  Index: CHANGES.txt
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/CHANGES.txt,v
  retrieving revision 1.8
  retrieving revision 1.9
  diff -u -r1.8 -r1.9
  --- CHANGES.txt   2 Jan 2003 13:00:59 -   1.8
  +++ CHANGES.txt   2 Jan 2003 17:12:55 -   1.9
  @@ -6,6 +6,9 @@
 [glenn]
   * Apache 2/1.3, if Tomcat returns an error but not content,
 let Apache handle processing the error returned by Tomcat.
  +* Added the load balancer sticky_session property. If set to 0
  +  requests with servlet SESSION ID's can be routed to any Tomcat
  +  worker. Default is 1, sessions are sticky.
   
   Changes with JK 1.2.2:
   * tomcat_trend.pl updated script to support changed logging of 
  
  
  
  1.12  +9 -3  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.11
  retrieving revision 1.12
  diff -u -r1.11 -r1.12
  --- jk_lb_worker.c30 Oct 2002 21:17:34 -  1.11
  +++ jk_lb_worker.c2 Jan 2003 17:12:55 -   1.12
  @@ -103,6 +103,7 @@
   jk_worker_t worker;
   int  in_local_worker_mode;
   int  local_worker_only;
  +int  sticky_session;
   };
   typedef struct lb_worker lb_worker_t;
   
  @@ -254,8 +255,12 @@
   worker_record_t *rc = NULL;
   double lb_min = 0.0;
   unsigned i;
  -char *session_route = get_session_route(s);
  -   
  +char *session_route = NULL;
  +
  +if (p->sticky_session) {
  +session_route = get_session_route(s);
  +}
  +
   if(session_route) {
   for(i = 0 ; i < p->num_of_workers ; i++) {
   if(0 == strcmp(session_route, p->lb_workers[i].name)) {
  @@ -421,6 +426,7 @@
   unsigned num_of_workers;
   p->in_local_worker_mode = JK_FALSE;
   p->local_worker_only = jk_get_local_worker_only_flag(props, p->name);
  +p->sticky_session = jk_get_is_sticky_session(props, p->name);
   
   if(jk_get_lb_worker_list(props,
p->name,
  
  
  
  1.19  +15 -1 jakarta-tomcat-connectors/jk/native/common/jk_util.c
  
  Index: jk_util.c
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/common/jk_util.c,v
  retrieving revision 1.18
  retrieving revision 1.19
  diff -u -r1.18 -r1.19
  --- jk_util.c 16 Sep 2002 08:26:46 -  1.18
  +++ jk_util.c 2 Jan 2003 17:12:55 -   1.19
  @@ -89,6 +89,7 @@
   #define SOCKET_KEEPALIVE_OF_WORKER  ("socket_keepalive")
   #define LOAD_FACTOR_OF_WORKER   ("lbfactor")
   #define BALANCED_WORKERS("balanced_workers")
  +#define STICKY_SESSION  ("sticky_session")
   #define LOCAL_WORKER_ONLY_FLAG  ("local_worker_only")
   #define LOCAL_WORKER_FLAG   ("local_worker")
   #define WORKER_AJP12("ajp12")
  @@ -499,6 +500,19 @@
   sprintf(buf, "%s.%s.%s", PREFIX_OF_WORKER, wname, LOAD_FACTOR_OF_WORKER);
   
   return map_get_double(m, buf, DEFAULT_LB_FACTOR);
  +}
  +
  +int jk_get_is_sticky_session(jk_map_t *m,
  +const char *wname) {
  +int rc = JK_TRUE;
  +char buf[1024];
  +if (m && wname) {
  +int value;
  +sprintf(buf, "%s.%s.%s", PREFIX_OF_WORKER, wname, STICKY_SESSION);
  +value = map_get_int(m, buf, 0);
  +if (!value) rc = JK_FALSE;
  +}
  +return rc;
   }
   
   int jk_get_is_local_worker(jk_map_t *m,
  
  
  
  1.9   +4 -1  jakarta-tomcat-connectors/jk/native/common/jk_util.h
  
  Index: jk_util.h
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/common/jk_util.h,v
  retrieving revision 1.8
  retrieving revision 1.9
  diff -u -r1.8 -r1.9
  --- jk_util.h 16 Sep 2002 08:26:46 -  1.8
  +++ jk_util.h 2 Jan 2003 17:12:55 -   1.9
  @@ -134,6 +134,9 @@
   double jk_get_lb_factor(jk_map_t *m, 
   const char *wname);
   
  +int jk_get_is_sticky_session(jk_map_t *m,
  +   const char *wname);
  +
   int j

DO NOT REPLY [Bug 15762] - Special character '&' in Data Source URL causes Tomcat to crash on restart

[bugzilla]

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

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

Special character '&' in Data Source URL causes Tomcat to crash on restart

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID



--- Additional Comments From [EMAIL PROTECTED]  2003-01-02 17:16 ---
The server.xml file is an XML document, and therefore you must obey the syntax
and semantic rules of XML.  Using a plain "&" character in XML does not conform,
so your server.xml file is broken.

If you want to include a URL that includes an ampersand, you need to do the
usual XML escape for it (&) instead.  For example:

jdbc:sybase:Tds:host.domain:4100/db?APPLICATIONNAME=Tomcat&HOSTNAME=myserver

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

RE: error-page status codes broken, no response to bugzilla report

[Craig R. McClanahan]

On Thu, 2 Jan 2003, Donald Ball wrote:

> Date: Thu, 02 Jan 2003 10:26:10 -0500
> From: Donald Ball <[EMAIL PROTECTED]>
> Reply-To: Tomcat Developers List <[EMAIL PROTECTED]>,
>  [EMAIL PROTECTED]
> To: [EMAIL PROTECTED]
> Subject: RE: error-page status codes broken, no response to bugzilla  report
>
> On 12/23/2002 at 9:40 AM Costin Manolache wrote:
>
> >It is on my todo list ( I also need this to work, at least for 500 ).
> >Do you have a patch ?
>
> I have attached an erstwhile patch to the bug in bugzilla. It assumes the
> content type of the error-page resource to be text/html and uses rd.include
> instead of rd.forward to get the content body. I have a feeling that
> someone more well-versed with catalina's internals could write a better
> patch that gets both the http status code _and_ the content type correct,
> but I am not that person.
>
> Nonetheless, I think the patched behavior is much more correct than the
> current behavior and should be applied to cvs.
>

(Sorry for being out of touch earlier -- holidays and busyness and such).

I do not agree with the assertion that the current behavior is broken.

The  that you declare inside an  element is a
context-relative URL of a web application resource that should handle this
error *instead of* the container's default handling (which would be to set
the status code and message per the HTTP spec's description).  As such, it
is totally up to your declared resource to decide what to do.

For example, you could easily define a resource URL that is mapped to a
servlet that called response.sendError() to set the ultimate error code,
plus did some other stuff.  But that is up to you to decide, not up to the
container.  The container's job is to send back whatever your application
told it to send.

If you point at a webapp resource that *itself* returns a 200 status
(which is the default behavior for static resources served by the
file-serving servlet, and which is what JSP pages will return unless you
do something different inside them), a 200 is what you should see in the
final response to the client.

If you want something different, map your error page handlers to a servlet
that does something different.

> - donald
>

Craig McClanahan



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

[PATCH] Iteration tags do not synchronize scripting variables after doStartTag

[Dimitry Ivanov]

Title: Сообщение



Hello,
 
  In jasper2, I 
have found one interesting bug. It hapens when tag implements 

BodyTag 
interface and doStartTag returns EVAL_BODY_INCLUDE.
 
  See test-case 
and patch attached. The patch tested under Tomcat 
4.1.18.
 
WBR,
Dimitry 
Ivanov


taglib-test-case.war
Description: Binary data


Generator.java.patch
Description: Binary data
--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: cvs commit: jakarta-tomcat-connectors/jk/xdocs/jk workershowto.xml

[Costin Manolache]

Are you going to port this to jk2 :-) ?

One issue: I'm not sure JavaGroup is doing the synchronous(?) replication of 
session data - there is a delay between a change is made on one worker and 
the moment this is known on all other workers. 

If you don't route back to the same worker - you'll loose data. If the
original worker doesn't respond - you can send to a different worker in 
the group.

Costin



[EMAIL PROTECTED] wrote:

> glenn   2003/01/02 09:12:55
> 
>   Modified:jk/native CHANGES.txt
>jk/native/common jk_lb_worker.c jk_util.c jk_util.h
>jk/xdocs/jk workershowto.xml
>   Log:
>   Add new lb property sticky_session.  If set to 0, requests with session
>   id's do not have to be routed back to the same Tomcat worker.  This is
>   to support the new Tomcat Session Manager code which supports
>   persistance of session data across multiple Tomcat instances, such as
>   JavaGroup's.
>   
>   Revision  ChangesPath
>   1.9   +4 -1  jakarta-tomcat-connectors/jk/native/CHANGES.txt
>   
>   Index: CHANGES.txt
>   ===
>   RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/CHANGES.txt,v
>   retrieving revision 1.8
>   retrieving revision 1.9
>   diff -u -r1.8 -r1.9
>   --- CHANGES.txt 2 Jan 2003 13:00:59 -   1.8
>   +++ CHANGES.txt 2 Jan 2003 17:12:55 -   1.9
>   @@ -6,6 +6,9 @@
>  [glenn]
>* Apache 2/1.3, if Tomcat returns an error but not content,
>  let Apache handle processing the error returned by Tomcat.
>   +* Added the load balancer sticky_session property. If set to 0
>   +  requests with servlet SESSION ID's can be routed to any Tomcat
>   +  worker. Default is 1, sessions are sticky.
>
>Changes with JK 1.2.2:
>* tomcat_trend.pl updated script to support changed logging of
>   
>   
>   
>   1.12  +9 -3 
>   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.11 retrieving revision 1.12
>   diff -u -r1.11 -r1.12
>   --- jk_lb_worker.c  30 Oct 2002 21:17:34 -  1.11
>   +++ jk_lb_worker.c  2 Jan 2003 17:12:55 -   1.12
>   @@ -103,6 +103,7 @@
>jk_worker_t worker;
>int  in_local_worker_mode;
>int  local_worker_only;
>   +int  sticky_session;
>};
>typedef struct lb_worker lb_worker_t;
>
>   @@ -254,8 +255,12 @@
>worker_record_t *rc = NULL;
>double lb_min = 0.0;
>unsigned i;
>   -char *session_route = get_session_route(s);
>   -
>   +char *session_route = NULL;
>   +
>   +if (p->sticky_session) {
>   +session_route = get_session_route(s);
>   +}
>   +
>if(session_route) {
>for(i = 0 ; i < p->num_of_workers ; i++) {
>if(0 == strcmp(session_route, p->lb_workers[i].name)) {
>   @@ -421,6 +426,7 @@
>unsigned num_of_workers;
>p->in_local_worker_mode = JK_FALSE;
>p->local_worker_only = jk_get_local_worker_only_flag(props,
>p->name);
>   +p->sticky_session = jk_get_is_sticky_session(props, p->name);
>
>if(jk_get_lb_worker_list(props,
> p->name,
>   
>   
>   
>   1.19  +15 -1
>   jakarta-tomcat-connectors/jk/native/common/jk_util.c
>   
>   Index: jk_util.c
>   ===
>   RCS file:
>   /home/cvs/jakarta-tomcat-connectors/jk/native/common/jk_util.c,v
>   retrieving revision 1.18 retrieving revision 1.19
>   diff -u -r1.18 -r1.19
>   --- jk_util.c   16 Sep 2002 08:26:46 -  1.18
>   +++ jk_util.c   2 Jan 2003 17:12:55 -   1.19
>   @@ -89,6 +89,7 @@
>#define SOCKET_KEEPALIVE_OF_WORKER  ("socket_keepalive")
>#define LOAD_FACTOR_OF_WORKER   ("lbfactor")
>#define BALANCED_WORKERS("balanced_workers")
>   +#define STICKY_SESSION  ("sticky_session")
>#define LOCAL_WORKER_ONLY_FLAG  ("local_worker_only")
>#define LOCAL_WORKER_FLAG   ("local_worker")
>#define WORKER_AJP12("ajp12")
>   @@ -499,6 +500,19 @@
>sprintf(buf, "%s.%s.%s", PREFIX_OF_WORKER, wname,
>LOAD_FACTOR_OF_WORKER);
>
>return map_get_double(m, buf, DEFAULT_LB_FACTOR);
>   +}
>   +
>   +int jk_get_is_sticky_session(jk_map_t *m,
>   +const char *wname) {
>   +int rc = JK_TRUE;
>   +char buf[1024];
>   +if (m && wname) {
>   +int value;
>   +sprintf(buf, "%s.%s.%s", PREFIX_OF_WORKER, wname,
>   STICKY_SESSION);
>   +value = map_get_int(m, buf, 0);
>   +if (!value) rc = JK_FALSE;
>   +}
>   +return rc;
>}
>   

Re: cvs commit: jakarta-tomcat-connectors/jk/xdocs/jk workershowto.xml

[Craig R. McClanahan]

On Thu, 2 Jan 2003, Costin Manolache wrote:

> Date: Thu, 02 Jan 2003 09:23:49 -0800
> From: Costin Manolache <[EMAIL PROTECTED]>
> Reply-To: Tomcat Developers List <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: Re: cvs commit: jakarta-tomcat-connectors/jk/xdocs/jk
> workershowto.xml
>
> Are you going to port this to jk2 :-) ?
>
> One issue: I'm not sure JavaGroup is doing the synchronous(?) replication of
> session data - there is a delay between a change is made on one worker and
> the moment this is known on all other workers.
>
> If you don't route back to the same worker - you'll loose data. If the
> original worker doesn't respond - you can send to a different worker in
> the group.
>

A further subtlety to keep in mind is a restriction from Section 7.7.2:

Within an application marked as distributable, all requests
that are part of a session must be handled by one virtual
machine at a time.

In other words, it's legal to migrate sessions from one JVM to another "in
between" requests.  But it's not legal to send two simultaneous requests
for the same session to two different JVMs.  I don't know all the
implications of this patch, but it sounds like you might be going down a
path that will have problems with this requirement.

(And it's also not technicallly legal to distribute an app that is not
marked  in web.xml, but that's a separate issue )

> Costin
>

Craig


>
>
> [EMAIL PROTECTED] wrote:
>
> > glenn   2003/01/02 09:12:55
> >
> >   Modified:jk/native CHANGES.txt
> >jk/native/common jk_lb_worker.c jk_util.c jk_util.h
> >jk/xdocs/jk workershowto.xml
> >   Log:
> >   Add new lb property sticky_session.  If set to 0, requests with session
> >   id's do not have to be routed back to the same Tomcat worker.  This is
> >   to support the new Tomcat Session Manager code which supports
> >   persistance of session data across multiple Tomcat instances, such as
> >   JavaGroup's.
> >
> >   Revision  ChangesPath
> >   1.9   +4 -1  jakarta-tomcat-connectors/jk/native/CHANGES.txt
> >
> >   Index: CHANGES.txt
> >   ===
> >   RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/CHANGES.txt,v
> >   retrieving revision 1.8
> >   retrieving revision 1.9
> >   diff -u -r1.8 -r1.9
> >   --- CHANGES.txt 2 Jan 2003 13:00:59 -   1.8
> >   +++ CHANGES.txt 2 Jan 2003 17:12:55 -   1.9
> >   @@ -6,6 +6,9 @@
> >  [glenn]
> >* Apache 2/1.3, if Tomcat returns an error but not content,
> >  let Apache handle processing the error returned by Tomcat.
> >   +* Added the load balancer sticky_session property. If set to 0
> >   +  requests with servlet SESSION ID's can be routed to any Tomcat
> >   +  worker. Default is 1, sessions are sticky.
> >
> >Changes with JK 1.2.2:
> >* tomcat_trend.pl updated script to support changed logging of
> >
> >
> >
> >   1.12  +9 -3
> >   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.11 retrieving revision 1.12
> >   diff -u -r1.11 -r1.12
> >   --- jk_lb_worker.c  30 Oct 2002 21:17:34 -  1.11
> >   +++ jk_lb_worker.c  2 Jan 2003 17:12:55 -   1.12
> >   @@ -103,6 +103,7 @@
> >jk_worker_t worker;
> >int  in_local_worker_mode;
> >int  local_worker_only;
> >   +int  sticky_session;
> >};
> >typedef struct lb_worker lb_worker_t;
> >
> >   @@ -254,8 +255,12 @@
> >worker_record_t *rc = NULL;
> >double lb_min = 0.0;
> >unsigned i;
> >   -char *session_route = get_session_route(s);
> >   -
> >   +char *session_route = NULL;
> >   +
> >   +if (p->sticky_session) {
> >   +session_route = get_session_route(s);
> >   +}
> >   +
> >if(session_route) {
> >for(i = 0 ; i < p->num_of_workers ; i++) {
> >if(0 == strcmp(session_route, p->lb_workers[i].name)) {
> >   @@ -421,6 +426,7 @@
> >unsigned num_of_workers;
> >p->in_local_worker_mode = JK_FALSE;
> >p->local_worker_only = jk_get_local_worker_only_flag(props,
> >p->name);
> >   +p->sticky_session = jk_get_is_sticky_session(props, p->name);
> >
> >if(jk_get_lb_worker_list(props,
> > p->name,
> >
> >
> >
> >   1.19  +15 -1
> >   jakarta-tomcat-connectors/jk/native/common/jk_util.c
> >
> >   Index: jk_util.c
> >   ===
> >   RCS file:
> >   /home/cvs/jakarta-tomcat-connectors/jk/native/common/jk_util.c,v
> >   retrieving revision 1.18 retrieving revision 1.19
> >   diff -u -r1.18 -r1.19
> >   --- jk_util.c  

RE: error-page status codes broken, no response to bugzilla report

[Donald Ball]

On 1/2/2003 at 9:23 AM Craig R. McClanahan wrote:

>> Nonetheless, I think the patched behavior is much more correct than the
>> current behavior and should be applied to cvs.
>>
>
>(Sorry for being out of touch earlier -- holidays and busyness and such).
>
>I do not agree with the assertion that the current behavior is broken.



I read and understand that you can map error-page handlers to locations
which in fact respond with the original status codes. Nonetheless, it still
seems to me that the behavior is incorrect wrt the servlet spec, not to
mention http and common sense. Again, I quote:

---
Hmm. Digging around in the 2.3 spec more deeply, I note the description of
HttpServletResponse.sendError reads:

"Sends an error response to the client using the specified status clearing
the buffer. The server defaults to creating the response to look like an
HTML-formatted server error page containing the specified message, setting
the content type to "text/html", leaving cookies and other headers
unmodified. If an error-page declaration has been made for the web
application corresponding to the status code passed in, it will be served
back in preference to the suggested msg parameter."

The first sentence clearly states that the response sent to the client must
use the specified status code, regardless of whether the content body is
generated by the server automatically or is read from an error-page
location.
---

It still seems to me that the status code of the error-page should be the
status code of the response. Not only is that the behavior implied by the
spec, but it also prevents naive web developers from writing webapps that
return pretty error response pages tagged with status 200. The default
behavior should be to preserve the http conversation, not to censor it. You
argue that I should do extra work to preserve the status code. I argue that
(if one really wanted to for some arcane reason) one should do extra work
to hide it.

Regardless of what you/we decide here for tomcat, should this be brought to
the servlet expert group for clarification in a forthcoming servlet spec?

- donald


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

RE: error-page status codes broken, no response to bugzilla report

[Craig R. McClanahan]

On Thu, 2 Jan 2003, Donald Ball wrote:

> Date: Thu, 02 Jan 2003 12:49:40 -0500
> From: Donald Ball <[EMAIL PROTECTED]>
> Reply-To: Tomcat Developers List <[EMAIL PROTECTED]>,
>  [EMAIL PROTECTED]
> To: [EMAIL PROTECTED], [EMAIL PROTECTED]
> Subject: RE: error-page status codes broken, no response to bugzilla   report
>
> On 1/2/2003 at 9:23 AM Craig R. McClanahan wrote:
>
> >> Nonetheless, I think the patched behavior is much more correct than the
> >> current behavior and should be applied to cvs.
> >>
> >
> >(Sorry for being out of touch earlier -- holidays and busyness and such).
> >
> >I do not agree with the assertion that the current behavior is broken.
>
> 
>
> I read and understand that you can map error-page handlers to locations
> which in fact respond with the original status codes. Nonetheless, it still
> seems to me that the behavior is incorrect wrt the servlet spec, not to
> mention http and common sense. Again, I quote:
>
> ---
> Hmm. Digging around in the 2.3 spec more deeply, I note the description of
> HttpServletResponse.sendError reads:
>
> "Sends an error response to the client using the specified status clearing
> the buffer. The server defaults to creating the response to look like an
> HTML-formatted server error page containing the specified message, setting
> the content type to "text/html", leaving cookies and other headers
> unmodified. If an error-page declaration has been made for the web
> application corresponding to the status code passed in, it will be served
> back in preference to the suggested msg parameter."
>
> The first sentence clearly states that the response sent to the client must
> use the specified status code, regardless of whether the content body is
> generated by the server automatically or is read from an error-page
> location.
> ---
>
> It still seems to me that the status code of the error-page should be the
> status code of the response. Not only is that the behavior implied by the
> spec, but it also prevents naive web developers from writing webapps that
> return pretty error response pages tagged with status 200. The default
> behavior should be to preserve the http conversation, not to censor it. You
> argue that I should do extra work to preserve the status code. I argue that
> (if one really wanted to for some arcane reason) one should do extra work
> to hide it.
>

The key issue is that declaring an  handler ***replaces*** the
standard container behavior; it doesn't ***augment*** it.

Consider, for example, a webapp that want to implement something like what
the "Redirect" configuration parameter does for Apache (so that old URLs
still work).  In today's world, you can write such a thing by mapping 404
errors to a servlet that redirects to the desired resource (which
ultimately returns a 200) for the URLs it knows about, and just returns
the original 404 for everything else.

With your proposed change, it would not be possible to implement this
functionality.  That would be bad.

> Regardless of what you/we decide here for tomcat, should this be brought to
> the servlet expert group for clarification in a forthcoming servlet spec?
>

You're certainly welcome to send them mail:

  [EMAIL PROTECTED]

and it's timely, since Servlet 2.4 is in Proposed Final Draft state, and
still subject to correction if needed.  (And I'm going to make the above
argument if it's brought up for discussion -- to say nothing of the fact
that this would break backwards compatibility for loads of existing
applications ;-).

> - donald
>

Craig


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

RE: error-page status codes broken, no response to bugzilla report

[Donald Ball]

>The key issue is that declaring an  handler ***replaces*** the
>standard container behavior; it doesn't ***augment*** it.
>
>Consider, for example, a webapp that want to implement something like what
>the "Redirect" configuration parameter does for Apache (so that old URLs
>still work).  In today's world, you can write such a thing by mapping 404
>errors to a servlet that redirects to the desired resource (which
>ultimately returns a 200) for the URLs it knows about, and just returns
>the original 404 for everything else.
>
>With your proposed change, it would not be possible to implement this
>functionality.  That would be bad.

Sure it would be possible. You could handle that case by mapping /* to a
servlet and having it do the logic - map old URLs to new URLs (with a
proper 301, not a silent internal redirect and a 200, ideally), return 404s
for everything else. I can't say if it's easier or harder than the solution
you proposed, but it definitely looks possible.

For that matter - for the solution that you propose, by a strict reading of
the servlet spec, why wouldn't you get into an infinite loop if the
location for a 404 error-page returns a 404 status code? or bounce back and
forth between 404 and 301, say? I see that tomcat avoids the first problem,
at least, but I don't see where in the servlet spec it says that it's
supposed to...

>> Regardless of what you/we decide here for tomcat, should this be brought
>to
>> the servlet expert group for clarification in a forthcoming servlet
spec?
>
>You're certainly welcome to send them mail:
>
>  [EMAIL PROTECTED]
>
>and it's timely, since Servlet 2.4 is in Proposed Final Draft state, and
>still subject to correction if needed.  (And I'm going to make the above
>argument if it's brought up for discussion -- to say nothing of the fact
>that this would break backwards compatibility for loads of existing
>applications ;-).

That's certainly something to consider. Since tomcat is the reference
implementation, ambiguities in the spec are resolved by looking at its
(buggy :)) behavior, yes? I guess I really wonder what webapps rely on this
behavior and why - it seems to me that fixing tomcat to work the way I
expect would fix more webapps than it would break. However, I guess I'd be
happy if the servlet spec simply explicitly declared what's supposed to
happen so web developers who care about http, rest, etc. realize they need
to explicitly give status codes to their pretty error pages. I'll write
something in.

Thanks for your patience with this pedantic problem.

- donald


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

Re: cvs commit: jakarta-tomcat-connectors/jk/xdocs/jk workershowto.xml

[Glenn Nielsen]

Craig R. McClanahan wrote:


On Thu, 2 Jan 2003, Costin Manolache wrote:



Date: Thu, 02 Jan 2003 09:23:49 -0800
From: Costin Manolache <[EMAIL PROTECTED]>
Reply-To: Tomcat Developers List <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: Re: cvs commit: jakarta-tomcat-connectors/jk/xdocs/jk
   workershowto.xml

Are you going to port this to jk2 :-) ?



It could be I ported to jk2, only a few lines of code. :-)


One issue: I'm not sure JavaGroup is doing the synchronous(?) replication of
session data - there is a delay between a change is made on one worker and
the moment this is known on all other workers.

If you don't route back to the same worker - you'll loose data. If the
original worker doesn't respond - you can send to a different worker in
the group.





Yes, there very well could be problems with persistance of session data
across multiple tomcat workers.  Being able to seamlessly failover from
one tomcat worker to another without loosing session data is an important
feature when you start clustering.  At least with this property we can start
testing different session persistance solutions.



A further subtlety to keep in mind is a restriction from Section 7.7.2:

Within an application marked as distributable, all requests
that are part of a session must be handled by one virtual
machine at a time.

In other words, it's legal to migrate sessions from one JVM to another "in
between" requests.  But it's not legal to send two simultaneous requests
for the same session to two different JVMs.  I don't know all the
implications of this patch, but it sounds like you might be going down a
path that will have problems with this requirement.

(And it's also not technicallly legal to distribute an app that is not
marked  in web.xml, but that's a separate issue )



Thanks for the heads up Craig.




Costin




Craig





[EMAIL PROTECTED] wrote:



glenn   2003/01/02 09:12:55

 Modified:jk/native CHANGES.txt
  jk/native/common jk_lb_worker.c jk_util.c jk_util.h
  jk/xdocs/jk workershowto.xml
 Log:
 Add new lb property sticky_session.  If set to 0, requests with session
 id's do not have to be routed back to the same Tomcat worker.  This is
 to support the new Tomcat Session Manager code which supports
 persistance of session data across multiple Tomcat instances, such as
 JavaGroup's.

 Revision  ChangesPath
 1.9   +4 -1  jakarta-tomcat-connectors/jk/native/CHANGES.txt

 Index: CHANGES.txt
 ===
 RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/CHANGES.txt,v
 retrieving revision 1.8
 retrieving revision 1.9
 diff -u -r1.8 -r1.9
 --- CHANGES.txt 2 Jan 2003 13:00:59 -   1.8
 +++ CHANGES.txt 2 Jan 2003 17:12:55 -   1.9
 @@ -6,6 +6,9 @@
[glenn]
  * Apache 2/1.3, if Tomcat returns an error but not content,
let Apache handle processing the error returned by Tomcat.
 +* Added the load balancer sticky_session property. If set to 0
 +  requests with servlet SESSION ID's can be routed to any Tomcat
 +  worker. Default is 1, sessions are sticky.

  Changes with JK 1.2.2:
  * tomcat_trend.pl updated script to support changed logging of



 1.12  +9 -3
 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.11 retrieving revision 1.12
 diff -u -r1.11 -r1.12
 --- jk_lb_worker.c  30 Oct 2002 21:17:34 -  1.11
 +++ jk_lb_worker.c  2 Jan 2003 17:12:55 -   1.12
 @@ -103,6 +103,7 @@
  jk_worker_t worker;
  int  in_local_worker_mode;
  int  local_worker_only;
 +int  sticky_session;
  };
  typedef struct lb_worker lb_worker_t;

 @@ -254,8 +255,12 @@
  worker_record_t *rc = NULL;
  double lb_min = 0.0;
  unsigned i;
 -char *session_route = get_session_route(s);
 -
 +char *session_route = NULL;
 +
 +if (p->sticky_session) {
 +session_route = get_session_route(s);
 +}
 +
  if(session_route) {
  for(i = 0 ; i < p->num_of_workers ; i++) {
  if(0 == strcmp(session_route, p->lb_workers[i].name)) {
 @@ -421,6 +426,7 @@
  unsigned num_of_workers;
  p->in_local_worker_mode = JK_FALSE;
  p->local_worker_only = jk_get_local_worker_only_flag(props,
  p->name);
 +p->sticky_session = jk_get_is_sticky_session(props, p->name);

  if(jk_get_lb_worker_list(props,
   p->name,



 1.19  +15 -1
 jakarta-tomcat-connectors/jk/native/common/jk_util.c

 Index: jk_util.c
 ===
 RCS file:
 /home/cvs/jakarta-tomcat-connectors/jk/native/common/jk_util.c,v
 retrieving revision 1.18 retrieving revision 1.19
 diff -u -r1.18 -r1.19
 -

DO NOT REPLY [Bug 15762] - Special character '&' in Data Source URL causes Tomcat to crash on restart

[bugzilla]

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

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

Special character '&' in Data Source URL causes Tomcat to crash on restart





--- Additional Comments From [EMAIL PROTECTED]  2003-01-02 22:59 ---
That is correct if I modify server.xml directly.  However this happens when I 
use the Tomcat Administration webapp.
Even if I use "&" in server.xml, the next time I change something using the 
Administration webapp, server.xml is rewritten with a plain "&" character 
instead, and Tomcat fails on the next restart.
I really think this is a bug in the code that writes out server.xml.

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

DO NOT REPLY [Bug 15771] New: - correction needed to Makefile.apxs

[bugzilla]

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

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

correction needed to Makefile.apxs

   Summary: correction needed to Makefile.apxs
   Product: Tomcat 5
   Version: 5.0.0
  Platform: Other
OS/Version: Other
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Connector:Coyote JK 2
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


jk/native2/server/apache13/Makefile.apxs.in
the line with $(APXS) in it needs to be fixed, to replace

  mod_jk2.c

with something like

 ${C_FILES}

Then C_FILES needs to be defined to add jk_service_apache13.c

eg:

C_FILES=jk_service_apache13.c mod_jk2.c

the code does not properly build as-is, since the DSO will be missing the code
in jk_service_apache13.c


PS: This is with "jk2-2.0.2" source.

I think it should really have its own bug area. But since it doesnt, I guess I
have to file the bug in this section.

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

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

[amyroh]

amyroh  2003/01/02 17:59:09

  Modified:catalina/src/share/org/apache/catalina/core
StandardServer.java
  Log:
  Fix for bugzilla 15762.
  
  Revision  ChangesPath
  1.33  +14 -6 
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/StandardServer.java
  
  Index: StandardServer.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/StandardServer.java,v
  retrieving revision 1.32
  retrieving revision 1.33
  diff -u -r1.32 -r1.33
  --- StandardServer.java   11 Sep 2002 14:19:33 -  1.32
  +++ StandardServer.java   3 Jan 2003 01:59:08 -   1.33
  @@ -824,7 +824,15 @@
   } else if (c == '"') {
   filtered.append(""");
   } else if (c == '&') {
  -filtered.append("&");
  +char s1 = input.charAt(i+3);
  +char s2 = input.charAt(i+4);
  +char s3 = input.charAt(i+5);
  +if (((s1 == ';') || (s2 == ';')) || (s3 == ';')) {
  +// do not convert if it's already in converted form
  +filtered.append(c);
  +} else {
  +filtered.append("&");
  +}
   } else {
   filtered.append(c);
   }
  @@ -1822,7 +1830,7 @@
   writer.print(' ');
   }
   writer.print("");
  -writer.print(value);
  +writer.print(convertStr(value));
   writer.println("");
   for (int j = 0; j < indent + 2; j++) {
   writer.print(' ');
  
  
  

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

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

[amyroh]

amyroh  2003/01/02 18:10:57

  Modified:catalina/src/share/org/apache/catalina/core
StandardServer.java
  Log:
  Port change.
  
  Revision  ChangesPath
  1.8   +14 -6 
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/StandardServer.java
  
  Index: StandardServer.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/StandardServer.java,v
  retrieving revision 1.7
  retrieving revision 1.8
  diff -u -r1.7 -r1.8
  --- StandardServer.java   16 Sep 2002 04:45:38 -  1.7
  +++ StandardServer.java   3 Jan 2003 02:10:56 -   1.8
  @@ -883,7 +883,15 @@
   } else if (c == '"') {
   filtered.append(""");
   } else if (c == '&') {
  -filtered.append("&");
  +char s1 = input.charAt(i+3);
  +char s2 = input.charAt(i+4);
  +char s3 = input.charAt(i+5);
  +if (((s1 == ';') || (s2 == ';')) || (s3 == ';')) {
  +// do not convert if it's already in converted form
  +filtered.append(c);
  +} else {
  +filtered.append("&");
  +}
   } else {
   filtered.append(c);
   }
  @@ -1923,7 +1931,7 @@
   writer.print(' ');
   }
   writer.print("");
  -writer.print(value);
  +writer.print(convertStr(value));
   writer.println("");
   for (int j = 0; j < indent + 2; j++) {
   writer.print(' ');
  
  
  

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

DO NOT REPLY [Bug 15762] - Special character '&' in Data Source URL causes Tomcat to crash on restart

[bugzilla]

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

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

Special character '&' in Data Source URL causes Tomcat to crash on restart

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|INVALID |



--- Additional Comments From [EMAIL PROTECTED]  2003-01-03 02:13 ---
I was able to reproduce this problem of admin changing "&" back to 
plain '&' character.

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

DO NOT REPLY [Bug 15762] - Special character '&' in Data Source URL causes Tomcat to crash on restart

[bugzilla]

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

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

Special character '&' in Data Source URL causes Tomcat to crash on restart

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2003-01-03 02:14 ---
Fixed in cvs.  Should be available in the next release.

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

DO NOT REPLY [Bug 15772] New: - catalina's web.xml missing mime-types some incorrect...

[bugzilla]

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

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

catalina's web.xml missing mime-types some incorrect...

   Summary: catalina's web.xml missing mime-types some incorrect...
   Product: Tomcat 5
   Version: Nightly Build
  Platform: Other
OS/Version: Other
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


I had reported a bug with Tomcat-4.1.10 missing xml and xsl mime type entries. 
It was fixed shortly thereafter, but it doesn't seem as if the change ever made
it to Tomcat5.  There are also a few other issues that are listed below...

The following mime-types are missing...


jsf
text/plain


jspf
text/plain


The above was added in the Tomcat-4.1.11 release by Remy.  See the following for
info:
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11674


xml
text/xml


xsl
text/xml



The following is wrong...



wmls
text/vnd.wap.wmls


it should be...



wmls
text/vnd.wap.wmlscript


I also cleaned up a couple of white space issues that were different between the
Tomcat-4.1.18 web.xml file and the Tomcat-5.0 nightly web.xml file.  A corrected
version is coming up...

Jake

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

DO NOT REPLY [Bug 15772] - catalina's web.xml missing mime-types some incorrect...

[bugzilla]

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

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

catalina's web.xml missing mime-types some incorrect...





--- Additional Comments From [EMAIL PROTECTED]  2003-01-03 02:22 ---
Created an attachment (id=4327)
zip file containing corrected web.xml based on Tomcat-5.0-nightly 2003-01-02

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

DO NOT REPLY [Bug 15774] New: - tomcat5 shared/lib behavior different than that of tomcat4.1.x

[bugzilla]

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

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

tomcat5 shared/lib behavior different than that of tomcat4.1.x

   Summary: tomcat5 shared/lib behavior different than that of
tomcat4.1.x
   Product: Tomcat 5
   Version: Nightly Build
  Platform: Other
OS/Version: Other
Status: NEW
  Severity: Major
  Priority: Other
 Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Using Tomcat-4.1.x, I can have separate instances of Tomcat running which access
their own shared/lib folder.  In Tomcat-5.0 latest nightly build, that doesn't
seem to be the case.  In fact, Tomcat5 only ever sees CATALINA_HOME/shared/lib
where Tomcat4.1.x only ever sees CATALINA_BASE/shared/lib and only when
CATALINA_BASE happens to be the same as CATALINA_HOME does Tomcat4.1.x see
CATALINA_HOME/shared/lib.

For instance, using Tomcat-4.1.18, if I have some jars in
CATALINA_HOME/shared/lib and I start up a new tomcat instance with CATALINA_BASE
set as something other than CATALINA_HOME, the jars in CATALINA_HOME/shared/lib
will *not* be loaded.  Instead, jars will be loaded from
CATALINA_BASE/shared/lib (if it exists).  This is the behavior I expect and love!

However, using Tomcat-5.0, if I set things up the same way, jars in
CATALNIA_HOME/shared/lib *will* be loaded and jars in CATALNIA_BASE/shared/lib
are completely ignored. This is behavior that I don't expect and don't like.

For a concrete example...
I use the capability of running separate instances of Tomcat to run apps which
require different versions of xerces.  I put xerces-1.4.4.jar in
CATALINA_HOME/shared/lib for apps which I use most often.  However, I have other
apps that need either slightly modified version of xerces-1.4.4 or require
xerces-2.x.x.  For those cases, I run separate instances of Tomcat (running on
different ports, of course), each with a distinct CATALNIA_BASE and a local
CATALINA_BASE/shared/lib with the appropriately versioned jars that I need for a
particular set of apps.  Everyone is happy because everyone gets to use their
own shared set of libraries without stepping on each other.

So, obviously, this is a great feature in Tomcat-4.1.x (and, I assume,
Tomcat-4.0.x) but it seems to be broken in Tomcat-5.0.  

Is this new behavior in Tomcat-5.0 a bug or was it intentional?  If it was
intentional, can someone please explain the reasons for the change in behavior
to that of Tomcat-4.1.x?

Jake

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