DO NOT REPLY [Bug 42419] New: - Options for changing jsessionid cookie name

[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=42419

   Summary: Options for changing jsessionid cookie name
   Product: Tomcat 5
   Version: 5.0.17
  Platform: All
OS/Version: All
Status: NEW
  Severity: enhancement
  Priority: P3
 Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Feature request for allowing people to change the default 
jsessionid cookie name.

This feature is needed in the following case :

Setup :
---
- A single Apache web server fronting Tomcat servers 
  AND other proprietary web servers.
- A web applications 'A' is deployed on a Tomcat server, while another 
  web application 'B' is deployed on another proprietary web server. 
  Both applications 'A' and 'B' are accessed through the same IP or DNS 
  name, but with different context-roots.

Problem :
-
1) A user logs in on application 'A' on a Tomcat server, and does some work.
   The id of his session is retained in a cookie, named "JSESSIONID"
2) web application A redirects the user to an application B on another, 
   proprietary, web server.
3) The user arrives on application B. The session id contained in the cookie
   is not recognized. A new one is created, which replaces the old one.
4) user returns to application A. The session id contained in JSESSIONID cookie
   is the id of a session on a proprietary web server, which obviously does not
   correspond to any session on Tomcat. Thus, Tomcat is unable to retrieve the
   user's session. Session is lost.

In some case, this problem can be fixed by setting the 'emptySessionPath'
attribute to 'false' in Tomcat's server.xml. This will make all JSESSIONID 
cookies target '/context' path instead of '/', and hence preserve the values
of the jessionid cookies. However, this attribute cannot be set to false in 
some scenarios, e.g. when portals are used, which require that jsessionid
cookies be transmitted across applications.

Solution :
--
A solution is to allow people to configure the name of the jsessionid cookie,
for all applications on a given server, or for a specific application.
In the depicted scenario, this prevents the application server 'B' to overwrite 
the jsessionid cookie of the application 'A'.

Currently, changing the name of the jessionid cookie is not possible, as it is 
harcoded in the following source files (non-exhaustive list) :
 org/apache/catalina/connector/CoyoteAdapter.java (catalina.jar)
 org/apache/catalina/connector/Response.java (catalina.jar)
 org/apache/catalina/realm/RealmBase.java (catalina.jar)
 org/apache/jasper/tagplugins/jstl/Util.java (jasper-compiler.jar)
 native/common/jk_global.h (mod_jk.so)

This feature request applies (at least) to Catalina, Jasper and Native:JK.

-- 
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]

DO NOT REPLY [Bug 42424] New: - Missing Hint about Adblock in the docs/FAQs

[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=42424

   Summary: Missing Hint about Adblock in the docs/FAQs
   Product: Tomcat 5
   Version: 5.5.17
  Platform: Other
OS/Version: Windows XP
Status: NEW
  Severity: trivial
  Priority: P2
 Component: Webapps:Administration
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


I don't know if this is the right place to put this, but I don't know any better
onw.

When you use AdBlock in Firefox 2.0 you wont see the top level frame
(banner.jsp) in the admin webapp, which means you can neither commit changes nor
log off.

Its not really tragic, but it took me a long while to find out what I was
missing (the Docs/FAQ only talks about the Commit Button, but not where it
should be).

-- 
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: [VOTE] Release build 6.0.13

[Martin Dubuc]

I have been using 6.0.13 for a few days. I was using 6.0.11 for some
time up to then. My app was running pretty smooth with 6.0.11. I do
not not if it is a coincidence or not, but since seitching to 6.0.13,
I have seen a few cases of Java exceptions, all seems to be related to
MySQL Connector/J connection timing out. I am wondering if anything
has changed in Tomcat since version 6.0.11 that could explain this
kind of issue.

Here is the stack trace of one such exception:

java.io.EOFException
   at com.mysql.jdbc.MysqlIO.readFully(MysqlIO.java:1963)
   at com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:2375)
   at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:2874)
   at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:1623)
   at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:1715)
   at com.mysql.jdbc.Connection.execSQL(Connection.java:3243)
   at com.mysql.jdbc.Connection.execSQL(Connection.java:3172)
   at com.mysql.jdbc.Statement.executeQuery(Statement.java:1197)
   at 
