svn commit: r548683 - in /tomcat/connectors/trunk/jk/xdocs: generic_howto/loadbalancers.xml miscellaneous/changelog.xml reference/workers.xml

[rjung]

Author: rjung
Date: Tue Jun 19 03:33:33 2007
New Revision: 548683

URL: http://svn.apache.org/viewvc?view=rev&rev=548683
Log:
Clarify relation between worker names and jvmRoute for load balancing.
Hopefully this will answer the most frequently asked question in a way
users will understand (at least if they RTFM).

Modified:
tomcat/connectors/trunk/jk/xdocs/generic_howto/loadbalancers.xml
tomcat/connectors/trunk/jk/xdocs/miscellaneous/changelog.xml
tomcat/connectors/trunk/jk/xdocs/reference/workers.xml

Modified: tomcat/connectors/trunk/jk/xdocs/generic_howto/loadbalancers.xml
URL: 
http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/xdocs/generic_howto/loadbalancers.xml?view=diff&rev=548683&r1=548682&r2=548683
==
--- tomcat/connectors/trunk/jk/xdocs/generic_howto/loadbalancers.xml (original)
+++ tomcat/connectors/trunk/jk/xdocs/generic_howto/loadbalancers.xml Tue Jun 19 
03:33:33 2007
@@ -66,6 +66,14 @@
 
 
 The overall result is that workers managed by the same lb worker are 
load-balanced (based on their lbfactor and current user session) and also 
fall-backed so a single Tomcat process death will not "kill" the entire site.
+
+
+If you want to use session stickyness, you must set different jvmRoute 
attributes
+in the Engine element in Tomcat's server.xml. Furthermore the names of the 
workers
+which are managed by the balancer have to be equal to the jvmRoute of the 
Tomcat
+instance they connect with.
+
+
 The following table specifies some properties that the lb worker can accept:
 
 balance_workers is a comma separated list of workers that the load 
balancer need to manage. 

Modified: tomcat/connectors/trunk/jk/xdocs/miscellaneous/changelog.xml
URL: 
http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/xdocs/miscellaneous/changelog.xml?view=diff&rev=548683&r1=548682&r2=548683
==
--- tomcat/connectors/trunk/jk/xdocs/miscellaneous/changelog.xml (original)
+++ tomcat/connectors/trunk/jk/xdocs/miscellaneous/changelog.xml Tue Jun 19 
03:33:33 2007
@@ -27,6 +27,9 @@
   
   
 
+  
+  Docs: Clarify relation between worker names and jvmRoute for load 
balancing. (rjung)
+  
   
   Use initial zero timeout for jk_is_socket_connected. The resulting
   detection is the same but offers a huge performance increase

Modified: tomcat/connectors/trunk/jk/xdocs/reference/workers.xml
URL: 
http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/xdocs/reference/workers.xml?view=diff&rev=548683&r1=548682&r2=548683
==
--- tomcat/connectors/trunk/jk/xdocs/reference/workers.xml (original)
+++ tomcat/connectors/trunk/jk/xdocs/reference/workers.xml Tue Jun 19 03:33:33 
2007
@@ -52,8 +52,9 @@
 
 
 Each workers.properties directive consists of three words separated by dot. 
The first word is always
-worker. The second word is the worker name that can be any name. The 
worker name reflects the
-name of the jvmRoute defined in Tomcat's server.xml configuration file.
+worker. The second word is the worker name that can be any name. In the 
case of load-balancing,
+the worker name has an additional meaning. Please consult the
+Load Balancer HowTo.
 
 
 
@@ -249,6 +250,17 @@
 The overall result is that workers managed by the same lb worker are 
load-balanced
 (based on their lbfactor and current user session) and also fall-backed so a 
single
 Tomcat process death will not "kill" the entire site.
+
+
+If you want to use session stickyness, you must set different jvmRoute 
attributes
+in the Engine element in Tomcat's server.xml. Furthermore the names of the 
workers
+which are managed by the balancer have to be equal to the jvmRoute of the 
Tomcat
+instance they connect with.
+
+
+The restriction on the worker names can be lifted, if you use the route 
attribute for the workers.
+
+
 The following table specifies properties that the lb worker can accept:
 
 



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

svn commit: r548709 - in /tomcat/connectors/trunk/jk: native/apache-1.3/mod_jk.c native/apache-2.0/mod_jk.c xdocs/miscellaneous/changelog.xml

