Patch for jk_sockbuf.c
These changes fixes the following problem:
When using ajp12 with mod_jk, httpd procesess handling a request
will hang, using all cpu time, if tomcat is shut down before the headers
of the request have been sent from tomcat.
BR,
Stefan berg
***
/usr/local/src/apache/jakarta-tomcat-3.2.1-src/src/native/jk/jk_sockbuf.c
Tue Mar 6 10:10:40 2001
--- jk_sockbuf.cTue Mar 6 10:15:54 2001
***
*** 131,137
if(sb-end == sb-start) {
sb-end = sb-start = 0;
! if(!fill_buffer(sb)) {
return JK_FALSE;
}
}
--- 131,137
if(sb-end == sb-start) {
sb-end = sb-start = 0;
! if(fill_buffer(sb) 0) {
return JK_FALSE;
}
}
***
*** 169,175
return JK_TRUE;
}
}
! if(!fill_buffer(sb)) {
return JK_FALSE;
}
}
--- 169,175
return JK_TRUE;
}
}
! if(fill_buffer(sb) = 0 ) {
return JK_FALSE;
}
}
***
*** 205,215
SOCKBUF_SIZE - sb-end, 0);
if(ret 0) {
! return JK_FALSE;
}
sb-end += ret;
! return JK_TRUE;
}
-
--- 205,214
SOCKBUF_SIZE - sb-end, 0);
if(ret 0) {
! return ret;
}
sb-end += ret;
! return ret;
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
RE: Assigning Servlets to different ports.
Why don't you just run 2 servlet container(Tomcat)s for each port? -Original Message- From: William Wishon [mailto:[EMAIL PROTECTED]] Sent: Tuesday, March 06, 2001 9:27 AM To: [EMAIL PROTECTED] Subject: Assigning Servlets to different ports. Hi, snipped An example of what I'm trying to do is to have a GET on "/" of port 8080 return webapps/app1/index.html and a GET of "/" on port 8081 return webapps/app2/index.html. Thanks, Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [GUMP] Build Failure - Tomcat 3.x
Costin, Is there any reasonable explanation for changing the ant structure ( i.e. removing ant/bin ) ? Besides breaking backward compatibility and forcing people to change their scripts ? We like you to change your scripts on a regular basis to stop them getting stale :-) Seriously Ant's build process was reorganized recently to build ant within the ant directory rather than above it. At that time, the bootstrapped Ant was moved into its own directory (bootstrap) so that generated jars (ant.jar) were not placed into a CVS directory (lib) where they may be inadvertently added to CVS. It made sense to move bin at the same time. If you have previously been using the ant/bin and ant/lib directories, you have actually been using the bootstrapped ant rather than the fully built ant. That is generally not a problem, of course, but perhaps not desirable. Also I think it is probably best for other projects not to rely on the internal organizaton of the Ant CVS tree but on the distribution built in the dist directory. Is that a "reasonable explanation" - you'll have to be the judge. Conor - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-4.0/catalina/src/bin catalina.sh
glenn 01/03/06 06:13:51
Modified:catalina/src/bin catalina.sh
Log:
Fix embedded startup classpath, contributed by Ulf Jaehrig
Revision ChangesPath
1.14 +5 -2 jakarta-tomcat-4.0/catalina/src/bin/catalina.sh
Index: catalina.sh
===
RCS file: /home/cvs/jakarta-tomcat-4.0/catalina/src/bin/catalina.sh,v
retrieving revision 1.13
retrieving revision 1.14
diff -u -r1.13 -r1.14
--- catalina.sh 2001/02/21 03:38:27 1.13
+++ catalina.sh 2001/03/06 14:13:49 1.14
@@ -12,7 +12,7 @@
#
# JAVA_HOME Must point at your Java Development Kit installation.
#
-# $Id: catalina.sh,v 1.13 2001/02/21 03:38:27 glenn Exp $
+# $Id: catalina.sh,v 1.14 2001/03/06 14:13:49 glenn Exp $
# -
@@ -93,7 +93,10 @@
elif [ "$1" = "embedded" ] ; then
shift
- for i in ${CATALINA_HOME}/server/*.jar ; do
+ for i in ${CATALINA_HOME}/server/lib/*.jar ; do
+CP=$i:${CP}
+ done
+ for i in ${CATALINA_HOME}/common/lib/*.jar ; do
CP=$i:${CP}
done
echo Embedded Classpath: $CP
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: Tomcat 4 and Embedded
I committed the patch to catalina.sh, thanks Ulf!
I'm not sure about the patch to ContextConfig.java,
anyone else want to take a look at that?
Regards,
Glenn
Ulf Jaehrig wrote:
Hi,
today I experimented with the Catalina Embedded.class. I first try to
start it with "catalina.sh embedded" failed, so I tried to get it run.
After these changes it started. Maybe these are of interest...
The change in the catalina.sh adds the jar files in server/lib and
common/lib to the embedded classpath. Without these the start fails
because of NoClassDefFoundError errors.
The change in the ContextConfig.java changes a cast of context. Without
it, a ClassCastException is thrown.
Bye,
Ulf
===
RCS file:
/home/cvspublic/jakarta-tomcat-4.0/catalina/src/bin/catalina.sh,v
retrieving revision 1.13
diff -u -r1.13 catalina.sh
--- catalina.sh 2001/02/21 03:38:27 1.13
+++ catalina.sh 2001/03/06 13:08:07
@@ -93,7 +93,10 @@
elif [ "$1" = "embedded" ] ; then
shift
- for i in ${CATALINA_HOME}/server/*.jar ; do
+ for i in ${CATALINA_HOME}/server/lib/*.jar ; do
+CP=$i:${CP}
+ done
+ for i in ${CATALINA_HOME}/common/lib/*.jar ; do
CP=$i:${CP}
done
echo Embedded Classpath: $CP
===
RCS file:
/home/cvspublic/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup/ContextConfig.java,v
retrieving revision 1.41
diff -u -r1.41 ContextConfig.java
--- ContextConfig.java 2001/02/26 03:53:12 1.41
+++ ContextConfig.java 2001/03/06 13:09:08
@@ -809,10 +809,16 @@
// Dump the contents of this pipeline if requested
if (debug = 1) {
log("Pipline Configuration:");
-Valve valves[] = ((Pipeline) context).getValves();
-for (int i = 0; i valves.length; i++) {
-log(" " + valves[i].getInfo());
+if (context instanceof ContainerBase) {
+Pipeline pipeline = ((ContainerBase)
context).getPipeline();
+if (pipeline != null) {
+Valve valves[] = pipeline.getValves();
+for (int i = 0; i valves.length; i++) {
+log(" " + valves[i].getInfo());
+}
+}
}
+
log("==");
}
--
Distributed Engineering Systems Software GmbH
Reichenbachstr. 16, 68309 Mannheim, Germany
Tel: +49(0)621-7363063 Fax: +49(0)621-7363064
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
--
--
Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder|
MOREnet System Programming | * if iz ina coment. |
Missouri Research and Education Network | */ |
--
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: [GUMP] Build Failure - Tomcat 3.x
Conor MacNeill wrote:
Costin,
Is there any reasonable explanation for changing the ant structure ( i.e.
removing ant/bin ) ? Besides breaking backward compatibility and forcing
people to change their scripts ?
We like you to change your scripts on a regular basis to stop them getting
stale :-)
Yah, we know :-)
I dealt with this particular change by setting my ANT_HOME environment variable
to "${my.jakarta.home}/jakarta-ant/dist" instead of
"${my.jakarta.home}/jakarta-ant". That way, everything that is resolved
relative to ANT_HOME works correctly, whether I'm using the current CVS source
code or a binary distro.
Craig
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: [GUMP] Build Failure - Tomcat 3.x
Thanks Conor, It was a double mistake - Sam set ant.home to a wrong value in gump and I guessed wrong what was changed ( assuming the distribution layout changed). Tomcat doesn't depend on how ant build process works, only on the final directory layout ( in the distrib ). Meanwhile I updated ant, did a build - and congrats for the cleaned-up build process ( I don't like building in the source dir, but I'll get used to it :-). Costin On Tue, 6 Mar 2001, Conor MacNeill wrote: Costin, Is there any reasonable explanation for changing the ant structure ( i.e. removing ant/bin ) ? Besides breaking backward compatibility and forcing people to change their scripts ? We like you to change your scripts on a regular basis to stop them getting stale :-) Seriously Ant's build process was reorganized recently to build ant within the ant directory rather than above it. At that time, the bootstrapped Ant was moved into its own directory (bootstrap) so that generated jars (ant.jar) were not placed into a CVS directory (lib) where they may be inadvertently added to CVS. It made sense to move bin at the same time. If you have previously been using the ant/bin and ant/lib directories, you have actually been using the bootstrapped ant rather than the fully built ant. That is generally not a problem, of course, but perhaps not desirable. Also I think it is probably best for other projects not to rely on the internal organizaton of the Ant CVS tree but on the distribution built in the dist directory. Is that a "reasonable explanation" - you'll have to be the judge. Conor - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Tomcat 3.2.2 [was: RE: Spec Compliance: getRequestedSessionId(), ...]
After some further investigation into session ids and url rewritting I've found more places in the Tomcat 3.2 code that are using the requested session id as the active session id. I'm tracking down and fixes these now. These code changes are beyond what I'm willing to accept, as a release manager, during a beta release. The release plan called for a single beta cycle with the provision of additional betas if necessary. Once these bugs are resolved I will create a Tocmat 3.2.2 beta 2 release for evaluation. -Original Message- From: Marc Saegesser [mailto:[EMAIL PROTECTED]] Sent: Monday, March 05, 2001 6:45 PM To: [EMAIL PROTECTED] Subject: RE: Spec Compliance: getRequestedSessionId(), ... The Servlet 3.2 API spec (PFD) attempts to clarify this some, but I think muddles it even further with some truly odd wording. I'm going to fix this in 3.2.2 unless I hear something contrary from the serlvet-api folks. Its kind of late in the game for code changes to 3.2.2 but I really hate known spec failures. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Hans Bergsten Sent: Monday, March 05, 2001 6:32 PM To: [EMAIL PROTECTED] Subject: Re: Spec Compliance: getRequestedSessionId(), ... Marc Saegesser wrote: I'm reviewing Bugzilla bugs in preparation of the Tomcat 3.2.2 release. Bugzilla 160 has been open since Tomcat 3.1 and it looks like its real and that it violates the Servlet 2.2 spec. I want to make sure I am correctly interpretting the spec before I dig too deep. I'll send a similar message to the servlet api mailing list. 1) HttpServletRequest.getRequestedSessionId() should return the session that arrived with the request. This might not match the session id returned by HttpServletRequest.getSession()because the session might have been invalidated or timed out, etc. So far so good. What isn't clear (at least from reading the code) is should calling HttpServletRequest.getSession() modify the requested session id. I think that it shouldn't but the code in RequestImpl.java updates the requested session id. A quick look at the Tomcat 3.3 version appears to work as I expected it to. Your interpretation of the spec is the same as mine: Calling getSession() should not modify the *requested* session ID. In other words, you need to keep track of both the requested and the actual session ID to implement these methods. 2) A related question, HttpServletRequest.isRequestedSessionIdValid() is implemented as follows: HttpSession session = (HttpSession)request.getSession(false); return (session != null); If this method is called *before* the invoking servlet calls getSession(true) then it will correctly determine if the *requested* session id was valid. After that it will always return true. This seems wrong because specification clearly states this method determines if the requested session id was valid. Tomcat 3.3 appears to suffer from this problem. Again, my interpretation is the same as yours. You should test if the requested session is the same as the actual session instead. Hans -- Hans Bergsten [EMAIL PROTECTED] Gefion Software http://www.gefionsoftware.com Author of JavaServer Pages (O'Reilly), http://TheJSPBook.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
[TC 3.3m1] New Bug in mod_jk auto config generation
It looks like there have been some new changes to the Tomcat auto config generator. Now when you startup, TC3.3 says: 2001-03-06 10:18:48 - ApacheConfig: Generating apache mod_jserv config = /conf/jserv/tomcat-apache.conf 2001-03-06 10:18:48 - ApacheConfig: Generating apache mod_jk config = /conf/jk/mod_jk.conf-auto The jserv stuff is new. This is OK, except that now the config files are put in /conf on the server, not $TOMCAT_HOME/conf # ls /conf jk jserv Could someone please fix this? The above is from last nights build of TC3.3m1 at http://jakarta.apache.org/builds/jakarta-tomcat/nightly-3.3/ It also looks like the mod_jk.conf-auto has been changed. The paths are not correct: was LoadModule jk_module libexec/mod_jk.so JkWorkersFile /usr/local/tomcat/conf/jk/workers.properties JkLogFile /usr/local/tomcat/logs/mod_jk.log now is LoadModule jk_module /usr/local/tomcat/libexec/mod_jk.so JkWorkersFile "/conf/jk/workers.properties" JkLogFile "/logs/mod_jk.log" Thanks, Mike. -- Mike Braden CNE, MCP+I, MCSE, CCNA, Sun Comp 2k Enterprise E10k Utenzi 808 Aviation Parkway Suite 1100 PO Box 13479 Research Triangle Park, NC 27709 [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat/src/facade22/org/apache/tomcat/facade HttpServletRequestFacade.java
larryi 01/03/06 08:07:45
Modified:src/facade22/org/apache/tomcat/facade
HttpServletRequestFacade.java
Log:
Port patch from tomcat_32 for part of Bugzilla Bug #160
The isRequestedSessionIdValid() should be based on the value of
getRequestedSessionId().Instead of just checking that getSession(false)
returns a non-null value (i.e. there is an active session) we must
also test that the active session's ID matches the requested session id.
Patch By: Marc Saegesser
Revision ChangesPath
1.20 +6 -3
jakarta-tomcat/src/facade22/org/apache/tomcat/facade/HttpServletRequestFacade.java
Index: HttpServletRequestFacade.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/facade22/org/apache/tomcat/facade/HttpServletRequestFacade.java,v
retrieving revision 1.19
retrieving revision 1.20
diff -u -r1.19 -r1.20
--- HttpServletRequestFacade.java 2001/02/27 02:49:27 1.19
+++ HttpServletRequestFacade.java 2001/03/06 16:07:44 1.20
@@ -451,9 +451,12 @@
}
public boolean isRequestedSessionIdValid() {
- // so here we just assume that if we have a session it's,
- // all good, else not.
- return null != request.getSession(false);
+boolean isvalid = false;
+ServerSession session = (ServerSession)request.getSession(false);
+if(session != null session.getId().equals(getRequestedSessionId()))
+isvalid = true;
+
+return isvalid;
}
/** Adapter - Request uses getSessionIdSource
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: [TC 3.3m1] New Bug in mod_jk auto config generation
This should be fixed in the nightly builds of tc3.3. As of last sunday, you should be able to explicitely control the setting of all these paths in the auto-generated files (and also where they get generated to) using attributes of the ApacheConfig ... / element in server.xml. If you get build the latest source, the attributes are documented in javadoc for org.apache.tomcat.modules.config.ApacheConfig. I'll try to get mods into the user docs this week. Mel --- Mike Braden [EMAIL PROTECTED] wrote: It looks like there have been some new changes to the Tomcat auto config generator. Now when you startup, TC3.3 says: 2001-03-06 10:18:48 - ApacheConfig: Generating apache mod_jserv config = /conf/jserv/tomcat-apache.conf 2001-03-06 10:18:48 - ApacheConfig: Generating apache mod_jk config = /conf/jk/mod_jk.conf-auto The jserv stuff is new. This is OK, except that now the config files are put in /conf on the server, not $TOMCAT_HOME/conf # ls /conf jk jserv Could someone please fix this? The above is from last nights build of TC3.3m1 at http://jakarta.apache.org/builds/jakarta-tomcat/nightly-3.3/ It also looks like the mod_jk.conf-auto has been changed. The paths are not correct: was LoadModule jk_module libexec/mod_jk.so JkWorkersFile /usr/local/tomcat/conf/jk/workers.properties JkLogFile /usr/local/tomcat/logs/mod_jk.log now is LoadModule jk_module /usr/local/tomcat/libexec/mod_jk.so JkWorkersFile "/conf/jk/workers.properties" JkLogFile "/logs/mod_jk.log" Thanks, Mike. -- Mike Braden CNE, MCP+I, MCSE, CCNA, Sun Comp 2k Enterprise E10k Utenzi 808 Aviation Parkway Suite 1100 PO Box 13479 Research Triangle Park, NC 27709 [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] __ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Tomcat 3.2.2 [was: RE: Spec Compliance: getRequestedSessionId(), ...]
Hi Marc, Does it look like a few days to come up with these patches? If so, I would like to include any missing from Tomcat 3.3 in Milestone 2. Thanks. -Original Message- From: Marc Saegesser [mailto:[EMAIL PROTECTED]] Sent: Tuesday, March 06, 2001 10:27 AM To: [EMAIL PROTECTED] Subject: Tomcat 3.2.2 [was: RE: Spec Compliance: getRequestedSessionId(), ...] After some further investigation into session ids and url rewritting I've found more places in the Tomcat 3.2 code that are using the requested session id as the active session id. I'm tracking down and fixes these now. These code changes are beyond what I'm willing to accept, as a release manager, during a beta release. The release plan called for a single beta cycle with the provision of additional betas if necessary. Once these bugs are resolved I will create a Tocmat 3.2.2 beta 2 release for evaluation. -Original Message- From: Marc Saegesser [mailto:[EMAIL PROTECTED]] Sent: Monday, March 05, 2001 6:45 PM To: [EMAIL PROTECTED] Subject: RE: Spec Compliance: getRequestedSessionId(), ... The Servlet 3.2 API spec (PFD) attempts to clarify this some, but I think muddles it even further with some truly odd wording. I'm going to fix this in 3.2.2 unless I hear something contrary from the serlvet-api folks. Its kind of late in the game for code changes to 3.2.2 but I really hate known spec failures. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Hans Bergsten Sent: Monday, March 05, 2001 6:32 PM To: [EMAIL PROTECTED] Subject: Re: Spec Compliance: getRequestedSessionId(), ... Marc Saegesser wrote: I'm reviewing Bugzilla bugs in preparation of the Tomcat 3.2.2 release. Bugzilla 160 has been open since Tomcat 3.1 and it looks like its real and that it violates the Servlet 2.2 spec. I want to make sure I am correctly interpretting the spec before I dig too deep. I'll send a similar message to the servlet api mailing list. 1) HttpServletRequest.getRequestedSessionId() should return the session that arrived with the request. This might not match the session id returned by HttpServletRequest.getSession()because the session might have been invalidated or timed out, etc. So far so good. What isn't clear (at least from reading the code) is should calling HttpServletRequest.getSession() modify the requested session id. I think that it shouldn't but the code in RequestImpl.java updates the requested session id. A quick look at the Tomcat 3.3 version appears to work as I expected it to. Your interpretation of the spec is the same as mine: Calling getSession() should not modify the *requested* session ID. In other words, you need to keep track of both the requested and the actual session ID to implement these methods. 2) A related question, HttpServletRequest.isRequestedSessionIdValid() is implemented as follows: HttpSession session = (HttpSession)request.getSession(false); return (session != null); If this method is called *before* the invoking servlet calls getSession(true) then it will correctly determine if the *requested* session id was valid. After that it will always return true. This seems wrong because specification clearly states this method determines if the requested session id was valid. Tomcat 3.3 appears to suffer from this problem. Again, my interpretation is the same as yours. You should test if the requested session is the same as the actual session instead. Hans -- Hans Bergsten [EMAIL PROTECTED] Gefion Software http://www.gefionsoftware.com Author of JavaServer Pages (O'Reilly), http://TheJSPBook.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: cvs commit: jakarta-tomcat/src/facade22/org/apache/tomcat/facade HttpServletRequestFacade.java
There may be more to this. This fix uncovered other places that were using
the requested session id and assuming that it was really the active session
id. I'll be committing a fix for that problem later today. I'm not as
familiar with the 3.3. code base but I'll try to port the patch.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, March 06, 2001 10:08 AM
To: [EMAIL PROTECTED]
Subject: cvs commit:
jakarta-tomcat/src/facade22/org/apache/tomcat/facade
HttpServletRequestFacade.java
larryi 01/03/06 08:07:45
Modified:src/facade22/org/apache/tomcat/facade
HttpServletRequestFacade.java
Log:
Port patch from tomcat_32 for part of Bugzilla Bug #160
The isRequestedSessionIdValid() should be based on the value of
getRequestedSessionId().Instead of just checking that getSession(false)
returns a non-null value (i.e. there is an active session) we must
also test that the active session's ID matches the requested session id.
Patch By: Marc Saegesser
Revision ChangesPath
1.20 +6 -3
jakarta-tomcat/src/facade22/org/apache/tomcat/facade/HttpServletRe
questFacade.java
Index: HttpServletRequestFacade.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/facade22/org/apache/tomcat/facade/Htt
pServletRequestFacade.java,v
retrieving revision 1.19
retrieving revision 1.20
diff -u -r1.19 -r1.20
--- HttpServletRequestFacade.java 2001/02/27 02:49:27 1.19
+++ HttpServletRequestFacade.java 2001/03/06 16:07:44 1.20
@@ -451,9 +451,12 @@
}
public boolean isRequestedSessionIdValid() {
- // so here we just assume that if we have a session it's,
- // all good, else not.
- return null != request.getSession(false);
+boolean isvalid = false;
+ServerSession session =
(ServerSession)request.getSession(false);
+if(session != null
session.getId().equals(getRequestedSessionId()))
+isvalid = true;
+
+return isvalid;
}
/** Adapter - Request uses getSessionIdSource
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
RE: HTTP Status Codes and Error Pages
Ethan, You missed some good discussions on this two weeks ago between Costin and myself! :-) Not only is it (premature commit) caused by the RequestDispatcher.include() calling flushBuffer() but there are other out.flush() calls in jasper that contribute to the problem. I don't know if it will or can be fixed in the 3.2.2 release (Mark?). The RequestDispatcher.include() bug is fixed in tc3.3. Costin - were you going to make the changes (out.flush() - out.flushBuffers()) in JspParseEventListener.generateFooter() and PageContextImpl.include() that we had discussed? I had thought that you implied you were going to do it (that was before I was a committer) but I just noticed that the out.flush() calls are still the same as before. Send me a note and I'll do this if you can't get to it. Mel --- Ethan Wallwork [EMAIL PROTECTED] wrote: Here is some more info on this problem. I'm seem to be having some problems with the respnse getting committed too early. It still seems wrong that an error page ever get returned with status code 200 though. 1) client makes request to Tomcat 2) Tomcat calls service() on my main servlet 3) servlet does an include() on some (possibly non-existant) JSP 4) JSP file does not exist (expected) 5) FileNotFoundException thrown from include() 6) main servlet catches exception 7) main servlet calls sendError() 8) sendError throws IllegalStateException (response already committed) 9) my error servlet gets called 10) error page get generated and sent to client with HTTP status 200 OK The RequestDispatcher.include() method calls flushBuffer(), which commits the response. This seems to mean that if you have a servlet which includes a JSP, any errors that occur can never be handled properly. Yikes! Code comments indicate that this flushBuffer() is not required by the spec, but is instead there to work around a problem with the session interceptor (BugRat bug #316). -- Ethan -Original Message- From: Ethan Wallwork [mailto:[EMAIL PROTECTED]] Sent: Wednesday, February 28, 2001 1:03 PM To: Tomcat-Dev Subject: HTTP Status Codes and Error Pages I can't tell if this is a bug or intended behavior: I have a servlet that acts as the error page for my webapp. Note that this is set up using the web.xml file, not the errorPage directive in the JSPs (if that makes any difference?) When there is an error (say 500 Internal Server Error), it returns a WML page saying things went wrong. This page is being properly generated, but the HTTP response code being sent along with it is "200 OK"! The request attribute java.servlet.error.status_code is set to 500, as I would expect. Calling response.setStatus(500) in the error servlet changes nothing. This is the response I get, headers included: HTTP/1.0 200 OK Content-Type: text/vnd.wap.wml;charset=UTF-8 Cache-Control: no-cache Servlet-Engine: Tomcat Web Server/3.2 (final) (JSP 1.1; Servlet 2.2; Java 1.3.0; SunOS 5.8 sparc; java.vendor=Sun Microsystems Inc.) ?xml version="1.0"? !DOCTYPE wml PUBLIC "-//WAPFORUM//DTD WML 1.1//EN" "http://www.wapforum.org/DTD/wml_1.1.xml" wml card title="Error 500" id="error" do label="Back" type="prev" prev/ /do p We're sorry, your request could be fulfilled. br/ 500 Internal Server Error /p /card /wml - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] __ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Tag Handler Pooling Clarification
Sorry for the long message, but I'm a bit unclear on some Tag related spec details. I need to make sure I have a clear understanding before I start thinking about tag handler reuse implementation. My original understanding of Tag.release was that it was always called after a tag handler was used -- after doEndTag. After calling release, the JSP container could then put the tag handler back into a pool for reuse. So, I was under the impression that a tag handler could be treated simply as a pooled resource. Based on my understanding, all of our code simply set tag handler attributes to their default values in the release method. By doing this we set the tag handler to a "default" or "initialized" state. Subsequently, setPageContext, various setters, etc. could be called and the whole tag use process would proceed again. But, after a more careful reading of the tag sections of the JSP 1.2 spec, it appears that tag reuse can only occur when tags have the same set of attributes that are initialized in the JSP. Specifically, in section 10.1.1 under the "Lifecycle" section, bullet [3] states: Note that since there are no guarantees on the state of the properties, a tag handler that had some optional properties set can only be reused if those properties are set to a new (known) value. This means that tag handlers can only be reused within the same "Att-Set" (set of attributes that have been set). This part of the spec could be interpreted to mean that tag handlers should only be reused if they have the same set of attributes. For example, given the following JSP fragment, two different tag1 handlers would have to be used (instead of reusing the handler): X:tag1 attr1="A" attr2="B"/ X:tag1 attr1="A"/ I hope that I'm misunderstanding something. I'd much prefer that the JSP container can rely on the handler's release method to reset the handler to a known state and simply start the tag process over again (setPageContext, setters, etc.) Such an assumption would greatly simplify a pooling strategy. Can anyone provide clarification? -Casey - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
FW: problem w/ ajp13 - if Tomcat is shutdown
Title: FW: problem w/ ajp13 - if Tomcat is shutdown I'm having problem with mod_jk if ajp13 is used. The problem is often reproduced when Tomcat is shut down without Apache being shut down. When a request is fired through Apache as soon as Tomcat starts, I often get Internal Server Error. The mod_jk.log will have the following: [jk_uri_worker_map.c (344)]: Into jk_uri_worker_map_t::map_uri_to_worker [jk_uri_worker_map.c (406)]: jk_uri_worker_map_t::map_uri_to_worker, Found a match ajp13 [jk_worker.c (123)]: Into wc_get_worker_for_name ajp13 [jk_worker.c (127)]: wc_get_worker_for_name, done found a worker [jk_ajp13_worker.c (651)]: Into jk_worker_t::get_endpoint [jk_ajp13_worker.c (536)]: Into jk_endpoint_t::service [jk_ajp13.c (346)]: Into ajp13_marshal_into_msgb [jk_ajp13.c (480)]: ajp13_marshal_into_msgb - Done [jk_ajp13_worker.c (203)]: connection_tcp_get_message: Error - jk_tcp_socket_recvfull failed [jk_ajp13_worker.c (619)]: Error reading request [jk_ajp13_worker.c (489)]: Into jk_endpoint_t::done If I hit reload multiple times, eventually Tomcat will serve the servlet fine. Did anyone see this problem before? Is there anyway around this? shinta
RE: cvs commit: jakarta-tomcat/src/facade22/org/apache/tomcat/facade HttpServletRequestFacade.java
I'm not as familiar with the 3.3. code base but I'll try to port the patch. Marc, Don't feel you need to port the patch. I'll be glad to do that. Thanks. Larry - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: [TC 3.3m1] New Bug in mod_jk auto config generation
OK. I noticed the change but didn't look at the latest source to see what was up. Let me know if I can help with the user docs. I've started to work on additions/new docs for 3.3 and the web server connection instructions. Thanks, Mike. -- Mike Braden -Original Message- From: Mel Martinez [mailto:[EMAIL PROTECTED]] Sent: Tuesday, March 06, 2001 11:31 AM To: [EMAIL PROTECTED] Subject: Re: [TC 3.3m1] New Bug in mod_jk auto config generation This should be fixed in the nightly builds of tc3.3. As of last sunday, you should be able to explicitely control the setting of all these paths in the auto-generated files (and also where they get generated to) using attributes of the ApacheConfig ... / element in server.xml. If you get build the latest source, the attributes are documented in javadoc for org.apache.tomcat.modules.config.ApacheConfig. I'll try to get mods into the user docs this week. Mel --- Mike Braden [EMAIL PROTECTED] wrote: It looks like there have been some new changes to the Tomcat auto config generator. Now when you startup, TC3.3 says: 2001-03-06 10:18:48 - ApacheConfig: Generating apache mod_jserv config = /conf/jserv/tomcat-apache.conf 2001-03-06 10:18:48 - ApacheConfig: Generating apache mod_jk config = /conf/jk/mod_jk.conf-auto The jserv stuff is new. This is OK, except that now the config files are put in /conf on the server, not $TOMCAT_HOME/conf # ls /conf jk jserv Could someone please fix this? The above is from last nights build of TC3.3m1 at http://jakarta.apache.org/builds/jakarta-tomcat/nightly-3.3/ It also looks like the mod_jk.conf-auto has been changed. The paths are not correct: was LoadModule jk_module libexec/mod_jk.so JkWorkersFile /usr/local/tomcat/conf/jk/workers.properties JkLogFile /usr/local/tomcat/logs/mod_jk.log now is LoadModule jk_module /usr/local/tomcat/libexec/mod_jk.so JkWorkersFile "/conf/jk/workers.properties" JkLogFile "/logs/mod_jk.log" Thanks, Mike. -- Mike Braden CNE, MCP+I, MCSE, CCNA, Sun Comp 2k Enterprise E10k Utenzi 808 Aviation Parkway Suite 1100 PO Box 13479 Research Triangle Park, NC 27709 [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] __ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/facade HttpServletResponseFacade.java
marcsaeg01/03/06 09:38:17
Modified:src/share/org/apache/tomcat/facade Tag: tomcat_32
HttpServletResponseFacade.java
Log:
This fixes some additional problems uncovered by the fix for
Bugzilla 160.
The isEncodable() method used isRequestedSessionIdValid() to determine
if there was an active session. This is incorrect, because the requested
session id may have expired or been invalidated and a new session created.
isEncodeable() now encodes sessions that are new (i.e. we don't know yet
if the client will be sending cookies or not) or if, if the session
is not new (meaning the requested session id was a valid session) and
the requested session id did not come from a cookie.
Revision ChangesPath
No revision
No revision
1.6.2.3 +19 -17
jakarta-tomcat/src/share/org/apache/tomcat/facade/Attic/HttpServletResponseFacade.java
Index: HttpServletResponseFacade.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/facade/Attic/HttpServletResponseFacade.java,v
retrieving revision 1.6.2.2
retrieving revision 1.6.2.3
diff -u -r1.6.2.2 -r1.6.2.3
--- HttpServletResponseFacade.java2000/11/20 23:59:43 1.6.2.2
+++ HttpServletResponseFacade.java2001/03/06 17:38:13 1.6.2.3
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/facade/Attic/HttpServletResponseFacade.java,v
1.6.2.2 2000/11/20 23:59:43 craigmcc Exp $
- * $Revision: 1.6.2.2 $
- * $Date: 2000/11/20 23:59:43 $
+ * $Header:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/facade/Attic/HttpServletResponseFacade.java,v
1.6.2.3 2001/03/06 17:38:13 marcsaeg Exp $
+ * $Revision: 1.6.2.3 $
+ * $Date: 2001/03/06 17:38:13 $
*
*
*
@@ -120,8 +120,7 @@
*/
public String encodeRedirectURL(String location) {
if (isEncodeable(toAbsolute(location)))
- return (toEncoded(location,
- response.getRequest().getRequestedSessionId()));
+ return (toEncoded(location, response.getRequest().getSession(false)));
else
return (location);
}
@@ -135,11 +134,10 @@
public String encodeURL(String url) {
if (isEncodeable(toAbsolute(url)))
- return (toEncoded(url,
- response.getRequest().getRequestedSessionId()));
+ return (toEncoded(url, response.getRequest().getSession(false)));
else
- return (url);
-}
+ return (url);
+ }
/**
* @deprecated
@@ -333,12 +331,14 @@
if (location.startsWith("#"))
return (false);
- // Are we in a valid session that is not using cookies?
- Request request = response.getRequest();
- if (!request.getFacade().isRequestedSessionIdValid() )
- return (false);
- if ( request.getFacade().isRequestedSessionIdFromCookie() )
- return (false);
+// Are we in a valid session that is not using cookies?
+Request request = response.getRequest();
+HttpSession session = request.getSession(false);
+if(session == null)
+return false;
+ // If the session is new, encode the URL
+ if(!session.isNew()
request.getFacade().isRequestedSessionIdFromCookie())
+return false;
// Is this a valid absolute URL?
URL url = null;
@@ -412,11 +412,12 @@
* @param url URL to be encoded with the session id
* @param sessionId Session id to be included in the encoded URL
*/
-private String toEncoded(String url, String sessionId) {
+private String toEncoded(String url, HttpSession session) {
- if ((url == null) || (sessionId == null))
+ if ((url == null) || (session == null))
return (url);
+ String sessionId = session.getId();
String path = null;
String query = null;
int question = url.indexOf("?");
@@ -431,6 +432,7 @@
sb.append(sessionId);
if (query != null)
sb.append(query);
+
return (sb.toString());
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: Patch for jk_sockbuf.c
Stefan,
Thanks for looking into this, but this bug has already been fixed in the 32
branch under cvs. If you check out the most recent version of tomcat_32, or
if you download 3.2.2b1, you can see that jk_sockbuf.c has been cleaned up
(Brian Vetter contributed the patch).
Thanks, though,
-Dan
p.s. For future patches, it would be very, very helpful if you could:
a) Use cvs diff -u, to get the diffs in the "unified" format, which patch
can read.
b) Attach your patches to your emails rather than pasting them in -- they
are much less likely to get mangled by email readers.
[EMAIL PROTECTED] wrote:
These changes fixes the following problem:
When using ajp12 with mod_jk, httpd procesess handling a request
will hang, using all cpu time, if tomcat is shut down before the headers
of the request have been sent from tomcat.
BR,
Stefan berg
***
/usr/local/src/apache/jakarta-tomcat-3.2.1-src/src/native/jk/jk_sockbuf.c
Tue Mar 6 10:10:40 2001
--- jk_sockbuf.cTue Mar 6 10:15:54 2001
***
*** 131,137
if(sb-end == sb-start) {
sb-end = sb-start = 0;
! if(!fill_buffer(sb)) {
return JK_FALSE;
}
}
--- 131,137
if(sb-end == sb-start) {
sb-end = sb-start = 0;
! if(fill_buffer(sb) 0) {
return JK_FALSE;
}
}
***
*** 169,175
return JK_TRUE;
}
}
! if(!fill_buffer(sb)) {
return JK_FALSE;
}
}
--- 169,175
return JK_TRUE;
}
}
! if(fill_buffer(sb) = 0 ) {
return JK_FALSE;
}
}
***
*** 205,215
SOCKBUF_SIZE - sb-end, 0);
if(ret 0) {
! return JK_FALSE;
}
sb-end += ret;
! return JK_TRUE;
}
-
--- 205,214
SOCKBUF_SIZE - sb-end, 0);
if(ret 0) {
! return ret;
}
sb-end += ret;
! return ret;
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
--
Dan Milstein // [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: FW: problem w/ ajp13 - if Tomcat is shutdown
What version of TC are you using? What version of Apache? I would look into the mod_jk docs -- I think this is the spec'd behavior (which, admittedly, is not great, but that makes it more of a feature request than a bug ;-). With ajp13, Apache opens up a persistent TCP/IP connection TC -- if TC restarts, I think that connection may just hang up and then timeout (since Apache doesn't know that TC has restarted). If anyone wants to work on this, you would have the undying thanks of the rest of the TC community -- having to restart Apache all the time bugs a *lot* of people. -Dan Shinta Tjio wrote: I'm having problem with mod_jk if ajp13 is used. The problem is often reproduced when Tomcat is shut down without Apache being shut down. When a request is fired through Apache as soon as Tomcat starts, I often get Internal Server Error. The mod_jk.log will have the following: [jk_uri_worker_map.c (344)]: Into jk_uri_worker_map_t::map_uri_to_worker [jk_uri_worker_map.c (406)]: jk_uri_worker_map_t::map_uri_to_worker, Found a match ajp13 [jk_worker.c (123)]: Into wc_get_worker_for_name ajp13 [jk_worker.c (127)]: wc_get_worker_for_name, done found a worker [jk_ajp13_worker.c (651)]: Into jk_worker_t::get_endpoint [jk_ajp13_worker.c (536)]: Into jk_endpoint_t::service [jk_ajp13.c (346)]: Into ajp13_marshal_into_msgb [jk_ajp13.c (480)]: ajp13_marshal_into_msgb - Done [jk_ajp13_worker.c (203)]: connection_tcp_get_message: Error - jk_tcp_socket_recvfull failed [jk_ajp13_worker.c (619)]: Error reading request [jk_ajp13_worker.c (489)]: Into jk_endpoint_t::done If I hit reload multiple times, eventually Tomcat will serve the servlet fine. Did anyone see this problem before? Is there anyway around this? shinta -- Dan Milstein // [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Tomcat 3.2.2 [was: RE: Spec Compliance: getRequestedSessionId(), ...]
Larry, I commited the changes to HttpServletResponseFacade that fix the problems with determine when URLs should be rewritten and what session id to use. I also beefed up the SessionExample servlet from the examples webapp to display additional information and allow sessions to be invalidated. This helped determine that the fixes did the right thing. -Original Message- From: Larry Isaacs [mailto:[EMAIL PROTECTED]] Sent: Tuesday, March 06, 2001 10:33 AM To: '[EMAIL PROTECTED]' Subject: RE: Tomcat 3.2.2 [was: RE: Spec Compliance: getRequestedSessionId(), ...] Hi Marc, Does it look like a few days to come up with these patches? If so, I would like to include any missing from Tomcat 3.3 in Milestone 2. Thanks. -Original Message- From: Marc Saegesser [mailto:[EMAIL PROTECTED]] Sent: Tuesday, March 06, 2001 10:27 AM To: [EMAIL PROTECTED] Subject: Tomcat 3.2.2 [was: RE: Spec Compliance: getRequestedSessionId(), ...] After some further investigation into session ids and url rewritting I've found more places in the Tomcat 3.2 code that are using the requested session id as the active session id. I'm tracking down and fixes these now. These code changes are beyond what I'm willing to accept, as a release manager, during a beta release. The release plan called for a single beta cycle with the provision of additional betas if necessary. Once these bugs are resolved I will create a Tocmat 3.2.2 beta 2 release for evaluation. -Original Message- From: Marc Saegesser [mailto:[EMAIL PROTECTED]] Sent: Monday, March 05, 2001 6:45 PM To: [EMAIL PROTECTED] Subject: RE: Spec Compliance: getRequestedSessionId(), ... The Servlet 3.2 API spec (PFD) attempts to clarify this some, but I think muddles it even further with some truly odd wording. I'm going to fix this in 3.2.2 unless I hear something contrary from the serlvet-api folks. Its kind of late in the game for code changes to 3.2.2 but I really hate known spec failures. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Hans Bergsten Sent: Monday, March 05, 2001 6:32 PM To: [EMAIL PROTECTED] Subject: Re: Spec Compliance: getRequestedSessionId(), ... Marc Saegesser wrote: I'm reviewing Bugzilla bugs in preparation of the Tomcat 3.2.2 release. Bugzilla 160 has been open since Tomcat 3.1 and it looks like its real and that it violates the Servlet 2.2 spec. I want to make sure I am correctly interpretting the spec before I dig too deep. I'll send a similar message to the servlet api mailing list. 1) HttpServletRequest.getRequestedSessionId() should return the session that arrived with the request. This might not match the session id returned by HttpServletRequest.getSession()because the session might have been invalidated or timed out, etc. So far so good. What isn't clear (at least from reading the code) is should calling HttpServletRequest.getSession() modify the requested session id. I think that it shouldn't but the code in RequestImpl.java updates the requested session id. A quick look at the Tomcat 3.3 version appears to work as I expected it to. Your interpretation of the spec is the same as mine: Calling getSession() should not modify the *requested* session ID. In other words, you need to keep track of both the requested and the actual session ID to implement these methods. 2) A related question, HttpServletRequest.isRequestedSessionIdValid() is implemented as follows: HttpSession session = (HttpSession)request.getSession(false); return (session != null); If this method is called *before* the invoking servlet calls getSession(true) then it will correctly determine if the *requested* session id was valid. After that it will always return true. This seems wrong because specification clearly states this method determines if the requested session id was valid. Tomcat 3.3 appears to suffer from this problem. Again, my interpretation is the same as yours. You should test if the requested session is the same as the actual session instead. Hans -- Hans Bergsten [EMAIL PROTECTED] Gefion Software http://www.gefionsoftware.com Author of JavaServer Pages (O'Reilly), http://TheJSPBook.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Patches in Bugzilla
I'm having a problem using Bugzilla, and I'm hoping someone can point me towards an easy solution. When people post bug reports, they often include patches in the text of the description (which is great). However, it's very difficult for me to get those patches into a file so that I can run the patch program to use them. Cut and paste does all kinds of weird line truncation things (which makes patch lose it's mind), and if you try to view source, there are all kinds of HTML escape codes. It's sort of like the Bugzilla system expects people to "attach" their proposed patches (which I could then download). But no one ever does (understandably). Am I missing a way to get the description saved as text without any HTML escapes? Or can we add something to the bug submission form to encourage people to attach their patches rather than paste them in? -Dan -- Dan Milstein // [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: HTTP Status Codes and Error Pages
I'll definitely have to look back in the archives. I've been looking at 3.3 recently and discovered that the issue seemed to be fixed there, which makes me happy :) Is there a list of known problems in the latest tc3.3 milestone? I may be able to use this in our production systems, since our requirements are limited. Tomcat 3.3 seems to do character encoding and jsp including better, which are our two most used features. I would love to know that things people know don't work quite right in 3.3 yet. Thanks for the reply! -- Ethan -Original Message- From: Mel Martinez [mailto:[EMAIL PROTECTED]] Sent: Tuesday, March 06, 2001 9:51 AM To: [EMAIL PROTECTED] Subject: RE: HTTP Status Codes and Error Pages Ethan, You missed some good discussions on this two weeks ago between Costin and myself! :-) Not only is it (premature commit) caused by the RequestDispatcher.include() calling flushBuffer() but there are other out.flush() calls in jasper that contribute to the problem. I don't know if it will or can be fixed in the 3.2.2 release (Mark?). The RequestDispatcher.include() bug is fixed in tc3.3. Costin - were you going to make the changes (out.flush() - out.flushBuffers()) in JspParseEventListener.generateFooter() and PageContextImpl.include() that we had discussed? I had thought that you implied you were going to do it (that was before I was a committer) but I just noticed that the out.flush() calls are still the same as before. Send me a note and I'll do this if you can't get to it. Mel --- Ethan Wallwork [EMAIL PROTECTED] wrote: Here is some more info on this problem. I'm seem to be having some problems with the respnse getting committed too early. It still seems wrong that an error page ever get returned with status code 200 though. 1) client makes request to Tomcat 2) Tomcat calls service() on my main servlet 3) servlet does an include() on some (possibly non-existant) JSP 4) JSP file does not exist (expected) 5) FileNotFoundException thrown from include() 6) main servlet catches exception 7) main servlet calls sendError() 8) sendError throws IllegalStateException (response already committed) 9) my error servlet gets called 10) error page get generated and sent to client with HTTP status 200 OK The RequestDispatcher.include() method calls flushBuffer(), which commits the response. This seems to mean that if you have a servlet which includes a JSP, any errors that occur can never be handled properly. Yikes! Code comments indicate that this flushBuffer() is not required by the spec, but is instead there to work around a problem with the session interceptor (BugRat bug #316). -- Ethan -Original Message- From: Ethan Wallwork [mailto:[EMAIL PROTECTED]] Sent: Wednesday, February 28, 2001 1:03 PM To: Tomcat-Dev Subject: HTTP Status Codes and Error Pages I can't tell if this is a bug or intended behavior: I have a servlet that acts as the error page for my webapp. Note that this is set up using the web.xml file, not the errorPage directive in the JSPs (if that makes any difference?) When there is an error (say 500 Internal Server Error), it returns a WML page saying things went wrong. This page is being properly generated, but the HTTP response code being sent along with it is "200 OK"! The request attribute java.servlet.error.status_code is set to 500, as I would expect. Calling response.setStatus(500) in the error servlet changes nothing. This is the response I get, headers included: HTTP/1.0 200 OK Content-Type: text/vnd.wap.wml;charset=UTF-8 Cache-Control: no-cache Servlet-Engine: Tomcat Web Server/3.2 (final) (JSP 1.1; Servlet 2.2; Java 1.3.0; SunOS 5.8 sparc; java.vendor=Sun Microsystems Inc.) ?xml version="1.0"? !DOCTYPE wml PUBLIC "-//WAPFORUM//DTD WML 1.1//EN" "http://www.wapforum.org/DTD/wml_1.1.xml" wml card title="Error 500" id="error" do label="Back" type="prev" prev/ /do p We're sorry, your request could be fulfilled. br/ 500 Internal Server Error /p /card /wml - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] __ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Assigning Servlets to different ports.
Hi Mel, If you are interested in an approach to getting Tomcat to serve apps on multiple ports, you might want to check out the Enhydra Enterprise 4.0 source. We create multiple ContextManagers, where each ContextManager handles the group of apps running on a particular connection (port). This is currently using Tomcat 3.2.1. Shawn Mel Martinez wrote: --- Uijin Hong [EMAIL PROTECTED] wrote: Why don't you just run 2 servlet container(Tomcat)s for each port? That could get memory expensive if you have to do this for several ports. The best performance scenario might be to use Apache to listen to several ports and rewrite them to go to a single tomcat 'delegator' servlet which then dispatches them to servlets/JSPs appropriately. And actually, you should just use apache rewrites directly to dispatch to any static resources. Mel -Original Message- From: William Wishon [mailto:[EMAIL PROTECTED]] Sent: Tuesday, March 06, 2001 9:27 AM To: [EMAIL PROTECTED] Subject: Assigning Servlets to different ports. Hi, snipped An example of what I'm trying to do is to have a GET on "/" of port 8080 return webapps/app1/index.html and a GET of "/" on port 8081 return webapps/app2/index.html. Thanks, Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] __ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] -- Shawn McMurdo mailto:[EMAIL PROTECTED] Lutris Technologieshttp://www.lutris.com Enhydra.Orghttp://www.enhydra.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Tag Handler Pooling Clarification
My reading of the spec is that after calling Tag.release, the tag handler could be safely put back into the pool. However calling Tag.release after doEndTag isn't mandatory. If the compiler is smart enough, it may re-use a tag without releasing it first if the second invocation uses a super-set of the first ones attributes. Granted, section 10.3 of the spec forgets to address this point , but my reading is that it should say: // loop } // put d back to pool } - Original Message - From: "Casey Lucas" [EMAIL PROTECTED] To: "tomcat dev" [EMAIL PROTECTED] Sent: Tuesday, March 06, 2001 9:00 AM Subject: Tag Handler Pooling Clarification Sorry for the long message, but I'm a bit unclear on some Tag related spec details. I need to make sure I have a clear understanding before I start thinking about tag handler reuse implementation. My original understanding of Tag.release was that it was always called after a tag handler was used -- after doEndTag. After calling release, the JSP container could then put the tag handler back into a pool for reuse. So, I was under the impression that a tag handler could be treated simply as a pooled resource. Based on my understanding, all of our code simply set tag handler attributes to their default values in the release method. By doing this we set the tag handler to a "default" or "initialized" state. Subsequently, setPageContext, various setters, etc. could be called and the whole tag use process would proceed again. But, after a more careful reading of the tag sections of the JSP 1.2 spec, it appears that tag reuse can only occur when tags have the same set of attributes that are initialized in the JSP. Specifically, in section 10.1.1 under the "Lifecycle" section, bullet [3] states: Note that since there are no guarantees on the state of the properties, a tag handler that had some optional properties set can only be reused if those properties are set to a new (known) value. This means that tag handlers can only be reused within the same "Att-Set" (set of attributes that have been set). This part of the spec could be interpreted to mean that tag handlers should only be reused if they have the same set of attributes. For example, given the following JSP fragment, two different tag1 handlers would have to be used (instead of reusing the handler): X:tag1 attr1="A" attr2="B"/ X:tag1 attr1="A"/ I hope that I'm misunderstanding something. I'd much prefer that the JSP container can rely on the handler's release method to reset the handler to a known state and simply start the tag process over again (setPageContext, setters, etc.) Such an assumption would greatly simplify a pooling strategy. Can anyone provide clarification? -Casey - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Assigning Servlets to different ports.
Shawn, Could you point me more specifically at where Enhydra uses multiple ContextManagers? I just downloaded EE 4.0a4 and couldn't find any files that have examples of multiple ContextManagers on different ports serving groups of apps. Whenever I try to use multiple ContextManagers on different ports I get lots of messages about removing duplicate servlets (like the jsp servlet, status servlet, exception servlet), and tomcat is unresponsive to any of my requests and refuses to shutdown, until I 'kill' it. Any help on figuring this out would be great. From my code archeology I was just about to conclude that it wasn't possible in tomcat 3.2.1 until your comment made me think that I had missed something. -Bill -Original Message- From: Shawn McMurdo [mailto:[EMAIL PROTECTED]] Sent: Tuesday, March 06, 2001 10:25 AM To: [EMAIL PROTECTED] Subject: Re: Assigning Servlets to different ports. Hi Mel, If you are interested in an approach to getting Tomcat to serve apps on multiple ports, you might want to check out the Enhydra Enterprise 4.0 source. We create multiple ContextManagers, where each ContextManager handles the group of apps running on a particular connection (port). This is currently using Tomcat 3.2.1. Shawn Mel Martinez wrote: --- Uijin Hong [EMAIL PROTECTED] wrote: Why don't you just run 2 servlet container(Tomcat)s for each port? That could get memory expensive if you have to do this for several ports. The best performance scenario might be to use Apache to listen to several ports and rewrite them to go to a single tomcat 'delegator' servlet which then dispatches them to servlets/JSPs appropriately. And actually, you should just use apache rewrites directly to dispatch to any static resources. Mel -Original Message- From: William Wishon [mailto:[EMAIL PROTECTED]] Sent: Tuesday, March 06, 2001 9:27 AM To: [EMAIL PROTECTED] Subject: Assigning Servlets to different ports. Hi, snipped An example of what I'm trying to do is to have a GET on "/" of port 8080 return webapps/app1/index.html and a GET of "/" on port 8081 return webapps/app2/index.html. Thanks, Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] __ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] -- Shawn McMurdo mailto:[EMAIL PROTECTED] Lutris Technologieshttp://www.lutris.com Enhydra.Orghttp://www.enhydra.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: HTTP Status Codes and Error Pages
Costin - were you going to make the changes (out.flush() - out.flushBuffers()) in JspParseEventListener.generateFooter() and PageContextImpl.include() that we had discussed? I had thought that you implied you were going to do it (that was before I was a committer) but I just noticed that the out.flush() calls are still the same as before. Well, 2 things happened - first I had to do the changes in jasper ( i.e. jasper-runtime ), and make it available in lib/common ( so I can cast JspWriter to JspWriterImpl - jasper.jar is not visible to serlvets/jsps ) Second, we are waiting ( Larry ? ) for a clarification, to decide which is the best solution. The fix is trivial now - I tried on my machine and seemed to work fine ( i.e. pass the test suite ). Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat/src/native/mod_jk/common jk_service.h
danmil 01/03/06 12:22:00
Modified:src/native/mod_jk/common jk_service.h
Log:
Extensive comments added to explain the structure of the core mod_jk
classes. Also explained how Shachor wrote object oriented code in C.
Revision ChangesPath
1.4 +196 -9jakarta-tomcat/src/native/mod_jk/common/jk_service.h
Index: jk_service.h
===
RCS file: /home/cvs/jakarta-tomcat/src/native/mod_jk/common/jk_service.h,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- jk_service.h 2001/02/02 17:29:04 1.3
+++ jk_service.h 2001/03/06 20:21:58 1.4
@@ -58,7 +58,8 @@
* These are the web server (ws) the worker and the connection*
* JVM connection point *
* Author: Gal Shachor [EMAIL PROTECTED] *
- * Version: $Revision: 1.3 $ *
+ * Dan Milstein [EMAIL PROTECTED]
+ * Version: $Revision: 1.4 $ *
***/
#ifndef JK_SERVICE_H
@@ -72,7 +73,7 @@
#ifdef __cplusplus
extern "C" {
#endif /* __cplusplus */
-
+
struct jk_ws_service;
struct jk_endpoint;
struct jk_worker;
@@ -80,11 +81,49 @@
typedef struct jk_endpoint jk_endpoint_t;
typedef struct jk_worker jk_worker_t;
+/*
+ * The web server service 'class'. An instance of this class is created
+ * for each request which is forwarded from the web server to the servlet
+ * container. Contains the basic information about the request
+ * (e.g. protocol, req_uri, etc), and also contains a series of methods
+ * which provide access to core web server functionality (start_response,
+ * read, write). This class might be more accurately called ws_request.
+ *
+ * As with all the core jk classes, this is essentially an abstract base
+ * class which is implemented/extended by classes which are specific to a
+ * particular web server. By using an abstract base class in this manner,
+ * workers can be written for different protocols (e.g. ajp12, ajp13)
+ * without the workers having to worry about which web server they are
+ * talking to.
+ *
+ * This particular OO-in-C system uses a 'ws_private' pointer to point to
+ * the platform-specific data. So in the subclasses, the methods do most
+ * of their work by getting their hands on the ws_private pointer and then
+ * using that to get at the correctly formatted data and functions for
+ * their platform.
+ *
+ * Try imagining this as a 'public abstract class', and the ws_private
+ * pointer as a sort of extra 'this' reference. Or imagine that you are
+ * seeing the internal vtables of your favorite OO language. Whatever
+ * works for you.
+ *
+ * See apache1.3/mod_jk.c and iis/jk_isapi_plugin.c for examples.
+ */
struct jk_ws_service {
+
+/*
+ * A 'this' pointer which is used by the subclasses of this class to
+ * point to data which is specific to a given web server platform
+ * (e.g. Apache or IIS).
+ */
void *ws_private;
/*
- * Alive as long as the request is alive.
+ * Provides memory management. All data specific to this request is
+ * allocated within this pool, which can then be reclaimed at the end
+ * of the request handling cycle.
+ *
+ * Alive as long as the request is alive.
*/
jk_pool_t *pool;
@@ -155,8 +194,14 @@
char*jvm_route;
/*
- * Callbacks into the web server.
+ * Callbacks into the web server. For each, the first argument is
+ * essentially a 'this' pointer. All return JK_TRUE on success
+ * and JK_FALSE on failure.
*/
+
+/*
+ * Send the response headers to the browser.
+ */
int (JK_METHOD *start_response)(jk_ws_service_t *s,
int status,
const char *reason,
@@ -164,48 +209,190 @@
const char * const *header_values,
unsigned num_of_headers);
+/*
+ * Read a chunk of the request body into a buffer. Attempt to read len
+ * bytes into the buffer. Write the number of bytes actually read into
+ * actually_read.
+ */
int (JK_METHOD *read)(jk_ws_service_t *s,
- void *b,
- unsigned l,
- unsigned *a);
+ void *buffer,
+ unsigned len,
+ unsigned *actually_read);
+/*
+ * Write a chunk of response data back
cvs commit: jakarta-tomcat/src/native/mod_jk/common jk_ajp13_worker.c
danmil 01/03/06 12:22:23
Modified:src/native/mod_jk/common jk_ajp13_worker.c
Log:
Fixed a few typos in some of the logging messages
Revision ChangesPath
1.5 +6 -6 jakarta-tomcat/src/native/mod_jk/common/jk_ajp13_worker.c
Index: jk_ajp13_worker.c
===
RCS file: /home/cvs/jakarta-tomcat/src/native/mod_jk/common/jk_ajp13_worker.c,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- jk_ajp13_worker.c 2001/02/02 17:29:03 1.4
+++ jk_ajp13_worker.c 2001/03/06 20:22:22 1.5
@@ -54,10 +54,10 @@
*/
/***
- * Description: Experimental bi-directionl protocol. *
+ * Description: Bi-directional protocol. *
* Author: Costin [EMAIL PROTECTED] *
* Author: Gal Shachor [EMAIL PROTECTED] *
- * Version: $Revision: 1.4 $ *
+ * Version: $Revision: 1.5 $ *
***/
#include "jk_pool.h"
@@ -710,16 +710,16 @@
jk_log(l,
JK_LOG_DEBUG,
- "Into ajp23_worker_factory\n");
+ "Into ajp13_worker_factory\n");
if(NULL == name || NULL == w) {
jk_log(l,
JK_LOG_ERROR,
- "In ajp23_worker_factory, NULL parameters\n");
+ "In ajp13_worker_factory, NULL parameters\n");
return JK_FALSE;
}
if(!private_data) {
-jk_log(l, JK_LOG_ERROR, "In ajp23_worker_factory, NULL parameters\n");
+jk_log(l, JK_LOG_ERROR, "In ajp13_worker_factory, NULL parameters\n");
return JK_FALSE;
}
@@ -727,7 +727,7 @@
if(!private_data-name) {
free(private_data);
- jk_log(l, JK_LOG_ERROR, "In ajp23_worker_factory, malloc failed\n");
+ jk_log(l, JK_LOG_ERROR, "In ajp13_worker_factory, malloc failed\n");
return JK_FALSE;
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
RE: Assigning Servlets to different ports.
Hi William, Regarding "multiple ContextManagers" - IMHO it should be possible to do that, but it's not a very tested feature. If what you want to do is support virtual hosts - tomcat supports virtual hosts using a single ContextManager ( the contextManager is a representation for a "server" that may have multiple hosts). There is no special representation for Host ( as a top-level object ) - each Context belongs to a virtual host, and the mapper is routing the requests. You can add additional modules to filter or do other tricks. ( just use Context.getHost() or getHostAliases() ). If you want to isolate applications/hosts - using separate VMs may give you more benefits. There are cases when multiple ContextManagers may help - for example if the servers have very different configuration ( i.e. top-level modules for mapping, etc). In 3.3 ( with the experimental ProfileLoader ) you can push all the modules as per/context interceptors, i.e. separate sets of modules for each web application - what's shared is the config modules and the top-level mapper. That means even fewer reasons to have multiple ContextManagers. IMHO if what you want to do requires changes/fixes in tomcat, you should try tomcat 3.3, where it is still possible to do this kind of change ( assuming it's not too big ). For 3.2.2 I don't think this can be clasified as a critical bug, and I don't think Marc would enjoy it :-) Costin Could you point me more specifically at where Enhydra uses multiple ContextManagers? I just downloaded EE 4.0a4 and couldn't find any files that have examples of multiple ContextManagers on different ports serving groups of apps. Whenever I try to use multiple ContextManagers on different ports I get lots of messages about removing duplicate servlets (like the jsp servlet, status servlet, exception servlet), and tomcat is unresponsive to any of my requests and refuses to shutdown, until I 'kill' it. Any help on figuring this out would be great. From my code archeology I was just about to conclude that it wasn't possible in tomcat 3.2.1 until your comment made me think that I had missed something. -Bill -Original Message- From: Shawn McMurdo [mailto:[EMAIL PROTECTED]] Sent: Tuesday, March 06, 2001 10:25 AM To: [EMAIL PROTECTED] Subject: Re: Assigning Servlets to different ports. Hi Mel, If you are interested in an approach to getting Tomcat to serve apps on multiple ports, you might want to check out the Enhydra Enterprise 4.0 source. We create multiple ContextManagers, where each ContextManager handles the group of apps running on a particular connection (port). This is currently using Tomcat 3.2.1. Shawn Mel Martinez wrote: --- Uijin Hong [EMAIL PROTECTED] wrote: Why don't you just run 2 servlet container(Tomcat)s for each port? That could get memory expensive if you have to do this for several ports. The best performance scenario might be to use Apache to listen to several ports and rewrite them to go to a single tomcat 'delegator' servlet which then dispatches them to servlets/JSPs appropriately. And actually, you should just use apache rewrites directly to dispatch to any static resources. Mel -Original Message- From: William Wishon [mailto:[EMAIL PROTECTED]] Sent: Tuesday, March 06, 2001 9:27 AM To: [EMAIL PROTECTED] Subject: Assigning Servlets to different ports. Hi, snipped An example of what I'm trying to do is to have a GET on "/" of port 8080 return webapps/app1/index.html and a GET of "/" on port 8081 return webapps/app2/index.html. Thanks, Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] __ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] -- Shawn McMurdo mailto:[EMAIL PROTECTED] Lutris Technologieshttp://www.lutris.com Enhydra.Orghttp://www.enhydra.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: [TC 3.3m1] New Bug in mod_jk auto config generation
Also, after some thought, why doesn't it default to the old locations? This will create some confusion, and it's not like mod_jk needs any more. Another problem is that the default is to root /. This could really be a problem. I'd rather it die with an error than put stuff in a really unexpected spot. What happens when the user is running on a shared server and doesn't have perms for / ? Does it crash? Not write anything, warn you? Just some thoughts. Mike. -- Mike Braden -Original Message- From: Mel Martinez [mailto:[EMAIL PROTECTED]] Sent: Tuesday, March 06, 2001 11:31 AM To: [EMAIL PROTECTED] Subject: Re: [TC 3.3m1] New Bug in mod_jk auto config generation This should be fixed in the nightly builds of tc3.3. As of last sunday, you should be able to explicitely control the setting of all these paths in the auto-generated files (and also where they get generated to) using attributes of the ApacheConfig ... / element in server.xml. If you get build the latest source, the attributes are documented in javadoc for org.apache.tomcat.modules.config.ApacheConfig. I'll try to get mods into the user docs this week. Mel --- Mike Braden [EMAIL PROTECTED] wrote: It looks like there have been some new changes to the Tomcat auto config generator. Now when you startup, TC3.3 says: 2001-03-06 10:18:48 - ApacheConfig: Generating apache mod_jserv config = /conf/jserv/tomcat-apache.conf 2001-03-06 10:18:48 - ApacheConfig: Generating apache mod_jk config = /conf/jk/mod_jk.conf-auto The jserv stuff is new. This is OK, except that now the config files are put in /conf on the server, not $TOMCAT_HOME/conf # ls /conf jk jserv Could someone please fix this? The above is from last nights build of TC3.3m1 at http://jakarta.apache.org/builds/jakarta-tomcat/nightly-3.3/ It also looks like the mod_jk.conf-auto has been changed. The paths are not correct: was LoadModule jk_module libexec/mod_jk.so JkWorkersFile /usr/local/tomcat/conf/jk/workers.properties JkLogFile /usr/local/tomcat/logs/mod_jk.log now is LoadModule jk_module /usr/local/tomcat/libexec/mod_jk.so JkWorkersFile "/conf/jk/workers.properties" JkLogFile "/logs/mod_jk.log" Thanks, Mike. -- Mike Braden CNE, MCP+I, MCSE, CCNA, Sun Comp 2k Enterprise E10k Utenzi 808 Aviation Parkway Suite 1100 PO Box 13479 Research Triangle Park, NC 27709 [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] __ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Assigning Servlets to different ports.
At 12:35 PM -0800 2001/03/06, [EMAIL PROTECTED] wrote: If what you want to do is support virtual hosts - tomcat supports virtual hosts using a single ContextManager ( the contextManager is a representation for a "server" that may have multiple hosts). There is no special representation for Host ( as a top-level object ) - each Context belongs to a virtual host, and the mapper is routing the requests. You can add additional modules to filter or do other tricks. ( just use Context.getHost() or getHostAliases() ). Costin, I see I can bind specific servlets to a host by name, but how can I bind to a specific port? I want my webapp only available via SSL, and a single homepage on port 80, redirecting users to port 443 to really use the site. There are cases when multiple ContextManagers may help - for example if the servers have very different configuration ( i.e. top-level modules for mapping, etc). In 3.3 ( with the experimental ProfileLoader ) you can push all the modules as per/context interceptors, i.e. separate sets of modules for each web application - what's shared is the config modules and the top-level mapper. That means even fewer reasons to have multiple ContextManagers. I'm using 3.2.1 -- does 3.3 add the capability to bind servlets/webapps to individual ports? IMHO if what you want to do requires changes/fixes in tomcat, you should try tomcat 3.3, where it is still possible to do this kind of change ( assuming it's not too big ). For 3.2.2 I don't think this can be clasified as a critical bug, and I don't think Marc would enjoy it :-) Thanks, Chris Pepper -- Chris Pepper: http://www.reppep.com/~pepper/ Rockefeller U Computing Services: http://www.rockefeller.edu/ Mac OS X Software: http://www.mosxsw.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Tag Handler Pooling Clarification
Casey Lucas wrote: Sorry for the long message, but I'm a bit unclear on some Tag related spec details. I need to make sure I have a clear understanding before I start thinking about tag handler reuse implementation. [...] The JSP 1.1 spec is very confusing in this regard. I suggest you look at the JSP 1.2 PDF spec before you get going with this. It contains much improved descriptions, even though it may still not be as clear as it should. Basically, you're assumptions are right though: you can only reuse a tag handler for action elements with the same attribute set. Calling release() and reinitialize the tag handler for each use is not always an efficient solution, because the tag handler may do expensive initialization in the setter methods. The release() method is intended to be used by the tag handler to release all its state when it will no longer be used, i.e. not as a "pool reset" method. I agree that this whole area is pretty messy and unclear. We had a looong discussion about how to resolve it in the best way within the JSR-053 group last year. The result of those discussions is reflected in the JSP 1.2 PDF spec. Hans -- Hans Bergsten [EMAIL PROTECTED] Gefion Software http://www.gefionsoftware.com Author of JavaServer Pages (O'Reilly), http://TheJSPBook.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Assigning Servlets to different ports.
Costin, If what you want to do is support virtual hosts - tomcat supports virtual hosts using a single ContextManager ( the contextManager is a representation for a "server" that may have multiple hosts). I don't mind using virtual hosts, but they don't do what I'm looking for. I have two servlets, one provides a public service and the other is the configuration and administration of that public service. I want to have the root "/" of port 8080 go to the publicly available servlet. Then using firewalling rules allow access to port 8081 only from the local network. "/" on port 8081 would go to the administration servlet. The problem with virtual hosting as implemented in Tomcat 3.2.1 is that both virtual hosts and their contexts are available on both ports. That exposes the administration functionallity to the public and I don't want that. There is no special representation for Host ( as a top-level object ) - each Context belongs to a virtual host, and the mapper is routing the requests. You can add additional modules to filter or do other tricks. ( just use Context.getHost() or getHostAliases() ). If you want to isolate applications/hosts - using separate VMs may give you more benefits. I can't use multiple VM's because the administration servlet 'talks' to the other servlet by changing it's in memory configuration. Ideally what I am looking for is something like: Context path="/" docBase="/webapps/PublicService" port="8080" Context path="/" docBase="/webapps/AdminService" port="8081" I'm begining to think I could modify (or subclass) Context.java to have a port property, then create a new mapper like SimpleMapper1 that looks at the request and looks at the contexts port property and enforces the separation. Does that sound about right? IMHO if what you want to do requires changes/fixes in tomcat, you should try tomcat 3.3, where it is still possible to do this kind of change ( assuming it's not too big ). For 3.2.2 I don't think this can be clasified as a critical bug, and I don't think Marc would enjoy it :-) I'm not trying make any more work for anyone else, I'm just trying to get some advice on how the code works and where to begin my changes. Because stability is important to me I am more willing to make a (hopefully small) patch against 3.2.1 than to 'upgrade' to the more unstable 3.3 code. I would, however, be willing to back port some changes if 3.3 had this functionallity, but from what I could gather 3.3 is also missing this ability. -Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
controlling the lifecycle of servlets ??
Title: controlling the lifecycle of servlets ?? Running a website with more than 1.000 pages - each becoming a servlet by using a JSP-Template - we are facing the following problem: The reserved JVM-memory (mx512m + ms512m on a 1280 MB W2k-Server) is running short very soon after about 30 - 45 min.). The only way we see by now to free memory is to restart the JSP-Engine. The only solution we can imagine is to get rid of 'obsolete' or 'older' servlets, but we have no idea of how to do this. Scanning several JSP-Discussionlists we came to the conclusion that this is the task of the JSP-engine itself, rather than doing it by garbage collection of the JVM or calling servlet destroy methods. We'd like to know wether your engine allows controlling the lifecycle of servlets without restart? If so, how? E.g. is it possible to onload a servlet that hasn't been requested for a given time period? It would be fine to get some comments from you by mail. Best regards Magnus Müller orgafactory gmbh Hügelstraße 8 60435 Frankfurt am Main Telefon (0 69) 90 54 66 21 Telefax (0 69) 90 54 66 13 mailto:[EMAIL PROTECTED]
Re: [TOMCAT 4.x SSI] Update
Hans Bergsten wrote: JSSI supports most of the NCSA SSI commands as well as the servlet tag for invoking servlets. In addition, it implements a number of configurable settings, such as expiration time, buffering, (and server-side caching, I believe) etc. When I started writing the SSI-servlet I did not have in mind to add support for ".jhtml", I was envisioning a servlet that _only_ supported NCSA SSI. I believe that SSI support and ".jhtml" support are two different packages so therefore when I looked at JSSI I did it from a view of how easy it was to modify this to work with Tomcat, for me and write up the missing SSI commands and also "strip out" the ".jhtml" support since I believe that that's another package/servlet/"whatever" to be implemented. Both so that it leaves the user with most flexibility as well as making it easier for us to maintain/update/modify without breaking the other functionality. I came to the conclusion that it was probably easier for me to try to use what JSSI has done in terms of SSI commands and implement that in "my" framework than it was for me to port the whole application. By the way, I just implemented Expiration and buffering. Most importantly, people who come to Tomcat from JServ are primarily interested in getting the same SSI support as they had in JServ. So in addition to saving on the initial implementation time by porting JSSI instead of starting from scratch, you will also end up with the SSI functionality the majority of the users expect. My goal is to stick to the NCSA SSI standard and maybe later on add support for xSSI so I don't think that _anyone_ will have problem with the SSI implementation from a user perspective. So I strongly suggest that you port JSSI. Most of it can be used as is. The only things that need to be tweaked are probably using resources instead of File, and using a different interface to ask Tomcat to load servlets. You may even drop support for the class and init parameters in the servlet tag, and then get away with just using the standard features in Servlet 2.3: getNamedDispatcher() plus a request wrapper that merges the original parameters with the ones specified in the servlet tag. I'm not trying the reinvent the wheel, I just want to accomplish a robust SSI-package that does only that and does it good. I haven't looked at ".jhtml" and hadn't even planned to write up that support for tomcat. But if my spare time allows me maybe I should :) Anyone can feel free to comment since I'm more than willing to discuss and eventually change my mind in this matter for the best of the outcome. ..bip - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat/src/examples/WEB-INF/classes LocalStrings_en.properties
larryi 01/03/06 13:31:05 Modified:src/examples/WEB-INF/classes Tag: tomcat_32 LocalStrings_en.properties Log: Add new strings for SessionExample servlet Revision ChangesPath No revision No revision 1.1.2.2 +6 -1 jakarta-tomcat/src/examples/WEB-INF/classes/LocalStrings_en.properties Index: LocalStrings_en.properties === RCS file: /home/cvs/jakarta-tomcat/src/examples/WEB-INF/classes/LocalStrings_en.properties,v retrieving revision 1.1.2.1 retrieving revision 1.1.2.2 diff -u -r1.1.2.1 -r1.1.2.2 --- LocalStrings_en.properties2000/07/05 17:45:04 1.1.2.1 +++ LocalStrings_en.properties2001/03/06 21:31:04 1.1.2.2 @@ -1,4 +1,4 @@ -# $Id: LocalStrings_en.properties,v 1.1.2.1 2000/07/05 17:45:04 nacho Exp $ +# $Id: LocalStrings_en.properties,v 1.1.2.2 2001/03/06 21:31:04 larryi Exp $ # Default localized resources for example servlets # This locale is en_US @@ -36,3 +36,8 @@ sessions.adddata=Add data to your session sessions.dataname=Name of Session Attribute: sessions.datavalue=Value of Session Attribute: +sessions.requestedid=Requested Session ID: +sessions.requestedidvalid=Requested Session ID is valid: +sessions.fromcookie=Requested Session ID is from a cookie: +sessions.fromurl=Requested Session ID is from a URL: +sessions.isnew=Session is new: - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat/src/share/org/apache/jasper/compiler JasperMangler.java
larryi 01/03/06 13:35:47
Modified:src/share/org/apache/jasper/compiler JasperMangler.java
Log:
Update init() method to change '/' character to File.separatorChar in pkgDir
for Windows systems. Jasper doesn't work well under Jdk1.1 on Windows
if classDir contains '/' characters.
Revision ChangesPath
1.5 +5 -1
jakarta-tomcat/src/share/org/apache/jasper/compiler/JasperMangler.java
Index: JasperMangler.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/jasper/compiler/JasperMangler.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- JasperMangler.java2001/02/20 03:36:00 1.4
+++ JasperMangler.java2001/03/06 21:35:46 1.5
@@ -222,7 +222,11 @@
pkgDir=JavaGeneratorTool.manglePackage(pkgDir);
pkgDir=pkgDir.replace('.', '_');
pkgDir=fixInvalidChars( pkgDir );
- classDir=workDir + File.separator + pkgDir;
+ if ( "/".equals(File.separator) )
+ classDir=workDir + File.separator + pkgDir;
+else
+ classDir=workDir + File.separator +
+ pkgDir.replace('/',File.separatorChar);
} else {
classDir=workDir;
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: Assigning Servlets to different ports.
Hi Costin, I will be very interested to learn more about the ProfileLoader and Tomcat 3.3 in general. I hope to have more time to bang on TC3.3 and TC4.0 after Enhydra Enterprise 4.0 is released. Shawn [EMAIL PROTECTED] wrote: Hi William, Regarding "multiple ContextManagers" - IMHO it should be possible to do that, but it's not a very tested feature. If what you want to do is support virtual hosts - tomcat supports virtual hosts using a single ContextManager ( the contextManager is a representation for a "server" that may have multiple hosts). There is no special representation for Host ( as a top-level object ) - each Context belongs to a virtual host, and the mapper is routing the requests. You can add additional modules to filter or do other tricks. ( just use Context.getHost() or getHostAliases() ). If you want to isolate applications/hosts - using separate VMs may give you more benefits. There are cases when multiple ContextManagers may help - for example if the servers have very different configuration ( i.e. top-level modules for mapping, etc). In 3.3 ( with the experimental ProfileLoader ) you can push all the modules as per/context interceptors, i.e. separate sets of modules for each web application - what's shared is the config modules and the top-level mapper. That means even fewer reasons to have multiple ContextManagers. IMHO if what you want to do requires changes/fixes in tomcat, you should try tomcat 3.3, where it is still possible to do this kind of change ( assuming it's not too big ). For 3.2.2 I don't think this can be clasified as a critical bug, and I don't think Marc would enjoy it :-) Costin Could you point me more specifically at where Enhydra uses multiple ContextManagers? I just downloaded EE 4.0a4 and couldn't find any files that have examples of multiple ContextManagers on different ports serving groups of apps. Whenever I try to use multiple ContextManagers on different ports I get lots of messages about removing duplicate servlets (like the jsp servlet, status servlet, exception servlet), and tomcat is unresponsive to any of my requests and refuses to shutdown, until I 'kill' it. Any help on figuring this out would be great. From my code archeology I was just about to conclude that it wasn't possible in tomcat 3.2.1 until your comment made me think that I had missed something. -Bill -Original Message- From: Shawn McMurdo [mailto:[EMAIL PROTECTED]] Sent: Tuesday, March 06, 2001 10:25 AM To: [EMAIL PROTECTED] Subject: Re: Assigning Servlets to different ports. Hi Mel, If you are interested in an approach to getting Tomcat to serve apps on multiple ports, you might want to check out the Enhydra Enterprise 4.0 source. We create multiple ContextManagers, where each ContextManager handles the group of apps running on a particular connection (port). This is currently using Tomcat 3.2.1. Shawn Mel Martinez wrote: --- Uijin Hong [EMAIL PROTECTED] wrote: Why don't you just run 2 servlet container(Tomcat)s for each port? That could get memory expensive if you have to do this for several ports. The best performance scenario might be to use Apache to listen to several ports and rewrite them to go to a single tomcat 'delegator' servlet which then dispatches them to servlets/JSPs appropriately. And actually, you should just use apache rewrites directly to dispatch to any static resources. Mel -Original Message- From: William Wishon [mailto:[EMAIL PROTECTED]] Sent: Tuesday, March 06, 2001 9:27 AM To: [EMAIL PROTECTED] Subject: Assigning Servlets to different ports. Hi, snipped An example of what I'm trying to do is to have a GET on "/" of port 8080 return webapps/app1/index.html and a GET of "/" on port 8081 return webapps/app2/index.html. Thanks, Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] __ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] -- Shawn McMurdo mailto:[EMAIL PROTECTED] Lutris Technologieshttp://www.lutris.com Enhydra.Orghttp://www.enhydra.org
Re: TC3.3m1 Possible bug with session.invalidate
Title: Re: TC3.3m1 Possible bug with session.invalidate I seem to be having a similar problem. My app also uses session information to track logins, and calls session.invalidate() when a user logs out. So far I'm seeing that if a user starts up a new browser, logs in, logs out, and attempts to login again as a different user, they get the session from their first login as if they had never logged out. Logging off again appears to fix the problem, and subsequent logins from the browser work fine. The problem recurs when a new browser is started. I don't see any references to this problem in Bugzilla, so I'll dive into the code and see what I can find. But if by chance someone has already fixed this problem somewhere, please let me know. --- Environment: Server: Tomcat 3.3m1 standalone on Solaris 2.7 IBM JDK 1.2.2 Client: NT 4.0 SP 5 IE 5.5 or Netscape 4.7 - same symptoms Thanks, Aaron Dunlop [EMAIL PROTECTED] -- From: [EMAIL PROTECTED] Hi, I seem to be having a problem with session.invalidate(). I'm using this for users to log out of my web site but it seems to take two attemps before the user is properly logged out! I am using JDBCRealms for authentication BTW. I have set up a simple four page web site: test/jsp/index.jsp front page % response.setHeader(Cache-Control,no-cache); //HTTP 1.1 response.setHeader(Pragma,no-cache); //HTTP 1.0 response.setDateHeader (Expires, 0); //prevents caching at the proxy server % html body %=request.toString()%br %=request.getSession (false)%br %=request.getRemoteUser()%br %=request.getUserPrincipal()%br h2a href=protected/index.jspLogin/ah2 /body /html test/jsp/protected/index.jsp --- protected page % response.setHeader(Cache-Control,no-cache); //HTTP 1.1 response.setHeader(Pragma,no-cache); //HTTP 1.0 response.setDateHeader (Expires, 0); //prevents caching at the proxy server % html body %=request.toString()%br %=request.getSession (false)%br h2you are currently logged in as %= request.getRemoteUser() %/h2 h3a href=logout.jspLogout/a/h3 /body /html test/jsp/protected/logout.jsp --- logout page % response.setHeader(Cache-Control,no-cache); //HTTP 1.1 response.setHeader(Pragma,no-cache); //HTTP 1.0 response.setDateHeader (Expires, 0); //prevents caching at the proxy server % html body %=request.toString()%br %=request.getSession (false)%br %=request.getRemoteUser()%br %=request.getUserPrincipal()%br % session.invalidate (); % %=request.getSession (false)%br %=request.toString()%br %=request.getRemoteUser()%br %=request.getUserPrincipal()%br a href=../index.jsphome/a. /body /html test/jsp/login/login.jsp --- login page used by FORM based authentication. html body h1Login page /h1 form method=POST action=j_security_check Username: input type=text name=j_usernamebr Password: input type=password name=j_passwordbr br input type=submit value=login name=j_security_check /form /body /html The problem occurs like this: The first time around the request for protected/index.jsp is detected and you have to log in. From there, access the logout page which does a % session.invalidate();%. Then back to jsp/index.jsp, try and access the protected page from here -- straight in as still authenticated. Accessing the log out page again, actually logs out this time! Is this a known problem? Any possible work arounds? Thanks, Sam. PS. This work fine on TC3.2.1
Re: TC3.3m1 Possible bug with session.invalidate
Title: Re: TC3.3m1 Possible bug with session.invalidate
The place to look is
src/share/org/apache/tomcat/modules/session/SimpleSessionStore.java. Or,
better, get the latest version of this file since the bug was fixed about two
weeks ago.
- Original Message -
From:
Dunlop,
Aaron
To: '[EMAIL PROTECTED]'
Sent: Tuesday, March 06, 2001 2:11
PM
Subject: Re: TC3.3m1 Possible bug with
session.invalidate
I seem to be having a similar problem. My app also uses
session information to track logins, and calls
session.invalidate() when a user logs out.
So far I'm seeing that if a user starts up a new browser, logs
in, logs out, and attempts to login again as a different user, they get the
session from their first login as if they
had never logged out. Logging off again appears to fix the
problem, and subsequent logins from the browser work
fine. The problem recurs when a new browser is started.
I don't see any references to this problem in Bugzilla, so
I'll dive into the code and see what I can find. But
if by chance someone has already fixed this problem somewhere,
please let me know.
--- Environment:
Server: Tomcat 3.3m1 standalone on
Solaris 2.7 IBM JDK 1.2.2
Client: NT 4.0 SP 5 IE 5.5 or Netscape 4.7 - same symptoms
Thanks, Aaron Dunlop [EMAIL PROTECTED]
--
From: [EMAIL PROTECTED]
Hi,
I seem to be having a problem with session.invalidate(). I'm
using this for users to log out of my web site but it
seems to take two attemps before the user is properly
logged out!
I am using JDBCRealms for authentication BTW.
I have set up a simple four page web site:
test/jsp/index.jsp front page % response.setHeader("Cache-Control","no-cache"); //HTTP 1.1
response.setHeader("Pragma","no-cache"); //HTTP 1.0
response.setDateHeader ("Expires", 0); //prevents caching at
the proxy server % html body %=request.toString()%br %=request.getSession (false)%br %=request.getRemoteUser()%br %=request.getUserPrincipal()%br
h2a
href="protected/index.jsp"Login/ah2
/body /html
test/jsp/protected/index.jsp --- protected page
% response.setHeader("Cache-Control","no-cache"); //HTTP 1.1
response.setHeader("Pragma","no-cache"); //HTTP 1.0
response.setDateHeader ("Expires", 0); //prevents caching at
the proxy server % html body
%=request.toString()%br %=request.getSession (false)%br h2you are currently logged in as %= request.getRemoteUser()
%/h2 h3a
href="logout.jsp"Logout/a/h3
/body /html
test/jsp/protected/logout.jsp --- logout page % response.setHeader("Cache-Control","no-cache"); //HTTP 1.1
response.setHeader("Pragma","no-cache"); //HTTP 1.0
response.setDateHeader ("Expires", 0); //prevents caching at
the proxy server % html body %=request.toString()%br %=request.getSession (false)%br %=request.getRemoteUser()%br %=request.getUserPrincipal()%br %
session.invalidate (); % %=request.getSession (false)%br %=request.toString()%br %=request.getRemoteUser()%br %=request.getUserPrincipal()%br
a href="../index.jsp"home/a. /body /html
test/jsp/login/login.jsp --- login page used by FORM based
authentication. html body h1Login page
/h1
form method="POST" action="j_security_check"
Username: input type="text"
name="j_username"br Password:
input type="password" name="j_password"br br input type="submit"
value="login" name="j_security_check" /form
/body /html
The problem occurs like this: The
first time around the request for protected/index.jsp is detected and
you have to log in. From
there, access the logout page which does a %
session.invalidate();%. Then back to
jsp/index.jsp, try and access the protected page from here --
straight in as still authenticated. Accessing the log out page again, actually logs out this time!
Is this a known problem? Any possible work arounds?
Thanks, Sam. PS. This work fine on TC3.2.1
RE: FW: problem w/ ajp13 - if Tomcat is shutdown
Title: RE: FW: problem w/ ajp13 - if Tomcat is shutdown I am using Tomcat 3.2.1, Apache 1.3.14, running on Solaris 2.8, Sun machines. After various attempts of debugging this, I have more information. 1. Even though I'm setting the worker's property cache_size to default (1), I'm finding there are up to 6 connections opened from Apache to Tomcat. I deduce this by looking at the mod_jk.conf and by doing netstat. I finally find out, this is so because my Apache is set to spawn minimum of 6 children and each of those children are making separate connections to Tomcat. This is very bad because, I ended up having to reload 6 times before Tomcat starts serving me the page again. Each time it uses a different Apache children that has defunct socket. So the more Apache children I have, the longer it takes me to recover from this problem. 2. It seems when Tomcat dies restarts, the send() called by ajp13's jk_tcp_socket_sendfull() does not get an error. But the recv() does get an error, with errno ECONNRESET. After which, the socket is properly closed. 3. When I shutdown Tomcat, those sockets that were opened between Apache/Tomcat showed up in state CLOSE_WAIT, and FIN_WAIT2. I think this is normally solved by calling the shutdown() API after closing the socket. However, this would have to be done from the Tomcat side in Ajp13ConnectionHandler.java. I can't find the corresponding method of Socket in Java. So.. based on all of these, the only fix I can think of putting is to make mod_jk retry the send() if recv() comes back with an error ECONNRESET. The retry should happen after the old socket is properly closed. Anyone wants to comment? shinta -Original Message- From: Dan Milstein [mailto:[EMAIL PROTECTED]] Sent: Tuesday, March 06, 2001 12:00 PM To: [EMAIL PROTECTED] Subject: Re: FW: problem w/ ajp13 - if Tomcat is shutdown What version of TC are you using? What version of Apache? I would look into the mod_jk docs -- I think this is the spec'd behavior (which, admittedly, is not great, but that makes it more of a feature request than a bug ;-). With ajp13, Apache opens up a persistent TCP/IP connection TC -- if TC restarts, I think that connection may just hang up and then timeout (since Apache doesn't know that TC has restarted). If anyone wants to work on this, you would have the undying thanks of the rest of the TC community -- having to restart Apache all the time bugs a *lot* of people. -Dan Shinta Tjio wrote: I'm having problem with mod_jk if ajp13 is used. The problem is often reproduced when Tomcat is shut down without Apache being shut down. When a request is fired through Apache as soon as Tomcat starts, I often get Internal Server Error. The mod_jk.log will have the following: [jk_uri_worker_map.c (344)]: Into jk_uri_worker_map_t::map_uri_to_worker [jk_uri_worker_map.c (406)]: jk_uri_worker_map_t::map_uri_to_worker, Found a match ajp13 [jk_worker.c (123)]: Into wc_get_worker_for_name ajp13 [jk_worker.c (127)]: wc_get_worker_for_name, done found a worker [jk_ajp13_worker.c (651)]: Into jk_worker_t::get_endpoint [jk_ajp13_worker.c (536)]: Into jk_endpoint_t::service [jk_ajp13.c (346)]: Into ajp13_marshal_into_msgb [jk_ajp13.c (480)]: ajp13_marshal_into_msgb - Done [jk_ajp13_worker.c (203)]: connection_tcp_get_message: Error - jk_tcp_socket_recvfull failed [jk_ajp13_worker.c (619)]: Error reading request [jk_ajp13_worker.c (489)]: Into jk_endpoint_t::done If I hit reload multiple times, eventually Tomcat will serve the servlet fine. Did anyone see this problem before? Is there anyway around this? shinta -- Dan Milstein // [EMAIL PROTECTED]
Re: TC3.3m1 Possible bug with session.invalidate
I got around this by just removing j_password and j_username from the sessionid.
HttpSession sessionid = request.getSession(false);
sessionid.removeValue("j_password");
sessionid.removeValue("j_username");
"Dunlop, Aaron" wrote:
I seem to be having a similar problem. My app also uses
session information to track
logins, and calls session.invalidate() when a user logs
out.
So far I'm seeing that if a user starts up a new browser,
logs in, logs out, and attempts to login again as a different user, they
get the session from their first login as if they
had never logged out. Logging off again appears to fix
the problem, and subsequent logins
from the browser work fine. The problem recurs when a
new browser is started.
I don't see any references to this problem in Bugzilla,
so I'll dive into the code and
see what I can find. But if by chance someone has already
fixed this problem somewhere,
please let me know.
---
Environment:
Server:
Tomcat 3.3m1 standalone on Solaris 2.7
IBM JDK 1.2.2
Client:
NT 4.0 SP 5
IE 5.5 or Netscape 4.7 - same symptoms
Thanks,
Aaron Dunlop
[EMAIL PROTECTED]
--
From: [EMAIL PROTECTED]
Hi,
I seem to be having a problem with session.invalidate().
I'm using this for
users to log out of my web site but it seems to take
two attemps before the user
is properly logged out!
I am using JDBCRealms for authentication BTW.
I have set up a simple four page web site:
test/jsp/index.jsp front page
%
response.setHeader("Cache-Control","no-cache"); //HTTP
1.1
response.setHeader("Pragma","no-cache"); //HTTP 1.0
response.setDateHeader ("Expires", 0); //prevents caching
at the proxy server
%>
html>
body>
%=request.toString()%>br>
%=request.getSession (false)%>br>
%=request.getRemoteUser()%>br>
%=request.getUserPrincipal()%>br>
h2>a href="protected/index.jsp">Login/a>h2>
/body>
/html>
test/jsp/protected/index.jsp --- protected page
%
response.setHeader("Cache-Control","no-cache"); //HTTP
1.1
response.setHeader("Pragma","no-cache"); //HTTP 1.0
response.setDateHeader ("Expires", 0); //prevents caching
at the proxy server
%>
html>
body>
%=request.toString()%>br>
%=request.getSession (false)%>br>
h2>you are currently logged in as %= request.getRemoteUser()
%>/h2>
h3>a href="logout.jsp">Logout/a>/h3>
/body>
/html>
test/jsp/protected/logout.jsp --- logout page
%
response.setHeader("Cache-Control","no-cache"); //HTTP
1.1
response.setHeader("Pragma","no-cache"); //HTTP 1.0
response.setDateHeader ("Expires", 0); //prevents caching
at the proxy server
%>
html>
body>
%=request.toString()%>br>
%=request.getSession (false)%>br>
%=request.getRemoteUser()%>br>
%=request.getUserPrincipal()%>br>
%
session.invalidate ();
%>
%=request.getSession (false)%>br>
%=request.toString()%>br>
%=request.getRemoteUser()%>br>
%=request.getUserPrincipal()%>br>
a href="../index.jsp">home/a>.
/body>
/html>
test/jsp/login/login.jsp --- login page used by FORM based
authentication.
html>
body>
h1>Login page /h1>
form method="POST" action="j_security_check" >
Username: input type="text" name="j_username">br>
Password: input type="password" name="j_password">br>
br>
input type="submit" value="login" name="j_security_check">
/form>
/body>
/html>
The problem occurs like this:
The first time around the request for protected/index.jsp
is detected and you
have to log in.
>From there, access the logout page which does a %
session.invalidate();%>.
Then back to jsp/index.jsp, try and access the protected
page from here --
straight in as still authenticated.
Accessing the log out page again, actually logs out this
time!
Is this a known problem? Any possible work arounds?
Thanks,
Sam.
PS. This work fine on TC3.2.1
Re: cvs commit: jakarta-tomcat/src/share/org/apache/jasper/compiler JasperMangler.java
There is one more problem that you should consider while you are looking at this
particular
code...
JasperMangler.java will generate incorrect class paths if you every have a number
after a
separator /.
It will try to generate package starting with a number, which (obviously) doesn't work
in java.
-Tom
[EMAIL PROTECTED] wrote:
larryi 01/03/06 13:35:47
Modified:src/share/org/apache/jasper/compiler JasperMangler.java
Log:
Update init() method to change '/' character to File.separatorChar in pkgDir
for Windows systems. Jasper doesn't work well under Jdk1.1 on Windows
if classDir contains '/' characters.
Revision ChangesPath
1.5 +5 -1
jakarta-tomcat/src/share/org/apache/jasper/compiler/JasperMangler.java
Index: JasperMangler.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/jasper/compiler/JasperMangler.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- JasperMangler.java2001/02/20 03:36:00 1.4
+++ JasperMangler.java2001/03/06 21:35:46 1.5
@@ -222,7 +222,11 @@
pkgDir=JavaGeneratorTool.manglePackage(pkgDir);
pkgDir=pkgDir.replace('.', '_');
pkgDir=fixInvalidChars( pkgDir );
- classDir=workDir + File.separator + pkgDir;
+ if ( "/".equals(File.separator) )
+ classDir=workDir + File.separator + pkgDir;
+else
+ classDir=workDir + File.separator +
+ pkgDir.replace('/',File.separatorChar);
} else {
classDir=workDir;
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
RE: FW: problem w/ ajp13 - if Tomcat is shutdown
I was running recently with that exact same configuration but did not experience that problem. Can you show some config files. -Andy -Original Message- From: Shinta Tjio To: [EMAIL PROTECTED] Cc: 'Dan Milstein' Sent: 3/6/01 7:01 PM Subject: RE: FW: problem w/ ajp13 - if Tomcat is shutdown I am using Tomcat 3.2.1, Apache 1.3.14, running on Solaris 2.8, Sun machines. After various attempts of debugging this, I have more information. 1. Even though I'm setting the worker's property cache_size to default (1), I'm finding there are up to 6 connections opened from Apache to Tomcat. I deduce this by looking at the mod_jk.conf and by doing netstat. I finally find out, this is so because my Apache is set to spawn minimum of 6 children and each of those children are making separate connections to Tomcat. This is very bad because, I ended up having to reload 6 times before Tomcat starts serving me the page again. Each time it uses a different Apache children that has defunct socket. So the more Apache children I have, the longer it takes me to recover from this problem. 2. It seems when Tomcat dies restarts, the send() called by ajp13's jk_tcp_socket_sendfull() does not get an error. But the recv() does get an error, with errno ECONNRESET. After which, the socket is properly closed. 3. When I shutdown Tomcat, those sockets that were opened between Apache/Tomcat showed up in state CLOSE_WAIT, and FIN_WAIT2. I think this is normally solved by calling the shutdown() API after closing the socket. However, this would have to be done from the Tomcat side in Ajp13ConnectionHandler.java. I can't find the corresponding method of Socket in Java. So.. based on all of these, the only fix I can think of putting is to make mod_jk retry the send() if recv() comes back with an error ECONNRESET. The retry should happen after the old socket is properly closed. Anyone wants to comment? shinta -Original Message- From: Dan Milstein [ mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] ] Sent: Tuesday, March 06, 2001 12:00 PM To: [EMAIL PROTECTED] Subject: Re: FW: problem w/ ajp13 - if Tomcat is shutdown What version of TC are you using? What version of Apache? I would look into the mod_jk docs -- I think this is the spec'd behavior (which, admittedly, is not great, but that makes it more of a feature request than a bug ;-). With ajp13, Apache opens up a persistent TCP/IP connection TC -- if TC restarts, I think that connection may just hang up and then timeout (since Apache doesn't know that TC has restarted). If anyone wants to work on this, you would have the undying thanks of the rest of the TC community -- having to restart Apache all the time bugs a *lot* of people. -Dan Shinta Tjio wrote: I'm having problem with mod_jk if ajp13 is used. The problem is often reproduced when Tomcat is shut down without Apache being shut down. When a request is fired through Apache as soon as Tomcat starts, I often get Internal Server Error. The mod_jk.log will have the following: [jk_uri_worker_map.c (344)]: Into jk_uri_worker_map_t::map_uri_to_worker [jk_uri_worker_map.c (406)]: jk_uri_worker_map_t::map_uri_to_worker, Found a match ajp13 [jk_worker.c (123)]: Into wc_get_worker_for_name ajp13 [jk_worker.c (127)]: wc_get_worker_for_name, done found a worker [jk_ajp13_worker.c (651)]: Into jk_worker_t::get_endpoint [jk_ajp13_worker.c (536)]: Into jk_endpoint_t::service [jk_ajp13.c (346)]: Into ajp13_marshal_into_msgb [jk_ajp13.c (480)]: ajp13_marshal_into_msgb - Done [jk_ajp13_worker.c (203)]: connection_tcp_get_message: Error - jk_tcp_socket_recvfull failed [jk_ajp13_worker.c (619)]: Error reading request [jk_ajp13_worker.c (489)]: Into jk_endpoint_t::done If I hit reload multiple times, eventually Tomcat will serve the servlet fine. Did anyone see this problem before? Is there anyway around this? shinta -- Dan Milstein // [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Tag Handler Pooling Clarification
Sorry for the long message, but I'm a bit unclear on some Tag related spec details. I need to make sure I have a clear understanding before I start thinking about tag handler reuse implementation. My original understanding of Tag.release was that it was always called after a tag handler was used -- after doEndTag. After calling release, the JSP container could then put the tag handler back into a pool for reuse. So, I was under the impression that a tag handler could be treated simply as a pooled resource. Based on my understanding, all of our code simply set tag handler attributes to their default values in the release method. By doing this we set the tag handler to a "default" or "initialized" state. Subsequently, setPageContext, various setters, etc. could be called and the whole tag use process would proceed again. But, after a more careful reading of the tag sections of the JSP 1.2 spec, it appears that tag reuse can only occur when tags have the same set of attributes that are initialized in the JSP. Specifically, in section 10.1.1 under the "Lifecycle" section, bullet [3] states: Note that since there are no guarantees on the state of the properties, a tag handler that had some optional properties set can only be reused if those properties are set to a new (known) value. This means that tag handlers can only be reused within the same "Att-Set" (set of attributes that have been set). This part of the spec could be interpreted to mean that tag handlers should only be reused if they have the same set of attributes. For example, given the following JSP fragment, two different tag1 handlers would have to be used (instead of reusing the handler): X:tag1 attr1="A" attr2="B"/ X:tag1 attr1="A"/ I hope that I'm misunderstanding something. I'd much prefer that the JSP container can rely on the handler's release method to reset the handler to a known state and simply start the tag process over again (setPageContext, setters, etc.) Such an assumption would greatly simplify a pooling strategy. Can anyone provide clarification? Your understanding matches my understanding of what the spec actually says. If you want to suggest changes in the spec, the proper feedback address is: [EMAIL PROTECTED] -Casey Craig McClanahan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: FW: problem w/ ajp13 - if Tomcat is shutdown
Title: RE: FW: problem w/ ajp13 - if Tomcat is shutdown Here's exactly what I did to reproduce the problem. Again, I'm running this on a Solaris 2.8 SunOS machine, using JDK1.2.2, Apache 1.3.14, Tomcat 3.2.1. 1. Start Apache 2. Start Tomcat 3. Start hitting Apache with multiple requests, such as /example/servlet/HelloWorldExample. Make sure there are some connections opened from Apache to Tomcat. To make sure, you can do netstat -a | grep Tomcat port where Tomcat port is the ajp13 port. It should show some socket in ESTABLISHED state. 4. While the connections are in the ESTABLISHED state (this should be the state because ajp13 reuse connections), shutdown Tomcat. Now you will notice the same netstat will show some sockets in FIN_WAIT2 and CLOSE_WAIT state. 5. Now restart Tomcat. 6. Repeat step 3. You will get Internal Server Error, up to the number of children Apache has. After that number, the page will be served. Attached is the server.xml, workers.properties, httpd.conf. My test servlet is called /mytest/servlet/testServlet but I think you can try it with any kind of servlet. I have been trying to code up the retry I mentioned below. I think I got it working. I just need to clean up the code some more. shinta -Original Message- From: oliver2, andy [mailto:[EMAIL PROTECTED]] Sent: Tuesday, March 06, 2001 6:33 PM To: 'Shinta Tjio '; '[EMAIL PROTECTED] ' Cc: ''Dan Milstein' ' Subject: RE: FW: problem w/ ajp13 - if Tomcat is shutdown I was running recently with that exact same configuration but did not experience that problem. Can you show some config files. -Andy -Original Message- From: Shinta Tjio To: [EMAIL PROTECTED] Cc: 'Dan Milstein' Sent: 3/6/01 7:01 PM Subject: RE: FW: problem w/ ajp13 - if Tomcat is shutdown I am using Tomcat 3.2.1, Apache 1.3.14, running on Solaris 2.8, Sun machines. After various attempts of debugging this, I have more information. 1. Even though I'm setting the worker's property cache_size to default (1), I'm finding there are up to 6 connections opened from Apache to Tomcat. I deduce this by looking at the mod_jk.conf and by doing netstat. I finally find out, this is so because my Apache is set to spawn minimum of 6 children and each of those children are making separate connections to Tomcat. This is very bad because, I ended up having to reload 6 times before Tomcat starts serving me the page again. Each time it uses a different Apache children that has defunct socket. So the more Apache children I have, the longer it takes me to recover from this problem. 2. It seems when Tomcat dies restarts, the send() called by ajp13's jk_tcp_socket_sendfull() does not get an error. But the recv() does get an error, with errno ECONNRESET. After which, the socket is properly closed. 3. When I shutdown Tomcat, those sockets that were opened between Apache/Tomcat showed up in state CLOSE_WAIT, and FIN_WAIT2. I think this is normally solved by calling the shutdown() API after closing the socket. However, this would have to be done from the Tomcat side in Ajp13ConnectionHandler.java. I can't find the corresponding method of Socket in Java. So.. based on all of these, the only fix I can think of putting is to make mod_jk retry the send() if recv() comes back with an error ECONNRESET. The retry should happen after the old socket is properly closed. Anyone wants to comment? shinta -Original Message- From: Dan Milstein [ mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] ] Sent: Tuesday, March 06, 2001 12:00 PM To: [EMAIL PROTECTED] Subject: Re: FW: problem w/ ajp13 - if Tomcat is shutdown What version of TC are you using? What version of Apache? I would look into the mod_jk docs -- I think this is the spec'd behavior (which, admittedly, is not great, but that makes it more of a feature request than a bug ;-). With ajp13, Apache opens up a persistent TCP/IP connection TC -- if TC restarts, I think that connection may just hang up and then timeout (since Apache doesn't know that TC has restarted). If anyone wants to work on this, you would have the undying thanks of the rest of the TC community -- having to restart Apache all the time bugs a *lot* of people. -Dan Shinta Tjio wrote: I'm having problem with mod_jk if ajp13 is used. The problem is often reproduced when Tomcat is shut down without Apache being shut down. When a request is fired through Apache as soon as Tomcat starts, I often get Internal Server Error. The mod_jk.log will have the following: [jk_uri_worker_map.c (344)]: Into jk_uri_worker_map_t::map_uri_to_worker [jk_uri_worker_map.c (406)]: jk_uri_worker_map_t::map_uri_to_worker, Found a match ajp13 [jk_worker.c (123)]: Into wc_get_worker_for_name ajp13
RequestImpl.recycle() not finalizing attributes
I have noticed that any objects stored in a requests attributes doesn't get finalized immediately after the completion of the request. The attributes get cleared in RequestImpl.initRequest(), but the resources aren't necessarily freed. I added a System.gc() after the initRequest() call in RequestImpl.recycle(), and was wondering if this is going to cause any problems... I wasn't sure if this message belongs in this list or the User list, sorry if I am in the wrong place! Thanks Casey P.S. I am not subscribed to the list, so please CC me on reply - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/core ContextManager.java
costin 01/03/06 23:13:27
Modified:src/share/org/apache/tomcat/core ContextManager.java
Log:
Small bug - for bad requests, the context is not set.
Revision ChangesPath
1.172 +9 -2
jakarta-tomcat/src/share/org/apache/tomcat/core/ContextManager.java
Index: ContextManager.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/core/ContextManager.java,v
retrieving revision 1.171
retrieving revision 1.172
diff -u -r1.171 -r1.172
--- ContextManager.java 2001/03/04 03:31:52 1.171
+++ ContextManager.java 2001/03/07 07:13:26 1.172
@@ -298,6 +298,10 @@
public void setProperty( String name, String value ) {
properties.put( name, value );
}
+
+public Hashtable getProperties() {
+ return properties;
+}
// Other properties
@@ -929,8 +933,11 @@
public final void handleError( Request req, Response res , Throwable t ) {
BaseInterceptor ri[];
int status;
- ri=req.getContext().getContainer().
- getInterceptors( Container.H_handleError );
+ if( req.getContext() == null )
+ ri=getContainer().getInterceptors( Container.H_handleError );
+ else
+ ri=req.getContext().getContainer().
+ getInterceptors( Container.H_handleError );
for( int i=0; i ri.length; i++ ) {
status=ri[i].handleError( req, res, t );
if( status!=0 ) return;
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/core ContextManager.java
costin 01/03/06 23:56:21
Modified:src/share/org/apache/tomcat/core ContextManager.java
Log:
Other places where getContext() needs to be checked.
Revision ChangesPath
1.173 +22 -7
jakarta-tomcat/src/share/org/apache/tomcat/core/ContextManager.java
Index: ContextManager.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/core/ContextManager.java,v
retrieving revision 1.172
retrieving revision 1.173
diff -u -r1.172 -r1.173
--- ContextManager.java 2001/03/07 07:13:26 1.172
+++ ContextManager.java 2001/03/07 07:56:20 1.173
@@ -708,8 +708,12 @@
handleError( req, res, ex );
}
finally {
- BaseInterceptor reqI[]= req.getContext().getContainer().
- getInterceptors(Container.H_postRequest);
+ BaseInterceptor reqI[];
+ if( req.getContext()==null )
+ reqI=getContainer().getInterceptors( Container.H_handleError );
+ else
+ reqI= req.getContext().getContainer().
+ getInterceptors(Container.H_postRequest);
for( int i=0; i reqI.length; i++ ) {
reqI[i].postRequest( req, res );
@@ -756,8 +760,13 @@
String roles[]=req.getRequiredRoles();
if(roles != null ) {
status=0;
- BaseInterceptor reqI[]= req.getContext().getContainer().
-getInterceptors(Container.H_authorize);
+ BaseInterceptor reqI[];
+ if( req.getContext()==null )
+ reqI=getContainer().
+ getInterceptors( Container.H_handleError );
+ else
+ reqI = req.getContext().getContainer().
+ getInterceptors(Container.H_authorize);
// Call all authorization callbacks.
for( int i=0; i reqI.length; i++ ) {
@@ -808,7 +817,10 @@
// the context is not fully initialized.
req.setAttribute("javax.servlet.error.message",
"Application not available");
- handleStatus( req, req.getResponse(), 503 ); // service unavailable
+ // return error code - the caller will handle it
+ // handleStatus( req, req.getResponse(), 503 );
+ // service unavailable
+ return 503;
}
ri=req.getContext().getContainer().
@@ -918,8 +930,11 @@
BaseInterceptor ri[];
int status;
- ri=req.getContext().getContainer().
- getInterceptors( Container.H_handleError );
+ if( req.getContext()==null )
+ ri=getContainer().getInterceptors( Container.H_handleError );
+ else
+ ri=req.getContext().getContainer().
+ getInterceptors( Container.H_handleError );
for( int i=0; i ri.length; i++ ) {
status=ri[i].handleError( req, res, null );
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