org.apache.tomcat.dbcp.dbcp.DelegatingStatement.executeQuery(DelegatingStatement.java:208)
...
   at org.apache.jsp.login_jsp._jspService(login_jsp.java:77)
   at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)
   at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
   at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper
.java:393)
   at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:3
20)
   at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:266)
   at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
   at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appl
icationFilterChain.java:290)
   at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationF
ilterChain.java:206)
   at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDisp
atcher.java:654)
   at org.apache.catalina.core.ApplicationDispatcher.processRequest(Applica
tionDispatcher.java:445)
   at org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationD
ispatcher.java:379)
   at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDis
patcher.java:292)
   at 
org.apache.catalina.authenticator.FormAuthenticator.forwardToLoginPage(FormAuthenticator.java:316)
   at 
org.apache.catalina.authenticator.FormAuthenticator.authenticate(FormAuthenticator.java:244)
   at 
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:491)
   at 
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
   at 
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:104)
   at 
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:563)
   at 
org.apache.catalina.authenticator.SingleSignOn.invoke(SingleSignOn.java:393)
   at 
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
   at 
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:261)
   at 
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
   at 
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:581)
   at 
org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
   at java.lang.Thread.run(Thread.java:619)

Martin

On 5/8/07, Remy Maucherat <[EMAIL PROTECTED]> wrote:

The candidates binaries are available here:
http://people.apache.org/~remm/tomcat-6/v6.0.13/

According to the release process, the 6.0.13 tag is:
[ ] Broken
[ ] Alpha
[ ] Beta
[ ] Stable

Rémy

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




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

[RESULT] Release build 6.0.13

[Remy Maucherat]

9 "stable" binding votes, no other votes.

Rémy

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

Re: [VOTE] Release build 6.0.13

[Remy Maucherat]

Martin Dubuc wrote:

I have been using 6.0.13 for a few days. I was using 6.0.11 for some
time up to then. My app was running pretty smooth with 6.0.11. I do
not not if it is a coincidence or not, but since seitching to 6.0.13,
I have seen a few cases of Java exceptions, all seems to be related to
MySQL Connector/J connection timing out. I am wondering if anything
has changed in Tomcat since version 6.0.11 that could explain this
kind of issue.


DBCP was updated in 6.0.11, but has not been changed since that build.

Rémy

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

[ANN] Apache Tomcat 6.0.13 released

[Remy Maucherat]

The Apache Tomcat team announces the immediate availability of Apache
Tomcat 6.0.13 stable. This release is the second stable release of the
6.0.x branch, and includes bugfixes over Apache Tomcat 6.0.10.

Apache Tomcat 6.0 includes new features over Apache Tomcat 5.5,
including support for the new Servlet 2.5 and JSP 2.1 specifications, a
refactored clustering implementation, advanced IO features, and
improvements in memory usage.

Please refer to the change log for the list of changes:
http://tomcat.apache.org/tomcat-6.0-doc/changelog.html

Downloads:
http://tomcat.apache.org/download-60.cgi

Migration guide from Apache Tomcat 5.5.x:
http://tomcat.apache.org/migration.html

Thank you,

-- The Apache Tomcat Team

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

tcnative-1.dll crashes jvm: how do i provide

[Stu Thompson]

Hi all,

 

My webapp can somewhat regularly crash the JVM on multiple machines.
Most of the hotspot dump files are remarkably consistence with where the
error is occurring...then again, I do know what is important and what is
not.  Running tomcat without tcnative-1.dll resolves the problem but I'd
like to help find the solution.  While researching this issue, it has
become clear that I should submit debugging info that would be generated
by having a specially compiled tcnative-1.dll what would provide a stack
trace.  C programming (and compiling) is not exactly my thing, so...

 