[rjung]

Author: rjung
Date: Tue Jun 19 05:34:33 2007
New Revision: 548709

URL: http://svn.apache.org/viewvc?view=rev&rev=548709
Log:
Apache: Add forwarding uri to debug log.

Modified:
tomcat/connectors/trunk/jk/native/apache-1.3/mod_jk.c
tomcat/connectors/trunk/jk/native/apache-2.0/mod_jk.c
tomcat/connectors/trunk/jk/xdocs/miscellaneous/changelog.xml

Modified: tomcat/connectors/trunk/jk/native/apache-1.3/mod_jk.c
URL: 
http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/native/apache-1.3/mod_jk.c?view=diff&rev=548709&r1=548708&r2=548709
==
--- tomcat/connectors/trunk/jk/native/apache-1.3/mod_jk.c (original)
+++ tomcat/connectors/trunk/jk/native/apache-1.3/mod_jk.c Tue Jun 19 05:34:33 
2007
@@ -578,24 +578,6 @@
 s->no_more_chunks = 0;
 s->query_string = r->args;
 
-/* Dump all connection param so we can trace what's going to
- * the remote tomcat
- */
-if (JK_IS_DEBUG_LEVEL(conf->log)) {
-jk_log(conf->log, JK_LOG_DEBUG,
-   "Service protocol=%s method=%s host=%s addr=%s name=%s port=%d 
auth=%s user=%s laddr=%s raddr=%s",
-   STRNULL_FOR_NULL(s->protocol),
-   STRNULL_FOR_NULL(s->method),
-   STRNULL_FOR_NULL(s->remote_host),
-   STRNULL_FOR_NULL(s->remote_addr),
-   STRNULL_FOR_NULL(s->server_name),
-   s->server_port,
-   STRNULL_FOR_NULL(s->auth_type),
-   STRNULL_FOR_NULL(s->remote_user),
-   STRNULL_FOR_NULL(r->connection->local_ip),
-   STRNULL_FOR_NULL(r->connection->remote_ip));
-}
-
 /*
  * The 2.2 servlet spec errata says the uri from
  * HttpServletRequest.getRequestURI() should remain encoded.
@@ -793,6 +775,26 @@
 }
 }
 s->uw_map = conf->uw_map;
+
+/* Dump all connection param so we can trace what's going to
+ * the remote tomcat
+ */
+if (JK_IS_DEBUG_LEVEL(conf->log)) {
+jk_log(conf->log, JK_LOG_DEBUG,
+   "Service protocol=%s method=%s host=%s addr=%s name=%s port=%d 
auth=%s user=%s laddr=%s raddr=%s uri=%s",
+   STRNULL_FOR_NULL(s->protocol),
+   STRNULL_FOR_NULL(s->method),
+   STRNULL_FOR_NULL(s->remote_host),
+   STRNULL_FOR_NULL(s->remote_addr),
+   STRNULL_FOR_NULL(s->server_name),
+   s->server_port,
+   STRNULL_FOR_NULL(s->auth_type),
+   STRNULL_FOR_NULL(s->remote_user),
+   STRNULL_FOR_NULL(r->connection->local_ip),
+   STRNULL_FOR_NULL(r->connection->remote_ip),
+   STRNULL_FOR_NULL(s->req_uri));
+}
+
 return JK_TRUE;
 }
 

Modified: tomcat/connectors/trunk/jk/native/apache-2.0/mod_jk.c
URL: 
http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/native/apache-2.0/mod_jk.c?view=diff&rev=548709&r1=548708&r2=548709
==
--- tomcat/connectors/trunk/jk/native/apache-2.0/mod_jk.c (original)
+++ tomcat/connectors/trunk/jk/native/apache-2.0/mod_jk.c Tue Jun 19 05:34:33 
2007
@@ -606,24 +606,6 @@
 s->query_string = r->args;
 #endif
 
