cvs commit: jakarta-tomcat-connectors/jk/native/common jk_uri_worker_map.c
jfclere 01/08/06 02:46:56 Modified:jk/native/common jk_uri_worker_map.c Log: Fix the comment! Revision ChangesPath 1.6 +2 -2 jakarta-tomcat-connectors/jk/native/common/jk_uri_worker_map.c Index: jk_uri_worker_map.c === RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/common/jk_uri_worker_map.c,v retrieving revision 1.5 retrieving revision 1.6 diff -u -r1.5 -r1.6 --- jk_uri_worker_map.c 2001/08/03 15:00:53 1.5 +++ jk_uri_worker_map.c 2001/08/06 09:46:56 1.6 @@ -67,7 +67,7 @@ * servlet container. * * * * Author: Gal Shachor [EMAIL PROTECTED] * - * Version: $Revision: 1.5 $ * + * Version: $Revision: 1.6 $ * ***/ #include jk_pool.h @@ -309,7 +309,7 @@ /* * JFC: please check... * Not sure what to do, but I try to prevent problems. - * I have fixed jk_mount_context() in apache*/mod_jk.c so we should + * I have fixed jk_mount_context() in apaches/mod_jk.c so we should * not arrive here when using Apache. */ jk_log(l, JK_LOG_ERROR,
Re: jsvc
Pier P. Fumagalli wrote: Jan Labanowski at [EMAIL PROTECTED] wrote: Howdy Gurus... (Pier?) Can you tell me what is jsvc? I dug out in some archives that it allows stopping/restarting Tomcat via UNIX signal? And allows to run Catalina on port 80 as nobody... Yeah... It works... It'll be included (probably) in the next Beta of TC4. I have ported it to cygwin, I will commit the changes the evening. You see, my pants are wet, and I am salivating... Gross :( Any docs? There's an INSTALL.txt in the jakarta-tomcat-4.0/service CVS repository. Pier
Re: Problem with mod_jk 1.2.0 (latest CVS snapshot)
Bojan Smojver wrote: Just a little trivial problem with the new source: it doesn't build because file common/jk_uri_worker_map.c has an unintentional comment end (the * after apache) in line 312: * I have fixed jk_mount_context() in apache*/mod_jk.c so we should The comment actually ends in line 314. Oops, sorry I added the comment after testing - My bad ! - Bojan Bojan Smojver wrote: jean-frederic clere wrote: Well I have fixed the code to prevent using the faulting JkMount syntax. I am happy my stupidity is good for something. At least the code became more idiot-proof ;-) Thanks heaps, Bojan
Re: Problem with mod_jk 1.2.0 (latest CVS snapshot)
Bojan Smojver wrote: Bojan Smojver wrote: Unfortunately, the problem is still there... Let me run gdb on the thing again and then I'll send you the backtrace. Bojan Slighty different problem this time, but along the lines of the previous one: DARN, That is the same kind of error, caused by the line: JkMount /login/j_security_check ajp13 The code only supports /context/* - I will try to fix this one - -- Program received signal SIGSEGV, Segmentation fault. 0x4021d26f in strncmp (s1=0x4f444145 Address 0x4f444145 out of bounds, s2=0x82d2c9c /, n=5852238) at ../sysdeps/generic/strncmp.c:42 42 ../sysdeps/generic/strncmp.c: No such file or directory. (gdb) where #0 0x4021d26f in strncmp (s1=0x4f444145 Address 0x4f444145 out of bounds, s2=0x82d2c9c /, n=5852238) at ../sysdeps/generic/strncmp.c:42 #1 0x8076ed1 in map_uri_to_worker (uw_map=0x82ef390, uri=0x82d2c9c /, l=0x82ef200) at jk_uri_worker_map.c:423 #2 0x8072a5c in jk_translate (r=0x82d155c) at mod_jk.c:1179 #3 0x8146b41 in run_method (r=0x82d155c, offset=0, run_all=0) at http_config.c:369 #4 0x8146b8a in ap_translate_name (r=0x82d155c) at http_config.c:381 #5 0x815535c in process_request_internal (r=0x82d155c) at http_request.c:1198 #6 0x815572a in ap_process_request (r=0x82d155c) at http_request.c:1323 #7 0x814f378 in child_main (child_num_arg=0) at http_main.c:4299 #8 0x814f593 in make_child (s=0x827c3e4, slot=0, now=996898126) at http_main.c:4467 #9 0x814f608 in startup_children (number_to_start=1) at http_main.c:4494 #10 0x814fc79 in standalone_main (argc=1, argv=0xb884) at http_main.c:4854 #11 0x81501e0 in main (argc=1, argv=0xb884) at http_main.c:5124 #12 0x401b9b5c in __libc_start_main (main=0x814fed4 main, argc=1, ubp_av=0xb884, init=0x806f500 _init, fini=0x81b7d10 _fini, rtld_fini=0x4000d634 _dl_fini, stack_end=0xb87c) at ../sysdeps/generic/libc-start.c:129 -- Hope this helps. Bojan
RE: TC33b1 Context path behavior: Is this a bug or by design?
Randall, It is the path of the context that makes them unique. So, Context path=/struts-documentation ... / would replace the auto-served context, where: Context path=/strutsdoc ... creates a new context. The fact that its docbase is the same as the one for the /struts-documentation context is irrelavent. If you don't want the struts-documentation.war auto-served, move it out of the webapps directory and expand it manually to a directory outside of webapps. Cheers, Larry -Original Message- From: Randall Parker [mailto:[EMAIL PROTECTED]] Sent: Sunday, August 05, 2001 2:11 AM To: [EMAIL PROTECTED] Subject: TC33b1 Context path behavior: Is this a bug or by design? 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/stru ts/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?
Please ignore. Didn't see the other discussion that already deal with this issue. -Original Message- From: Larry Isaacs [mailto:[EMAIL PROTECTED]] Sent: Monday, August 06, 2001 9:26 AM To: '[EMAIL PROTECTED]' Subject: RE: TC33b1 Context path behavior: Is this a bug or by design? Randall, It is the path of the context that makes them unique. So, Context path=/struts-documentation ... / would replace the auto-served context, where: Context path=/strutsdoc ... creates a new context. The fact that its docbase is the same as the one for the /struts-documentation context is irrelavent. If you don't want the struts-documentation.war auto-served, move it out of the webapps directory and expand it manually to a directory outside of webapps. Cheers, Larry -Original Message- From: Randall Parker [mailto:[EMAIL PROTECTED]] Sent: Sunday, August 05, 2001 2:11 AM To: [EMAIL PROTECTED] Subject: TC33b1 Context path behavior: Is this a bug or by design? 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/stru ts/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: Binding to a single IP
yes... -Original Message- From: Bojan Smojver [mailto:[EMAIL PROTECTED]] Sent: Friday, August 03, 2001 8:04 PM To: Tomcat Dev List Subject: Binding to a single IP I've asked this question over on the Tomcat user list, but nobody replied... Can Tomcat (3.3) be bound to a single IP address (ie. just 127.0.0.1)? Bojan
Re: Binding to a single IP
I know, I know, RTFCF... Bojan Curtis Dougherty wrote: yes... -Original Message- From: Bojan Smojver [mailto:[EMAIL PROTECTED]] Sent: Friday, August 03, 2001 8:04 PM To: Tomcat Dev List Subject: Binding to a single IP I've asked this question over on the Tomcat user list, but nobody replied... Can Tomcat (3.3) be bound to a single IP address (ie. just 127.0.0.1)? Bojan
RE: Binding to a single IP
:) -Original Message- From: Bojan Smojver [mailto:[EMAIL PROTECTED]] Sent: Monday, August 06, 2001 8:57 AM To: [EMAIL PROTECTED] Subject: Re: Binding to a single IP I know, I know, RTFCF... Bojan Curtis Dougherty wrote: yes... -Original Message- From: Bojan Smojver [mailto:[EMAIL PROTECTED]] Sent: Friday, August 03, 2001 8:04 PM To: Tomcat Dev List Subject: Binding to a single IP I've asked this question over on the Tomcat user list, but nobody replied... Can Tomcat (3.3) be bound to a single IP address (ie. just 127.0.0.1)? Bojan
RE: SimpleMapper1.java
Hi Chris, I've looked at committing your patch. However, in reviewing who uses Context.getHost(), I a little nervous about having Context.getHost() contain a wildcard. (I think this is what your patch implies.) Though I don't think anything bad happens currently, Context.getHost() is used in a number of locations which would seem as though they aren't expecting a wildcard. ContextManager.createRequest() is the one that make me the most nervous. Context does have a vhostAliases field. This would seem a more appropriate location for your wildcard string. Unfortunately, I don't think vhostAliases can be specified in server.xml or apps-xxx.xml yet. You are welcome to look into adding that. I'll try to find time if you can't. Once that is done, your patch and a simple update to SimpleMapper1.addContext() should get the behavior you desire without putting a wildcard in Context.getHost(). Cheers, Larry -Original Message- From: Chris Bryden [mailto:[EMAIL PROTECTED]] Sent: Tuesday, July 31, 2001 10:07 PM To: [EMAIL PROTECTED] Subject: SimpleMapper1.java Hi, I didn't get a response from the last mail I sent on this subject, but I hope I could borrow a few minutes of your time to at least point me in the direction of the relevant documentation on virtual hosts in tomcat... I am using Apache 1.3.20 and Tomcat 3.3 on Linux 2.4.5 We use a large number of virtual hosts in apache of the form xyz.subdomain.ourdomain.com. They all point to the same context, with the xyz art of the name being used by the webapp to determine how it was accessed and set content accordingly... In the apache configuration, the virtual host is defined using the ServerAlias directive and a wildcard, however, tomcat seems to need the Host tags in server.xml to exactly match the host header.. I was under a lot of pressure to get this working at the time, so hacked SimpleMapper1.java so that I could put a wildcard in my Host tag in server.xml according to the attached patch... The question I have is, what is the future for defining wildcard hosts in the Host tags in server.xml..? I would be more than happy to help with any development in this area, but I need to know what the plans are for virtual host definitions in server.xml If the reason that I didn't get a reply to my earlier mail is that I am being a complete muppet, please could you direct me to the relevent docs so I can demuppetize :-) Kind Regards, Chris
RE: SimpleMapper1.java
At 10:23 06/08/01 -0400, you wrote: Hi Chris, I've looked at committing your patch. However, in reviewing who uses Context.getHost(), I a little nervous about having Context.getHost() contain a wildcard. (I think this is what your patch implies.) Though I don't think anything bad happens currently, Context.getHost() is used in a number of locations which would seem as though they aren't expecting a wildcard. ContextManager.createRequest() is the one that make me the most nervous. Context does have a vhostAliases field. This would seem a more appropriate location for your wildcard string. Unfortunately, I don't think vhostAliases can be specified in server.xml or apps-xxx.xml yet. You are welcome to look into adding that. I'll try to find time if you can't. I agree, that patch was really just a bit of a hack to get me out of a tight spot. I did see a few references to vhostAliases as I was looking through and thought that It would probably be the better place for this sort of thing. I'll try to make some time this week to have a look at adding alias specifications to server.xml or apps-whatever.xml this week if you like... Once that is done, your patch and a simple update to SimpleMapper1.addContext() should get the behavior you desire without putting a wildcard in Context.getHost(). sounds good to me. I'll let you know how I get on Regards, Chris -Original Message- From: Chris Bryden [mailto:[EMAIL PROTECTED]] Sent: Tuesday, July 31, 2001 10:07 PM To: [EMAIL PROTECTED] Subject: SimpleMapper1.java Hi, I didn't get a response from the last mail I sent on this subject, but I hope I could borrow a few minutes of your time to at least point me in the direction of the relevant documentation on virtual hosts in tomcat... I am using Apache 1.3.20 and Tomcat 3.3 on Linux 2.4.5 We use a large number of virtual hosts in apache of the form xyz.subdomain.ourdomain.com. They all point to the same context, with the xyz art of the name being used by the webapp to determine how it was accessed and set content accordingly... In the apache configuration, the virtual host is defined using the ServerAlias directive and a wildcard, however, tomcat seems to need the Host tags in server.xml to exactly match the host header.. I was under a lot of pressure to get this working at the time, so hacked SimpleMapper1.java so that I could put a wildcard in my Host tag in server.xml according to the attached patch... The question I have is, what is the future for defining wildcard hosts in the Host tags in server.xml..? I would be more than happy to help with any development in this area, but I need to know what the plans are for virtual host definitions in server.xml If the reason that I didn't get a reply to my earlier mail is that I am being a complete muppet, please could you direct me to the relevent docs so I can demuppetize :-) Kind Regards, Chris
cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/modules/config ContextXmlReader.java
costin 01/08/06 08:42:36
Modified:src/share/org/apache/tomcat/modules/config
ContextXmlReader.java
Log:
Added missing support for
Host name=foo
Alias name=bar /
...
Context ...
This will call ctx.addHostAlias(). Thanks to Larry and Chris for finding this,
I hope it's enough to get the host wildcard patch back on track.
I agree with Larry, the main host name can't be wildcard, it's also used to
construct the reply ( for example for redirects and to recreate the url ).
Revision ChangesPath
1.8 +27 -4
jakarta-tomcat/src/share/org/apache/tomcat/modules/config/ContextXmlReader.java
Index: ContextXmlReader.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/modules/config/ContextXmlReader.java,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- ContextXmlReader.java 2001/03/08 01:09:50 1.7
+++ ContextXmlReader.java 2001/08/06 15:42:36 1.8
@@ -154,14 +154,37 @@
// Virtual host support - if Context is inside a Host
xh.addRule( Host, xh.setVar( current_host, name));
xh.addRule( Host, xh.setProperties());
+ xh.addRule( Alias, new XmlAction() {
+ public void start( SaxContext xctx) throws Exception {
+ Vector aliases=(Vector)xctx.getVariable( host_aliases );
+ if( aliases==null ) {
+ aliases=new Vector();
+ xctx.setVariable( host_aliases, aliases );
+ }
+ String alias=(String)xctx.getCurrentAttributes().getValue(name);
+ if( alias!=null )
+ aliases.addElement( alias );
+ }
+ });
xh.addRule( Context, new XmlAction() {
- public void end( SaxContext ctx) throws Exception {
- Context tcCtx=(Context)ctx.currentObject();
- String host=(String)ctx.getVariable(current_host);
+ public void end( SaxContext xctx) throws Exception {
+ Context tcCtx=(Context)xctx.currentObject();
+ String host=(String)xctx.getVariable(current_host);
+ Vector aliases=(Vector)xctx.getVariable( host_aliases );
- if( host!=null ! DEFAULT.equals( host ))
+ if( host!=null ! DEFAULT.equals( host )) {
tcCtx.setHost( host );
+ if( aliases!=null ) {
+ Enumeration alE=aliases.elements();
+ while( alE.hasMoreElements() ) {
+ String alias=(String)alE.nextElement();
+ tcCtx.addHostAlias( alias );
+ if( tcCtx.getDebug() 0 )
+ tcCtx.log( Alias + host + + alias );
+ }
+ }
+ }
}
});
cvs commit: jakarta-tomcat-connectors/jk/native/apache-1.3 mod_jk.c
jfclere 01/08/06 08:43:30
Modified:jk/native/apache-1.3 mod_jk.c
Log:
Arrange jk_set_log_file: otherwise we need an absolut path for the file
name!
Revision ChangesPath
1.11 +9 -2 jakarta-tomcat-connectors/jk/native/apache-1.3/mod_jk.c
Index: mod_jk.c
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/apache-1.3/mod_jk.c,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -r1.10 -r1.11
--- mod_jk.c 2001/08/03 14:42:45 1.10
+++ mod_jk.c 2001/08/06 15:43:30 1.11
@@ -61,7 +61,7 @@
* Author: Gal Shachor [EMAIL PROTECTED] *
* Dan Milstein [EMAIL PROTECTED]*
* Henri Gomez [EMAIL PROTECTED] *
- * Version: $Revision: 1.10 $ *
+ * Version: $Revision: 1.11 $ *
***/
/*
@@ -667,7 +667,14 @@
jk_server_conf_t *conf =
(jk_server_conf_t *)ap_get_module_config(s-module_config, jk_module);
-conf-log_file = log_file;
+if ( log_file[0] != '/' ) {
+/* we need an absolut path */
+conf-log_file = ap_server_root_relative(cmd-pool,log_file);
+} else
+conf-log_file = ap_pstrdup(cmd-pool,log_file);
+
+if (conf-log_file == NULL)
+return JkLogFile file_name invalid;
return NULL;
}
cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/core Request.java Response.java
costin 01/08/06 08:45:26
Modified:src/share/org/apache/tomcat/core Request.java Response.java
Log:
Few fixes in Request, Response: make sure all fields are protected ( some were
package ), so it can be extended. Added deprecated on some of the really old
methods, and make sure we use getters instead of the fields ( methods could be
overriden ).
This is part of the final review of the APIs, preparing for ( hopefully ) final beta.
Revision ChangesPath
1.106 +31 -14jakarta-tomcat/src/share/org/apache/tomcat/core/Request.java
Index: Request.java
===
RCS file: /home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/core/Request.java,v
retrieving revision 1.105
retrieving revision 1.106
diff -u -r1.105 -r1.106
--- Request.java 2001/08/03 02:47:58 1.105
+++ Request.java 2001/08/06 15:45:25 1.106
@@ -184,7 +184,7 @@
// auth infor
protected String authType;
-boolean notAuthenticated=true;
+protected boolean notAuthenticated=true;
protected String remoteUser;
protected Principal principal;
// active roles for the current user
@@ -206,19 +206,19 @@
// Handler
protected Handler handler = null;
-Container container;
+protected Container container;
protected Cookies scookies;
// sub-request support
-Request top;
-Request parent;
-Request child;
+protected Request top;
+protected Request parent;
+protected Request child;
protected UDecoder urlDecoder;
// Error handling support
-Exception errorException;
+protected Exception errorException;
private Object notes[]=new Object[ContextManager.MAX_NOTES];
@@ -323,7 +323,7 @@
}
public MessageBytes queryString() {
- return queryMB;
+ return query();
}
public MessageBytes servletPath() {
@@ -355,6 +355,7 @@
public void setServerPort(int serverPort ) {
this.serverPort=serverPort;
}
+
public MessageBytes remoteAddr() {
return remoteAddrMB;
}
@@ -438,6 +439,10 @@
// encoding/type
public String getCharacterEncoding() {
+ return getCharEncoding();
+}
+
+public String getCharEncoding() {
if(charEncoding!=null) return charEncoding;
Object result=null;
@@ -477,13 +482,15 @@
public int getContentLength() {
if( contentLength -1 ) return contentLength;
- MessageBytes clB=headers.getValue(content-length);
+ MessageBytes clB=getMimeHeaders().getValue(content-length);
contentLength = (clB==null || clB.isNull() ) ? -1 : clB.getInt();
available=contentLength;
return contentLength;
}
+/** @deprecated
+ */
public String getContentType() {
contentType();
if( contentTypeMB==null ||
@@ -491,16 +498,20 @@
return contentTypeMB.toString();
}
+/** @deprecated
+ */
public void setContentType( String type ) {
contentTypeMB.setString( type );
}
public MessageBytes contentType() {
if( contentTypeMB == null )
- contentTypeMB=headers.getValue( content-type );
+ contentTypeMB=getMimeHeaders().getValue( content-type );
return contentTypeMB;
}
+/** @deprecated
+ */
public void setContentType( MessageBytes mb ) {
contentTypeMB=mb;
}
@@ -831,16 +842,22 @@
}
// Facade for MimeHeaders
+/** @deprecated
+ */
public Enumeration getHeaders(String name) {
return getMimeHeaders().values(name);
}
+/** @deprecated
+ */
public String getHeader(String name) {
-return headers.getHeader(name);
+return getMimeHeaders().getHeader(name);
}
+/** @deprecated
+ */
public Enumeration getHeaderNames() {
-return headers.names();
+return getMimeHeaders().names();
}
// Computed fields
@@ -929,9 +946,9 @@
sb.append( R( );
if( context!=null) {
sb.append( context.getPath() );
- if( ! servletPathMB.isNull() )
- sb.append( + + servletPathMB.toString() + + +
-pathInfoMB.toString());
+ if( ! servletPath().isNull() )
+ sb.append( + + servletPath().toString() + + +
+pathInfo().toString());
} else {
sb.append(requestURI().toString());
}
1.53 +3 -3 jakarta-tomcat/src/share/org/apache/tomcat/core/Response.java
Index: Response.java
cvs commit: jakarta-tomcat-connectors/jk/native/apache-2.0 mod_jk.c
jfclere 01/08/06 08:54:20
Modified:jk/native/apache-2.0 mod_jk.c
Log:
Arrange jk_set_log_file to allow relative path.
Revision ChangesPath
1.16 +9 -2 jakarta-tomcat-connectors/jk/native/apache-2.0/mod_jk.c
Index: mod_jk.c
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/apache-2.0/mod_jk.c,v
retrieving revision 1.15
retrieving revision 1.16
diff -u -r1.15 -r1.16
--- mod_jk.c 2001/08/03 14:42:45 1.15
+++ mod_jk.c 2001/08/06 15:54:20 1.16
@@ -60,7 +60,7 @@
* Description: Apache 2 plugin for Jakarta/Tomcat *
* Author: Gal Shachor [EMAIL PROTECTED] *
* Henri Gomez [EMAIL PROTECTED] *
- * Version: $Revision: 1.15 $ *
+ * Version: $Revision: 1.16 $ *
***/
/*
@@ -667,7 +667,14 @@
jk_server_conf_t *conf =
(jk_server_conf_t *)ap_get_module_config(s-module_config, jk_module);
-conf-log_file = log_file;
+if ( log_file[0] != '/' ) {
+/* we need an absolut path */
+conf-log_file = ap_server_root_relative(cmd-pool,log_file);
+} else
+conf-log_file = ap_pstrdup(cmd-pool,log_file);
+
+if (conf-log_file == NULL)
+return JkLogFile file_name invalid;
return NULL;
}
RE: partial URLPatternMatching in Tomcat 4.0 (Servlet 2.3 spec)?
Would/Must the RewriteValve do that? Loïc Lefèvre note : thanks Pier ;) note 2: it worked before, I mean the e-mail address -Message d'origine- De : Craig R. McClanahan [mailto:[EMAIL PROTECTED]] Envoyé : samedi 4 août 2001 04:08 À : '[EMAIL PROTECTED]' Cc : '[EMAIL PROTECTED]' Objet : Re: partial URLPatternMatching in Tomcat 4.0 (Servlet 2.3 spec)? On Thu, 2 Aug 2001, Ru, Simon wrote: I wonder if Servlet 2.3's Filter allow partial URLPatternMatching. Something like: filter-mapping filter-nametimerFilter/filter-name url-pattern/Controller?action=timer*/url-pattern /filter-mapping If it can, then we can use the Filtering mechanism as a controller to do request dispatching. We can avoid having thousands if statements in the Controller and we can easily modify the dispatching route without recompile. If it can't, is it something worth enhancing? What needs to add to have that capability? Thanks in advance. While what you propose might be quite nice, Tomcat needs to conform to the servlet spec's rules for what a legal url-pattern can contain -- it's the same for both filter mappings and servlet mappings -- and this pattern is not legal. One strategy would be to match for /Controller/* and let the filter look at the query parameters to decide whether or not to do anything special. Otherwise, it can just pass the request on unmolested. Simon Ru Software Engineer (510) 897-5331 http://www.worldchain.com Craig McClanahan
RE: partial URLPatternMatching in Tomcat 4.0 (Servlet 2.3 spec)?
On Mon, 6 Aug 2001, Loïc Lefèvre wrote: Would/Must the RewriteValve do that? Well, you can certainly use Valves if you don't mind being tied to Tomcat 4. But, to implement a controller type mechanism that uses request dispatchers, a Filter is a much better answer (the only way a Valve can do the dispatch is to change the Request URI to select the appropriate servlet). Doing the pattern matching yourself (say, with the jakarta-regexp package) inside a Filter still avoids all the thousands of if statements you are worried about. (But talking about how to implement this is straying into TOMCAT-USER topics -- this list is for Tomcat development related questions). Loïc Lefèvre Craig note : thanks Pier ;) note 2: it worked before, I mean the e-mail address -Message d'origine- De : Craig R. McClanahan [mailto:[EMAIL PROTECTED]] Envoyé : samedi 4 août 2001 04:08 À : '[EMAIL PROTECTED]' Cc : '[EMAIL PROTECTED]' Objet : Re: partial URLPatternMatching in Tomcat 4.0 (Servlet 2.3 spec)? On Thu, 2 Aug 2001, Ru, Simon wrote: I wonder if Servlet 2.3's Filter allow partial URLPatternMatching. Something like: filter-mapping filter-nametimerFilter/filter-name url-pattern/Controller?action=timer*/url-pattern /filter-mapping If it can, then we can use the Filtering mechanism as a controller to do request dispatching. We can avoid having thousands if statements in the Controller and we can easily modify the dispatching route without recompile. If it can't, is it something worth enhancing? What needs to add to have that capability? Thanks in advance. While what you propose might be quite nice, Tomcat needs to conform to the servlet spec's rules for what a legal url-pattern can contain -- it's the same for both filter mappings and servlet mappings -- and this pattern is not legal. One strategy would be to match for /Controller/* and let the filter look at the query parameters to decide whether or not to do anything special. Otherwise, it can just pass the request on unmolested. Simon Ru Software Engineer (510) 897-5331 http://www.worldchain.com Craig McClanahan
Catalina Startup Hook
I need a quick jumpstart on how to hook my password prompter into the Catalina startup process. I assume that I shouldn't implement it as a Valve, as those have to do with the Request/Response chain. The Connector level in server.xml appears to be the appropriate level in the hierarchy, but it's not really a connecter per se, since its lifecycle is complete before the startup process even finishes (i.e. it doesn't need to sit in the service and pass requests off to the engine). So is there a more generic module architecture in place that I should implement? I just need a quick, high-level idea of what internal component to use and how to implement that component in the server.xml config. TIA Regards, Christopher
cvs commit: jakarta-tomcat-4.0/webapps/tomcat-docs/funcspecs - New directory
craigmcc01/08/06 10:18:18 jakarta-tomcat-4.0/webapps/tomcat-docs/funcspecs - New directory
cvs commit: jakarta-tomcat-connectors/jk/native/common jk_uri_worker_map.c
jfclere 01/08/06 10:31:45
Modified:jk/native/common jk_uri_worker_map.c
Log:
Arrange JkMount for entries like:
JkMount /examples/servlet/HelloWorldExample example
Note that things like /examples/servlet/Hello* example are not working...
Revision ChangesPath
1.7 +13 -2 jakarta-tomcat-connectors/jk/native/common/jk_uri_worker_map.c
Index: jk_uri_worker_map.c
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/common/jk_uri_worker_map.c,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- jk_uri_worker_map.c 2001/08/06 09:46:56 1.6
+++ jk_uri_worker_map.c 2001/08/06 17:31:45 1.7
@@ -67,7 +67,7 @@
* servlet container. *
* *
* Author: Gal Shachor [EMAIL PROTECTED] *
- * Version: $Revision: 1.6 $ *
+ * Version: $Revision: 1.7 $ *
***/
#include jk_pool.h
@@ -293,6 +293,7 @@
uri, worker);
}
} else {
+/* Something like : JkMount /servlets/exampl* ajp13 */
uwr-uri = uri;
uwr-worker_name = worker;
uwr-context = uri;
@@ -303,8 +304,18 @@
uri, worker);
}
-uwr-ctxt_len = strlen(uwr-context);
+} else {
+/* Something like: JkMount /login/j_security_check ajp13 */
+uwr-uri = uri;
+uwr-worker_name = worker;
+uwr-context = uri;
+uwr-suffix = NULL;
+uwr-match_type = MATCH_TYPE_EXACT;
+jk_log(l, JK_LOG_DEBUG,
+ Into jk_uri_worker_map_t::uri_worker_map_open, exact rule %s=%s
was added\n,
+uri, worker);
}
+uwr-ctxt_len = strlen(uwr-context);
} else {
/*
* JFC: please check...
cvs commit: jakarta-tomcat-connectors/webapp/support aplocal.m4 apjava.m4 buildconf.sh
pier01/08/06 10:59:49
Modified:webapp/support apjava.m4 buildconf.sh
Added: webapp/support aplocal.m4
Log:
- Fixed license typos/mistakes
- Uppercasing of all exported variables
- M4 Sources cleanup
- Moved LOCAL_* AutoConf functions in new aplocal.m4
Revision ChangesPath
1.5 +23 -17jakarta-tomcat-connectors/webapp/support/apjava.m4
Index: apjava.m4
===
RCS file: /home/cvs/jakarta-tomcat-connectors/webapp/support/apjava.m4,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- apjava.m4 2001/08/01 17:14:29 1.4
+++ apjava.m4 2001/08/06 17:59:49 1.5
@@ -26,10 +26,10 @@
dnlAlternately, this acknowlegement may appear in the software itself, if
dnland wherever such third-party acknowlegements normally appear.
dnl
-dnl 4. The names The Jakarta Project, WebApp, and Apache Software
-dnlFoundation must not be used to endorse or promote products derived
-dnlfrom this software without prior written permission. For written
-dnlpermission, please contact [EMAIL PROTECTED].
+dnl 4. The names The Jakarta Project, Apache WebApp Module, and Apache
+dnlSoftware Foundation must not be used to endorse or promote products
+dnlderived from this software without prior written permission. For
+dnlwritten permission, please contact [EMAIL PROTECTED].
dnl
dnl 5. Products derived from this software may not be called Apache nor may
dnlApache appear in their names without prior written permission of the
@@ -55,38 +55,44 @@
dnl
dnl =
-dnl -
-dnl Author Pier Fumagalli mailto:[EMAIL PROTECTED]
-dnl Version $Id: apjava.m4,v 1.4 2001/08/01 17:14:29 pier Exp $
-dnl -
+dnl --
+dnl Author Pier Fumagalli [EMAIL PROTECTED]
+dnl Version $Id: apjava.m4,v 1.5 2001/08/06 17:59:49 pier Exp $
+dnl --
AC_DEFUN([AP_PROG_JAVAC_WORKS],[
- AC_CACHE_CHECK([wether the Java compiler ($JAVAC) works],ap_cv_prog_javac_works,[
+ AC_CACHE_CHECK([wether the Java compiler (${JAVAC}) works],
+ap_cv_prog_javac_works,[
echo public class Test {} Test.java
-$JAVAC $JAVACFLAGS Test.java /dev/null 21
-if ${test} $? -eq 0
+${JAVAC} ${JAVACFLAGS} Test.java /dev/null 21
+if ${TEST} ${?} -eq 0
then
rm -f Test.java Test.class
ap_cv_prog_javac_works=yes
else
rm -f Test.java Test.class
AC_MSG_RESULT(no)
- AC_MSG_ERROR([installation or configuration problem: javac cannot compile])
+ AC_MSG_ERROR([${JAVAC} cannot compile])
fi
])
])
AC_DEFUN([AP_PROG_JAVAC],[
- AC_PATH_PROG(JAVAC,javac,AC_MSG_ERROR([javac not found]),$JAVA_HOME/bin:$PATH)
+ AC_PATH_PROG(JAVAC,javac,
+AC_MSG_ERROR([javac not found]),
+${JAVA_HOME}/bin:${PATH}
+ )
AP_PROG_JAVAC_WORKS()
- AC_PROVIDE([$0])
+ AC_PROVIDE([${0}])
AC_SUBST(JAVAC)
AC_SUBST(JAVACFLAGS)
])
AC_DEFUN([AP_PROG_JAR],[
- AC_PATH_PROG(JAR,jar,AC_MSG_ERROR([jar not found]),$JAVA_HOME/bin:$PATH)
- AC_PROVIDE([$0])
+ AC_PATH_PROG(JAR,jar,
+AC_MSG_ERROR([jar not found]),
+${JAVA_HOME}/bin:${PATH})
+ AC_PROVIDE([${0}])
AC_SUBST(JAR)
])
@@ -106,7 +112,7 @@
AC_MSG_RESULT([${JAVA_HOME}])
;;
esac
-if ${test} ! -d ${JAVA_HOME}
+if ${TEST} ! -d ${JAVA_HOME}
then
AC_MSG_ERROR([${JAVA_HOME} is not a directory])
fi
1.3 +60 -5 jakarta-tomcat-connectors/webapp/support/buildconf.sh
Index: buildconf.sh
===
RCS file: /home/cvs/jakarta-tomcat-connectors/webapp/support/buildconf.sh,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- buildconf.sh 2001/07/18 17:38:48 1.2
+++ buildconf.sh 2001/08/06 17:59:49 1.3
@@ -1,11 +1,66 @@
#!/bin/sh
+# = #
+# #
+# The Apache Software License, Version 1.1 #
+# #
+# Copyright (c) 1999-2001 The Apache Software Foundation. #
+# All rights reserved.#
+# #
cvs commit: jakarta-tomcat-connectors/webapp/support formatfile.c
pier01/08/06 11:03:41
Modified:webapp/support formatfile.c
Log:
Fixed license
Revision ChangesPath
1.3 +9 -6 jakarta-tomcat-connectors/webapp/support/formatfile.c
Index: formatfile.c
===
RCS file: /home/cvs/jakarta-tomcat-connectors/webapp/support/formatfile.c,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- formatfile.c 2001/07/13 03:00:35 1.2
+++ formatfile.c 2001/08/06 18:03:41 1.3
@@ -4,7 +4,6 @@
* *
* Copyright (c) 1999-2001 The Apache Software Foundation. *
* All rights reserved.*
- * *
* = *
* *
* Redistribution and use in source and binary forms, with or without modi- *
@@ -26,10 +25,10 @@
*Alternately, this acknowlegement may appear in the software itself, if *
*and wherever such third-party acknowlegements normally appear. *
* *
- * 4. The names The Jakarta Project, WebApp, 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].*
+ * 4. The names The Jakarta Project, Apache WebApp Module, 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 *
@@ -54,8 +53,12 @@
* on the Apache Software Foundation, please see http://www.apache.org/. *
* *
* = */
+
+/* - *
+ * Author Pier Fumagalli [EMAIL PROTECTED]
+ * Version $Id: formatfile.c,v 1.3 2001/08/06 18:03:41 pier Exp $
+ * - */
-/* @version $Id: formatfile.c,v 1.2 2001/07/13 03:00:35 pier Exp $ */
#include stdio.h
int main(void) {
cvs commit: jakarta-tomcat-connectors/webapp/support apjava.m4 aplocal.m4 buildconf.sh
pier01/08/06 11:04:15 Modified:webapp/support apjava.m4 aplocal.m4 buildconf.sh Log: Wrong email address. Revision ChangesPath 1.6 +2 -2 jakarta-tomcat-connectors/webapp/support/apjava.m4 Index: apjava.m4 === RCS file: /home/cvs/jakarta-tomcat-connectors/webapp/support/apjava.m4,v retrieving revision 1.5 retrieving revision 1.6 diff -u -r1.5 -r1.6 --- apjava.m4 2001/08/06 17:59:49 1.5 +++ apjava.m4 2001/08/06 18:04:14 1.6 @@ -56,8 +56,8 @@ dnl = dnl -- -dnl Author Pier Fumagalli [EMAIL PROTECTED] -dnl Version $Id: apjava.m4,v 1.5 2001/08/06 17:59:49 pier Exp $ +dnl Author Pier Fumagalli [EMAIL PROTECTED] +dnl Version $Id: apjava.m4,v 1.6 2001/08/06 18:04:14 pier Exp $ dnl -- AC_DEFUN([AP_PROG_JAVAC_WORKS],[ 1.2 +2 -2 jakarta-tomcat-connectors/webapp/support/aplocal.m4 Index: aplocal.m4 === RCS file: /home/cvs/jakarta-tomcat-connectors/webapp/support/aplocal.m4,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- aplocal.m42001/08/06 17:59:49 1.1 +++ aplocal.m42001/08/06 18:04:14 1.2 @@ -56,8 +56,8 @@ dnl = dnl -- -dnl Author Pier Fumagalli [EMAIL PROTECTED] -dnl Version $Id: aplocal.m4,v 1.1 2001/08/06 17:59:49 pier Exp $ +dnl Author Pier Fumagalli [EMAIL PROTECTED] +dnl Version $Id: aplocal.m4,v 1.2 2001/08/06 18:04:14 pier Exp $ dnl -- AC_DEFUN(LOCAL_INIT,[ 1.4 +2 -2 jakarta-tomcat-connectors/webapp/support/buildconf.sh Index: buildconf.sh === RCS file: /home/cvs/jakarta-tomcat-connectors/webapp/support/buildconf.sh,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- buildconf.sh 2001/08/06 17:59:49 1.3 +++ buildconf.sh 2001/08/06 18:04:14 1.4 @@ -57,9 +57,9 @@ # = # # - # -# Author Pier Fumagalli [EMAIL PROTECTED] +# Author Pier Fumagalli [EMAIL PROTECTED] # Author Jon S. Stevens [EMAIL PROTECTED] -# Version $Id: buildconf.sh,v 1.3 2001/08/06 17:59:49 pier Exp $ +# Version $Id: buildconf.sh,v 1.4 2001/08/06 18:04:14 pier Exp $ # - # if [ ! -f ./configure.in ]
Re: [Fwd: GTest in watchdog fails with Apache...]
Craig R. McClanahan at [EMAIL PROTECTED] wrote: Thanks Justin ... my initial assumption was that Apache would be doing this right, considering all the people involved ... :-) I'll fix the Watchdog test so that it reacts to this correctly. We also need to fix the HTTP/1.1 connector in tomcat so that it behaves in the right way... Currently it replies with the version the request was posted on... Pier
cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/valves AccessLogValve.java Constants.java
remm01/08/06 12:21:55
Modified:catalina/src/share/org/apache/catalina/valves
AccessLogValve.java Constants.java
Log:
- Add a new combined mode for logging (logs the referer as well as the user-agent).
- New alias name for the patterm (combined).
- Patch submitted by Michael Smith msmith at speedlegal.com.
Revision ChangesPath
1.9 +40 -2
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/valves/AccessLogValve.java
Index: AccessLogValve.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/valves/AccessLogValve.java,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- AccessLogValve.java 2001/07/24 23:21:09 1.8
+++ AccessLogValve.java 2001/08/06 19:21:55 1.9
@@ -119,6 +119,8 @@
* commonly utilized patterns:/p
* ul
* libcommon/b - code%h %l %u %t %r %s %b/code
+ * libcombined/b -
+ * code%h %l %u %t %r %s %b %{Referer}i %{User-Agent}i/code
* /ul
*
* pbFIXME/b - Improve the parsing so that things like
@@ -126,7 +128,7 @@
*
* @author Craig R. McClanahan
* @author Jason Brittain
- * @version $Revision: 1.8 $ $Date: 2001/07/24 23:21:09 $
+ * @version $Revision: 1.9 $ $Date: 2001/08/06 19:21:55 $
*/
public final class AccessLogValve
@@ -195,6 +197,13 @@
/**
+ * For the combined format (common, plus useragent and referer), we do
+ * the same
+ */
+private boolean combined = false;
+
+
+/**
* The pattern used to format our access log lines.
*/
private String pattern = null;
@@ -347,6 +356,8 @@
pattern = ;
if (pattern.equals(Constants.AccessLog.COMMON_ALIAS))
pattern = Constants.AccessLog.COMMON_PATTERN;
+if (pattern.equals(Constants.AccessLog.COMBINED_ALIAS))
+pattern = Constants.AccessLog.COMBINED_PATTERN;
this.pattern = pattern;
if (this.pattern.equals(Constants.AccessLog.COMMON_PATTERN))
@@ -354,6 +365,11 @@
else
common = false;
+if (this.pattern.equals(Constants.AccessLog.COMBINED_PATTERN))
+combined = true;
+else
+combined = false;
+
}
@@ -449,7 +465,7 @@
StringBuffer result = new StringBuffer();
// Check to see if we should log using the common access log pattern
-if (common) {
+if (common || combined) {
String value = null;
ServletRequest req = request.getRequest();
@@ -501,11 +517,33 @@
result.append(space);
int length = response.getContentCount();
+
if (length = 0)
value = -;
else
value = + length;
result.append(value);
+
+if (combined) {
+result.append(space);
+result.append(\);
+String referer = hreq.getHeader(referer);
+if(referer != null)
+result.append(referer);
+else
+result.append(-);
+result.append(\);
+
+result.append(space);
+result.append(\);
+String ua = hreq.getHeader(user-agent);
+if(ua != null)
+result.append(ua);
+else
+result.append(-);
+result.append(\);
+}
+
} else {
// Generate a message based on the defined pattern
boolean replace = false;
1.3 +2 -0
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/valves/Constants.java
Index: Constants.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/valves/Constants.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- Constants.java2001/07/22 20:25:15 1.2
+++ Constants.java2001/08/06 19:21:55 1.3
@@ -76,6 +76,8 @@
public static final class AccessLog {
public static final String COMMON_ALIAS = common;
public static final String COMMON_PATTERN = %h %l %u %t \%r\ %s %b;
+public static final String COMBINED_ALIAS = combined;
+public static final String COMBINED_PATTERN = %h %l %u %t \%r\ %s %b
\%{Referer}i\ \%{User-Agent}i\;
}
}
cvs commit: jakarta-tomcat-connectors/webapp/support apjava.m4 aplocal.m4
pier01/08/06 13:18:26
Modified:webapp/support apjava.m4 aplocal.m4
Log:
Values like ${1}, ${2}, ${?}... don't run in ZSH
Revision ChangesPath
1.7 +4 -4 jakarta-tomcat-connectors/webapp/support/apjava.m4
Index: apjava.m4
===
RCS file: /home/cvs/jakarta-tomcat-connectors/webapp/support/apjava.m4,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- apjava.m4 2001/08/06 18:04:14 1.6
+++ apjava.m4 2001/08/06 20:18:26 1.7
@@ -57,7 +57,7 @@
dnl --
dnl Author Pier Fumagalli [EMAIL PROTECTED]
-dnl Version $Id: apjava.m4,v 1.6 2001/08/06 18:04:14 pier Exp $
+dnl Version $Id: apjava.m4,v 1.7 2001/08/06 20:18:26 pier Exp $
dnl --
AC_DEFUN([AP_PROG_JAVAC_WORKS],[
@@ -65,7 +65,7 @@
ap_cv_prog_javac_works,[
echo public class Test {} Test.java
${JAVAC} ${JAVACFLAGS} Test.java /dev/null 21
-if ${TEST} ${?} -eq 0
+if ${TEST} $? -eq 0
then
rm -f Test.java Test.class
ap_cv_prog_javac_works=yes
@@ -83,7 +83,7 @@
${JAVA_HOME}/bin:${PATH}
)
AP_PROG_JAVAC_WORKS()
- AC_PROVIDE([${0}])
+ AC_PROVIDE([$0])
AC_SUBST(JAVAC)
AC_SUBST(JAVACFLAGS)
])
@@ -92,7 +92,7 @@
AC_PATH_PROG(JAR,jar,
AC_MSG_ERROR([jar not found]),
${JAVA_HOME}/bin:${PATH})
- AC_PROVIDE([${0}])
+ AC_PROVIDE([$0])
AC_SUBST(JAR)
])
1.3 +8 -11 jakarta-tomcat-connectors/webapp/support/aplocal.m4
Index: aplocal.m4
===
RCS file: /home/cvs/jakarta-tomcat-connectors/webapp/support/aplocal.m4,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- aplocal.m42001/08/06 18:04:14 1.2
+++ aplocal.m42001/08/06 20:18:26 1.3
@@ -57,13 +57,10 @@
dnl --
dnl Author Pier Fumagalli [EMAIL PROTECTED]
-dnl Version $Id: aplocal.m4,v 1.2 2001/08/06 18:04:14 pier Exp $
+dnl Version $Id: aplocal.m4,v 1.3 2001/08/06 20:18:26 pier Exp $
dnl --
AC_DEFUN(LOCAL_INIT,[
- AC_MSG_RESULT([])
- AC_MSG_RESULT([Initializing])
- ac_t=
AC_PATH_PROG(TEST,test,${PATH})
AC_PATH_PROG(TRUE,true,${PATH})
AC_PATH_PROG(ECHO,echo,${PATH})
@@ -82,21 +79,21 @@
AC_DEFUN(LOCAL_HEADER,[
${ECHO}
- ${ECHO} ${1} 12
+ ${ECHO} $1 12
])
AC_DEFUN(LOCAL_FILTEREXEC,[
- ${ECHO} Invoking: ${1}
+ ${ECHO} Invoking: $1
${ECHO} -1 retvalue.tmp
{
-${1}
-${ECHO} retvalue ${?}
+$1
+${ECHO} retvalue $?
}|{
ret=0
while ${TRUE}
do
read first line
- if ${TEST} ! ${?} -eq 0
+ if ${TEST} ! $? -eq 0
then
break
else
@@ -104,7 +101,7 @@
then
ret=${line}
else
- ${ECHO} ${2}: ${first} ${line}
+ ${ECHO} $2: ${first} ${line}
fi
fi
done
@@ -114,6 +111,6 @@
}
ret=`${CAT} retvalue.tmp`
${RM} retvalue.tmp
- ${ECHO} Execution of ${1} returned ${ret}
+ ${ECHO} Execution of $1 returned ${ret}
])
cvs commit: jakarta-tomcat-connectors/webapp/lib Makefile.in
pier01/08/06 13:23:43
Modified:webapp/lib Makefile.in
Log:
Patching build process.
Revision ChangesPath
1.13 +25 -8 jakarta-tomcat-connectors/webapp/lib/Makefile.in
Index: Makefile.in
===
RCS file: /home/cvs/jakarta-tomcat-connectors/webapp/lib/Makefile.in,v
retrieving revision 1.12
retrieving revision 1.13
diff -u -r1.12 -r1.13
--- Makefile.in 2001/07/18 19:08:35 1.12
+++ Makefile.in 2001/08/06 20:23:43 1.13
@@ -56,7 +56,7 @@
# = #
# @author Pier Fumagalli mailto:[EMAIL PROTECTED]
-# @version $Id: Makefile.in,v 1.12 2001/07/18 19:08:35 pier Exp $
+# @version $Id: Makefile.in,v 1.13 2001/08/06 20:23:43 pier Exp $
include @SRCDIR@/Makedefs
@@ -69,14 +69,31 @@
LIB = libwebapp.la
-all: $(LIB)
+all: pr_warp_defs.h $(LIB)
-$(LIB): $(OBJS) $(PROVS) @SRCDIR@/Makedefs
- @echo Creating library $(LIB)
- @$(LIBTOOL) --silent --mode=link $(CC) -static -o $(LIB) \
+$(LIB): $(OBJS) $(PROVS)
+ @$(ECHO) Creating library $(LIB)
+ @$(LIBTOOL) $(LTFLAGS) --mode=link $(CC) -static -o $(LIB) \
$(OBJS) $(PROVS) 1 /dev/null
-clean:
- @echo Removing *.o *.lo $(LIB) .libs
- @rm -rf *.o *.lo $(LIB) .libs
+pr_warp_defs.h: @SRCDIR@/java/Constants.java
+ @$(ECHO) Generating pr_warp_defs.h
+ @$(CAT) @SRCDIR@/java/Constants.java | \
+ grep TYPE_ | \
+ sed s/public static final int/#define/g | \
+ sed y/=;/ / pr_warp_defs.h
+clean:
+ @for ENTRY in *.o *.lo $(LIB) pr_warp_defs.h .libs ; \
+ do \
+ if $(TEST) -f $${ENTRY} ; \
+ then \
+ $(ECHO) Removing file $${ENTRY} ; \
+ $(RM) -f $${ENTRY} ; \
+ fi ; \
+ if $(TEST) -d $${ENTRY} ; \
+ then \
+ $(ECHO) Removing directory $${ENTRY} ; \
+ $(RM) -rf $${ENTRY} ; \
+ fi ; \
+ done
cvs commit: jakarta-tomcat-4.0/webapps/tomcat-docs introduction.xml index.xml project.xml
craigmcc01/08/06 13:24:07 Modified:webapps/tomcat-docs index.xml project.xml Added: webapps/tomcat-docs introduction.xml Log: Add Rob Slifka's introduction.xml document to the tree, with a few cleanups. Quick review comments: - Please use an editor that wraps lines at = 80 characters. Otherwise it is difficult to edit this file in many editors. - There were several incomplete paragraphs at the bottom, so I took a few liberties at completing them. - Given the way that the overall document tree takes shape, the content of this file needs to be reviewed. For example, the terminology section will probably deserve its own page, while the rehash of the directory structure is probably redundant with the contents of the README.txt file. Revision ChangesPath 1.5 +2 -0 jakarta-tomcat-4.0/webapps/tomcat-docs/index.xml Index: index.xml === RCS file: /home/cvs/jakarta-tomcat-4.0/webapps/tomcat-docs/index.xml,v retrieving revision 1.4 retrieving revision 1.5 diff -u -r1.4 -r1.5 --- index.xml 2001/08/06 19:08:51 1.4 +++ index.xml 2001/08/06 20:24:07 1.5 @@ -36,6 +36,8 @@ Tomcat 4, and (if you wish to) building a distribution from the source code. /p ul +lia href=introduction.htmlstrongIntroduction/strong/a - A +brief, high level, overview of Tomcat./li lia href=README.txtstrongREADME.txt/strong/a - Describes the contents and directory structure of a Tomcat 4 binary distribution./li lia href=RUNNING.txtstrongRUNNING.txt/strong/a - Documents the 1.5 +5 -1 jakarta-tomcat-4.0/webapps/tomcat-docs/project.xml Index: project.xml === RCS file: /home/cvs/jakarta-tomcat-4.0/webapps/tomcat-docs/project.xml,v retrieving revision 1.4 retrieving revision 1.5 diff -u -r1.4 -r1.5 --- project.xml 2001/08/06 19:08:51 1.4 +++ project.xml 2001/08/06 20:24:07 1.5 @@ -11,8 +11,12 @@ body -menu name=Getting Started +menu name=Links item name=Docs Home href=index.html/ +/menu + +menu name=Getting Started +item name=Introduction href=introduction.html/ item name=READ ME href=README.txt/ item name=Install and Run href=RUNNING.txt/ item name=Building from Source href=BUILDING.txt/ 1.1 jakarta-tomcat-4.0/webapps/tomcat-docs/introduction.xml Index: introduction.xml === ?xml version=1.0? !DOCTYPE document [ !ENTITY project SYSTEM project.xml ] document project; properties author email=[EMAIL PROTECTED]Robert Slifka/author titleIntroduction/title /properties body section name=Introduction pFor administrators and web developers alike, there are some important bits of information you should familiarize yourself with before starting out. This document serves as a brief introduction to some of the concepts and terminology behind the Tomcat container. As well, where to go when you need help./p /section section name=Terminology pIn the course of reading these documents, you'll run across a number of terms; some specific to Tomcat, and others defined by the a href=http://java.sun.com/products/servlet/;Servlet/a or a href=http://java.sun.com/products/jsp/;JSP/a specifications./p ul listrongContext/strong - In a nutshell, a Context is a web application./li listrongTerm2/strong - This is it./li listrongTerm3/strong - This is it!/li /ul /section section name=Directories and Files pThroughout the docs, you'll notice there are numerous references to strong$CATALINA_HOME/strong. This represents the root of your Tomcat installation. When we say, This information can be found in your $CATALINA_HOME/README.txt file we mean to look at the README.txt file at the root of your Tomcat install./p pFor the complete description of the Tomcat distribution, each folder can be found in the a href=README.txtREADME.txt/a file, residing in the root directory of your Tomcat installation. Here, we will cover the ones where you'll be spending the majority of your time./p ul listrong/bin/strong - Startup, shutdown, and other scripts. The code*.sh/code files (for Unix systems) are functional duplicates of the code*.bat/code files (for Windows systems). Since the Win32 command-line lacks certain functionality, there are some additional files in here./li listrong/conf/strong - Configuration files and related DTDs. The most important file in here is
cvs commit: jakarta-tomcat-connectors/webapp/java Makefile.in
pier01/08/06 13:59:35
Modified:webapp/java Makefile.in
Log:
Correctly derive values from Makedefs for JAR and JAVAC.
Set up classpath to include JARs from the Tomcat 4.0 distribution.
Revision ChangesPath
1.2 +30 -7 jakarta-tomcat-connectors/webapp/java/Makefile.in
Index: Makefile.in
===
RCS file: /home/cvs/jakarta-tomcat-connectors/webapp/java/Makefile.in,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- Makefile.in 2001/07/13 02:11:21 1.1
+++ Makefile.in 2001/08/06 20:59:35 1.2
@@ -56,7 +56,7 @@
# = #
# @author Pier Fumagalli mailto:[EMAIL PROTECTED]
-# @version $Id: Makefile.in,v 1.1 2001/07/13 02:11:21 pier Exp $
+# @version $Id: Makefile.in,v 1.2 2001/08/06 20:59:35 pier Exp $
include @SRCDIR@/Makedefs
@@ -65,11 +65,34 @@
all: $(ARCHIVE)
$(ARCHIVE): *.java @SRCDIR@/Makedefs
- @echo Compiling Java sources with CLASSPATH=$$CLASSPATH...
- @javac -d . -classpath $$CLASSPATH *.java
- @jar -cvf0 warp.jar org/
+ @$(ECHO) Compiling Java sources with CLASSPATH set to:
+
+ @CP=$(JAVACPATH):$${CLASSPATH} ; \
+ for ENTRY in `$(ECHO) $${CP} | $(SED) y/:/\ /` ; \
+ do \
+ $(ECHO) $${ENTRY} ; \
+ done ; \
+ for ENTRY in *.java ; \
+ do \
+ $(ECHO) Compiling $${ENTRY} ; \
+ done ; \
+ $(JAVAC) $(JAVACFLAGS) -d . -classpath $(JAVACPATH):$${CLASSPATH} \
+ *.java
-clean:
- @echo Removing Java classes and archive
- @rm -rf org $(ARCHIVE)
+ @$(ECHO) Storing classes in warp.jar
+ @$(JAR) -cvf0 warp.jar org/ 1/dev/null
+clean:
+ @for ENTRY in $(ARCHIVE) org ; \
+ do \
+ if $(TEST) -f $${ENTRY} ; \
+ then \
+ $(ECHO) Removing file $${ENTRY} ; \
+ $(RM) -f $${ENTRY} ; \
+ fi ; \
+ if $(TEST) -d $${ENTRY} ; \
+ then \
+ $(ECHO) Removing directory $${ENTRY} ; \
+ $(RM) -rf $${ENTRY} ; \
+ fi ; \
+ done
cvs commit: jakarta-tomcat-connectors/webapp Makedefs.in configure.in
pier01/08/06 14:02:27 Modified:webapp Makedefs.in configure.in Log: Global touch-up of the build process. Revision ChangesPath 1.7 +34 -24jakarta-tomcat-connectors/webapp/Makedefs.in Index: Makedefs.in === RCS file: /home/cvs/jakarta-tomcat-connectors/webapp/Makedefs.in,v retrieving revision 1.6 retrieving revision 1.7 diff -u -r1.6 -r1.7 --- Makedefs.in 2001/07/13 02:06:26 1.6 +++ Makedefs.in 2001/08/06 21:02:27 1.7 @@ -56,39 +56,49 @@ # = # # @author Pier Fumagalli mailto:[EMAIL PROTECTED] -# @version $Id: Makedefs.in,v 1.6 2001/07/13 02:06:26 pier Exp $ +# @version $Id: Makedefs.in,v 1.7 2001/08/06 21:02:27 pier Exp $ -CC = @CC@ -CPP = @CPP@ -JAVAC = @JAVAC@ -JAR = @JAR@ -SHELL = @SHELL@ -LIBTOOL = @LIBTOOL@ +.SUFFIXES: .c .lo -CFLAGS = @CFLAGS@ +# Values imported from @APRDIR@/APRVARS +CC = @CC@ +CPP =@CPP@ +SHELL = @SHELL@ +LIBTOOL =@LIBTOOL@ EXTRA_CFLAGS = @EXTRA_CFLAGS@ -CPPFLAGS = @CPPFLAGS@ EXTRA_CPPFLAGS = @EXTRA_CPPFLAGS@ - EXTRA_LDFLAGS = @EXTRA_LDFLAGS@ EXTRA_LIBS = @EXTRA_LIBS@ EXTRA_INCLUDES = @EXTRA_INCLUDES@ -LIBTOOL_LIBS = @LIBTOOL_LIBS@ @APRDIR@/libapr.la - -LTFLAGS =--silent - -SRCDIR = @SRCDIR@ +LIBTOOL_LIBS = @LIBTOOL_LIBS@ -.SUFFIXES: .c .lo .o +# Default programs discovered by configure +CAT =@CAT@ +ECHO = @ECHO@ +GREP = @GREP@ +RM = @RM@ +SED =@SED@ +TEST = @TEST@ +TRUE = @TRUE@ + +# Java values discovered by configure +JAVA_HOME = @JAVA_HOME@ +JAR =@JAR@ +JAVAC = @JAVAC@ +JAVACFLAGS = @JAVACFLAGS@ +JAVACPATH = @TOMCATDIR@/common/lib/servlet.jar:@TOMCATDIR@/server/lib/catalina.jar -.c.o: - @echo Compiling $ - @$(CC) $(CFLAGS) $(EXTRA_CFLAGS) $(CPPFLAGS) $(EXTRA_CPPFLAGS) \ - -c $ -o $@ +# Compilation flags set by configure +CFLAGS = @CFLAGS@ +CPPFLAGS = @CPPFLAGS@ +LTFLAGS =@LTFLAGS@ +DEBUG = @DEBUG@ -.c.lo: +# Compile a C source using APR's libtool +.c.lo: @SRCDIR@/Makedefs @echo Compiling $ - @$(SHELL) $(LIBTOOL) --silent --mode=compile \ - $(CC) $(CFLAGS) $(EXTRA_CFLAGS) $(CPPFLAGS) $(EXTRA_CPPFLAGS) \ + @$(SHELL) $(LIBTOOL) $(LTFLAGS) --mode=compile \ + $(CC) \ + $(CFLAGS) $(EXTRA_CFLAGS) \ + $(CPPFLAGS) $(EXTRA_CPPFLAGS) \ -c $ -o $@ - 1.20 +115 -123 jakarta-tomcat-connectors/webapp/configure.in Index: configure.in === RCS file: /home/cvs/jakarta-tomcat-connectors/webapp/configure.in,v retrieving revision 1.19 retrieving revision 1.20 diff -u -r1.19 -r1.20 --- configure.in 2001/08/06 02:47:21 1.19 +++ configure.in 2001/08/06 21:02:27 1.20 @@ -1,119 +1,70 @@ -dnl = +dnl = dnl -dnl The Apache Software License, Version 1.1 +dnl The Apache Software License, Version 1.1 dnl -dnl Copyright (c) 1999-2001 The Apache Software Foundation. -dnlAll rights reserved. +dnl Copyright (c) 1999-2001 The Apache Software Foundation. +dnl All rights reserved. dnl -dnl = +dnl = dnl -dnl Redistribution and use in source and binary forms, with or without modi- -dnl fication, are permitted provided that the following conditions are met: +dnl Redistribution and use in source and binary forms, with or without modi- +dnl fication, are permitted provided that the following conditions are met: dnl -dnl 1. Redistributions of source code must retain the above copyright notice -dnl notice, this list of conditions and the following disclaimer. +dnl 1. Redistributions of source code must retain the above copyright notice +dnlnotice, this list of conditions and the following disclaimer. dnl -dnl 2. Redistributions in binary form must reproduce the above copyright -dnl notice, this list of conditions and the following disclaimer in the -dnl documentation and/or other materials provided with the distribution. +dnl 2. Redistributions in binary form must reproduce the above copyright +dnlnotice, this list
FW: Velocity and JSP speed testing...
Not exactly scientific, but I do trust Rickard to do things correctly...he has an existing JSP page for testing and then converted it to Velocity...here are the results... JSP - 240-480ms Velocity - 50-70ms You make the decision. :-) -jon -- Forwarded Message From: Rickard Öberg [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Date: Mon, 06 Aug 2001 17:41:37 +0200 To: [EMAIL PROTECTED] Cc: Webwork-User [EMAIL PROTECTED] Subject: Re: Velocity monthlist Rickard Öberg wrote: Ok guys, this is latest(-ish) Catalina sources. I tried hitting the page a couple of hundred times before checking the time, and it stabilized at scores around 50-70ms. So, that's like, 6 times faster than the same JSP running on Tomcat 3.2. And the VM was direct converted, almost line by line, since the WebWork taglib is very similar to the Velocity directives, so it's a quite fair comparison. And to make this comparison even more fair, I just tested the JSP page on the same Catalina build, and it scored between 240-480ms. So, not only is it slower, it is more fluctuating (and I also think I dare say that the JSP taglib in WebWork is as optimized as it can be). Interesting... /Rickard -- Rickard Öberg Software Development Specialist xlurc - Xpedio Linköping Ubiquitous Research Center Author of Mastering RMI Email: [EMAIL PROTECTED] -- End of Forwarded Message
cvs commit: jakarta-tomcat-connectors/webapp README.txt
pier01/08/06 14:26:11 Modified:webapp README.txt Log: Describe what's up with --with-tomcat in the configure script. Revision ChangesPath 1.13 +7 -7 jakarta-tomcat-connectors/webapp/README.txt Index: README.txt === RCS file: /home/cvs/jakarta-tomcat-connectors/webapp/README.txt,v retrieving revision 1.12 retrieving revision 1.13 diff -u -r1.12 -r1.13 --- README.txt2001/07/26 17:27:01 1.12 +++ README.txt2001/08/06 21:26:10 1.13 @@ -52,17 +52,17 @@ --with-java[=JAVA_HOME] Compile also the Java portion of WebApp. If the JAVA_HOME variable is not set in your environment, you'll have to specify the root -path of your JDK installation on this command line. To compile -the Java classes, you will need to set your CLASSPATH variable to -include the catalina.jar and servlet.jar distributed with -Tomcat 4.0. For example: - # CLASSPATH=$CATALINA_HOME/server/lib/catalina.jar - # CLASSPATH=$CLASSPATH:$CATALINA_HOME/common/lib/servlet.jar - # export CLASSPATH +path of your JDK installation on this command line. This will generate a new warp.jar file in the java directory that you must use instead of the one provided with the default Tomcat distribution. For example: # mv ./java/warp.jar $CATALINA_HOME/server/lib/warp.jar + +--with-tomcat[=TOMCAT_HOME] +When compiling the Java portion of WebApp, you will also need to +specify where a Tomcat 4.0 distribution can be found. This will +automatically set up your CLASSPATH environment with the required +JAR files included with Tomcat 4.0. --enable-debug Enable compiled-in debugging output. Using this option the WebApp
cvs commit: jakarta-tomcat-4.0/service/support apsupport.m4
jfclere 01/08/06 14:54:33
Modified:service configure.in
service/native java.c location.c
service/support apsupport.m4
Log:
Add support from cygwin.
Revision ChangesPath
1.2 +6 -2 jakarta-tomcat-4.0/service/configure.in
Index: configure.in
===
RCS file: /home/cvs/jakarta-tomcat-4.0/service/configure.in,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- configure.in 2001/06/26 01:31:29 1.1
+++ configure.in 2001/08/06 21:54:33 1.2
@@ -57,7 +57,7 @@
dnl -
dnl Author Pier Fumagalli mailto:[EMAIL PROTECTED]
-dnl Version $Id: configure.in,v 1.1 2001/06/26 01:31:29 pier Exp $
+dnl Version $Id: configure.in,v 1.2 2001/08/06 21:54:33 jfclere Exp $
dnl -
dnl -
@@ -107,12 +107,16 @@
unset _prevdir
else
CFLAGS=$CFLAGS -I$JAVA_HOME/include -I$JAVA_HOME/include/$supported_os
- LDFLAGS=$LDFLAGS -ldl
+ if test $supported_os != win32
+ then
+LDFLAGS=$LDFLAGS -ldl
+ fi
fi
if test $supported_os = solaris
then
LDFLAGS=$LDFLAGS -lthread
fi
+
dnl -
dnl Random programs we need to compile locally
1.3 +4 -1 jakarta-tomcat-4.0/service/native/java.c
Index: java.c
===
RCS file: /home/cvs/jakarta-tomcat-4.0/service/native/java.c,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- java.c2001/06/26 03:24:52 1.2
+++ java.c2001/08/06 21:54:33 1.3
@@ -55,9 +55,12 @@
* *
* = */
-/* @version $Id: java.c,v 1.2 2001/06/26 03:24:52 pier Exp $ */
+/* @version $Id: java.c,v 1.3 2001/08/06 21:54:33 jfclere Exp $ */
#include jsvc.h
+#ifdef OS_CYGWIN
+typedef long long __int64;
+#endif
#include jni.h
static JavaVM *jvm=NULL;
1.2 +7 -1 jakarta-tomcat-4.0/service/native/location.c
Index: location.c
===
RCS file: /home/cvs/jakarta-tomcat-4.0/service/native/location.c,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- location.c2001/06/26 01:37:41 1.1
+++ location.c2001/08/06 21:54:33 1.2
@@ -55,7 +55,7 @@
* *
* = */
-/* @version $Id: location.c,v 1.1 2001/06/26 01:37:41 pier Exp $ */
+/* @version $Id: location.c,v 1.2 2001/08/06 21:54:33 jfclere Exp $ */
#include jsvc.h
/* Locations of various JVM files. We have to deal with all this madness since
@@ -74,6 +74,8 @@
#elif defined(OS_LINUX) || defined(OS_SOLARIS) || defined(OS_BSD)
/usr/java,
/usr/local/java,
+#elfif define(OS_CYGWIN)
+/cygdrive/c/WINNT/system32/java,
#endif
NULL,
};
@@ -94,6 +96,8 @@
char *location_jvm_default[] = {
#if defined(OS_DARWIN)
$JAVA_HOME/../Libraries/libjvm.dylib,
+#elif defined(OS_CYGWIN)
+$JAVA_HOME/jre/bin/classic/jvm.dll, // Sun JDK 1.3
#elif defined(OS_LINUX) || defined(OS_SOLARIS) || defined(OS_BSD)
$JAVA_HOME/jre/lib/ CPU /classic/libjvm.so, // Sun JDK 1.2
$JAVA_HOME/jre/lib/ CPU /client/libjvm.so, // Sun JDK 1.3
@@ -129,6 +133,8 @@
char *location_jvm_configured[] = {
#if defined(OS_DARWIN)
$JAVA_HOME/../Libraries/lib$VM_NAME.dylib,
+#elif defined(OS_CYGWIN)
+$JAVA_HOME/jre/bin/$VM_NAME/jvm.dll, // Sun JDK 1.3
#elif defined(OS_LINUX) || defined(OS_SOLARIS) || defined(OS_BSD)
$JAVA_HOME/jre/lib/ CPU /$VM_NAME/libjvm.so,// Sun JDK 1.3
$JAVA_HOME/lib/ CPU /$VM_NAME/libjvm.so,// Sun JRE 1.3
1.2 +5 -1 jakarta-tomcat-4.0/service/support/apsupport.m4
Index: apsupport.m4
===
RCS file: /home/cvs/jakarta-tomcat-4.0/service/support/apsupport.m4,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- apsupport.m4 2001/06/26 01:33:16 1.1
+++ apsupport.m4 2001/08/06 21:54:33 1.2
@@ -57,7 +57,7 @@
dnl -
dnl Author Pier Fumagalli mailto:[EMAIL PROTECTED]
-dnl Version $Id: apsupport.m4,v 1.1 2001/06/26 01:33:16 pier
cvs commit: jakarta-tomcat-connectors/webapp Makefile.in configure.in
pier01/08/06 15:21:52
Modified:webapp Makefile.in configure.in
Log:
Finishing touch to build process. Re-enabling APR configure calls and
modified global Makefile to use the right discovered binaries.
Revision ChangesPath
1.15 +28 -26jakarta-tomcat-connectors/webapp/Makefile.in
Index: Makefile.in
===
RCS file: /home/cvs/jakarta-tomcat-connectors/webapp/Makefile.in,v
retrieving revision 1.14
retrieving revision 1.15
diff -u -r1.14 -r1.15
--- Makefile.in 2001/08/06 02:47:21 1.14
+++ Makefile.in 2001/08/06 22:21:52 1.15
@@ -56,7 +56,7 @@
# = #
# @author Pier Fumagalli mailto:[EMAIL PROTECTED]
-# @version $Id: Makefile.in,v 1.14 2001/08/06 02:47:21 pier Exp $
+# @version $Id: Makefile.in,v 1.15 2001/08/06 22:21:52 pier Exp $
include @SRCDIR@/Makedefs
@@ -64,7 +64,7 @@
APRDIR = @APRDIR@
CFGS = @CONFIGFILES@ \
- ./lib/pr_warp_defs.h \
+ @SRCDIR@/lib/pr_warp_defs.h \
config.cache \
config.log \
config.status
@@ -74,61 +74,63 @@
clean: apr-clean local-clean
distclean: clean
- @echo Removing configure generated files...
- @rm -f $(CFGS)
+ @$(ECHO)
+ @$(ECHO) Removing configure generated files...
+ @$(RM) -f $(CFGS)
cvsclean: distclean
- @echo Removing configure script...
- @rm -f configure
+ @$(ECHO)
+ @$(ECHO) Removing configure script...
+ @$(ECHO) -f configure
apr-all:
@for DIR in $(APRDIR) ; do \
- echo ; \
- echo Compiling sources in $$DIR... ; \
- cd $$DIR ; \
+ $(ECHO) ; \
+ $(ECHO) Compiling sources in $${DIR}... ; \
+ cd $${DIR} ; \
$(MAKE) all ; \
RET=$$? ; \
cd $(SRCDIR) ; \
- if test $$RET != 0 ; then \
- exit $$RET ; \
+ if $(TEST) $${RET} != 0 ; then \
+ exit $${RET} ; \
fi ; \
done
apr-clean:
@for DIR in $(APRDIR) ; do \
- echo ; \
- echo Cleaning up $$DIR... ; \
- cd $$DIR ; \
+ $(ECHO) ; \
+ $(ECHO) Cleaning up $${DIR}... ; \
+ cd $${DIR} ; \
$(MAKE) clean ; \
RET=$$? ; \
cd $(SRCDIR) ; \
- if test $$RET != 0 ; then \
- exit $$RET ; \
+ if test $${RET} != 0 ; then \
+ exit $${RET} ; \
fi ; \
done
local-all:
@for DIR in $(LOCALDIRS) ; do \
- echo ; \
- echo Compiling sources in $$DIR... ; \
- cd $$DIR ; \
+ $(ECHO) ; \
+ $(ECHO) Compiling sources in $${DIR}... ; \
+ cd $${DIR} ; \
$(MAKE) all ; \
RET=$$? ; \
cd $(SRCDIR) ; \
- if test $$RET != 0 ; then \
- exit $$RET ; \
+ if test $${RET} != 0 ; then \
+ exit $${RET} ; \
fi ; \
done
local-clean:
@for DIR in $(LOCALDIRS) ; do \
- echo ; \
- echo Cleaning up $$DIR... ; \
- cd $$DIR ; \
+ $(ECHO) ; \
+ $(ECHO) Cleaning up $${DIR}... ; \
+ cd $${DIR} ; \
$(MAKE) clean ; \
RET=$$? ; \
cd $(SRCDIR) ; \
- if test $$RET != 0 ; then \
- exit $$RET ; \
+ if test $${RET} != 0 ; then \
+ exit $${RET} ; \
fi ; \
done
1.21 +6 -6 jakarta-tomcat-connectors/webapp/configure.in
Index: configure.in
===
RCS file: /home/cvs/jakarta-tomcat-connectors/webapp/configure.in,v
retrieving revision 1.20
retrieving revision 1.21
diff -u -r1.20 -r1.21
--- configure.in 2001/08/06 21:02:27 1.20
+++ configure.in 2001/08/06 22:21:52 1.21
@@ -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.20 2001/08/06 21:02:27 pier Exp $
+dnl Version $Id: configure.in,v 1.21 2001/08/06 22:21:52 pier Exp $
dnl --
dnl --
@@ -245,17 +245,17 @@
cd ${APRDIR}
LOCAL_HEADER([Building APR configure
cvs commit: jakarta-tomcat-connectors/webapp/apache-1.3 Makefile.in
pier01/08/06 15:48:45
Modified:webapp configure.in
webapp/apache-1.3 Makefile.in
Log:
Fixed small linking error in mod_webapp.so.
Revision ChangesPath
1.22 +2 -3 jakarta-tomcat-connectors/webapp/configure.in
Index: configure.in
===
RCS file: /home/cvs/jakarta-tomcat-connectors/webapp/configure.in,v
retrieving revision 1.21
retrieving revision 1.22
diff -u -r1.21 -r1.22
--- configure.in 2001/08/06 22:21:52 1.21
+++ configure.in 2001/08/06 22:48:45 1.22
@@ -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.21 2001/08/06 22:21:52 pier Exp $
+dnl Version $Id: configure.in,v 1.22 2001/08/06 22:48:45 pier Exp $
dnl --
dnl --
@@ -254,8 +254,7 @@
LOCAL_HEADER([Configuring APR])
LOCAL_FILTEREXEC(
[./configure --enable-static --disable-shared --disable-threads],
- [APR configure]
-)
+ [APR configure])
if ${TEST} ${ret} -ne 0
then
AC_MSG_ERROR([APR configure script terminated with error code ${ret}])
1.8 +2 -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.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- Makefile.in 2001/08/06 21:30:11 1.7
+++ Makefile.in 2001/08/06 22:48:45 1.8
@@ -56,7 +56,7 @@
# = #
# @author Pier Fumagalli mailto:[EMAIL PROTECTED]
-# @version $Id: Makefile.in,v 1.7 2001/08/06 21:30:11 pier Exp $
+# @version $Id: Makefile.in,v 1.8 2001/08/06 22:48:45 pier Exp $
include @SRCDIR@/Makedefs
@@ -90,7 +90,7 @@
@$(SHELL) $(LIBTOOL) $(LTFLAGS) --mode=link \
$(APXS_LD_SHLIB) $(APXS_LDFLAGS_SHLIB) \
mod_webapp.lo @SRCDIR@/lib/libwebapp.la \
- $(LIBTOOL_LIBS) $(EXTRA_LIBS) \
+ $(LIBTOOL_LIBS) $(EXTRA_LIBS) @APRDIR@/libapr.la \
-o mod_webapp.so
clean:
[PATCH] ajp13 logs 500 code on stop button
This is only a cosmetic patch, so it may not make the cut for TC3.3, but the diff is against TC3.3B1. At the moment, when the user hits the stop button, it shows up in the Apache logs with a status code of 500 (regardless of the status code returned by Tomcat). With this patch, the Apache logs show the status code returned by Tomcat (hopefully 200 in most cases). The fail-over logic is otherwise unchanged. jk_ajp13_worker.diff
Re: listener-class
On Mon, 6 Aug 2001, Andrew Arrow wrote: I added this to my web.xml file: listener listener-class com.mystuff.SessionListener /listener-class /listener I put a HashTable in the class and add each session to the table every time sessionCreated is called. I'd like to be able to access the same instance of com.mystuff.SessionListener that Tomcat is using from a jsp page. (i.e. I want the JSP page to display a list of all the sessions in the hashtable.) If I say: jsp:useBean id=test scope=application class=com.mystuff.SessionListener / I'll get a new instance of the class right? I want the SAME instance. Anyway to do this? This question is more appropriate on TOMCAT-USER, but ... All your JSP pages will get a reference to the same application-scope instance, but it will be different from the instance created by the servlet container. Nobody but the container has a reference to that instance. The best approach to a problem like this is to store the Hashtable itself as an application-scope bean (same as a servlet context attribute from the perspective of the listener). That way, your JSP pages have access to the collection containing all the sessions, without worrying about the object that is actually maintaining the collection. Craig
Re: FW: Velocity and JSP speed testing...
On Mon, 6 Aug 2001, Jon Stevens wrote: Not exactly scientific, but I do trust Rickard to do things correctly...he has an existing JSP page for testing and then converted it to Velocity...here are the results... JSP - 240-480ms Velocity - 50-70ms Frankly, I'm astounded it took you so long to figure out that you had a legitimate case on performance ... at least versus Jasper :-). Try this on some other containers and you will find different results. Orion, Resin, and WebLogic are supposed to have pretty fast implementations. You make the decision. :-) I did ... the code that Jasper generates is not optimized at all, so doing a decent optimizing compiler will make a pretty dramatic difference. Watch this space. :-) -jon Craig (who is actually quite happy with Catalina at this point :-)
Re: Velocity and JSP speed testing...
Craig R. McClanahan at [EMAIL PROTECTED] wrote: -jon Craig (who is actually quite happy with Catalina at this point :-) Never been a fan of JSPs myself, but seeing Velocity (lately I had to install it for EyeBrowse on Nagoya, and it was painful) I'm not a big fan of that thing either. But anyway, coming out of the blue on that, I'm pretty damn tired of this whole argument about Velocity VS. JSPs thing... Tomcat IS the R.I. for Servlets AND JSPs, that's what we agreed on with Sun from the very first time, that's what I keep believing into. So, please, both of you (yeah, I'm going to say shut up to my project lead) SHUT UP. I don't give a damn on which one is faster/better. We're here to talk about the development of one product. If you were new users being moderated I would reject your postings as OFF-TOPIC. Especially you, Jon. Damn it, we've walked this path together for a very long time. And _as_a_friend_ I'm begging you, if you want to keep going on with your crusade against JSPs do it, but be wise enough to do it in the right places... Thanks... Pier
Re: Velocity and JSP speed testing...
on 8/6/01 7:45 PM, Pier P. Fumagalli [EMAIL PROTECTED] wrote: Never been a fan of JSPs myself, but seeing Velocity (lately I had to install it for EyeBrowse on Nagoya, and it was painful) I'm not a big fan of that thing either. Installation != Use Remember the old JServ 1.0 days when it *sucked* to install it, but it was still pretty damn good software that *you* were proud of? :-) Especially you, Jon. Damn it, we've walked this path together for a very long time. And _as_a_friend_ I'm begging you, if you want to keep going on with your crusade against JSPs do it, but be wise enough to do it in the right places... Sorry Pier. I think that performance testing and results of Tomcat 4.0 is perfectly legal here. Especially in the context of competition with JSP. Lets not fool our users into thinking that the ASF is producing the fastest JSP implementation. Oh wait. That's obvious. :-) The fact that I throw in quips about how JSP sucks balls is my own gibberish that you are just going to have to put up with. Sorry. :-) -jon
Re: Velocity and JSP speed testing...
on 8/6/01 7:18 PM, Craig R. McClanahan [EMAIL PROTECTED] wrote: On Mon, 6 Aug 2001, Jon Stevens wrote: Not exactly scientific, but I do trust Rickard to do things correctly...he has an existing JSP page for testing and then converted it to Velocity...here are the results... JSP - 240-480ms Velocity - 50-70ms Frankly, I'm astounded it took you so long to figure out that you had a legitimate case on performance ... at least versus Jasper :-). It wasn't my posting. I was forwarding another posting. So, the you should be directed at the original poster. That said, the previous results that I had achieved were a quite bit closer than those though. The above is pretty astounding. Try this on some other containers and you will find different results. Orion, Resin, and WebLogic are supposed to have pretty fast implementations. Rickard did. Velocity was either on par or faster. Read the Velocity-dev archives. I did ... the code that Jasper generates is not optimized at all, so doing a decent optimizing compiler will make a pretty dramatic difference. Watch this space. :-) Ok. Craig (who is actually quite happy with Catalina at this point :-) I'm pretty happy with the container. Jasper still sucks...regardless of it being a JSP implementation. :-) p.s. Even though Tomcat is supposed to be more concerned with the R.I. status, people are using it for more than that and are depending on it. *I think* it is ludicrous to assume otherwise as well as to force people to purchase commercial implementations in order to get a decently performing engine. -jon
Re: Velocity and JSP speed testing...
Craig R. McClanahan at [EMAIL PROTECTED] wrote: -jon Craig (who is actually quite happy with Catalina at this point :-) Never been a fan of JSPs myself, but seeing Velocity (lately I had to install it for EyeBrowse on Nagoya, and it was painful) I'm not a big fan of that thing either. But anyway, coming out of the blue on that, I'm pretty damn tired of this whole argument about Velocity VS. JSPs thing... Tomcat IS the R.I. for Servlets AND JSPs, that's what we agreed on with Sun from the very first time, that's what I keep believing into. So, please, both of you (yeah, I'm going to say shut up to my project lead) SHUT UP. Behave ;-) I don't give a damn on which one is faster/better. We're here to talk about the development of one product. If you were new users being moderated I would reject your postings as OFF-TOPIC. I don't really agree in general, although here Jon's post is not very useful, since there are no details at all on the benchmark. At least, we can use that as a motivation to improve Jasper so we don't look as bad ;-) Remy
Re: FW: Velocity and JSP speed testing...
When I switched my projects from JSP to Velocity, I did it more for: - simplicity of the language (VTL) - taking away (from web designers) the power to write/execute Java directly but if it's fast as well, even better :-) Bojan PS. It does take longer to get the first page. Velocity has to start and all... Jon Stevens wrote: Not exactly scientific, but I do trust Rickard to do things correctly...he has an existing JSP page for testing and then converted it to Velocity...here are the results... JSP - 240-480ms Velocity - 50-70ms You make the decision. :-) -jon -- Forwarded Message From: Rickard Öberg [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Date: Mon, 06 Aug 2001 17:41:37 +0200 To: [EMAIL PROTECTED] Cc: Webwork-User [EMAIL PROTECTED] Subject: Re: Velocity monthlist Rickard Öberg wrote: Ok guys, this is latest(-ish) Catalina sources. I tried hitting the page a couple of hundred times before checking the time, and it stabilized at scores around 50-70ms. So, that's like, 6 times faster than the same JSP running on Tomcat 3.2. And the VM was direct converted, almost line by line, since the WebWork taglib is very similar to the Velocity directives, so it's a quite fair comparison. And to make this comparison even more fair, I just tested the JSP page on the same Catalina build, and it scored between 240-480ms. So, not only is it slower, it is more fluctuating (and I also think I dare say that the JSP taglib in WebWork is as optimized as it can be). Interesting... /Rickard -- Rickard Öberg Software Development Specialist xlurc - Xpedio Linköping Ubiquitous Research Center Author of Mastering RMI Email: [EMAIL PROTECTED] -- End of Forwarded Message
Re: Velocity and JSP speed testing...
Totally OT, bandwidth-wasting, irrelevant musings P.S. ... Where did that Paulo Gaspar cat go? That guy was always interesting in a flame war, especially with Jon involved. Man ... dude did NOT like Jon, but he sure loved Velocity. I wonder he went ... I really miss those days, back when we were all so young and innocent ... it was a simpler time ;-) Anyway, Jon, I always thought that you should have used some of those flame posts from Gaspar for some really sweet Velocity advocacy, maybe in your mag articles and web site and stuff. I can hardly think of a more compelling advertisement for Velocity than one of those, Jon is in insufferable ass, but I wouldn't use any other solution than Velocity. That speaks volumes. I really do miss that Gaspar guy though ... we liked him :-) - Christopher
Re: Velocity and JSP speed testing...
on 8/6/01 9:24 PM, Christopher Cain [EMAIL PROTECTED] wrote:
Totally OT, bandwidth-wasting, irrelevant musings P.S. ...
Where did that Paulo Gaspar cat go? That guy was always interesting in a flame
war, especially with Jon involved. Man ... dude did NOT like Jon, but he sure
loved Velocity. I wonder he went ... I really miss those days, back when we
were all so young and innocent ... it was a simpler time ;-)
Anyway, Jon, I always thought that you should have used some of those flame
posts from Gaspar for some really sweet Velocity advocacy, maybe in your mag
articles and web site and stuff. I can hardly think of a more compelling
advertisement for Velocity than one of those, Jon is in insufferable ass, but
I wouldn't use any other solution than Velocity. That speaks volumes.
I really do miss that Gaspar guy though ... we liked him :-)
- Christopher
He is over on the Velocity lists being a pain in the ass still. :-)
I just love him.
Our last flame war was about me wanting to get rid of the dynamic logging in
Velocity and just make a dependency on Log4J. Eventually, I think he just
gave up. Now that Ceki has the 25k .jar file, it is no contest.
:-)
p.s. Below is a recent privately sent email that I got about the JDJ article
I wrote...name/company removed to protect this fine enlightened individual.
:-)
-jon
Dear Jon,
I have just finished reading your article evaluating JSP in the July issue
of Java Developers Journal. Thank you for your very thoughtful analysis of
JSP and the use of alternatives. My company does not use Velocity, but we
could have written this article years ago. Our team consists of four
people who are all Java programmers. Three years ago when everybody else
was just doing out.print lines from servlets, we saw the need for a
template based approached to embedding reusable code elements in HTML
pages. So we wrote a template parsing engine that takes in an HTML page,
parses out tags that look like {%PAGE_VAL namedThis%} and outputs a
page. The servlet code handles everything a web application ever needs
such as database connections, SQL, math, array handling, user objects,
caching, etc. and the templates themselves act in a consequence free
environment where all errors are caught and simply explained back to the
designer or user. When a client's project demands custom code, we simple
extend the basic tag parsing engine and code the processing of the custom
tag elements.
We built this architecture for convenience and because there was nothing
like available at at the time. But throughout the emergence of JSP 1.1, we
have looked to migrate away from our home grown solution to move to a more
industry standard solution for our clients. The problem is the closer we
get to developing in JSP, the more we started to really hate it. We hate it
for all of the reasons you describe in your article. I think one of your
best points is how JSP is really only a solution for Java
programmers. That being said, we are a team of all Java programmers, and
we are still running screaming away from it. As much as we enjoy writing
code, we don't want a line of it inside our HTML pages.
Thank you very much for thinking outside the JSP box, and helping us
justify the techniques we believe are best for ourselves and our clients.
Re: Catalina Startup Hook
On Mon, 6 Aug 2001, Christopher Cain wrote: I need a quick jumpstart on how to hook my password prompter into the Catalina startup process. I assume that I shouldn't implement it as a Valve, as those have to do with the Request/Response chain. The Connector level in server.xml appears to be the appropriate level in the hierarchy, but it's not really a connecter per se, since its lifecycle is complete before the startup process even finishes (i.e. it doesn't need to sit in the service and pass requests off to the engine). Valves are designed for request processing, not component startup and shutdown. See below for an alternative suggestion. So is there a more generic module architecture in place that I should implement? I just need a quick, high-level idea of what internal component to use and how to implement that component in the server.xml config. The simplest approach to your particular issue would be to create a class that implements the org.apache.catalina.LifecycleListener interface, and then nest a Listener element inside the SSL-based Connector element that creates an instance of that listener, associated with the correspondeing connector. Now, the lifecycleEvent() method will be fired when this Connector is started up (and when it is shut down), so you can interject your dialog with the user at that point. Just look for an event of type Lifecycle.START_EVENT. Note that the Lifecycle element, like most elements in server.xml, can dynamically map the XML attributes specified in the Listener element to corresponding bean properties on your LifecycleListener class. This is tremendously useful for configuring the behavior of your listener. The only required attribute is className, which specifies the fully qualified classname of your class itself. It won't help for this particular use case, but lifecycle listeners can also be nested inside Engine, Host, and Context elements, depending on what kind of startup and shutdown events you care about. TIA Regards, Christopher Craig
Re: Catalina Startup Hook (actually, both camps should read this :-)
Quoting Craig R. McClanahan [EMAIL PROTECTED]: Valves are designed for request processing, not component startup and shutdown. See below for an alternative suggestion. Yep, that's the general conslusion I came to in looking over the codebase. Cool, at least I know I can still RTFS and get it right (on occasion) :-) The simplest approach to your particular issue would be to create a class that implements the org.apache.catalina.LifecycleListener interface, and then nest a Listener element inside the SSL-based Connector element that creates an instance of that listener, associated with the correspondeing connector. Now, the lifecycleEvent() method will be fired when this Connector is started up (and when it is shut down), so you can interject your dialog with the user at that point. Just look for an event of type Lifecycle.START_EVENT. Exactly what I needed to know. Thanks! Note that the Lifecycle element, like most elements in server.xml, can dynamically map the XML attributes specified in the Listener element to corresponding bean properties on your LifecycleListener class. This is tremendously useful for configuring the behavior of your listener. The only required attribute is className, which specifies the fully qualified classname of your class itself. It won't help for this particular use case, but lifecycle listeners can also be nested inside Engine, Host, and Context elements, depending on what kind of startup and shutdown events you care about. WARNING: KODAK MOMENT TO FOLLOW ... Man ... after more than a year, I am FINALLY starting to understand why the whole 3.x vs 4.0 war was so fiercely waged. In the process of implementing this little module of mine for both trees, I have to say that they are BOTH, really, damn clever solutions. I mean, I'm sure the resident experts in each camp each have their little nitpicks with the other codebase. But I have to say, from someone without a great deal of personal investment in either tree in particular, ALL of you people should be damn proud. Costin (et. al) with his hooks and interceptors ... Craig (et. al) with his valves and listeners ... you guys and your respective posses have BOTH designed an incredible product. The more I dig into both trees, the more impressed I am with both. As far as I'm concerned, personally, arguing over which is the superior design would be alot like arguing over whether to take the Porche or the Jag out for a spin. People might have their slight personal preferences, but at the end of the day, your driving a DAMN fine machine either way. Anyway, I'm not trying to stir up anything at all, and I DEFINITELY don't want to drag the 3 vs 4 thing back out of the closet. (PLASE, if there are any list newbies reading, do NOT reply to this with some kind of feature comparison or other opinion on which is better ... you'll get me in all sorts of trouble in here :-) I just wanted to say what I didn't have the knowledge or experience to say at the time: the greatest testament to the entire Tomcat project is the fact that we were fortunate enough to be in the akward position of deciding between these two codebases. Because I GUARANTEE you, any strictly-proprietary software vendor on the planet would absolutely SALIVATE if given the chance to have originally based a closed, commercial product on either one of these two designs. You could kick the crap out the competition with either of them (the other codebase excluded, of course ;-) ... they're that good. Anyway, that's just how I feel, and I look forward to continuing work in both (easy for me to say, I like to develop plugins =) Regards, Christopher
Re: [Fwd: GTest in watchdog fails with Apache...]
On Mon, Aug 06, 2001 at 05:25:03PM +0100, Pier P. Fumagalli wrote: Justin Erenkrantz at [EMAIL PROTECTED] wrote: On Mon, Aug 06, 2001 at 11:17:18AM +0200, jean-frederic clere wrote: I have tested it with 1.3.20 it behaves the same way. This is correct behavior on httpd's part. It is a bug in Tomcat (rather the Watchdog test). The server should respond with the highest HTTP version it supports. Somewhere in the RFC is the rules for how to determine whether it should be upgraded or not (it must still be parsable by the original request version). Roy or someone else can jump in here if they want to discuss that vagaries of upgrading the response version, but this is expected behavior. -- justin I can't find this written anywhere in the HTTP spec (rfc 2616). Section 6.1 describes how the first line of an HTTP response is composed, but it doesn't say anything about the version number to be used. I can assume (by some observations made on what's going on between my client (OmniWeb PRO 4.01 for OS/X) and Apache, that the client posts a request as HTTP/1.0, if the response is HTTP/1.1, then all following requests will be made with the upgraded protocol version... But actually the spec (as far as I can see from a brief re-reading) doesn't specify anything about it... Let the spec war begin. =-) RFC 2616 - Section 3.1 - HTTP Version: The HTTP version of an application is the highest HTTP version for which the application is at least conditionally compliant. RFC 2145 goes into specific detail about this problem (what to send) - see Section 2.3: --- An HTTP client SHOULD send a request version equal to the highest version for which the client is at least conditionally compliant, and whose major version is no higher than the highest version supported by the server, if this is known. An HTTP client MUST NOT send a version for which it is not at least conditionally compliant. An HTTP client MAY send a lower request version, if it is known that the server incorrectly implements the HTTP specification, but only after the client has determined that the server is actually buggy. An HTTP server SHOULD send a response version equal to the highest version for which the server is at least conditionally compliant, and whose major version is less than or equal to the one received in the request. An HTTP server MUST NOT send a version for which it is not at least conditionally compliant. A server MAY send a 505 (HTTP Version Not Supported) response if cannot send a response using the major version used in the client's request. --- Of course, I could be misunderstanding it all. But, the chances of httpd's HTTP parser being incorrect w.r.t. the spec or the intent of the authors is very very slim. FWIW, IIS and iPlanet both behave identically to Apache (try out microsoft.com and netscape.com). I'll now get out of the way to make room for the spec police. -- justin
Re: [Fwd: GTest in watchdog fails with Apache...]
Thanks Justin ... my initial assumption was that Apache would be doing this right, considering all the people involved ... :-) I'll fix the Watchdog test so that it reacts to this correctly. Craig On Mon, 6 Aug 2001, Justin Erenkrantz wrote: On Mon, Aug 06, 2001 at 05:25:03PM +0100, Pier P. Fumagalli wrote: Justin Erenkrantz at [EMAIL PROTECTED] wrote: On Mon, Aug 06, 2001 at 11:17:18AM +0200, jean-frederic clere wrote: I have tested it with 1.3.20 it behaves the same way. This is correct behavior on httpd's part. It is a bug in Tomcat (rather the Watchdog test). The server should respond with the highest HTTP version it supports. Somewhere in the RFC is the rules for how to determine whether it should be upgraded or not (it must still be parsable by the original request version). Roy or someone else can jump in here if they want to discuss that vagaries of upgrading the response version, but this is expected behavior. -- justin I can't find this written anywhere in the HTTP spec (rfc 2616). Section 6.1 describes how the first line of an HTTP response is composed, but it doesn't say anything about the version number to be used. I can assume (by some observations made on what's going on between my client (OmniWeb PRO 4.01 for OS/X) and Apache, that the client posts a request as HTTP/1.0, if the response is HTTP/1.1, then all following requests will be made with the upgraded protocol version... But actually the spec (as far as I can see from a brief re-reading) doesn't specify anything about it... Let the spec war begin. =-) RFC 2616 - Section 3.1 - HTTP Version: The HTTP version of an application is the highest HTTP version for which the application is at least conditionally compliant. RFC 2145 goes into specific detail about this problem (what to send) - see Section 2.3: --- An HTTP client SHOULD send a request version equal to the highest version for which the client is at least conditionally compliant, and whose major version is no higher than the highest version supported by the server, if this is known. An HTTP client MUST NOT send a version for which it is not at least conditionally compliant. An HTTP client MAY send a lower request version, if it is known that the server incorrectly implements the HTTP specification, but only after the client has determined that the server is actually buggy. An HTTP server SHOULD send a response version equal to the highest version for which the server is at least conditionally compliant, and whose major version is less than or equal to the one received in the request. An HTTP server MUST NOT send a version for which it is not at least conditionally compliant. A server MAY send a 505 (HTTP Version Not Supported) response if cannot send a response using the major version used in the client's request. --- Of course, I could be misunderstanding it all. But, the chances of httpd's HTTP parser being incorrect w.r.t. the spec or the intent of the authors is very very slim. FWIW, IIS and iPlanet both behave identically to Apache (try out microsoft.com and netscape.com). I'll now get out of the way to make room for the spec police. -- justin
