Re: TC33b1 Context path behavior: Is this a bug or by design?
Hi Randall, I believe the behavior is correct - you have 2 contexts with the same docbase ( one defined in a config file, one automatically ). They are completely independent of each other ( you can look into work and you'll see one work dir for each ). If you write a simple test servlet, you'll see the 2 contexts have different ServletContext objects, and behave like 2 separate webapps. The same thing would happen if you copy or do a (symbolic)link between 2 dirs in /webapps, or you add 2 app-XXX.xml files pointing to the same docbase. BTW, thanks for investigating this :-) Costin On Sat, 4 Aug 2001, Randall Parker wrote: I'm seeing two different paths as being accepted for pages in the same war file. I'm wondering if the behavior I'm seeing is by design or a bug. I installed the struts-documentation.war file in webapps and restarted Tomcat 3.3 b1. As expected I was able to access such URLs as: http://127.0.0.1:8080/struts-documentation/index.html and http://127.0.0.1:8080/struts-documentation/api/org/apache/struts/taglib/bean/package- summary.html#package_description So the leading /struts-documentation mapped to the corresponding war file. Then I decided to add to the /conf dir the following: apps-struts-documentation.xml ?xml version=1.0 encoding=ISO-8859-1? webapps !-- Setting special properties for /examples ( as an example of overriding the defaults ) -- Context path=/strutsdoc docBase=webapps/struts-documentation debug=0 reloadable=true SimpleRealm filename=conf/users/strutsdoc-users.xml / LogSetter name=strutsdoc_tc.log path=logs/strutsdoc.log / LogSetter name=strutsdoc_servlet_log path=logs/servlet_strutsdoc.log servletLogger=true/ /Context /webapps After stopping and restarting Tomcat I was then able (as expected) to access pages using the shorter /strutsdoc leading path. For instance: http://127.0.0.1:8080/strutsdoc/index.html However, when I went back and tried the original: http://127.0.0.1:8080/struts-documentation/index.html that still worked. I even did Refresh and fired up a different brand of browser that hadn't previously visited either page to make sure the browser wasn't just loading the older URL from cache. Well, I'd expect that when one defined the Context path in the xml file that that path would _replace_ the default path named after the war file. Is that not the case? Is this normal behavior or incorrect behavior?
Re: TC33b1 Context path behavior: Is this a bug or by design?
On Sun, 5 Aug 2001 00:30:03 -0700 (PDT), [EMAIL PROTECTED] wrote: Hi Randall, I believe the behavior is correct - you have 2 contexts with the same docbase ( one defined in a config file, one automatically ). So is there a way to turn off the creation of that automatic context? I'd also like a way to say If a Context tag is defined then do not also generate an automatic context. I'd also like a way to say Only generate contexts for those which are explicitly defined with a Context tag. Is either of these possible now? They are completely independent of each other ( you can look into work and you'll see one work dir for each ). If you write a simple test servlet, you'll see the 2 contexts have different ServletContext objects, and behave like 2 separate webapps. Its certainly neat that this is possible. One could customize the same WAR to run in two contexts with two different sets of properties. The same thing would happen if you copy or do a (symbolic)link between 2 dirs in /webapps, or you add 2 app-XXX.xml files pointing to the same docbase. BTW, thanks for investigating this :-) You're quite welcome. I really like the apps-XXX.xml feature btw. Costin
Re: TC33b1 Context path behavior: Is this a bug or by design?
So is there a way to turn off the creation of that automatic context? I'd also like a way to say If a Context tag is defined then do not also generate an automatic context. The name of the path attribute and the name of the dir in /webapps have to be the same. You can rename one or the other. I'd also like a way to say Only generate contexts for those which are explicitly defined with a Context tag. There's a way to completely disable automatic Context creation. IIRC, it's by removing one of the elements in server.xml. - r
Re: TC33b1 Context path behavior: Is this a bug or by design?
On Sun, 5 Aug 2001, Randall Parker wrote: So is there a way to turn off the creation of that automatic context? Remove AutoDeploy src=webapps / to disable all automatic contexts ( from webapps ). Move the app out of webapps. AutoDeploy takes all the files from the specified dir and add them. I'd also like a way to say If a Context tag is defined then do not also generate an automatic context. If you place the app under webapps, AutoDeploy will add it. But webapps/ is just a dir, designed to simplify configuration - you can place your webapp anywhere. ( another usefull feature of AutoDeploy is that it can set the virtual host for all the apps loaded from a dir - AutoDeply src=/myHost host=my.host.com / ) You are free to add other modules doing what you want - it's quite easy to write a module that will remove all the modules that are duplicated, or anything like that. All the configuration happens via configuration modules that add other modules, add contexts (manually - via ContextXmlReader config=apps.xml or automatically ). You can play as much as you want at this stage - remove, replace, add modules/contexts/properties. After the context manager moves to STATE_CONFIG, things are different, it means tomcat is in a stable state ( i.e. the config is stable ). I'd also like a way to say Only generate contexts for those which are explicitly defined with a Context tag. Not sure what you mean by that, but if you're not happy with AutoDeploy behavior, it's quite easy to replace it with YourAutoDeploy. The set of modules that is included with 3.3 is supposed to just implement the servlet container, without too much complications or featurs. Is either of these possible now? Anything is possible now ( and if it's not, you can file a bug !). Just write a module that configures it the way you want it ( for most stuff, it should be as easy as writing an ant task, maybe just a bit more difficult ). Tomcat provides the basic container with as-simple-as-possible configurabilty, the behavior of AutoDeploy and other modules is just what we believed is simple enough ( but not simpler :-). It doesn't mean tomcat is limited to only what AutoDeploy can do ( or we don't want other features), it's just that we want manageable code to maintain and the place for features is in modules. You're quite welcome. I really like the apps-XXX.xml feature btw. Then contribute a small html describing what you discover. Costin
Re: TC33b1 Context path behavior: Is this a bug or by design?
Costin, If one does define a context in apps-.xml can one sent context-param tags in it that are then accessible as part of that ServletContext? More generally, can anything from webl.xml be put in server.xml inside a Context tag's scope? See for example the context-param below where this file is an apps-.xml that is in the conf directory. Is this legal and will it work when one does a getInitParameter in a doPost below? If one does this and it works then a further question: Suppose the web.xml defines the pdf-out-path and then the server.xml/apps-.xml redefines it again for the same context. Will the latter value _replace_ the former value? ?xml version=1.0 encoding=ISO-8859-1? webapps !-- Setting special properties for /examples ( as an example of overriding the defaults ) -- Context path=/strutsdoc docBase=webapps/struts-documentation debug=0 reloadable=true SimpleRealm filename=conf/users/strutsdoc-users.xml / LogSetter name=strutsdoc_tc.log path=logs/strutsdoc.log / LogSetter name=strutsdoc_servlet_log path=logs/servlet_strutsdoc.log servletLogger=true/ context-param param-namepdf-out-path/param-name param-value\reports\graphics\/param-value /context-param /Context Then in a doPost do: String PdfOutPath = this.getServletContext().getInitParameter(pdf-out-path); javax.servlet.ServletConfig.getServletContext(); javax.servlet.jsp.PageContext On Sun, 5 Aug 2001 00:30:03 -0700 (PDT), [EMAIL PROTECTED] wrote: I believe the behavior is correct - you have 2 contexts with the same docbase ( one defined in a config file, one automatically ). They are completely independent of each other ( you can look into work and you'll see one work dir for each ). If you write a simple test servlet, you'll see the 2 contexts have different ServletContext objects, and behave like 2 separate webapps.
Re: TC33b1 Context path behavior: Is this a bug or by design?
On Sun, 5 Aug 2001, Randall Parker wrote: Costin, If one does define a context in apps-.xml can one sent context-param tags in it that are then accessible as part of that ServletContext? More generally, can anything from webl.xml be put in server.xml inside a Context tag's scope? No, and that's premeditated :-) Keep in mind server.xml ( and apps.xml ) is an ad-hoc format, and just one of the ways to configure tomcat ( there is absolutely nothing in tomcat that cares about server.xml except a small module that happens to read it). Tomcat doesn't care how is configured - it can be ServerXmlReader module, or it can read the modules from a properties file or from an LDAP server. Web.xml on the other side is a clearly specified format. If something can be done in web.xml, it should be done there. But of course, that's just how proper jakarta-tomcat works - i.e. how the current set of modules operate. This is what we provide and support - for anything fancy you can write your own modules, the way you want them. It would be trivial to enhance ContextXmlReader - the module that deals with Context definitions - to support what you want ( but I'm -1 on adding any such enhancement to tomcat3.3 - we already have more than we need, the 'proper' tomcat should have 1/2 of the modules it has today ). If one does this and it works then a further question: Suppose the web.xml defines the pdf-out-path and then the server.xml/apps-.xml redefines it again for the same context. Will the latter value _replace_ the former value? It's up to you and your module. Again, IMHO whatever can be specified in web.xml should be specified there. Tomcat3.3 ( and 3.2 ) already removes another odity - the default web.xml that generated so many bugs and mess in 3.1. If you want your application to be portable, make sure it has all the information it needs in its web.xml - anything you put in apps-XXX.xml, server.xml, etc is specific to tomcat3.x and will be lost if you move your app to a different container. Costin
cvs commit: jakarta-tomcat-connectors/webapp/java WarpRequestHandler.java
pier01/08/05 11:33:42
Modified:webapp/java WarpRequestHandler.java
Log:
Compliancy patch:
- Now values of URL-encoded sessions are correctly handled (Thanks to
Eryq [EMAIL PROTECTED] for reporting this bug.
- Locales are set correctly in the request object, parsing the
Accept-Languages header as done in the HTTP/1.1 connector.
- The query string is now set to null if there are no query parameters.
With this patch, mod_webapp using WARP runs all WatchDog compliancy tests
just fine.
Revision ChangesPath
1.15 +165 -15 jakarta-tomcat-connectors/webapp/java/WarpRequestHandler.java
Index: WarpRequestHandler.java
===
RCS file: /home/cvs/jakarta-tomcat-connectors/webapp/java/WarpRequestHandler.java,v
retrieving revision 1.14
retrieving revision 1.15
diff -u -r1.14 -r1.15
--- WarpRequestHandler.java 2001/07/25 22:32:05 1.14
+++ WarpRequestHandler.java 2001/08/05 18:33:42 1.15
@@ -59,7 +59,12 @@
import java.io.File;
import java.io.IOException;
import java.net.URL;
+import java.util.*;
+import java.util.Locale;
+import java.util.TreeMap;
+
import javax.servlet.http.Cookie;
+import javax.servlet.http.HttpServletRequest;
import org.apache.catalina.Container;
import org.apache.catalina.Context;
@@ -68,9 +73,13 @@
import org.apache.catalina.Host;
import org.apache.catalina.core.StandardHost;
import org.apache.catalina.util.RequestUtil;
+import org.apache.catalina.util.StringParser;
public class WarpRequestHandler {
+private StringParser parser = new StringParser();
+private static final String match=;+Globals.SESSION_PARAMETER_NAME+=;
+
/* */
/* Constructor */
/* */
@@ -118,8 +127,9 @@
response.setPacket(packet);
request.setMethod(meth);
-request.setRequestURI(ruri);
-request.setQueryString(args);
+this.processUri(logger,request,ruri);
+if (args.length()0) request.setQueryString(args);
+else request.setQueryString(null);
request.setProtocol(prot);
request.setConnection(connection);
Context ctx=connector.applicationContext(id);
@@ -163,10 +173,7 @@
case Constants.TYPE_REQ_HEADER: {
String hnam=packet.readString();
String hval=packet.readString();
-if (Constants.DEBUG)
-logger.debug(Request header +hnam+: +hval);
-request.addHeader(hnam,hval);
-this.processHeader(request,hnam,hval);
+this.processHeader(logger,request,hnam,hval);
break;
}
@@ -220,9 +227,43 @@
}
}
}
+}
+
+private void processUri(WarpLogger logger, WarpRequest req, String uri) {
+
+// Parse any requested session ID out of the request URI
+int semicolon = uri.indexOf(match);
+if (semicolon = 0) {
+String rest = uri.substring(semicolon + match.length());
+int semicolon2 = rest.indexOf(';');
+if (semicolon2 = 0) {
+req.setRequestedSessionId(rest.substring(0, semicolon2));
+rest = rest.substring(semicolon2);
+} else {
+req.setRequestedSessionId(rest);
+rest = ;
+}
+req.setRequestedSessionURL(true);
+uri = uri.substring(0, semicolon) + rest;
+if (Constants.DEBUG) {
+logger.log(Requested URL session id is +
+((HttpServletRequest) req.getRequest())
+.getRequestedSessionId());
+}
+} else {
+req.setRequestedSessionId(null);
+req.setRequestedSessionURL(false);
+}
+
+req.setRequestURI(uri);
}
-
-private void processHeader(WarpRequest req, String name, String value) {
+
+private void processHeader(WarpLogger logger, WarpRequest req,
+ String name, String value) {
+
+if (Constants.DEBUG)
+logger.debug(Request header +name+: +value);
+
if (cookie.equalsIgnoreCase(name)) {
Cookie cookies[] = RequestUtil.parseCookieHeader(value);
for (int i = 0; i cookies.length; i++) {
@@ -235,17 +276,126 @@
(cookies[i].getValue());
RE: Servllet
Time to go back to the old good java tutorial, I guess. Ever heard of autoloading and threads? And, was it _that_ important to post it six times or my mailbox went crazy? Greetings, deacon Marcus p.s. NTFG p.s.2 Is there a way to moderate newcomers? p.s.3 How often you get method/class not found errors ? -Original Message- From: Usul Chandra [mailto:[EMAIL PROTECTED]] Sent: Sunday, August 05, 2001 5:31 AM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Servllet How can a servlet be automatically be invoked by itself, say peroidically? Usul __ Do You Yahoo!? Make international calls for as low as $.04/minute with Yahoo! Messenger http://phonecard.yahoo.com/
Re: TC33b1 Context path behavior: Is this a bug or by design?
On Sun, 5 Aug 2001 10:48:31 -0700 (PDT), [EMAIL PROTECTED] wrote: More generally, can anything from webl.xml be put in server.xml inside a Context tag's scope? No, and that's premeditated :-) Okay. Keep in mind server.xml ( and apps.xml ) is an ad-hoc format, and just one of the ways to configure tomcat ( there is absolutely nothing in tomcat that cares about server.xml except a small module that happens to read it). Tomcat doesn't care how is configured - it can be ServerXmlReader module, or it can read the modules from a properties file or from an LDAP server. Well, suppose one wanted to use something else instead of or in addition to the ServerXmlReader module. Would one need to hack Tomcat to do it? Web.xml on the other side is a clearly specified format. If something can be done in web.xml, it should be done there. Well, here's the problem I see with web.xml: It comes as part of a war file. Okay, well and good. But it seems to me that the servlets in a given war have some context that is war-specifc but in some cases the context is going to be site-specific (eg the name of a printer to use or a file path to use to access data or the name of a JDBC database source and so on). Well, shouldn't a war contain nothing that is site-specific? I mean, isn't it the whole idea that a war is like a redistributable application? So how to provide context to servlets when that context is site-specific? This seems like a really basic need. But of course, that's just how proper jakarta-tomcat works - i.e. how the current set of modules operate. This is what we provide and support - for anything fancy you can write your own modules, the way you want them. It would be trivial to enhance ContextXmlReader - the module that deals with Context definitions - to support what you want ( but I'm -1 on adding any such enhancement to tomcat3.3 - we already have more than we need, the 'proper' tomcat should have 1/2 of the modules it has today ). I can appreciate that. Then I need another solution to my problem. What do you think of these ideas: 1) Create a directory that is relative to webapps that is not under webapps where settings for a given war can go in some settings file. so %TOMCAT_HOME%/webapps/reportsystem would be matched %TOMCAT_HOME%/settings/reportsystem/ Then in the web.xml one could do: context-param param-namereportsettings/param-name param-value../../settings/reportsystem/rptconfig.xml/param-value /context-param and after installing the war one would create a relevant file: %TOMCAT_HOME%/settings/reportsystem/rptconfig.xml In the initializatoin of a servlet one would then need to do: String ReportSettingsXMLPath = this.getServletContext().getInitParameter(reportsettings); Then have the servlet's init method open and parse the xml file at ReportSettingsXMLPath in order to get this out of it: context-param param-namepdf-out-path/param-name param-valuereports/graphics/param-value /context-param The idea is to have the web.xml point to a relative path that is outside of the subdirectory where the war gets expanded. This location should be a location that wouldn't get overwritten by war file overwrites. The first time a war file is 2) Similar to the previous item but instead is there some way for the web.xml to have an include to go get a file that is relative to it htat would insert the original xml snippet so that the originally desired info could be put into the servlet context? I don't know XML well enough but I don't think file includes can be done like this without XSLT and I'm guessing that isn't used in reading web.xml. The class that reads in web.xml would need to be able to recognize and deal with a relative include path to some file pathed relative to web.xml or to the curr dir that the web.xml reader uses. Then that relative pathed file would have this in it: context-param param-namepdf-out-path/param-name param-valuereports/graphics/param-value /context-param Basically, I need some way tell a web.xml where to find resources that isn't an absolute path since it has to be portable to different operating systems and sites. If one does this and it works then a further question: Suppose the web.xml defines the pdf-out-path and then the server.xml/apps-.xml redefines it again for the same context. Will the latter value _replace_ the former value? It's up to you and your module. Again, IMHO whatever can be specified in web.xml should be specified there. Tomcat3.3 ( and 3.2 ) already removes another odity - the default web.xml that generated so many bugs and mess in 3.1. If you want your application to be portable, make sure it has all the information it needs in its web.xml - anything you put in apps-XXX.xml, server.xml, etc is specific to tomcat3.x and will be lost if you move your app to a different container.
cvs commit: jakarta-tomcat-connectors/webapp/java WarpPacket.java WarpResponse.java
pier01/08/05 12:59:48
Modified:webapp/java WarpPacket.java WarpResponse.java
Log:
Fix for BUG # 2990: Large files are not handled correctly.
Revision ChangesPath
1.15 +1 -1 jakarta-tomcat-connectors/webapp/java/WarpPacket.java
Index: WarpPacket.java
===
RCS file: /home/cvs/jakarta-tomcat-connectors/webapp/java/WarpPacket.java,v
retrieving revision 1.14
retrieving revision 1.15
diff -u -r1.14 -r1.15
--- WarpPacket.java 2001/07/25 22:32:05 1.14
+++ WarpPacket.java 2001/08/05 19:59:48 1.15
@@ -70,7 +70,7 @@
/* Type of this packet */
private int type=-1;
/* Maximum value for a 16 bit unsigned value (0x0 +1) */
-private static final int MAX_LENGTH=65536;
+private static final int MAX_LENGTH=65535;
/**
* Construct a new WarpPacket instance.
1.8 +1 -0 jakarta-tomcat-connectors/webapp/java/WarpResponse.java
Index: WarpResponse.java
===
RCS file: /home/cvs/jakarta-tomcat-connectors/webapp/java/WarpResponse.java,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- WarpResponse.java 2001/07/25 01:30:47 1.7
+++ WarpResponse.java 2001/08/05 19:59:48 1.8
@@ -276,6 +276,7 @@
public void write(int b)
throws IOException {
if (closed) throw new IOException(Stream closed);
+if (packet.size=packet.buffer.length) this.flush();
packet.buffer[packet.size++]=(byte)b;
}
In process worker and IIS
I've been trying out the 'in process' worker with TC3.2.3 and IIS. When using a servlet that does a reasonable amount in its init() method, IIS complains that the service did not respond in a timely fashion! This obviously isn't a bug as such, but shouldn't the webapps be initialised in a different thread so that TC can return without M$ throwing a wobbly! Dave. [EMAIL PROTECTED] _ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp
TC3.3b1: can't find action servlet on start-up
See the SAXEception. I'm not sure if this is a bug in Tomcat or from something not configured properly or maybe its normal behavior. Since I have only example war files from Tomcat and Struts loaded I don't even know where this action servlet is supposed to come from. I thought I would report it here just in case it is relevant to TC3.3 b1's code: Tomcat: setAttribute home=J:\webdev\tomcat33b1 2001-08-05 14:50:04 - ContextXmlReader: Context config=$TOMCAT_HOME\conf\apps-127.0.0.1.xml 2001-08-05 14:50:04 - ContextXmlReader: Context config=$TOMCAT_HOME\conf\apps-admin.xml 2001-08-05 14:50:04 - ContextXmlReader: Context config=$TOMCAT_HOME\conf\apps-examples.xml 2001-08-05 14:50:04 - ContextXmlReader: Context config=$TOMCAT_HOME\conf\apps-strutsdoc.xml 2001-08-05 14:50:05 - AutoWebApp: Already loaded: DEFAULT:/admin 2001-08-05 14:50:05 - AutoWebApp: Already loaded: DEFAULT:/examples 2001-08-05 14:50:05 - AutoWebApp: Auto-Adding DEFAULT:/perfproj1 2001-08-05 14:50:05 - AutoWebApp: Auto-Adding DEFAULT:/rgptry1 2001-08-05 14:50:05 - AutoWebApp: Auto-Adding DEFAULT:/rgptry2 2001-08-05 14:50:05 - AutoWebApp: Auto-Adding DEFAULT:/rgptry3 2001-08-05 14:50:05 - AutoWebApp: Auto-Adding DEFAULT:/ 2001-08-05 14:50:05 - AutoWebApp: Auto-Adding DEFAULT:/struts-documentation 2001-08-05 14:50:05 - ContextManager: Adding DEFAULT:/admin 2001-08-05 14:50:05 - ContextManager: Adding DEFAULT:/examples 2001-08-05 14:50:05 - ContextManager: Adding DEFAULT:/strutsdoc 2001-08-05 14:50:05 - ContextManager: Adding DEFAULT:/perfproj1 2001-08-05 14:50:05 - ContextManager: Adding DEFAULT:/rgptry1 2001-08-05 14:50:05 - ContextManager: Adding DEFAULT:/rgptry2 2001-08-05 14:50:05 - ContextManager: Adding DEFAULT:/rgptry3 2001-08-05 14:50:05 - ContextManager: Adding DEFAULT:/ROOT 2001-08-05 14:50:05 - ContextManager: Adding DEFAULT:/struts-documentation 2001-08-05 14:50:05 - LoadOnStartupInterceptor: cannot load servlet name: action - java.lang.No ClassDefFoundError: org/xml/sax/SAXException at java.lang.Class.newInstance0(Native Method) at java.lang.Class.newInstance(Class.java:237) at org.apache.tomcat.facade.ServletHandler.getServlet(ServletHandler.java:348) at org.apache.tomcat.facade.ServletHandler.preInit(ServletHandler.java:402) at org.apache.tomcat.facade.ServletHandler.init(ServletHandler.java:227) at org.apache.tomcat.facade.LoadOnStartupInterceptor.contextInit(LoadOnStartupIntercept or.java:136) at org.apache.tomcat.core.Context.init(Context.java:501) at org.apache.tomcat.core.ContextManager.init(ContextManager.java:588) at org.apache.tomcat.startup.EmbededTomcat.initContextManager(EmbededTomcat.java:310) at org.apache.tomcat.startup.Tomcat.startTomcat(Tomcat.java:176) at org.apache.tomcat.startup.Tomcat.execute(Tomcat.java:120) at java.lang.reflect.Method.invoke(Native Method) at org.apache.tomcat.util.IntrospectionUtils.execute(IntrospectionUtils.java:87) at org.apache.tomcat.startup.Main.execute(Main.java:305) at org.apache.tomcat.startup.Main.main(Main.java:191) 2001-08-05 14:50:05 - ContextManager: Init time 1132 2001-08-05 14:50:05 - Http10Interceptor: Starting on 8080 2001-08-05 14:50:05 - Ajp12Interceptor: Starting on 8007 2001-08-05 14:50:05 - Ajp13Interceptor: Starting on 8009 2001-08-05 14:50:05 - ContextManager: Startup 50
Command-Line Utility Attached - Feedback Requested
Attached is my generic utility which will allow for command-line interaction with the user during Tomcat startup. I've named it Feliner because I'm so witty. Even better, I've decided to name my proposed centralized External Resource Security module LitterBox, since it will be where Tomcat does its private business. The inside joke, which probably only makes sense to my fellow cat owners, is that LitterBox will use the 'Liner. :-) Any feedback on this utility is welcome. If you think it's an abomination and that I've lost my mind, *definitely* let me know ;-) It's important to note that this is *not* an actual module/interceptor. It's a generic utility class which provides a safe API for accessing the command line. The idea is that specific modules/interceptors can call out to this utility to get user input, then do whatever specific processing they required. There are three ways you can give me some feedback on this utility. 1) Open the hood and check the source. Let me know if you see any problems, anything which could be implemented better, etc. 2) The Javadocs are also included in the zip file. This class is *extrememly* well-documented, so by looking over the Javadocs you will get a complete picture of the design. If you don't have the inclination or time to look over the full source, you can glance over the general design and tell me what you think. 3) The main() method contains a pretty comprehensive test suite. Since I'm dealing directly with the OS, I would really like to have it tested on a wide variety of environments. If you have an environment which has not already been tested, it would be great if you could simply compile it, run it, and let me know if the test suite was a success or failure. The API doc for the main() method explains how to run the test suite. I have personally tested it on both Windoze 98 and Redhat 7.1, both under the 1.3 JDK. It should be JDK 1.1 compatible, but unfortunately I don't currently have a 1.1 installation to test it on. If you have any combination of OS/JDK that hasn't yet been tested, please give it a shot and let me know. Regards, Christopher feliner-0.1.zip
cvs commit: jakarta-tomcat-connectors/webapp/apache-1.3 Makefile.in
pier01/08/05 16:59:34 Modified:webapp/apache-1.3 Makefile.in Log: Fix for bug # 2991 thanks to Fred Romelfanger [EMAIL PROTECTED]. Revision ChangesPath 1.6 +3 -2 jakarta-tomcat-connectors/webapp/apache-1.3/Makefile.in Index: Makefile.in === RCS file: /home/cvs/jakarta-tomcat-connectors/webapp/apache-1.3/Makefile.in,v retrieving revision 1.5 retrieving revision 1.6 diff -u -r1.5 -r1.6 --- Makefile.in 2001/07/13 02:08:01 1.5 +++ Makefile.in 2001/08/05 23:59:34 1.6 @@ -56,7 +56,7 @@ # = # # @author Pier Fumagalli mailto:[EMAIL PROTECTED] -# @version $Id: Makefile.in,v 1.5 2001/07/13 02:08:01 pier Exp $ +# @version $Id: Makefile.in,v 1.6 2001/08/05 23:59:34 pier Exp $ include @SRCDIR@/Makedefs @@ -88,7 +88,8 @@ @echo Linking Apache 1.3 WebApp Module @$(SHELL) $(LIBTOOL) $(LTFLAGS) --mode=link \ $(APXS_LD_SHLIB) $(APXS_LDFLAGS_SHLIB) \ - mod_webapp.lo ../lib/libwebapp.la $(LIBTOOL_LIBS) -o mod_webapp.so + mod_webapp.lo ../lib/libwebapp.la $(LIBTOOL_LIBS) $(EXTRA_LIBS) \ + -o mod_webapp.so clean: @echo Removing *.o *.lo $(MODULE) .libs
Re: TC3.3b1: can't find action servlet on start-up
Tomcat3.3 doesn't expose any sax parser ( or any of it's internal objects ) to the application. The app should be self-contained. One solution is to copy jaxp.jar and crimson.jar from lib/container ( the directory used for implementation-private libs ) into lib/apps ( all files here will be shared and visible in all implementations ). A better solution that will automate this is in progress, but will not be included in tc3.3 ( it's just a separate module ). Costin On Sun, 5 Aug 2001, Randall Parker wrote: See the SAXEception. I'm not sure if this is a bug in Tomcat or from something not configured properly or maybe its normal behavior. Since I have only example war files from Tomcat and Struts loaded I don't even know where this action servlet is supposed to come from. I thought I would report it here just in case it is relevant to TC3.3 b1's code: Tomcat: setAttribute home=J:\webdev\tomcat33b1 2001-08-05 14:50:04 - ContextXmlReader: Context config=$TOMCAT_HOME\conf\apps-127.0.0.1.xml 2001-08-05 14:50:04 - ContextXmlReader: Context config=$TOMCAT_HOME\conf\apps-admin.xml 2001-08-05 14:50:04 - ContextXmlReader: Context config=$TOMCAT_HOME\conf\apps-examples.xml 2001-08-05 14:50:04 - ContextXmlReader: Context config=$TOMCAT_HOME\conf\apps-strutsdoc.xml 2001-08-05 14:50:05 - AutoWebApp: Already loaded: DEFAULT:/admin 2001-08-05 14:50:05 - AutoWebApp: Already loaded: DEFAULT:/examples 2001-08-05 14:50:05 - AutoWebApp: Auto-Adding DEFAULT:/perfproj1 2001-08-05 14:50:05 - AutoWebApp: Auto-Adding DEFAULT:/rgptry1 2001-08-05 14:50:05 - AutoWebApp: Auto-Adding DEFAULT:/rgptry2 2001-08-05 14:50:05 - AutoWebApp: Auto-Adding DEFAULT:/rgptry3 2001-08-05 14:50:05 - AutoWebApp: Auto-Adding DEFAULT:/ 2001-08-05 14:50:05 - AutoWebApp: Auto-Adding DEFAULT:/struts-documentation 2001-08-05 14:50:05 - ContextManager: Adding DEFAULT:/admin 2001-08-05 14:50:05 - ContextManager: Adding DEFAULT:/examples 2001-08-05 14:50:05 - ContextManager: Adding DEFAULT:/strutsdoc 2001-08-05 14:50:05 - ContextManager: Adding DEFAULT:/perfproj1 2001-08-05 14:50:05 - ContextManager: Adding DEFAULT:/rgptry1 2001-08-05 14:50:05 - ContextManager: Adding DEFAULT:/rgptry2 2001-08-05 14:50:05 - ContextManager: Adding DEFAULT:/rgptry3 2001-08-05 14:50:05 - ContextManager: Adding DEFAULT:/ROOT 2001-08-05 14:50:05 - ContextManager: Adding DEFAULT:/struts-documentation 2001-08-05 14:50:05 - LoadOnStartupInterceptor: cannot load servlet name: action - java.lang.No ClassDefFoundError: org/xml/sax/SAXException at java.lang.Class.newInstance0(Native Method) at java.lang.Class.newInstance(Class.java:237) at org.apache.tomcat.facade.ServletHandler.getServlet(ServletHandler.java:348) at org.apache.tomcat.facade.ServletHandler.preInit(ServletHandler.java:402) at org.apache.tomcat.facade.ServletHandler.init(ServletHandler.java:227) at org.apache.tomcat.facade.LoadOnStartupInterceptor.contextInit(LoadOnStartupIntercept or.java:136) at org.apache.tomcat.core.Context.init(Context.java:501) at org.apache.tomcat.core.ContextManager.init(ContextManager.java:588) at org.apache.tomcat.startup.EmbededTomcat.initContextManager(EmbededTomcat.java:310) at org.apache.tomcat.startup.Tomcat.startTomcat(Tomcat.java:176) at org.apache.tomcat.startup.Tomcat.execute(Tomcat.java:120) at java.lang.reflect.Method.invoke(Native Method) at org.apache.tomcat.util.IntrospectionUtils.execute(IntrospectionUtils.java:87) at org.apache.tomcat.startup.Main.execute(Main.java:305) at org.apache.tomcat.startup.Main.main(Main.java:191) 2001-08-05 14:50:05 - ContextManager: Init time 1132 2001-08-05 14:50:05 - Http10Interceptor: Starting on 8080 2001-08-05 14:50:05 - Ajp12Interceptor: Starting on 8007 2001-08-05 14:50:05 - Ajp13Interceptor: Starting on 8009 2001-08-05 14:50:05 - ContextManager: Startup 50
cvs commit: jakarta-tomcat-connectors/webapp/java WarpPacket.java
pier01/08/05 19:17:39
Modified:webapp/java WarpPacket.java
Log:
Correctly handles transmission of NULL strings over WARP.
Revision ChangesPath
1.16 +1 -0 jakarta-tomcat-connectors/webapp/java/WarpPacket.java
Index: WarpPacket.java
===
RCS file: /home/cvs/jakarta-tomcat-connectors/webapp/java/WarpPacket.java,v
retrieving revision 1.15
retrieving revision 1.16
diff -u -r1.15 -r1.16
--- WarpPacket.java 2001/08/05 19:59:48 1.15
+++ WarpPacket.java 2001/08/06 02:17:39 1.16
@@ -158,6 +158,7 @@
*/
public void writeString(String string) {
try {
+if (string==null) string=;
byte temp[]=string.getBytes(UTF-8);
if ((this.size+temp.length+2)MAX_LENGTH)
throw new ArrayIndexOutOfBoundsException(Too much data);
cvs commit: jakarta-tomcat-connectors/webapp/include wa.h
pier01/08/05 19:18:48
Modified:webapp/include wa.h
Log:
Include apr_file_info.h to start processing shared contexts between
Apache and Tomcat over WARP.
Revision ChangesPath
1.11 +2 -1 jakarta-tomcat-connectors/webapp/include/wa.h
Index: wa.h
===
RCS file: /home/cvs/jakarta-tomcat-connectors/webapp/include/wa.h,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -r1.10 -r1.11
--- wa.h 2001/07/15 08:44:11 1.10
+++ wa.h 2001/08/06 02:18:48 1.11
@@ -57,7 +57,7 @@
/**
* @author Pier Fumagalli mailto:[EMAIL PROTECTED]
- * @version $Id: wa.h,v 1.10 2001/07/15 08:44:11 pier Exp $
+ * @version $Id: wa.h,v 1.11 2001/08/06 02:18:48 pier Exp $
*/
#ifndef _WA_H_
#define _WA_H_
@@ -81,6 +81,7 @@
#include apr_tables.h
#include apr_time.h
#include apr_network_io.h
+#include apr_file_info.h
/* WebApp Library type definitions. */
typedef enum {
cvs commit: jakarta-tomcat-connectors/webapp/lib pr_warp_config.c
pier01/08/05 19:20:10
Modified:webapp/lib pr_warp_config.c
Log:
Analyze wether the Web-Application exists locally and can be accessed by
Apache. This will come handy when contexts will be shared between Apache
and Tomcat.
Revision ChangesPath
1.5 +23 -4 jakarta-tomcat-connectors/webapp/lib/pr_warp_config.c
Index: pr_warp_config.c
===
RCS file: /home/cvs/jakarta-tomcat-connectors/webapp/lib/pr_warp_config.c,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- pr_warp_config.c 2001/07/19 23:51:48 1.4
+++ pr_warp_config.c 2001/08/06 02:20:10 1.5
@@ -54,7 +54,7 @@
* *
* = */
-/* @version $Id: pr_warp_config.c,v 1.4 2001/07/19 23:51:48 pier Exp $ */
+/* @version $Id: pr_warp_config.c,v 1.5 2001/08/06 02:20:10 pier Exp $ */
#include pr_warp.h
wa_boolean c_check(wa_connection *conn, warp_packet *pack) {
@@ -155,10 +155,29 @@
p_read_int(pack,(int *)appl-conf);
p_read_string(pack,temp);
appl-lpth=apr_pstrdup(wa_pool,temp);
-appl-depl=wa_true;
-wa_debug(WA_MARK,Application \%s\ deployed with root=%s id=%d,
-appl-name,appl-lpth,appl-conf);
+
+/* Check if this web-application is local or not by checking if its
+ WEB-INF directory can be opened. */
+if (appl-lpth!=NULL) {
+apr_dir_t *dir=NULL;
+char *webinf=apr_pstrcat(wa_pool,appl-lpth,/WEB-INF,NULL);
+if (apr_dir_open(dir,webinf,wa_pool)==APR_SUCCESS) {
+if (dir!=NULL) apr_dir_close(dir);
+else appl-lpth=NULL;
+} else {
+appl-lpth=NULL;
+}
+}
+if (appl-lpth==NULL) {
+wa_debug(WA_MARK,Application \%s\ deployed with id=%d (%s),
+appl-name,appl-conf,remote);
+} else {
+wa_debug(WA_MARK,Application \%s\ deployed with id=%d (%s),
+appl-name,appl-conf,appl-lpth);
+}
+
+appl-depl=wa_true;
elem=elem-next;
}
cvs commit: jakarta-tomcat-connectors/webapp/java Constants.java.in
pier01/08/05 19:45:05 Modified:webapp/java Constants.java.in Log: Modified packet signatures for request handling request (in line with request handling stages) Revision ChangesPath 1.7 +2 -2 jakarta-tomcat-connectors/webapp/java/Constants.java.in Index: Constants.java.in === RCS file: /home/cvs/jakarta-tomcat-connectors/webapp/java/Constants.java.in,v retrieving revision 1.6 retrieving revision 1.7 diff -u -r1.6 -r1.7 --- Constants.java.in 2001/07/26 15:18:15 1.6 +++ Constants.java.in 2001/08/06 02:45:05 1.7 @@ -139,7 +139,7 @@ * br * No payload:br */ -public static final int TYPE_CONF_DONE=0x04; +public static final int TYPE_CONF_DONE=0x0e; /** * CONF_PROCEED: Server issues this message in response to a CONF_DONE @@ -147,7 +147,7 @@ * br * No payload:br */ -public static final int TYPE_CONF_PROCEED=0x05; +public static final int TYPE_CONF_PROCEED=0x0f; public static final int TYPE_REQ_INIT=0x10; public static final int TYPE_REQ_CONTENT=0x11;
cvs commit: jakarta-tomcat-connectors/webapp/lib .cvsignore pr_warp.h
pier01/08/05 19:47:21
Modified:webapp Makefile.in configure.in
webapp/lib .cvsignore pr_warp.h
Log:
Now WARP packet type signatures are held only in the Java source, and
are copied over to the C part during the execution of configure
Revision ChangesPath
1.14 +2 -1 jakarta-tomcat-connectors/webapp/Makefile.in
Index: Makefile.in
===
RCS file: /home/cvs/jakarta-tomcat-connectors/webapp/Makefile.in,v
retrieving revision 1.13
retrieving revision 1.14
diff -u -r1.13 -r1.14
--- Makefile.in 2001/07/18 18:45:05 1.13
+++ Makefile.in 2001/08/06 02:47:21 1.14
@@ -56,7 +56,7 @@
# = #
# @author Pier Fumagalli mailto:[EMAIL PROTECTED]
-# @version $Id: Makefile.in,v 1.13 2001/07/18 18:45:05 pier Exp $
+# @version $Id: Makefile.in,v 1.14 2001/08/06 02:47:21 pier Exp $
include @SRCDIR@/Makedefs
@@ -64,6 +64,7 @@
APRDIR = @APRDIR@
CFGS = @CONFIGFILES@ \
+ ./lib/pr_warp_defs.h \
config.cache \
config.log \
config.status
1.19 +14 -1 jakarta-tomcat-connectors/webapp/configure.in
Index: configure.in
===
RCS file: /home/cvs/jakarta-tomcat-connectors/webapp/configure.in,v
retrieving revision 1.18
retrieving revision 1.19
diff -u -r1.18 -r1.19
--- configure.in 2001/07/18 18:31:29 1.18
+++ configure.in 2001/08/06 02:47:21 1.19
@@ -58,7 +58,7 @@
dnl --
dnl Author Pier Fumagalli mailto:[EMAIL PROTECTED]
dnl Author Jon S. Stevens mailto:[EMAIL PROTECTED]
-dnl Version $Id: configure.in,v 1.18 2001/07/18 18:31:29 pier Exp $
+dnl Version $Id: configure.in,v 1.19 2001/08/06 02:47:21 pier Exp $
dnl --
dnl --
@@ -68,6 +68,9 @@
AC_PATH_PROG(test,test,${PATH})
AC_PATH_PROG(true,true,${PATH})
AC_PATH_PROG(echo,echo,${PATH})
+ AC_PATH_PROG(grep,grep,${PATH})
+ AC_PATH_PROG(cat,cat,${PATH})
+ AC_PATH_PROG(sed,sed,${PATH})
AC_PATH_PROG(rm,rm,${PATH})
])
@@ -307,9 +310,19 @@
TGTDIRS=${TGTDIRS} ${SRCDIR}/lib
AC_SUBST(TGTDIRS)
+dnl --
+dnl Output files
+dnl --
CONFIGFILES=./Makedefs ./Makefile ./lib/Makefile ./java/Makefile
CONFIGFILES=$CONFIGFILES ./java/Constants.java ${makefile}
AC_SUBST(CONFIGFILES)
+
+AC_MSG_RESULT([creating ./lib/pr_warp_defs.h])
+${cat} ./java/Constants.java.in | \
+ ${grep} TYPE_ | \
+ ${sed} s/public\ static\ final\ int/\#define/g | \
+ ${sed} s/\=/\ /g | \
+ ${sed} s/\;/\ /g ./lib/pr_warp_defs.h
AC_OUTPUT(${CONFIGFILES})
1.6 +1 -0 jakarta-tomcat-connectors/webapp/lib/.cvsignore
Index: .cvsignore
===
RCS file: /home/cvs/jakarta-tomcat-connectors/webapp/lib/.cvsignore,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- .cvsignore2001/07/18 19:08:35 1.5
+++ .cvsignore2001/08/06 02:47:21 1.6
@@ -9,6 +9,7 @@
pr_warp.o
pr_warp_config.lo
pr_warp_config.o
+pr_warp_defs.h
pr_warp_network.lo
pr_warp_network.o
pr_warp_packet.lo
1.7 +2 -32 jakarta-tomcat-connectors/webapp/lib/pr_warp.h
Index: pr_warp.h
===
RCS file: /home/cvs/jakarta-tomcat-connectors/webapp/lib/pr_warp.h,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- pr_warp.h 2001/07/25 22:32:05 1.6
+++ pr_warp.h 2001/08/06 02:47:21 1.7
@@ -54,7 +54,7 @@
* *
* = */
-/* @version $Id: pr_warp.h,v 1.6 2001/07/25 22:32:05 pier Exp $ */
+/* @version $Id: pr_warp.h,v 1.7 2001/08/06 02:47:21 pier Exp $ */
#ifndef _PR_WARP_H_
#define _PR_WARP_H_
@@ -104,37 +104,7 @@
/* WARP definitions */
#define VERS_MAJOR 0
#define VERS_MINOR 9
-
-#define TYPE_INVALID -1
-#define TYPE_ERROR0x00
-#define TYPE_DISCONNECT 0xfe
-#define TYPE_FATAL0xff
-
-#define TYPE_CONF_WELCOME 0x01
-#define TYPE_CONF_DEPLOY 0x02
-#define TYPE_CONF_APPLIC 0x03
-#define TYPE_CONF_DONE0x04
-#define TYPE_CONF_PROCEED 0x05
-
-#define TYPE_REQ_INIT 0x10
-#define TYPE_REQ_CONTENT 0x11
-#define
cvs commit: jakarta-tomcat-connectors/webapp/lib pr_info.c wa_request.c
pier01/08/05 20:07:06 Modified:webapp/lib pr_info.c wa_request.c Log: Avoid dumping request information back to the client in case of errors and when looking the WebApp information page if we were not compiled with DEBUG defined. Revision ChangesPath 1.4 +3 -1 jakarta-tomcat-connectors/webapp/lib/pr_info.c Index: pr_info.c === RCS file: /home/cvs/jakarta-tomcat-connectors/webapp/lib/pr_info.c,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- pr_info.c 2001/07/19 04:20:42 1.3 +++ pr_info.c 2001/08/06 03:07:06 1.4 @@ -55,7 +55,7 @@ * * * = */ -/* @version $Id: pr_info.c,v 1.3 2001/07/19 04:20:42 pier Exp $ */ +/* @version $Id: pr_info.c,v 1.4 2001/08/06 03:07:06 pier Exp $ */ #include wa.h /* Counter for requests */ @@ -297,6 +297,7 @@ wa_rprintf(r, /table\n); wa_rprintf(r, br\n); +#ifdef DEBUG /* See the request */ wa_rprintf(r, table width=\80%%\ border=\1\ cellspacing=\0\\n); wa_rprintf(r, tr\n); @@ -425,6 +426,7 @@ } wa_rprintf(r, /table\n); +#endif /* ifdef DEBUG */ wa_rprintf(r, br\n); wa_rprintf(r, /div\n); 1.15 +3 -1 jakarta-tomcat-connectors/webapp/lib/wa_request.c Index: wa_request.c === RCS file: /home/cvs/jakarta-tomcat-connectors/webapp/lib/wa_request.c,v retrieving revision 1.14 retrieving revision 1.15 diff -u -r1.14 -r1.15 --- wa_request.c 2001/07/19 23:50:47 1.14 +++ wa_request.c 2001/08/06 03:07:06 1.15 @@ -55,7 +55,7 @@ * * * = */ -/* @version $Id: wa_request.c,v 1.14 2001/07/19 23:50:47 pier Exp $ */ +/* @version $Id: wa_request.c,v 1.15 2001/08/06 03:07:06 pier Exp $ */ #include wa.h /* Allocate a new request structure. */ @@ -162,6 +162,7 @@ wa_rprintf(r, hr\n); wa_rprintf(r, %s\n,buf); wa_rprintf(r, hr\n); +#ifdef DEBUG wa_rprintf(r, dl\n); wa_rprintf(r, dtYour Request:/dt\n); wa_rprintf(r, ddServer Host: \%s\/dd\n,r-serv-host); @@ -182,6 +183,7 @@ apr_table_do(headers,r,r-hdrs,NULL); wa_rprintf(r, /dl\n); wa_rprintf(r, hr\n); +#endif /* ifdef DEBUG */ wa_rprintf(r, /body\n); wa_rprintf(r,/html\n); wa_rflush(r);
Fwd: Re: Command-Line Utility Attached - Feedback Requested
FYI. As Dmitri astutely points out below, there should be a finally in the
try/catch block in promptForInput method. What actually happened is that I
accidentally sent a working copy of the source file rather than
the official copy I had meant to send (that's what I get for leaving multiple
copies lying around :-).
The copy you _should_ have gotten is laid out pretty much as he describes.
Basically, anywhere where I am storing IOException to a variable, it is
actually being thrown (plus the finally block he describes). Other than that,
and a few semantic changes to some code comments, the files are the same, so I
won't bother resending it.
Thanks to Dmitri for the catch!
- Forwarded message from Dmitri Colebatch [EMAIL PROTECTED] -
Date: Mon, 06 Aug 2001 11:43:05 +1000
From: Dmitri Colebatch [EMAIL PROTECTED]
Reply-To: Dmitri Colebatch [EMAIL PROTECTED]
Subject: Re: Command-Line Utility Attached - Feedback Requested
To: Christopher Cain [EMAIL PROTECTED]
Hi,
I'm guessing you're probably after feedback on how it would fit into the
tomcat archtecture, but I thought I'd offer this anyway. I changed the
promptForInput to this:
[snip]
try {
System.out.println();
System.out.println(promptMessage);
br = new BufferedReader(new InputStreamReader(System.in));
userInput = br.readLine();
// Perform basic validation
if (userInput.length() MAX_INPUT_LENGTH)
throw new IOException(Input limit exceeded);
else if (isMalformed(userInput))
throw new IOException(Input contains an illegal
character);
return userInput;
} catch (IOException ioe) {
// nb. this will be chained into a feline specific exception
throw ioe;
}
finally {
// Restore stdout to its original stream
restoreStdOut(initialStdOut);
}
}
The way you had it you were missing the situation where an undeclared
throwable was thrown, you weren't restoring your stdout.
btw - love the naming (o:
cheesr
dim
GTest in watchdog fails with Apache...
There's a small bug in the WatchDog GTest. Simply what it does is that it's
sending TWO Content-Length headers in the same request, and Apache correctly
translates those two headers into one single headers like:
Content-Length: firstval, secondval
This small patch fixes the problem, but Tomcat 4.0 SHOULD throw back an
error to the client too (IMO).
Pier
Index: src/tools/org/apache/tomcat/task/GTest.java
===
RCS file:
/home/cvs/jakarta-watchdog-4.0/src/tools/org/apache/tomcat/task/GTest.java,v
retrieving revision 1.1
diff -u -3 -r1.1 GTest.java
--- src/tools/org/apache/tomcat/task/GTest.java 2000/11/03 17:07:20 1.1
+++ src/tools/org/apache/tomcat/task/GTest.java 2001/08/05 18:25:14
@@ -419,9 +419,6 @@
try {
pw.println(request);
- if( content != null) {
- pw.println(Content-Length: + content.length());
- }
// Now sending any specified request headers
if ( requestHeaders != null )
{
Re: GTest in watchdog fails with Apache...
Another small issue with watchdog (coming out of the JSP tests this time) is that Apache always replies with HTTP/1.1 also to an HTTP/1.0 request For example: # telnet localhost 80 Trying 127.0.0.1... Connected to localhost.betaversion.org. Escape character is '^]'. GET / HTTP/1.0 HTTP/1.1 200 OK Date: Sun, 05 Aug 2001 19:05:20 GMT Server: Apache/1.3.19 (Darwin) [...] Connection closed by foreign host. # This will make 4 tests in the JSP tests suite fail, although they shouldn't (the only difference is that Watchdogs expects 1.0 while Apache replies 1.1). Can someone fix that? Pier