-/* Dump all connection param so we can trace what's going to
- * the remote tomcat
- */
-if (JK_IS_DEBUG_LEVEL(conf->log)) {
-jk_log(conf->log, JK_LOG_DEBUG,
-   "Service protocol=%s method=%s host=%s addr=%s name=%s port=%d 
auth=%s user=%s laddr=%s raddr=%s",
-   STRNULL_FOR_NULL(s->protocol),
-   STRNULL_FOR_NULL(s->method),
-   STRNULL_FOR_NULL(s->remote_host),
-   STRNULL_FOR_NULL(s->remote_addr),
-   STRNULL_FOR_NULL(s->server_name),
-   s->server_port,
-   STRNULL_FOR_NULL(s->auth_type),
-   STRNULL_FOR_NULL(s->remote_user),
-   STRNULL_FOR_NULL(r->connection->local_ip),
-   STRNULL_FOR_NULL(r->connection->remote_ip));
-}
-
 /*
  * The 2.2 servlet spec errata says the uri from
  * HttpServletRequest.getRequestURI() should remain encoded.
@@ -822,6 +804,26 @@
 }
 }
 s->uw_map = conf->uw_map;
+
+/* Dump all connection param so we can trace what's going to
+ * the remote tomcat
+ */
+if (JK_IS_DEBUG_LEVEL(conf->log)) {
+jk_log(conf->log, JK_LOG_DEBUG,
+   "Service protocol=%s method=%s host=%s addr=%s name=%s port=%d 
auth=%s user=%s laddr=%s raddr=%s uri=%s",
+   STRNULL_FOR_NULL(s->protocol),
+   STRNULL_FOR_NULL(s->method),
+   STRNULL_FOR_NULL(s->remote_host),
+   STRNULL_FOR_NULL(s->remote_addr),
+   STRNULL_FOR_NULL(s->server_name),
+   s->server_port,
+   STRNULL_FOR_NULL(s->auth_type),
+   STRNULL_FOR_NULL(s->remote_user),
+   STRNULL_FOR_NULL(r->connection->local_ip),
+   STRNULL_

DO NOT REPLY [Bug 42566] - hangs including jsp with < symbol

[bugzilla]

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

http://issues.apache.org/bugzilla/show_bug.cgi?id=42566


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|INVALID |




--- Additional Comments From [EMAIL PROTECTED]  2007-06-19 08:47 ---
(In reply to comment #1)
> You need to encode the included '<'

With the previous version my example works and the inner_ko.jsp is a valid 
JSP (calling it directly it works fine). 
Why '<' should be encoded (or escaped?) ?

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

svn commit: r548791 - in /tomcat/connectors/trunk/jk: native/apache-1.3/ native/apache-2.0/ native/common/ native/iis/ native/netscape/ xdocs/miscellaneous/

[rjung]

Author: rjung
Date: Tue Jun 19 09:36:22 2007
New Revision: 548791

URL: http://svn.apache.org/viewvc?view=rev&rev=548791
Log:
Fix Bugzilla 42608: Handle Content-length as unsigned 64Bit
to allow for huge up- and downloads.

This still needs intensive testing in combination with the
fixes of the jk connectors on the tomcat side!

Modified:
tomcat/connectors/trunk/jk/native/apache-1.3/mod_jk.c
tomcat/connectors/trunk/jk/native/apache-2.0/mod_jk.c
tomcat/connectors/trunk/jk/native/common/jk_ajp12_worker.c
tomcat/connectors/trunk/jk/native/common/jk_ajp_common.c
tomcat/connectors/trunk/jk/native/common/jk_ajp_common.h
tomcat/connectors/trunk/jk/native/common/jk_lb_worker.c
tomcat/connectors/trunk/jk/native/common/jk_service.h
tomcat/connectors/trunk/jk/native/iis/jk_isapi_plugin.c
tomcat/connectors/trunk/jk/native/netscape/jk_nsapi_plugin.c
tomcat/connectors/trunk/jk/xdocs/miscellaneous/changelog.xml

Modified: tomcat/connectors/trunk/jk/native/apache-1.3/mod_jk.c
URL: 
http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/native/apache-1.3/mod_jk.c?view=diff&rev=548791&r1=548790&r2=548791
==
--- tomcat/connectors/trunk/jk/native/apache-1.3/mod_jk.c (original)
+++ tomcat/connectors/trunk/jk/native/apache-1.3/mod_jk.c Tue Jun 19 09:36:22 
2007
@@ -477,17 +477,17 @@
 }
 
 /* Return the content length associated with an Apache request structure */
-static int get_content_length(request_rec * r)
+static jk_uint64_t get_content_length(request_rec * r)
 {
 if (r->clength > 0) {
-return r->clength;
+return (jk_uint64_t)r->clength;
 }
 else {
 char *lenp = (char *)ap_table_get(r->headers_in, "Content-Length");
 
 if (lenp) {
-int rc = atoi(lenp);
-if (rc > 0) {
+jk_uint64_t rc = 0;
+if (sscanf(lenp, "%" JK_UINT64_T_FMT, &rc) > 0 && rc > 0) {
 return rc;
 }
 }

Modified: tomcat/connectors/trunk/jk/native/apache-2.0/mod_jk.c
URL: 
http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/native/apache-2.0/mod_jk.c?view=diff&rev=548791&r1=548790&r2=548791
==
--- tomcat/connectors/trunk/jk/native/apache-2.0/mod_jk.c (original)
+++ tomcat/connectors/trunk/jk/native/apache-2.0/mod_jk.c Tue Jun 19 09:36:22 
2007
@@ -515,17 +515,17 @@
 exit(1);
 }
 
-static int get_content_length(request_rec * r)
+static jk_uint64_t get_content_length(request_rec * r)
 {
 if (r->clength > 0) {
-return (int)r->clength;
+return (jk_uint64_t)r->clength;
 }
 else if (r->main == NULL || r->main == r) {
 char *lenp = (char *)apr_table_get(r->headers_in, "Content-Length");
 
 if (lenp) {
-int rc = atoi(lenp);
-if (rc > 0) {
+jk_uint64_t rc = 0;
+if (sscanf(lenp, "%" JK_UINT64_T_FMT, &rc) > 0 && rc > 0) {
 return rc;
 }
 }

Modified: tomcat/connectors/trunk/jk/native/common/jk_ajp12_worker.c
URL: 
http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/native/common/jk_ajp12_worker.c?view=diff&rev=548791&r1=548790&r2=548791
==
--- tomcat/connectors/trunk/jk/native/common/jk_ajp12_worker.c (original)
+++ tomcat/connectors/trunk/jk/native/common/jk_ajp12_worker.c Tue Jun 19 
09:36:22 2007
@@ -457,17 +457,20 @@
 
 if (s->content_length) {
 char buf[READ_BUF_SIZE];
-unsigned so_far = 0;
+jk_uint64_t so_far = 0;
 
 jk_log(l, JK_LOG_DEBUG,
"ajpv12_handle_request, sending the request body");
 
 while (so_far < s->content_length) {
 unsigned this_time = 0;
-unsigned to_read = s->content_length - so_far;
-if (to_read > READ_BUF_SIZE) {
+unsigned to_read;
+if (s->content_length > so_far + READ_BUF_SIZE) {
 to_read = READ_BUF_SIZE;
 }
+else {
+to_read = s->content_length - so_far;
+}
 
 if (!s->read(s, buf, to_read, &this_time)) {
 jk_log(l, JK_LOG_ERROR,
@@ -488,7 +491,7 @@
 }
 else if (this_time == 0) {
 jk_log(l, JK_LOG_ERROR,
-   "In ajpv12_handle_request, Error: short read. content 
length is %d, read %d",
+   "In ajpv12_handle_request, Error: short read. content 
length is %" JK_UINT64_T_FMT ", read %" JK_UINT64_T_FMT,
s->content_length, so_far);
 return JK_FALSE;
 }

Modified: tomcat/connectors/trunk/jk/native/common/jk_ajp_common.c
URL: 
http://svn.apache.org/viewvc/tomcat/connectors/trunk/jk/native/common/jk_ajp_common.c?view=diff&rev=548791&r1=548790&r2=548791

DO NOT REPLY [Bug 42608] - Invalid Content-Length error for the binary file size greater than 2.1GB

[bugzilla]

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

http://issues.apache.org/bugzilla/show_bug.cgi?id=42608


[EMAIL PROTECTED] changed:

   What|Removed |Added

  Component|Native:JK   |Connector:AJP




--- Additional Comments From [EMAIL PROTECTED]  2007-06-19 09:45 ---
I committed a patch for mod_jk. A dev-tarball of mod_jk can be found at

  http://people.apache.org/~rjung/mod_jk-dev/HugeContent/

This needs to be tested well, especially in combination with Bill Barker's
patches for the Tomcat connectors.

Please report any test results here.


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

Re: client ssl re-negotiation after invalidating session

[Atul Mahajan]

Sorry for the xross post but I wasn't sure if I should open a bug on this and 
wanted to see if its already been resolved.

Thanks
A t u l


- Original Message 
From: Mark Thomas <[EMAIL PROTECTED]>
To: Tomcat Developers List 
Sent: Monday, June 18, 2007 5:14:28 PM
Subject: Re: client ssl re-negotiation after invalidating session


atul wrote:
> Is there a way in tomcat to re-negotiate client certificate after the http 
> session has been invalidated (it had been successfully authenticated once 
> before) in the app. i.e. without closing and starting a new client browser.
> I tried accessing request attributes javax.servlet.request.X509Certificate 
> and org.apache.coyote.request.X509certificate,
> but it did not work.

Please do not cross post.

Mark

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



 

Need Mail bonding?
Go to the Yahoo! Mail Q&A for great tips from Yahoo! Answers users.
http://answers.yahoo.com/dir/?link=list&sid=396546091

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

svn commit: r548802 - in /tomcat/container/tc5.5.x: catalina/build.xml catalina/src/share/org/apache/catalina/mbeans/JMXAdaptorLifecycleListener.java webapps/docs/changelog.xml webapps/docs/monitoring

[pero]

Author: pero
Date: Tue Jun 19 10:19:43 2007
New Revision: 548802

URL: http://svn.apache.org/viewvc?view=rev&rev=548802
Log:
Add JMXAdaptorLifecycleListener to start JMX Connector with fix naming and data 
port. 
This feature is needed to have stable remote access as your local firewall is 
activ.
Implementation only included at src release, build with JDK 1.4.2. 
JMXAdaptorLifecycleListener used some JDK 1.5 classes.

Added:

tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/mbeans/JMXAdaptorLifecycleListener.java
   (with props)
Modified:
tomcat/container/tc5.5.x/catalina/build.xml
tomcat/container/tc5.5.x/webapps/docs/changelog.xml
tomcat/container/tc5.5.x/webapps/docs/monitoring.xml

Modified: tomcat/container/tc5.5.x/catalina/build.xml
URL: 
http://svn.apache.org/viewvc/tomcat/container/tc5.5.x/catalina/build.xml?view=diff&rev=548802&r1=548801&r2=548802
==
--- tomcat/container/tc5.5.x/catalina/build.xml (original)
+++ tomcat/container/tc5.5.x/catalina/build.xml Tue Jun 19 10:19:43 2007
@@ -393,7 +393,7 @@
 
 
 
-
+ 
 
 
 
@@ -401,6 +401,7 @@
 
 
 
+
 
 
 
@@ -613,6 +614,7 @@
   
   
   
+  
 
 
 
@@ -656,7 +658,9 @@
unless="compile.jsse"/>
   
-
+  
+   
 
 
 
@@ -990,6 +994,7 @@
 
 
 
+
 
   
 
@@ -1025,6 +1030,7 @@
 
 
 
+
 
 
 

Added: 
tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/mbeans/JMXAdaptorLifecycleListener.java
URL: 
http://svn.apache.org/viewvc/tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/mbeans/JMXAdaptorLifecycleListener.java?view=auto&rev=548802
==
--- 
tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/mbeans/JMXAdaptorLifecycleListener.java
 (added)
+++ 
tomcat/container/tc5.5.x/catalina/src/share/org/apache/catalina/mbeans/JMXAdaptorLifecycleListener.java
 Tue Jun 19 10:19:43 2007
@@ -0,0 +1,355 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements.  See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License.  You may obtain a copy of the License at
+ * 
+ *  http://www.apache.org/licenses/LICENSE-2.0
+ * 
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.catalina.mbeans;
+
+import java.util.HashMap;
+import java.util.Properties;
+import java.io.IOException;
+import java.io.FileInputStream;
+import java.io.FileNotFoundException;
+
+import org.apache.catalina.Lifecycle;
+import org.apache.catalina.LifecycleEvent;
+import org.apache.catalina.LifecycleListener;
+import org.apache.catalina.core.StandardServer;
+
+import java.net.InetAddress;
+import java.rmi.registry.LocateRegistry;
+import java.rmi.registry.Registry;
+import java.rmi.server.UnicastRemoteObject;
+import javax.rmi.ssl.SslRMIServerSocketFactory;
+import javax.rmi.ssl.SslRMIClientSocketFactory;
+
+import java.lang.management.ManagementFactory;
+import javax.management.MBeanServer;
+import javax.management.remote.JMXServiceURL;
+import javax.management.remote.JMXConnectorServer;
+import javax.management.remote.JMXConnectorServerFactory;
+import javax.management.remote.rmi.RMIConnectorServer;
+
+/**
+ * Start JSR160 JMX Adapter with naming and jmx port! Add only as Server 
Listner
+ * to your tomcat server.xml 
+ * 
+ * ...
+ *     
+ * ...
+ * 
+ * 
+ * 
+ * You can use normal jmx system properties from command line or jmx config 
file: 
+ * 
+ * -Dcom.sun.management.jmxremote.authenticate=true
+ * -Dcom.sun.management.jmxremote.ssl=false
+ * 
-Dcom.sun.management.jmxremote.access.file=$CATALINA_BASE/conf/access.file
+ * 
-Dcom.sun.management.jmxremote.password.file=$CATALINA_BASE/conf/password.file
+ * 
-Dcom.sun.management.config.file=$CATALINA_BASE/conf/jmx.properties
+ * 
+ * 
+ * Then run jconsole with:
+ * 
+ * jconsole service:jmx:rmi://myhost:8084/jndi/rmi://myhost:8083/server
+ * 
+ * 
+ * 
+ * It would be be better if this was built into Tomcat as a configuration
+ * option, rather than having to do it as part of every Tomcat instance.
+ * 
+ * Origanal code idea comes fr

Forms and chunked encoding (fwd)

[Daniel Barkalow]

I'm trying to post a form response from a program I'm writing using curl 
to a web app. So that I don't have to buffer the entire post on the 
sending side, because it could be long, I'd like to use HTTP/1.1's 
"Transfer-Encoding: chunked" instead of "Content-Length". I notice that 
getParameter() doesn't handle this, although getInputStream() does, 
according to an old bug posted against 5.5.12. Has this been fixed? Is 
there any chance of getting it fixed? I can test and write Java, but don't 
have any experience with the Tomcat codebase. I'm using 5.5.23 now, and 
I'm fine with running a patched version.

-Daniel
*This .sig left intentionally blank*

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

ApplicationDispatcher Patch

[Peter Rossbach]

Hi Remy and Filip

you veto my ApplicationDispatcher patch for Tomcat Release 5.5.25  
(revision 545127) 7.6.2007  and see Bugreport 30949:


My patch fix following bugs:

After a exception at ApplicationDispatcher.forward and include is  
thrown:


- Memory Leak at STRICT_SERVLET_COMPILANCE is enabled
Session counter never decrease
- Is crossContext=true at cluster is setup the crossContext session  
replication not working correct
-The correct response close handling at forward is not called after  
an exception is thrown


=> wrequest.recycle is not called

Why unwrapRequest at forward is call twice?
Inside processRequest
and after wrap request at forward()

How we can elegant fix the bugs?

regards
peter

Re: ApplicationDispatcher Patch

[Remy Maucherat]

Peter Rossbach wrote:

Hi Remy and Filip

you veto my ApplicationDispatcher patch for Tomcat Release 5.5.25 
(revision 545127) 7.6.2007  and see Bugreport 30949:


My patch fix following bugs:

After a exception at ApplicationDispatcher.forward and include is thrown:

- Memory Leak at STRICT_SERVLET_COMPILANCE is enabled
Session counter never decrease
- Is crossContext=true at cluster is setup the crossContext session 
replication not working correct
-The correct response close handling at forward is not called after an 
exception is thrown


=> wrequest.recycle is not called

Why unwrapRequest at forward is call twice?
Inside processRequest
and after wrap request at forward()

How we can elegant fix the bugs?


I didn't like your fix at all. Given the problem (if it's real) can 
basically be ignored, the fix would have to be really clean and not 
introduce any try/finally.


Rémy

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

DO NOT REPLY [Bug 42608] - Invalid Content-Length error for the binary file size greater than 2.1GB

[bugzilla]

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

http://issues.apache.org/bugzilla/show_bug.cgi?id=42608





--- Additional Comments From [EMAIL PROTECTED]  2007-06-19 19:55 ---
I have a simple test that submits 4G data and counts the bytes received.

Tested with:
Tomcat 5.5.HEAD, Win XP SP2 Home, using Java APR connector.

Apache 1.3.37, mod_jk 1.2.24-dev built locally with httpd on the same box as
Tomcat fails with a 400 - Invalid content length. The error appears to be httpd
generated.

Apache 2.2.4, mod_jk 1.2.24-dev built locally with httpd on the same box as
Tomcat works (all 4G data is received)

IIS 5, Win2k running on VMWare, mod_jk 1.2.24-dev built locally is *very* slow
for smaller files and fails completely (connection is dropped) for 4G files.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

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

ClassNotFoundException when deserialized from tomcat web app

[jtigre]

Hi,
Sorry for being little over descriptive here. I have an issue deserializing
a file that contains a Map>. These POJO bean classes are stored in a jar
file uder web-app/lib. I can deserialize the file from a standalone java
program, from tomcat web app when tomcat is started from within Eclipse IDE;
but I can not get it to work from the same webapp when tomcat is started in
standalone mode (not from within IDE). I have some javabeans added into a
List object which is added to a LinkedHashMap object in the serialized file.

This is the partial stack trace - 
java.lang.ClassNotFoundException: com.biz.icomp.dbi.DBCustomer  
at java.net.URLClassLoader$1.run(URLClassLoader.java:200)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:268)
at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:242)
at java.io.ObjectInputStream.resolveClass(ObjectInputStream.java:585)

This is the code -
FileInputStream fis = new FileInputStream(serializedFilePath);
ObjectInputStream ois = new ObjectInputStream(fis);
Map map = (Map)ois.readObject();
ois.close();

I even tried to override the default class loader as -
ClassLoader old = Thread.currentThread().getContextClassLoader();
FileInputStream fis = new FileInputStream(serializedFilePath);
ObjectInputStream ois = new ObjectInputStream(fis);
File root = new File();
URLClassLoader urlLoader = new URLClassLoader(new URL[] { root.toURL() },
Thread.currentThread().getContextClassLoader());
Map map = (Map)ois.readObject();
ois.close();
Thread.currentThread().setContextClassLoader(old);

It still doesn't work. I also tried printing the default class loader and
the loader after overriding it. This is what I see - 
>When run from a standalone java class-
Default Class Loader -> [EMAIL PROTECTED]
URLClassLoader Class Loader -> [EMAIL PROTECTED]

>When run from tomcat started directly (not from IDE)-
Default Class Loader -> WebappClassLoader
  delegate: false
  repositories:
/WEB-INF/classes/
--> Parent Classloader:
[EMAIL PROTECTED] (these last 3 lines
are automatically printed)

URLClassLoader Class Loader -> [EMAIL PROTECTED]

>When run from tomcat started within Eclipse-
Default Class Loader -> WebappClassLoader
  delegate: false
  repositories:
/WEB-INF/classes/
--> Parent Classloader:
[EMAIL PROTECTED]

URLClassLoader Class Loader -> [EMAIL PROTECTED]


The class which is not found by the class loader, is actually there in a jar
file in WEB-IN\lib. As I said, it works when I start tomcat from eclipse. Am
I missing anything? Appreciate your help.



-- 
View this message in context: 
http://www.nabble.com/ClassNotFoundException-when-deserialized-from-tomcat-web-app-tf3950085.html#a11206616
Sent from the Tomcat - Dev mailing list archive at Nabble.com.

Re: ApplicationDispatcher Patch

[Peter Rossbach]

Hi remy,


I think the problem is real. Some portlet api and modularized web  
applications have this problem.
Why you veto a fix without a better proposal? I don't see currently  
an option without a try/finally block.


regards
Peter



Am 19.06.2007 um 22:59 schrieb Remy Maucherat:


Peter Rossbach wrote:

Hi Remy and Filip
you veto my ApplicationDispatcher patch for Tomcat Release 5.5.25  
(revision 545127) 7.6.2007  and see Bugreport 30949:

My patch fix following bugs:
After a exception at ApplicationDispatcher.forward and include is  
thrown:

- Memory Leak at STRICT_SERVLET_COMPILANCE is enabled
Session counter never decrease
- Is crossContext=true at cluster is setup the crossContext  
session replication not working correct
-The correct response close handling at forward is not called  
after an exception is thrown

=> wrequest.recycle is not called
Why unwrapRequest at forward is call twice?
Inside processRequest
and after wrap request at forward()
How we can elegant fix the bugs?


I didn't like your fix at all. Given the problem (if it's real) can  
basically be ignored, the fix would have to be really clean and not  
introduce any try/finally.


Rémy

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