Servlet API support for multiple HTTP status codes (1xx)?
Question How to send multiple 1xx responses and a final 200 response to a single request? An example -- A HTTP/1.1 user agent (UA) sends a large, multi-GB XML data file to your server. Thirty seconds pass and the server is still digesting the data file. The server responds with a 100 status code to inform the UA to continue waiting. Another 30 seconds pass -- rinse, repeat ten more times over the same HTTP connection. Withouth the 1xx responses, a UA like MS IE or Mozilla would've timed out the request by now. Seven more seconds pass and the server finally gets back to the UA with the real response -- a fancy PDF-formatted graphical representation of their XML file, perhaps. Some background --- HTTP/1.1 (RFC 2616) [1] defines informational status codes as those in the 1xx range, and indicates that HTTP/1.1 UAs must be prepared to accept many such intermediate responses before the final response (to the single, original request). Here's the relevant section from RFC 2616: 10.1 Informational 1xx This class of status code indicates a provisional response, consisting only of the Status-Line and optional headers, and is terminated by an empty line. There are no required headers for this class of status code. Since HTTP/1.0 did not define any 1xx status codes, servers MUST NOT send a 1xx response to an HTTP/1.0 client except under experimental conditions. A client MUST be prepared to accept one or more 1xx status responses prior to a regular response, even if the client does not expect a 100 (Continue) status message. Unexpected 1xx status responses MAY be ignored by a user agent. Proxies MUST forward 1xx responses, unless the connection between the proxy and its client has been closed, or unless the proxy itself requested the generation of the 1xx response. (For example, if a proxy adds a Expect: 100-continue field when it forwards a request, then it need not forward the corresponding 100 (Continue) response(s).) 10.1.1 100 Continue The client SHOULD continue with its request. This interim response is used to inform the client that the initial part of the request has been received and has not yet been rejected by the server. The client SHOULD continue by sending the remainder of the request or, if the request has already been completed, ignore this response. The server MUST send a final response after the request has been completed. See section 8.2.3 for detailed discussion of the use and handling of this status code. WebDAV extensions to HTTP/1.1 (RFC 2518) [2] continues definition of informational status codes with 102 (Processing) as a way for the server to provide yes I'm still working so hold your horses feedback to the UA when dealing with long-lived requests. Using our XML - PDF example from above, this is a bit more descriptive than continue waiting 100 response, indicating not just that the UA should wait, but also that the server is indeed working on proessing the request. Here's the relevant section: 10.1 102 Processing The 102 (Processing) status code is an interim response used to inform the client that the server has accepted the complete request, but has not yet completed it. This status code SHOULD only be sent when the server has a reasonable expectation that the request will take significant time to complete. As guidance, if a method is taking longer than 20 seconds (a reasonable, but arbitrary value) to process the server SHOULD return a 102 (Processing) response. The server MUST send a final response after the request has been completed. Methods can potentially take a long period of time to process, especially methods that support the Depth header. In such cases the client may time-out the connection while waiting for a response. To prevent this the server may return a 102 (Processing) status code to indicate to the client that the server is still processing the method. Servlet API lacking? Brief examination of the source for Tomcat 4.1 leads me to believe that though sendError(int) does provide a way for communicating informational responses in the 1xx range -- which incidently aren't error conditions -- that later attempts to communicate additional 1xx or the final 200 response are not supported, and result in an IllegalStateException or IOException or some such. Without writing code directly against Tomcat's own API to gain access to the underlying TCP socket connection (rather than against the more portable Servlet API), I'm not seeing a way of sending multiple interim responses to the UA. Is Servlet API 2.3 really lacking this feature, or did I just miss it somewhere? If so, is this feature planned for future versions of the Servlet API, and is there an interim work-around? Thanks for your time, Dan p.s. Please CC me on any responses. [1]
[PATCH] Remove redundant constructor from StandardSessionFacade
* catalina/src/share/org/apache/catalina/session/StandardSessionFacade.java
StandardSessionFacade(StandardSession): Removed redundant constructor. As
StandardSession implements HttpSession, the
StandardSessionFacade(HttpSession) constructor already does the job
admirably.
---
/tmp/jakarta-tomcat-4.1.18-src/catalina/src/share/org/apache/catalina/session/StandardSessionFacade.java
Wed Jan 29 15:56:00 2003
+++ /tmp/StandardSessionFacade.java Wed Jan 29 15:56:00 2003
@@ -104,15 +104,6 @@
/**
* Construct a new session facade.
*/
-public StandardSessionFacade(StandardSession session) {
-super();
-this.session = (HttpSession) session;
-}
-
-
-/**
- * Construct a new session facade.
- */
public StandardSessionFacade(HttpSession session) {
super();
this.session = session;
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[PATCH][JK] Ajp13Processor connection leak prevention
Adjusted Ajp13Processor's run() method to protect against unexpected
unchecked excpetions, preventing the possibility of a leak in
Ajp13Connector's request processor pool.
Index: Ajp13Processor.java
===
RCS file:
/home/cvspublic/jakarta-tomcat-connectors/jk/java/org/apache/ajp/tomcat4/Ajp13Processor.java,v
retrieving revision 1.9
diff -u -u -r1.9 Ajp13Processor.java
--- Ajp13Processor.java 7 Jun 2002 18:54:21 - 1.9
+++ Ajp13Processor.java 6 Nov 2002 08:01:14 -
@@ -547,14 +547,16 @@
logger.log(socket assigned.);
}
- // Process the request from this socket
- process(socket);
-
- // Finish up this request
-if (debug 0) {
-logger.log(recycling myself ...);
+try {
+// Process the request from this socket
+process(socket);
+} finally {
+// Finish up this request
+if (debug 0) {
+logger.log(recycling myself ...);
+}
+connector.recycle(this);
}
- connector.recycle(this);
}
// Tell threadStop() we have shut ourselves down successfully
On another note, what's the most robust Java and Apache httpd
connector code bases these days for Tomcat 4.1? Not trying to start a
religious war -- interested in your opinions. Please send me to the
appropriate docs if this is a RTFM question.
Thanks!
--
Daniel Rall [EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: Replacing WebappClassLoader
hung [EMAIL PROTECTED] writes: Dear Tomcat Dev, Is there a website that have the instruction on how to connection Tomcat 4 with Apache 2? Please help. Made me running tomcat as module of apache. This sort of question is most appropriate on the Tomcat User list. The documentation for what you're asking about is located under the Connectors section of the left nav in the following links: http://jakarta.apache.org/tomcat/tomcat-4.0-doc/config/index.html http://jakarta.apache.org/tomcat/tomcat-4.1-doc/config/index.html -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[PATCH/COMMENTS] Automatic Application Deployment and Host.liveDeploy
Added missing closing paren. Index: host.xml === RCS file: /home/cvspublic/jakarta-tomcat-4.0/webapps/tomcat-docs/config/host.xml,v retrieving revision 1.12 diff -u -u -r1.12 host.xml --- host.xml20 Mar 2002 12:33:01 - 1.12 +++ host.xml19 Apr 2002 00:11:30 - @@ -245,7 +245,7 @@ pIf you are using the standard strongHost/strong implementation, the following actions take place automatically when Catalina is first started, if the codeautoDeploy/code property is set to -codetrue/code (which is the default value:/p +codetrue/code (which is the default value):/p ul liAny XML file in this directory is assumed to contain a a href=context.htmlContext/a element (and its associated This Automatic Application Deployment section should also mention the new liveDeploy flag. This flag must be used in conjunction with autoDeploy if the name of your web application directory differs from the name of the Context where you mount your web app (when you want _only_ the Context entries defined in server.xml to be deployed). Consider the following layout: $CATALINA_BASE/ webapps/ secretapp/ ...with a server.xml like: Host name=mysite.com appBase=webapps autoDeploy=false ... Context path=mycontext docBase=secretapp reloadable=true/ /Host The initial startup occurs, and secretapp is mounted at /mycontext. After the initial startup, if I haven't included liveDeploy=false in my Host entry, Catalina's live deployment thread wanders over, spots the secretapp directory under my Host's appBase, and decides to load it as another web app (even though it has already been loaded and mounted at /mycontext). Wasted resources aside, this can be painful (example: consider the case where your web app's servlets open TCP listener sockets). Definitely worth mentioning in the doc, and perhaps protecting against in some fashion in the code (if possible). - Dan -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: HTML form: multipart/form-data
Bojan Smojver [EMAIL PROTECTED] writes: On Wed, 2002-03-13 at 06:39, Jon Scott Stevens wrote: p.s. Don't use JavaMail for it, because JavaMail tends to have a lot of overhead. Yes, you're right. And I don't think you can limit (with JavaMail) how much data you want to allow, so that's another downside. When dealing with MIME email messages (using MimeMessage), JavaMail reads entire messages memory into memory at a time. For huge messages, this can be a very bad thing. For Eyebrowse, I was able to replace JavaMail's MimeMessage with my own skeleton implementation: http://eyebrowse.tigris.org/source/browse/eyebrowse/src/java/org/tigris/eyebrowse/util/mail/EyebrowseMimeMessage.java?rev=1content-type=text/x-cvsweb-markup -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector HttpResponseBase.java
[EMAIL PROTECTED] writes: billbarker02/01/29 19:45:23 Modified:catalina/src/share/org/apache/catalina/connector HttpResponseBase.java Log: Fix for case where URL only has an anchor. Now response.encodeURL(#foobar) works as expected. Thanks for fixing the other part of that issue, Bill. I realized that the other patch didn't statisfy the whole complaint when looking at that Bugzilla message, but hadn't a chance to update the issue yet. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [tomcat3] Sharing Utility Code
Like Jason suggests, feel free to park the servlet utilities in jakarta-commons-sandbox/util (that's going to need a release pretty soon anyways). [EMAIL PROTECTED] writes: +1, it'll solve a lot of problems with jk and probably coyotee as well. I allways wanted to move some of the utils in commons, but there were allways more important things to do, but if there is at least one other project besides tomcat using it we should certainly make the change. I guess we need at least another +1, and that's Remy, who is also using some classes. And we can discuss if/when jk2, coyotee, 3.3.1 ( or 2 ) will start using the common package. It already is a problem, I had to do changes to C2B - the efficient char to byte used for output - and I can't do it in j-t-c/utils since it'll generate conflicts with 3.3.0. In Turbine we have a new caching package that we have introduced and it uses a few of the utility classes in the tomcat3 tree. We are having problems with Gump because the package structure changed and some classes were probably refactored and moved. I realize that these utilities are used internally for tomcat3 uses but I was wondering if there's anyway we could share this code. Possibly in the commons-util package? It is in the sandbox right now only because there wasn't a dire need to push it up to the top level, but if we could get your code into the commons-util package I would be will to the proposal and first release of that package. Any takers? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Updating the site
I answered this on general@. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PATCH] JvmRoute changes
Hey Tom, when sending patches inline, you need to instruct your email client to not line wrap at 76 columns (what's good for the humans isn't good for the machines :-). Dan -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PATCH] JvmRoute changes
Daniel Rall [EMAIL PROTECTED] writes: Hey Tom, when sending patches inline, you need to instruct your email client to not line wrap at 76 columns (what's good for the humans isn't good for the machines :-). Look like you already noticed. :-) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: How to find the Changelog files for different versions of Tomcat?
chenk [EMAIL PROTECTED] writes: I am doing research on software engineering. I wish to use the Tomcat as an example to analysis the process of the java open source software. It is important for me to get changelog files for different versions of the Tomcat. I have tried my best, but can't find it. Are there anybody who would like to tell me how to find the Changelog file? Your help is highly appreciated! http://jakarta.apache.org/site/cvsindex.html http://cvs.apache.org/viewcvs/jakarta-tomcat-4.0/ Look at the RELEASE-NOTES* entries. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PATCH] Fix for data corruption in the Warp connector
Hi Daniel. Pier checked this change into jakarta-tomcat-connectors CVS a while back. I don't believe it's been ported to the jakarta-tomcat-4.0 repository yet -- it really needs to be, there have been a lot of reports of this bug (though few fixes :). Daniel Harding [EMAIL PROTECTED] writes: When using the Warp connector, the read method of the stream returned by request.getInputStream() would return negative numbers for bytes greater than 0xEF. The attached patch fixes this problem. --- WarpRequest.java Wed Jan 9 20:38:23 2002 +++ WarpRequest.java.new Wed Jan 9 20:36:00 2002 @@ -139,7 +139,7 @@ throw new IOException(Invalid WARP packet type for body); if (this.packet.pointerthis.packet.size) -return((int)this.packet.buffer[this.packet.pointer++]); +return((int)this.packet.buffer[this.packet.pointer++] 0xFF); this.packet.reset(); this.packet.setType(Constants.TYPE_CBK_READ); -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: mod_webapp and other connectors status...
GOMEZ Henri [EMAIL PROTECTED] writes: BTW: How did we get TOMCAT 4.1 and 4.0.2 ? Which is the head ? I believe that 4.1-dev is the tip of the HEAD, 4.0.2-dev is the tip of tomcat_40_branch. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: mod_webapp and other connectors status...
Craig R. McClanahan [EMAIL PROTECTED] writes: I believe that 4.1-dev is the tip of the HEAD, 4.0.2-dev is the tip of tomcat_40_branch. That's correct. Currently I'm only building nightly distributions from the HEAD branch, but it would be fairly straightforward to do nightly builds of the 4.0 branch as well. I'm currently using nightlies from the HEAD and am running into some SAX parser class loading issues (ClassCastExceptions due to classes coming from different loaders). Have their been any significant changes to class loading in HEAD which are not in tomcat_40_branch? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: tomcat 4.0.2 and jakarta-tomcat-connectors
Kevin Seguin [EMAIL PROTECTED] writes: there was a thread a couple weeks ago regarding what to do with j-t-c and tomcat 4.0.2. i believe it was decided that the 4.0.2 release would contain the same jars from j-t-c (tomcat-ajp.jar, tomcat-util.jar) as 4.0.1 did. well, i just did some quick tests with the 4.0.2-b1 dist and the head of j-t-c, and all seemed to be in working order. so, i think it might be a good idea to try to release the latest stuff from j-t-c with 4.0.2 for a couple of reasons: *) if we release and tag j-t-c along with jakarta-tomcat-4.0, i think it'll be easier to do maintenance, fix bugs, etc.. i'm not only talking about the java code in j-t-c, but also the c code. *) there have been some bug fixes in j-t-c since 4.0.1 -- these may as well be released :) The mod_webapp connector code is definitely in a freshening. :) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: tomcat 4.0.2 and jakarta-tomcat-connectors
Daniel Rall [EMAIL PROTECTED] writes: The mod_webapp connector code is definitely in a freshening. :) ^ need of Specifically, it would be great to get in Pier's fix to the file upload problem (if not the rest of the changes as well). Index: catalina/src/share/org/apache/catalina/connector/warp/WarpRequest.java === RCS file: /home/cvs/jakarta-tomcat-connectors/webapp/java/WarpRequest.java,v retrieving revision 1.9 retrieving revision 1.10 diff -u -r1.9 -r1.10 --- catalina/src/share/org/apache/catalina/connector/warp/WarpRequest.java 2001/07/25 22:32:05 1.9 +++ catalina/src/share/org/apache/catalina/connector/warp/WarpRequest.java 2001/10/19 +19:18:28 1.10 @@ -139,7 +139,7 @@ throw new IOException(Invalid WARP packet type for body); if (this.packet.pointerthis.packet.size) -return((int)this.packet.buffer[this.packet.pointer++]); +return(((int)this.packet.buffer[this.packet.pointer++])0x0ff); this.packet.reset(); this.packet.setType(Constants.TYPE_CBK_READ); -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core StandardContextValve.java StandardHostValve.java
Remy, I built today's HEAD and verified your fix (much cleaner than
what was previously proposed).
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5368
Please backport this bug fix to the 4.0.x branch.
Thanks, Dan
[EMAIL PROTECTED] writes:
remm02/01/04 08:33:40
Modified:catalina/src/share/org/apache/catalina/core
StandardContextValve.java StandardHostValve.java
Log:
- Fix for 5368: mark the session as accessed before going in the Context
pipeline (before, the session was marked as non-new only in the last useable
valve of the pipeline). This is not the proposed patch for this bug. Please
confirm
it does fix the problem.
Revision ChangesPath
1.15 +6 -17
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/StandardContextValve.java
Index: StandardContextValve.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/StandardContextValve.java,v
retrieving revision 1.14
retrieving revision 1.15
diff -u -r1.14 -r1.15
--- StandardContextValve.java 5 Oct 2001 22:03:53 - 1.14
+++ StandardContextValve.java 4 Jan 2002 16:33:40 - 1.15
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/StandardContextValve.java,v
1.14 2001/10/05 22:03:53 remm Exp $
- * $Revision: 1.14 $
- * $Date: 2001/10/05 22:03:53 $
+ * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/StandardContextValve.java,v
1.15 2002/01/04 16:33:40 remm Exp $
+ * $Revision: 1.15 $
+ * $Date: 2002/01/04 16:33:40 $
*
*
*
@@ -74,10 +74,9 @@
import org.apache.naming.ContextBindings;
import org.apache.naming.resources.DirContextURLStreamHandler;
import org.apache.catalina.Container;
-import org.apache.catalina.Manager;
+import org.apache.catalina.Context;
import org.apache.catalina.Request;
import org.apache.catalina.Response;
-import org.apache.catalina.Session;
import org.apache.catalina.ValveContext;
import org.apache.catalina.Wrapper;
import org.apache.catalina.util.RequestUtil;
@@ -93,7 +92,7 @@
* when processing HTTP requests.
*
* @author Craig R. McClanahan
- * @version $Revision: 1.14 $ $Date: 2001/10/05 22:03:53 $
+ * @version $Revision: 1.15 $ $Date: 2002/01/04 16:33:40 $
*/
final class StandardContextValve
@@ -169,17 +168,7 @@
return;
}
-// Update the session last access time for our session (if any)
-StandardContext context = (StandardContext) getContainer();
-String sessionId = hreq.getRequestedSessionId();
-if (sessionId != null) {
-Manager manager = context.getManager();
-if (manager != null) {
-Session session = manager.findSession(sessionId);
-if ((session != null) session.isValid())
-session.access();
-}
-}
+Context context = (Context) getContainer();
// Select the Wrapper to be used for this Request
Wrapper wrapper = null;
1.6 +21 -5
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/StandardHostValve.java
Index: StandardHostValve.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/StandardHostValve.java,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- StandardHostValve.java 22 Jul 2001 20:25:08 - 1.5
+++ StandardHostValve.java 4 Jan 2002 16:33:40 - 1.6
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/StandardHostValve.java,v
1.5 2001/07/22 20:25:08 pier Exp $
- * $Revision: 1.5 $
- * $Date: 2001/07/22 20:25:08 $
+ * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/StandardHostValve.java,v
1.6 2002/01/04 16:33:40 remm Exp $
+ * $Revision: 1.6 $
+ * $Date: 2002/01/04 16:33:40 $
*
*
*
@@ -71,8 +71,10 @@
import javax.servlet.http.HttpServletResponse;
import org.apache.catalina.Container;
import org.apache.catalina.Context;
+import org.apache.catalina.Manager;
import org.apache.catalina.Request;
import org.apache.catalina.Response;
+import org.apache.catalina.Session;
import org.apache.catalina.ValveContext;
import org.apache.catalina.util.StringManager;
import org.apache.catalina.valves.ValveBase;
Re: [PATCH][4.0] remove spurious casts in ApplicationFilterChain
+1, old code was redundant. Java should find the right method to call
based on object--not reference--type.
Christopher K. St. John [EMAIL PROTECTED] writes:
The fall off the end of the chain code in
ApplicationFilterChain.internalDoFilter checks if the
passed in request and response are HttpServletRequest/
Response objects. Based on the test, it casts the
objects and invokes servlet.service(). However, since
the servlet member has a static type of javax.servlet.Servlet,
the exact same method is called in both cases. The code
operates correctly (since the non-http version of the
service() method eventually invokes the correct version
of service()), but the test and cast are redundant and
confusing. The following patch removes them:
Index: ApplicationFilterChain.java
===
RCS file:
/home/cvspublic/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/ApplicationFilterChain.java,v
retrieving revision 1.11
diff -u -r1.11 ApplicationFilterChain.java
--- ApplicationFilterChain.java 2001/10/11 23:30:58 1.11
+++ ApplicationFilterChain.java 2001/12/28 19:06:24
@@ -242,13 +242,7 @@
try {
support.fireInstanceEvent(InstanceEvent.BEFORE_SERVICE_EVENT,
servlet, request, response);
-if ((request instanceof HttpServletRequest)
-(response instanceof HttpServletResponse)) {
-servlet.service((HttpServletRequest) request,
-(HttpServletResponse) response);
-} else {
-servlet.service(request, response);
-}
+servlet.service(request, response);
support.fireInstanceEvent(InstanceEvent.AFTER_SERVICE_EVENT,
servlet, request, response);
} catch (IOException e) {
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Jk2: error handling and method signatures
This is reminiscent of what the Subersion folks are doing for error handling. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Jk2: error handling and method signatures
[EMAIL PROTECTED] writes: On Thu, 13 Dec 2001, Daniel Rall wrote: This is reminiscent of what the Subersion folks are doing for error handling. Could you give a URL ? If it was already invented... ( I was thinking to use a subset of what's 'invented' in jni, I believe there are quite a few people who'll feel 'familiar' with this and it's natural for java programmers ). Here's what Subversion does for error progation: http://svn.collab.net/repos/svn/trunk/subversion/include/svn_error.h Could propogate that in the suggested env. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Refactor of o-a-j-JspC
David Hoag [EMAIL PROTECTED] writes: How do I contribute these changes? http://jakarta.apache.org/site/source.html -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Jk2: error handling and method signatures
[EMAIL PROTECTED] writes: On Thu, 13 Dec 2001, Daniel Rall wrote: http://svn.collab.net/repos/svn/trunk/subversion/include/svn_error.h It seems they are using a struct that is returned instead of a simple int, as status. It does solve the problem of propagating more info. In practice, I've found casual error information to be extremely useful. It seems that I'm not the only one, as it's been incorporated into the JDK for version 1.4. Catalina, Commons Util, Ant, and other project employ this technique with good results. It's just another tool to consider (which might not apply equally well to all situations). -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Jk2: error handling and method signatures
I meant causal, not casual. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Emulating JServ's session.topleveldomain with Catalina
Craig R. McClanahan [EMAIL PROTECTED] writes: I'd certainly be interested in a patch to allow pattern matching in the host mapper, as long as the code was smart about using direct string compares when no patterns are specified (to avoid slowing down all requests by regexp processing). Note that Tomcat already loads jakarta-regexp for use in the RemoteAddrValve and RemoteHostValve filters. If you need regexp patterns, that would be a convenient choice because no additional dependencies would be created. Hi Craig. Did you have a chance to look over my initial rev of the patch to add pattern matching to the host mapper? Is the Alias change acceptable? (Sorry if you already responded -- I've been off-line. My ATT@Home service was temporarily down after Excite declared chapter 11.) If so, would you comment on how to get the Digester/Modeler to properly configure an Alias object? I could use some guidance with that. If not, how would you suggest I proceed to make such a patch acceptable (i.e. what other constraints should I take into account)? Thanks, Dan -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Off topic:Old jserv source question
On Tue, 4 Dec 2001, Antony Bowesman wrote: Thanks Daniel, I noticed your name in the comments, we are just trying to remove the jserv dependancy to use tomcat 4. Most of the work is done, just have to get customers to move... Just recently made the switch from JServ to Catalina myself. Things could've gone smoothly, but we were fairly coupled to JServ, so I'm still trying to tie up loose ends (which is involving patching Catalina). Best of luck to you. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Off topic:Old jserv source question
On Mon, 3 Dec 2001, Antony Bowesman wrote: Craig R. McClanahan wrote: Apache JServ sources are still available via anonymous CVS from the Jakarta web site (see http://jakarta.apache.org/site/cvsindex.html). The CVS module name is java-jserv. Brilliant! Thanks Craig. containsHeader() was broken in jserv 1.1.2. Noticed by Michael Stack, I submitted a fix for this issue a while back (committed by Jon Stevens). JServ development is dead, but if you're in a situation where you must use JServ, I recommend using CVS HEAD. Daniel -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat/src/share/org/apache/jasper/compilerCharDataGenerator.java JspParseEventListener.java MappedCharDataGenerator.java
On 4 Dec 2001 [EMAIL PROTECTED] wrote: larryi 01/12/03 18:21:04 Modified:src/share/org/apache/jasper/compiler CharDataGenerator.java JspParseEventListener.java MappedCharDataGenerator.java Log: Eliminate hard coded '\n' line separators. Revision ChangesPath 1.5 +5 -4 jakarta-tomcat/src/share/org/apache/jasper/compiler/CharDataGenerator.java Index: CharDataGenerator.java === RCS file: /home/cvs/jakarta-tomcat/src/share/org/apache/jasper/compiler/CharDataGenerator.java,v retrieving revision 1.4 retrieving revision 1.5 diff -u -r1.4 -r1.5 --- CharDataGenerator.java 2001/07/03 16:27:12 1.4 +++ CharDataGenerator.java 2001/12/04 02:21:04 1.5 @@ -1,7 +1,7 @@ /* - * $Header: /home/cvs/jakarta-tomcat/src/share/org/apache/jasper/compiler/CharDataGenerator.java,v 1.4 2001/07/03 16:27:12 hgomez Exp $ - * $Revision: 1.4 $ - * $Date: 2001/07/03 16:27:12 $ + * $Header: /home/cvs/jakarta-tomcat/src/share/org/apache/jasper/compiler/CharDataGenerator.java,v 1.5 2001/12/04 02:21:04 larryi Exp $ + * $Revision: 1.5 $ + * $Date: 2001/12/04 02:21:04 $ * * * @@ -127,7 +127,8 @@ } } writer.print(sb.toString()); - writer.print(\);\n); + writer.print(\);); + writer.println(); } Why not just call println() instead of print() then println()? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Emulating JServ's session.topleveldomain with Catalina
Craig R. McClanahan [EMAIL PROTECTED] writes: I'd certainly be interested in a patch to allow pattern matching in the host mapper, as long as the code was smart about using direct string compares when no patterns are specified (to avoid slowing down all requests by regexp processing). Since . is a regex character, there is no way to automatically infer whether an alias string is a pattern or a literal, meaning that a way to communicate to the Mapper implementations which aliases are patterns is required. Because of this, I don't believe that it is possible to avoid minor API/server.xml additions/changes. The cleanest implementation route I see for addition of pattern matching is to solidfy an existing data type (Alias) as an interface accompanied by standard implementation. The suggested syntax would be as follows: Host ... Alias isPattern=true.*domain.com/Alias !-- An Alias element is not a pattern by default -- Aliaswww.otherdomain.com/Alias /Host I haven't previously used Digester, Modeler, or BeanUtils, so am unsure of what changes to make to mbeans-descriptors.xml and HostRuleSet.java (I definitely screwed up the declaration for Alias). Note that Tomcat already loads jakarta-regexp for use in the RemoteAddrValve and RemoteHostValve filters. If you need regexp patterns, that would be a convenient choice because no additional dependencies would be created. Gotcha -- I used RE.match() in the style of RequestFilterValve. Here's an incomplete version of the modifications to solicit feedback, and make sure I'm following the desired path: Index: src/share/org/apache/catalina/Alias.java === RCS file: Alias.java diff -N Alias.java --- /dev/null Fri Nov 30 17:57:31 2001 +++ Alias.java Fri Nov 30 17:59:22 2001 @@ -0,0 +1,128 @@ +/* + * $Header: +/home/cvspublic/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/Host.java,v +1.7 2001/10/22 04:48:56 remm Exp $ + * $Revision: 1.7 $ + * $Date: 2001/10/22 04:48:56 $ + * + * + * + * The Apache Software License, Version 1.1 + * + * Copyright (c) 1999 The Apache Software Foundation. All rights + * reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * + * 1. Redistributions of source code must retain the above copyright + *notice, this list of conditions and the following disclaimer. + * + * 2. Redistributions in binary form must reproduce the above copyright + *notice, this list of conditions and the following disclaimer in + *the documentation and/or other materials provided with the + *distribution. + * + * 3. The end-user documentation included with the redistribution, if + *any, must include the following acknowlegement: + * This product includes software developed by the + *Apache Software Foundation (http://www.apache.org/). + *Alternately, this acknowlegement may appear in the software itself, + *if and wherever such third-party acknowlegements normally appear. + * + * 4. The names The Jakarta Project, Tomcat, and Apache Software + *Foundation must not be used to endorse or promote products derived + *from this software without prior written permission. For written + *permission, please contact [EMAIL PROTECTED] + * + * 5. Products derived from this software may not be called Apache + *nor may Apache appear in their names without prior written + *permission of the Apache Group. + * + * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED + * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES + * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE + * DISCLAIMED. IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR + * ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, + * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT + * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF + * USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND + * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, + * OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT + * OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + * + * + * This software consists of voluntary contributions made by many + * individuals on behalf of the Apache Software Foundation. For more + * information on the Apache Software Foundation, please see + * http://www.apache.org/. + * + */ + + +package org.apache.catalina; + + +import javax.servlet.ServletContext; + +/** + * An codeAlias/code defines a mapping from a host name used in a + * request to a bHost/b object from server.xml. + * + * @author a href=mailto:[EMAIL PROTECTED];Daniel Rall
Re: Emulating JServ's session.topleveldomain with Catalina
Craig R. McClanahan [EMAIL PROTECTED] writes: On Sat, 24 Nov 2001, Daniel Rall wrote: Craig R. McClanahan [EMAIL PROTECTED] writes: On Wed, 21 Nov 2001, Daniel Rall wrote: Using Tomcat 4.0.1, is there any way to emulate JServ's session.topleveldomain context configuration? # Set the domain= header that gets sent with the cookie. This is # entirely optional # Default: null # this is needed when we vhost to avoid multiple login session.topleveldomain=.foo.com I would like all requests to the set of virtual hosts represented by the glob *.foo.com to share the same session ID. Unfortunately, implementing this functionality would violate the Servlet spec's requirements about sessions being scoped to a single ServletContext. Even if you were willing to do this, you're going to run into lots of technical problems due to the fact that each webapp is loaded by it's own classloader -- trying to access a session attribute loaded from a different webapp will throw ClassNotFoundException errors at you. I wasn't clear enough in my original query -- I don't want to scope one session to multiple contexts, but to a single context accessed by multiple host names which correspond to the same physical host (the default host in server.xml). This is still illegal based on the same rule - each virtual host has its own set of webapps. Tomcat 4 is built on this assumption. Using the distinction you mention below, the host name used in the request is merely a host alias (rather than a virtual host). One way to work around it (with Tomcat 4) would be to use the host aliasing capability, where you say that a set of host names really refer to the same virtual host. This was primarily intended to deal with cases like company.com and www.company.com resolving to the same app, but could actually be used for more than that. Check out the Alias directive (in server.xml). Thanks for suggesting a work around, Craig (I'm only concerned with Tomcat 4 ATM =). Reviewing the implementation of the Alias directive in StandardEngineMapper and FastEngineMapper, it appears that only literal mappings are provided for (i.e. wildcards are not allowed supported). I have a requirement of supporting addition of host alias mappings at run-time, but neither see a way to reload server.xml nor have much of a desire to modify it from servlet code. Is there another way to handle this situation? If not, would the Catalina developers be amenable to a patch which adds wildcard capability to the host alias feature? Would regex or file system-style globs be preferred (I lean towards the latter)? If this is undesirable, what are my options (i.e. can I configure my Engine entry in server.xml to use a custom Mapper)? Thanks, Daniel -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[PATCH][Catalina] Improved flexiblity of pipeline WRT session cookies
First, this patch fixes a problem with Catalina's sendHeaders()
implementation which prevents post-service() Valve code from having a
chance to cleanly set or modify the JSESSIONID cookie used to store
Catalina's session identifier.
Second, this removes some of the remnants of a cut and paste birth of
WarpResponse from jakarta-tomcat-4.0 (note that there is another copy
of this file in the jakarta-turbine-connectors repository).
This patch is against CVS HEAD of jakarta-tomcat-4.0 from the evening
of Wed, Nov 28.
On a parallel note, neither JServ (in JServServletManager) nor
Catalina (in two HttpProcessor impls and WarpRequestHandler) use the
equalsIgnoreCase that section 4.1 of RFC 2109 to me suggests use when
rooting through the cookies parsed from the request stream (when
initially seeking the session identifier). Even though a constant is
used internally in Catalina, I would assume that Catalina would accept
cookies formatted as per the RFC (perhaps common usage suggests
otherwise?).
Index: HttpResponseBase.java
===
RCS file:
/home/cvspublic/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/HttpResponseBase.java,v
retrieving revision 1.40
diff -u -u -r1.40 HttpResponseBase.java
--- HttpResponseBase.java 2001/11/13 19:39:27 1.40
+++ HttpResponseBase.java 2001/11/28 09:15:20
@@ -614,25 +614,7 @@
}
// Add the session ID cookie if necessary
-HttpServletRequest hreq = (HttpServletRequest) request.getRequest();
-HttpSession session = hreq.getSession(false);
-
-if ((session != null) session.isNew() (getContext() != null)
- getContext().getCookies()) {
-Cookie cookie = new Cookie(Globals.SESSION_COOKIE_NAME,
- session.getId());
-cookie.setMaxAge(-1);
-String contextPath = null;
-if (context != null)
-contextPath = context.getPath();
-if ((contextPath != null) (contextPath.length() 0))
-cookie.setPath(contextPath);
-else
-cookie.setPath(/);
-if (hreq.isSecure())
-cookie.setSecure(true);
-addCookie(cookie);
-}
+addAbsentSessionCookie((HttpServletRequest) request.getRequest());
// Send all specified cookies (if any)
synchronized (cookies) {
@@ -657,6 +639,63 @@
// The response is now committed
committed = true;
+
+}
+
+
+/**
+ * Adds the session ID cookie if a new session exists for
+ * codehreq/code, the Context is configured to pass the
+ * session ID via cookies (the default), and the session cookie
+ * doesn't already exist in the request (could've been inserted by
+ * a meddling Valve during Pipeline execution).
+ *
+ * @param hreq The HttpServletRequest whose session to service.
+ */
+protected void addAbsentSessionCookie(HttpServletRequest hreq) {
+
+HttpSession session = hreq.getSession(false);
+
+if ((session != null) session.isNew() (getContext() != null)
+ getContext().getCookies() !containsSessionCookie()) {
+Cookie cookie = new Cookie(Globals.SESSION_COOKIE_NAME,
+ session.getId());
+cookie.setMaxAge(-1);
+String contextPath = null;
+if (context != null)
+contextPath = context.getPath();
+if ((contextPath != null) (contextPath.length() 0))
+cookie.setPath(contextPath);
+else
+cookie.setPath(/);
+if (hreq.isSecure())
+cookie.setSecure(true);
+addCookie(cookie);
+}
+
+}
+
+
+/**
+ * Returns whether this HttpResponse contains the session
+ * identifier cookie. Though section 4.1 of RFC 2109 suggests
+ * that cookie name comparisons are case-insentive, a
+ * case-sensitive comparison is performed for consistancy with the
+ * rest of Catalina's implementation.
+ *
+ * @return Whether this response has a session identifier cookie
+ * set.
+ */
+protected boolean containsSessionCookie() {
+
+Cookie c;
+for (Iterator i = cookies.iterator(); i.hasNext(); ) {
+c = (Cookie) i.next();
+if (Globals.SESSION_COOKIE_NAME.equals(c.getName())) {
+return true;
+}
+}
+return false;
}
Index: WarpResponse.java
===
RCS file:
/home/cvspublic/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/warp/WarpResponse.java,v
retrieving revision 1.7
diff -u -u -r1.7 WarpResponse.java
--- WarpResponse.java 2001/08/09 20:08:58 1.7
+++ WarpResponse.java 2001/11/28 09:15:00
@@ -201,25 +201,7 @@
}
Re: Emulating JServ's session.topleveldomain with Catalina
Daniel Rall [EMAIL PROTECTED] writes: [This was originally sent to tomcat-user, but is probably better discussed on tomcat-dev.] Why does the Valve implementation at the bottom of this message never print out any session cookies? To answer myself (as addressed by my recent patch), because the session cookie is added via the sendHeaders() method of HttpResponseBase AFTER the Pipeline finishes processing. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-4.0/catalina/src/bin setenv.sh catalina.sh tool-wrapper.sh
Jon Stevens [EMAIL PROTECTED] writes: on 11/27/01 2:34 PM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Index: setenv.sh === #!/bin/sh # - # setenv.sh - File to hold all user customizable environment variables # # $Id: setenv.sh,v 1.1 2001/11/27 22:34:25 patrickl Exp $ # - # To permanently set your JAVA_HOME environment variable, uncomment and # customize the following line with the absolute path to your JAVA_HOME # JAVA_HOME=/usr/java -1 I don't think that this file should exist in CVS if it is a user file. The problem being that if a user upgrades to a new version of Catalina, then they will risk overwriting this file. Instead, it should be documented that the file needs to be created in order to be used. I agree with Jon. Files editted by the user should never be in CVS -- clear documentation is key here. Other than that, I like the change! -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Emulating JServ's session.topleveldomain with Catalina
[This was originally sent to tomcat-user, but is probably better discussed on tomcat-dev.] Why does the Valve implementation at the bottom of this message never print out any session cookies? Craig R. McClanahan [EMAIL PROTECTED] writes: On Wed, 21 Nov 2001, Daniel Rall wrote: Using Tomcat 4.0.1, is there any way to emulate JServ's session.topleveldomain context configuration? # Set the domain= header that gets sent with the cookie. This is # entirely optional # Default: null # this is needed when we vhost to avoid multiple login session.topleveldomain=.foo.com I would like all requests to the set of virtual hosts represented by the glob *.foo.com to share the same session ID. Unfortunately, implementing this functionality would violate the Servlet spec's requirements about sessions being scoped to a single ServletContext. Even if you were willing to do this, you're going to run into lots of technical problems due to the fact that each webapp is loaded by it's own classloader -- trying to access a session attribute loaded from a different webapp will throw ClassNotFoundException errors at you. I wasn't clear enough in my original query -- I don't want to scope one session to multiple contexts, but to a single context accessed by multiple host names which correspond to the same physical host (the default host in server.xml). So, if the DNS for both baz.foo.com and bar.foo.com resolves to the same IP, a request to /myapp for baz.foo.com will create a session with a JSESSIONID cookie domain of .foo.com, allowing requests to bar.foo.com (or any other DNS mappings) to /myapp servlet context to share the same HttpSession. I took a stab at implementing this as a Valve, with some success. My original thought was to groom the JSESSIONID cookies in the request and response -- however, they never seem to show up (i.e. I never have any cookies available from HttpRequest::getCookies() or HttpResponse::getCookies()). Perhaps I just attached the Valve at the wrong spot (in the config file)? Because I haven't been able to access the JSESSIONID cookies, I end up getting a two cookies written on the original request, one for the first host requested (baz.foo.com), and another from my Valve for .foo.com (also from the first request). I get the desired result from this (unfortunately with an extra cookie set for baz.foo.com), but am curious why I those JSESSIONID cookies haven't turned up. Any comments would be appreciated. Dan /* * $Header: $ * $Revision: $ * $Date: $ * * * * The Apache Software License, Version 1.1 * * Copyright (c) 1999 The Apache Software Foundation. All rights * reserved. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * * 1. Redistributions of source code must retain the above copyright *notice, this list of conditions and the following disclaimer. * * 2. Redistributions in binary form must reproduce the above copyright *notice, this list of conditions and the following disclaimer in *the documentation and/or other materials provided with the *distribution. * * 3. The end-user documentation included with the redistribution, if *any, must include the following acknowlegement: * This product includes software developed by the *Apache Software Foundation (http://www.apache.org/). *Alternately, this acknowlegement may appear in the software itself, *if and wherever such third-party acknowlegements normally appear. * * 4. The names The Jakarta Project, Tomcat, and Apache Software *Foundation must not be used to endorse or promote products derived *from this software without prior written permission. For written *permission, please contact [EMAIL PROTECTED] * * 5. Products derived from this software may not be called Apache *nor may Apache appear in their names without prior written *permission of the Apache Group. * * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE * DISCLAIMED. IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR * ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF * USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, * OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT * OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE. * * * This software consists of voluntary contributions made
Re: Triple initialization of Catalina/mod_webapp
Recently found a symlink which would explain this unexpected behavior. :-\ Daniel Rall [EMAIL PROTECTED] writes: This is a followup to a message I posted to the user list which describes some undesirable behavior of Tomcat 4.0.1 (unrelated to use of mod_webapp). My application's build process currently generates the deployment descriptor for my web app from many files which contain snippets of the final web.xml. After generation of the deployment descriptor (as $SRC_DIR/conf/web.xml), it is then copied into the appropriate sub directory of my webapps tree. At this point, I should be able to launch Catalina (using a $CATALINA_BASE of $SRC_DIR/site and $CATALINA_HOME of /usr/share/tomcat4). However, the file $SRC_DIR/conf/web.xml is read in before $CATALINA_BASE/webapps/myapp/WEB-INF/web.xml. Since both these files contain the same content, my web app is initialized multiple times. That the conf/web.xml relative to my current working directory is used at all at seems like undesirable behavior to me. If a conf/web.xml file is going to be looked for at all, at the very least it could be looked for relative to $CATALINA_BASE. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: 4.0.1 ClassLoader breaks singletons on webapp reload.
[EMAIL PROTECTED] (Kevin A. Burton) writes: Jon Stevens [EMAIL PROTECTED] writes: Sadly, I have to admit that the Turbine Services framework shutdown code is currently broken and has been for some time now...it needs to be re-written... Are you saying that the theory is broken or just Turbine's impl? Turbine's impl...no one has made use of shutdown in a while. It'll be fixed soon, though. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Triple initialization of Catalina/mod_webapp
This is a followup to a message I posted to the user list which describes some undesirable behavior of Tomcat 4.0.1 (unrelated to use of mod_webapp). My application's build process currently generates the deployment descriptor for my web app from many files which contain snippets of the final web.xml. After generation of the deployment descriptor (as $SRC_DIR/conf/web.xml), it is then copied into the appropriate sub directory of my webapps tree. At this point, I should be able to launch Catalina (using a $CATALINA_BASE of $SRC_DIR/site and $CATALINA_HOME of /usr/share/tomcat4). However, the file $SRC_DIR/conf/web.xml is read in before $CATALINA_BASE/webapps/myapp/WEB-INF/web.xml. Since both these files contain the same content, my web app is initialized multiple times. That the conf/web.xml relative to my current working directory is used at all at seems like undesirable behavior to me. If a conf/web.xml file is going to be looked for at all, at the very least it could be looked for relative to $CATALINA_BASE. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[PATCH] [Catalina] StandardContext::addParameter() JavaDoc
addParameter() instance method actually throws an IllegalArgumentException if a duplicate name is used. I came across this while attempting to setup Catalina behind Apache + mod_webapp -- AFAICT, my setup is currently giving me the joy of multiple initializations of Catalina. Index: StandardContext.java === RCS file: /home/cvspublic/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/StandardContext.java,v retrieving revision 1.87 diff -u -u -r1.87 StandardContext.java --- StandardContext.java2001/11/10 00:01:54 1.87 +++ StandardContext.java2001/11/17 02:18:47 @@ -1506,8 +1506,7 @@ /** - * Add a new context initialization parameter, replacing any existing - * value for the specified name. + * Add a new context initialization parameter. * * @param name Name of the new parameter * @param value Value of the new parameter -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