Where can I get myself a tcnative-1.dll binary compiled with debugging
symbol?  

 

Once I get that, I should be able to reproduce the error and submit a
bug report with the debugging data.

 

Tia,

 

Stu

 

Particulars:

 - OS: Windows XP and Server 2003

- Java: 1.5.0_08-b03, 1.5.0_07-b03, ...

- Tomcat: 6.0.10

 

HotSpot dump:

#

# An unexpected error has been detected by HotSpot Virtual Machine:

#

#  EXCEPTION_ACCESS_VIOLATION (0xc005) at pc=0x10003ede, pid=2040,
tid=2444

#

# Java VM: Java HotSpot(TM) Client VM (1.5.0_08-b03 mixed mode)

# Problematic frame:

# C  [tcnative-1.dll+0x3ede]

#

 

---  T H R E A D  ---

 

Current thread (0x0b4da4a8):  JavaThread "Thread-2" [_thread_in_native,
id=2444]

 

siginfo: ExceptionCode=0xc005, reading address 0x1225

 

Registers:

EAX=0x1221, EBX=0x, ECX=0x0b72, EDX=0x0b484f38

ESP=0x0ba2f7ec, EBP=0x0ba2f7f0, ESI=0x0b484f38, EDI=0x0b71ff38

EIP=0x10003ede, EFLAGS=0x00010206

 

Top of Stack: (sp=0x0ba2f7ec)

0x0ba2f7ec:   0b717f90 0ba2f810 10014394 0b484f38

0x0ba2f7fc:    06ed64e8 0b717f90 0ba2f824

0x0ba2f80c:   10004048 0ba2f824 10004055 0b71ff38

0x0ba2f81c:   0b4da4a8 06ed64e8 0ba2f858 008d832f

0x0ba2f82c:   0b4da568 0ba2f860 0b717f90 

0x0ba2f83c:   0ba2f83c 06ed64e8 0ba2f86c 06ed7410

0x0ba2f84c:    06ed64e8 0ba2f868 0ba2f88c

0x0ba2f85c:   008d2a8f 06ed73b0 008d6509 0b717f90 

 

Instructions: (pc=0x10003ede)

0x10003ece:   90 90 55 8b ec 56 8b 75 08 8b 46 18 85 c0 74 10

0x10003ede:   8b 40 04 85 c0 74 09 8b 4e 0c 51 ff d0 83 c4 04 

 

 

Stack: [0x0b9f,0x0ba3),  sp=0x0ba2f7ec,  free space=253k

Native frames: (J=compiled Java code, j=interpreted, Vv=VM code,
C=native code)

C  [tcnative-1.dll+0x3ede]

C  [tcnative-1.dll+0x14394]

C  [tcnative-1.dll+0x4055]

j  org.apache.tomcat.jni.Socket.close(J)I+0

j  org.apache.tomcat.util.net.AprEndpoint.destroy()V+27

j  org.apache.coyote.http11.Http11AprProtocol.destroy()V+35

j  org.apache.catalina.connector.Connector.stop()V+109

j  org.apache.catalina.core.StandardService.stop()V+201

j  org.apache.catalina.core.StandardServer.stop()V+65

j  org.apache.catalina.startup.Catalina.stop()V+39

j  org.apache.catalina.startup.Catalina.start()V+154

v  ~StubRoutines::call_stub

V  [jvm.dll+0x86e84]

V  [jvm.dll+0xddead]

V  [jvm.dll+0x86d55]

V  [jvm.dll+0xf1f59]

V  [jvm.dll+0xa4d04]

C  [java.dll+0x6d11]

j
sun.reflect.NativeMethodAccessorImpl.invoke(Ljava/lang/Object;[Ljava/lan
g/Object;)Ljava/lang/Object;+87

J
sun.reflect.DelegatingMethodAccessorImpl.invoke(Ljava/lang/Object;[Ljava
/lang/Object;)Ljava/lang/Object;

J
java.lang.reflect.Method.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Lj
ava/lang/Object;

v  ~RuntimeStub::alignment_frame_return Runtime1 stub

j  org.apache.catalina.startup.Bootstrap.start()V+37

j  org.apache.catalina.startup.Bootstrap.main([Ljava/lang/String;)V+125

v  ~StubRoutines::call_stub

V  [jvm.dll+0x86e84]

V  [jvm.dll+0xddead]

V  [jvm.dll+0x86d55]

V  [jvm.dll+0x8dda7]

C  [tomcat6.exe+0x625a]

 

Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)

j  org.apache.tomcat.jni.Socket.close(J)I+0

j  org.apache.tomcat.util.net.AprEndpoint.destroy()V+27

j  org.apache.coyote.http11.Http11AprProtocol.destroy()V+35

j  org.apache.catalina.connector.Connector.stop()V+109

j  org.apache.catalina.core.StandardService.stop()V+201

j  org.apache.catalina.core.StandardServer.stop()V+65

j  org.apache.catalina.startup.Catalina.stop()V+39

j  org.apache.catalina.startup.Catalina.start()V+154

v  ~StubRoutines::call_stub

j
sun.reflect.NativeMethodAccessorImpl.invoke0(Ljava/lang/reflect/Method;L
java/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+0

j
sun.reflect.NativeMethodAccessorImpl.invoke(Ljava/lang/Object;[Ljava/lan
g/Object;)Ljava/lang/Object;+87

J
sun.reflect.DelegatingMethodAccessorImpl.invoke(Ljava/lang/Object;[Ljava
/lang/Object;)Ljava/lang/Object;

J
java.lang.reflect.Method.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Lj
ava/lang/Object;

v  ~RuntimeStub::alignment_frame_return Runtime1 stub

j  org.apache.catalina.startup.Bootstrap.start()V+37

j  org.apache.catalina.startup.Bootstrap.main([Ljava/lang/String;)V+125

v  ~StubRoutines::call_stub

 

---  P R O C E S S  ---

 

Java Threads: ( => current thread )

  0x0bcf3e18 JavaThread "ajp-8009-1" daemon [_thread_blocked

Changing JK_OPT_FWDURIDEFAULT to JK_OPT_FWDURICOMPATUNPARSED

[Jean-Frederic]

Hi,

I think that the default value of JK_OPT_FWDURIDEFAULT is bad and should
be JK_OPT_FWDURICOMPATUNPARSED.

Any comments?

Cheers

Jean-Frederic


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

Re: tcnative-1.dll crashes jvm: how do i provide

[Markus Schönhaber]

Stu Thompson wrote:

> My webapp can somewhat regularly crash the JVM on multiple machines.
> Most of the hotspot dump files are remarkably consistence with where the
> error is occurring...then again, I do know what is important and what is
> not.  Running tomcat without tcnative-1.dll resolves the problem but I'd
> like to help find the solution.  While researching this issue, it has
> become clear that I should submit debugging info that would be generated
> by having a specially compiled tcnative-1.dll what would provide a stack
> trace.  C programming (and compiling) is not exactly my thing, so...
> 
> Where can I get myself a tcnative-1.dll binary compiled with debugging
> symbol?  

I don't know if pre-built binaries with debugging symbols are available
somewhere. But you can always roll your own tcnative-1.dll. The sources
are available from
http://tomcat.heanet.ie/native/

>  - OS: Windows XP and Server 2003
> 
> - Java: 1.5.0_08-b03, 1.5.0_07-b03, ...
> 
> - Tomcat: 6.0.10

But before I'd start with debugging, I'd install the latest update for
the JVM and the latest version of the native DLL an check whether the
problem still shows.

Regards
  mks

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

Re: Changing JK_OPT_FWDURIDEFAULT to JK_OPT_FWDURICOMPATUNPARSED

[Rainer Jung]

I didn't follow this, but the comment in the httpd 2.x module code says:

/*
 * The 2.2 servlet spec errata says the uri from
 * HttpServletRequest.getRequestURI() should remain encoded.
 * [http://java.sun.com/products/servlet/errata_042700.html]
 *
 * We use JkOptions to determine which method to be used
 *
 * ap_escape_uri is the latest recommanded but require
 *   some java decoding (in TC 3.3 rc2)
 *
 * unparsed_uri is used for strict compliance with spec and
 *  old Tomcat (3.2.3 for example)
 *
 * uri is use for compatibilty with mod_rewrite with old Tomcats
 */

We do (pseudo code):

JK_OPT_FWDURICOMPATUNPARSED:
s->req_uri = r->unparsed_uri;
if (s->req_uri != NULL) {
char *query_str = strchr(s->req_uri, '?');
if (query_str != NULL) {
*query_str = 0;
}
}

JK_OPT_FWDURICOMPAT (the DEFAULT):
s->req_uri = r->uri;

JK_OPT_FWDURIESCAPED:
s->req_uri = ap_escape_uri(r->pool, r->uri);
break;


And finally our docs state:

The three following options +ForwardURIxxx are mutually exclusive. ...
By default, the option ForwardURICompat is turned on. You can turn this 
off by switching on one of the other two.


JkOptions ForwardURICompat, you ask mod_jk to send the URI to Tomcat 
normally, which is less spec compliant but mod_rewrite compatible, use 
it for compatibility with Tomcat 3.2.x engines (on by default).


JkOptions ForwardURICompatUnparsed, the forwarded URI is unparsed, it's 
spec compliant but broke mod_rewrite.


JkOptions ForwardURIEscaped, the forwarded URI is escaped and Tomcat 
(since 3.3 rc2) will do the decoding part.


So what we do is what is documented. Breaking the default should have 
serious reasons at least. For 1.3/3.0 we could consider changing more 
easily of course.


Why do you think the default is bad?

Regards,

Rainer

Jean-Frederic wrote:

Hi,

I think that the default value of JK_OPT_FWDURIDEFAULT is bad and should
be JK_OPT_FWDURICOMPATUNPARSED.

Any comments?

Cheers

Jean-Frederic


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

DO NOT REPLY [Bug 40070] - APR causes JVM to crashon SEGV

[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=40070





--- Additional Comments From [EMAIL PROTECTED]  2007-05-15 10:48 ---
(In reply to comment #6)
> Fixed in the SVN. The fix will be available with tomcat-native-1.1.7

I have experienced this issue (or one very similar) with tomcat-native-1.1.8. 
Would you like my hs_err dump?

-- 
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]

DO NOT REPLY [Bug 40070] - APR causes JVM to crashon SEGV

[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=40070


[EMAIL PROTECTED] changed:

   What|Removed |Added

 CC||[EMAIL PROTECTED]




-- 
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]

DO NOT REPLY [Bug 40070] - APR causes JVM to crashon SEGV

[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=40070





--- Additional Comments From [EMAIL PROTECTED]  2007-05-15 10:57 ---
Created an attachment (id=20203)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=20203&action=view)
jvm crash dump


-- 
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: DO NOT REPLY [Bug 42353] - org.apache.jk.core.MsgContext Error sending end packet

[Shankar Unni]

--- Additional Comments From [EMAIL PROTECTED]  2007-05-14 16:31 ---
There are other explanations but Bugzilla is not a support forum to provide
these explanations. Please sue the users list.


Isn't that rather a heavy-handed course of action? :-)


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

Tomcat is not responding

[Vishal Dedaniya]

Hi,
 
I am using Tomcat 5.0.28 in a RedHat Linux machine. We have deployed a
j2ee application under root context of Tomcat server and we are using
MySQL as database which is exists on different box. Our application was
running fine when we have first deployed it on Jan, 2006
 
Max connection limit in MySQL Config file is 100
 
Since last two months we are facing some problem with the Tomcat is that
every day it is falling in hang state and to make it up either we have
to restart the Tomcat or sometime we have reboot Linux box too..
 
We would like to request you to please look into this problem and please
provide us some suggestion to resolve this problem.
 
Waiting for your reply.
 
Thank You,
Vishal

"Legal Disclaimer: This electronic message and all contents contain information 
from Cybage Software Private Limited which may be privileged, confidential, or 
otherwise protected from disclosure. The information is intended to be for the 
addressee(s) only. If you are not an addressee, any disclosure, copy, 
distribution, or use of the contents of this message is strictly prohibited. If 
you have received this electronic message in error please notify the sender by 
reply e-mail to and destroy the original message and all copies. Cybage has 
taken every reasonable precaution to minimize the risk of malicious content in 
the mail, but is not liable for any damage you may sustain as a result of any 
malicious content in this e-mail. You should carry out your own malicious 
content checks before opening the e-mail or attachment."
www.cybage.com 

Re: Changing JK_OPT_FWDURIDEFAULT to JK_OPT_FWDURICOMPATUNPARSED

[Jean-Frederic]

On Tue, 2007-05-15 at 18:37 +0200, Rainer Jung wrote:
> I didn't follow this, but the comment in the httpd 2.x module code says:
> 
>  /*
>   * The 2.2 servlet spec errata says the uri from
>   * HttpServletRequest.getRequestURI() should remain encoded.
>   * [http://java.sun.com/products/servlet/errata_042700.html]
>   *
>   * We use JkOptions to determine which method to be used
>   *
>   * ap_escape_uri is the latest recommanded but require
>   *   some java decoding (in TC 3.3 rc2)
>   *
>   * unparsed_uri is used for strict compliance with spec and
>   *  old Tomcat (3.2.3 for example)
>   *
>   * uri is use for compatibilty with mod_rewrite with old Tomcats
>   */
> 
> We do (pseudo code):
> 
> JK_OPT_FWDURICOMPATUNPARSED:
>  s->req_uri = r->unparsed_uri;
>  if (s->req_uri != NULL) {
>  char *query_str = strchr(s->req_uri, '?');
>  if (query_str != NULL) {
>  *query_str = 0;
>  }
>  }
> 
> JK_OPT_FWDURICOMPAT (the DEFAULT):
>  s->req_uri = r->uri;
> 
> JK_OPT_FWDURIESCAPED:
>  s->req_uri = ap_escape_uri(r->pool, r->uri);
>  break;
> 
> 
> And finally our docs state:
> 
> The three following options +ForwardURIxxx are mutually exclusive. ...
> By default, the option ForwardURICompat is turned on. You can turn this 
> off by switching on one of the other two.
> 
> JkOptions ForwardURICompat, you ask mod_jk to send the URI to Tomcat 
> normally, which is less spec compliant but mod_rewrite compatible, use 
> it for compatibility with Tomcat 3.2.x engines (on by default).
> 
> JkOptions ForwardURICompatUnparsed, the forwarded URI is unparsed, it's 
> spec compliant but broke mod_rewrite.
> 
> JkOptions ForwardURIEscaped, the forwarded URI is escaped and Tomcat 
> (since 3.3 rc2) will do the decoding part.
> 
> So what we do is what is documented. Breaking the default should have 
> serious reasons at least. For 1.3/3.0 we could consider changing more 
> easily of course.
> 
> Why do you think the default is bad?

Because it breaks the spec's and allows unexpected handling of url that
are encoded (for example: /context-A/%252E%252E/context-B that is send
to Tomcat as /context-A/%2E%2E/context-B and mapped by Tomcat
as /context-B).

Cheers

Jean-Frederic

> 
> Regards,
> 
> Rainer
> 
> Jean-Frederic wrote:
> > Hi,
> > 
> > I think that the default value of JK_OPT_FWDURIDEFAULT is bad and should
> > be JK_OPT_FWDURICOMPATUNPARSED.
> > 
> > Any comments?
> > 
> > Cheers
> > 
> > Jean-Frederic
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 


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