Can't get mod_webapp.c to compile
If there is something really obvious I'm missing please let me know. I just can't get mod_webapp.c to compile. Please help!! make results below. Regards Paul Smyth. [EMAIL PROTECTED] Make results: Compiling Apache 1.3 WebApp module mod_webapp.c:77: parse error before `webapp_module' mod_webapp.c:77: warning: data definition has no type or storage class mod_webapp.c:90: parse error before `pool' mod_webapp.c:97: parse error before `pool' mod_webapp.c: In function `wam_startup': mod_webapp.c:99: `s' undeclared (first use in this function) mod_webapp.c:99: (Each undeclared identifier is reported only once mod_webapp.c:99: for each function it appears in.) mod_webapp.c: At top level: mod_webapp.c:104: parse error before `*' mod_webapp.c: In function `wam_server': mod_webapp.c:127: request for member `module_index' in something not a structure or union mod_webapp.c:145: request for member `module_index' in something not a structure or union mod_webapp.c: In function `wa_log': mod_webapp.c:270: warning: passing arg 4 of `ap_log_error' makes integer from pointer without a cast mod_webapp.c:270: warning: passing arg 5 of `ap_log_error' from incompatible pointer type mod_webapp.c: In function `wam_handler_log': mod_webapp.c:278: warning: passing arg 4 of `ap_log_error' makes integer from pointer without a cast mod_webapp.c:278: warning: passing arg 5 of `ap_log_error' from incompatible pointer type mod_webapp.c: In function `wam_handler_setctype': mod_webapp.c:294: warning: assignment makes pointer from integer without a cast mod_webapp.c: In function `wam_match': mod_webapp.c:386: request for member `module_index' in something not a structure or union mod_webapp.c:401: warning: assignment makes pointer from integer without a cast mod_webapp.c:404: request for member `module_index' in something not a structure or union mod_webapp.c: In function `wam_invoke': mod_webapp.c:424: request for member `module_index' in something not a structure or union mod_webapp.c:429: warning: passing arg 4 of `ap_log_error' makes integer from pointer without a cast mod_webapp.c:429: warning: passing arg 5 of `ap_log_error' from incompatible pointer type mod_webapp.c:436: too few arguments to function `ap_get_remote_host' mod_webapp.c:443: request for member `sin_port' in something not a structure or union mod_webapp.c:443: request for member `sin_port' in something not a structure or union mod_webapp.c:443: request for member `sin_port' in something not a structure or union mod_webapp.c:443: request for member `sin_port' in something not a structure or union mod_webapp.c:444: request for member `sin_port' in something not a structure or union mod_webapp.c:444: request for member `sin_port' in something not a structure or union mod_webapp.c:444: request for member `sin_port' in something not a structure or union mod_webapp.c:444: request for member `sin_port' in something not a structure or union mod_webapp.c:452: structure has no member named `user' mod_webapp.c:453: structure has no member named `ap_auth_type' mod_webapp.c:460: `array_header' undeclared (first use in this function) mod_webapp.c:460: `arr' undeclared (first use in this function) mod_webapp.c:461: `table_entry' undeclared (first use in this function) mod_webapp.c:461: `ele' undeclared (first use in this function) mod_webapp.c:461: parse error before `)' mod_webapp.c:465: `x' undeclared (first use in this function) mod_webapp.c: At top level: mod_webapp.c:492: parse error before `wam_handlers' mod_webapp.c:493: warning: braces around scalar initializer mod_webapp.c:493: warning: (near initialization for `wam_handlers[0]') mod_webapp.c:493: warning: initialization makes integer from pointer without a cast mod_webapp.c:493: warning: excess elements in scalar initializer mod_webapp.c:493: warning: (near initialization for `wam_handlers[0]') mod_webapp.c:494: warning: braces around scalar initializer mod_webapp.c:494: warning: (near initialization for `wam_handlers[1]') mod_webapp.c:494: warning: initialization makes integer from pointer without a cast mod_webapp.c:495: warning: data definition has no type or storage class mod_webapp.c:498: parse error before `webapp_module' mod_webapp.c:499: `this_module_needs_to_be_ported_to_apache_2_0' undeclared here (not in a function) mod_webapp.c:499: initializer element is not constant mod_webapp.c:499: (near initialization for `webapp_module') mod_webapp.c:500: warning: excess elements in scalar initializer mod_webapp.c:500: warning: (near initialization for `webapp_module') mod_webapp.c:501: warning: excess elements in scalar initializer mod_webapp.c:501: warning: (near initialization for `webapp_module') mod_webapp.c:502: warning: excess elements in scalar initializer mod_webapp.c:502: warning: (near initialization for `webapp_module') mod_webapp.c:503: warning: excess elements in scalar initializer mod_webapp.c:503: warning: (near initialization for `webapp_module') mod_webapp.c:504: warning: excess elements in
Web server integration / NameTrans stage
I've been looking at the existing web server integration stuff (both mod_jk and mod_webapp), and it seems to me that there is one significant piece missing - a NameTrans directive that takes its configuration from a separate file. I know I'm talking iPlanet here - but that's where my experience is. At the moment I'm running a bodged together iPlanet / Tomcat 4 combo where the servlet requests are http-proxied to Tomcat, but I need to to the NameTrans part myself: NameTrans fn=assign-name from=/myapp/firsturl name=tomcat NameTrans fn=assign-name from=/myapp/secondurl name=tomcat Obviously you don't want hundreds on NameTrans directives to maintain in obj.conf, and you don't want your Java developers fiddling with your web server configuration. I don't do Apache, so I don't know whether there is an equivalent issue there. It seems to me that a single configuration file that is read at web server init time, that tells the web server where the webapps are, what url prefixes they map to, and whether they are distributable etc would be a good idea. Something like: deployment connection name=serverone type=warp hosthostone/host port8081/port /connection connection name=servertwo type=warp hosthosttwo/host port8081/port /connection webapp name=myapp distributable=no url-mapping/myapp/url-mapping connections connectionserverone/connection connectionservertwo/connection /connections /webapp /deployment Does this sound sensible? I think I want this for myself anyway, so I might see if I can knock it up. The only complex thing would be parsing the file (I want to stick to C - so I don't know what I'd do about XML parsing). Does anyone have any opinions? Am I duplicating any previous work?
Re: Can't get mod_webapp.c to compile
Well, it's clear that the baby is not finding all apache 1.3 headers... Did you follow what's described in the README.txt file? Can you send me your apache-1.3/Makefile file? Pier Paul Smyth at [EMAIL PROTECTED] wrote: If there is something really obvious I'm missing please let me know. I just can't get mod_webapp.c to compile. Please help!! make results below. Regards Paul Smyth. [EMAIL PROTECTED] Make results: Compiling Apache 1.3 WebApp module mod_webapp.c:77: parse error before `webapp_module' mod_webapp.c:77: warning: data definition has no type or storage class mod_webapp.c:90: parse error before `pool' mod_webapp.c:97: parse error before `pool' mod_webapp.c: In function `wam_startup': mod_webapp.c:99: `s' undeclared (first use in this function) mod_webapp.c:99: (Each undeclared identifier is reported only once mod_webapp.c:99: for each function it appears in.) mod_webapp.c: At top level: mod_webapp.c:104: parse error before `*' mod_webapp.c: In function `wam_server': mod_webapp.c:127: request for member `module_index' in something not a structure or union mod_webapp.c:145: request for member `module_index' in something not a structure or union mod_webapp.c: In function `wa_log': mod_webapp.c:270: warning: passing arg 4 of `ap_log_error' makes integer from pointer without a cast mod_webapp.c:270: warning: passing arg 5 of `ap_log_error' from incompatible pointer type mod_webapp.c: In function `wam_handler_log': mod_webapp.c:278: warning: passing arg 4 of `ap_log_error' makes integer from pointer without a cast mod_webapp.c:278: warning: passing arg 5 of `ap_log_error' from incompatible pointer type mod_webapp.c: In function `wam_handler_setctype': mod_webapp.c:294: warning: assignment makes pointer from integer without a cast mod_webapp.c: In function `wam_match': mod_webapp.c:386: request for member `module_index' in something not a structure or union mod_webapp.c:401: warning: assignment makes pointer from integer without a cast mod_webapp.c:404: request for member `module_index' in something not a structure or union mod_webapp.c: In function `wam_invoke': mod_webapp.c:424: request for member `module_index' in something not a structure or union mod_webapp.c:429: warning: passing arg 4 of `ap_log_error' makes integer from pointer without a cast mod_webapp.c:429: warning: passing arg 5 of `ap_log_error' from incompatible pointer type mod_webapp.c:436: too few arguments to function `ap_get_remote_host' mod_webapp.c:443: request for member `sin_port' in something not a structure or union mod_webapp.c:443: request for member `sin_port' in something not a structure or union mod_webapp.c:443: request for member `sin_port' in something not a structure or union mod_webapp.c:443: request for member `sin_port' in something not a structure or union mod_webapp.c:444: request for member `sin_port' in something not a structure or union mod_webapp.c:444: request for member `sin_port' in something not a structure or union mod_webapp.c:444: request for member `sin_port' in something not a structure or union mod_webapp.c:444: request for member `sin_port' in something not a structure or union mod_webapp.c:452: structure has no member named `user' mod_webapp.c:453: structure has no member named `ap_auth_type' mod_webapp.c:460: `array_header' undeclared (first use in this function) mod_webapp.c:460: `arr' undeclared (first use in this function) mod_webapp.c:461: `table_entry' undeclared (first use in this function) mod_webapp.c:461: `ele' undeclared (first use in this function) mod_webapp.c:461: parse error before `)' mod_webapp.c:465: `x' undeclared (first use in this function) mod_webapp.c: At top level: mod_webapp.c:492: parse error before `wam_handlers' mod_webapp.c:493: warning: braces around scalar initializer mod_webapp.c:493: warning: (near initialization for `wam_handlers[0]') mod_webapp.c:493: warning: initialization makes integer from pointer without a cast mod_webapp.c:493: warning: excess elements in scalar initializer mod_webapp.c:493: warning: (near initialization for `wam_handlers[0]') mod_webapp.c:494: warning: braces around scalar initializer mod_webapp.c:494: warning: (near initialization for `wam_handlers[1]') mod_webapp.c:494: warning: initialization makes integer from pointer without a cast mod_webapp.c:495: warning: data definition has no type or storage class mod_webapp.c:498: parse error before `webapp_module' mod_webapp.c:499: `this_module_needs_to_be_ported_to_apache_2_0' undeclared here (not in a function) mod_webapp.c:499: initializer element is not constant mod_webapp.c:499: (near initialization for `webapp_module') mod_webapp.c:500: warning: excess elements in scalar initializer mod_webapp.c:500: warning: (near initialization for `webapp_module') mod_webapp.c:501: warning: excess elements in scalar initializer mod_webapp.c:501: warning: (near initialization for `webapp_module')
tomcat4, webdav, and IIS
Hi all, I'm trying to set up tomcat4.0 (cvs, few days old), talking through mod_jk (java bits compiled today from cvs, native bits the most recent compiled version I could find - I don't have a copy of devstudio here) to IIS (5.0, on win2k), using isapi_redirect.dll . That bit works fine. Then I throw webdav into the mix - using both tomcat's built-in webdav servlet and jakarta-slide (well, one then the other). That _mostly_ works. However, using microsoft web folders, it fails. Exactly the same server, but a different client (the slide command line client, for instance), and everything works (same URL, etc. also). Has anyone here had any experience with debugging this sort of thing? Am I going in totally the wrong direction (jk seemed to be the only thing that had IIS support)? From looking at log files, it seems like this is happening (roughly): Normal client: IIS receives request, forwards to isapi_redirect.dll. This matches the request to a tomcat 'worker'. Request gets sent off to tomcat worker, tomcat processes, client gets useful response. MS Webfolders: IIS receives request, forwards to isapi_redirect. isapi_redirect maps it to a tomcat worker. Request never actually gets sent to tomcat worker (tomcat never sees anything, as far as I can tell - certainly nothing is logged, and I have all the debugging on). Client gets _some sort_ (unknown details) of response from IIS (NOT from tomcat), but the response is wrong, so webfolders rejects it completely. Note that the config seems to be fine - the requests (according to the log files) get mapped to the tomcat instance correctly in either case, it's just that with webfolders thrown in, the request then doesn't actually get to tomcat. Also, a 'normal' HTTP request (i.e. not webdav. GET, for example) works from everything. Any advice as to a) what I did wrong, or b) where to start looking for debugging this myself, would be very much appreciated. Michael
Re: Multiple requests get generated for a single request
Are you using IE ? It sometimes has a tendency to request multiple times, with slightly different headers each time. I've never tracked down exactly what triggers this. You can sometimes also get it if you have multiple submit fields on a form, some with Javascript, and then you hit return ... [EMAIL PROTECTED] on 08/08/2001 21:21:32 Please respond to [EMAIL PROTECTED] To: [EMAIL PROTECTED] cc:(bcc: Ken X Horn) Subject: Multiple requests get generated for a single request Hi all I have a servlet generating a PDF document of approx 1. MB size streaming its content into the browser of the client. The single request I make to the servlet spawns 2 more requests to the web-server/servlet. Can I configure and make it only one request for this document. Any ideas Shankar From: Pier P. Fumagalli [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/http SocketInputStream.java Date: Wed, 08 Aug 2001 21:11:47 +0100 [EMAIL PROTECTED] at [EMAIL PROTECTED] wrote: Log: - A HT (tab) is also considered a leading white space. It was a bit hidden in the HTTP spec, so I had missed it. Told you it was something regarding tabs/spaces on the second line of the header :) :) :) Great job for hunting that down :) Pier _ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp
Re: Web server integration / NameTrans stage
Hi Colin, This idea is ( surprise ) already implemented, as part of the IIS connector. It isn't a config file, but a properties file ( much easier to parse and work with ). We already discussed few times about adding this configuration style to the other containers ( apache, nes ) - so your work will certainly be helpfull. One problem ( and that's common to apache as well ) is that if you are using the NameTrans ( or SetHandler ), that means netscape/apache is managing the mappings. By using the jk mapper, the whole thing is duplicated, and that will affect ( slow down ) _all_ requests that are processed by the server. We are trying to enhance the native config style, allowing the user to use standard Apache directives ( SetHandler, etc ). This is also part of the effort to integrate the authentication ( use apache to do auth, etc ). Of course, this is just a choice - each config style has its benefits. Regarding the config, the most common 2 cases shouldn't require any additional user configuration. - one web server, one tomcat instance - all the contexts are configured in server.xml, tomcat can generate a config or, via Ajp14, send the config on the wire - one web server, pool of load-balanced tomcats - almost the same, there is only one worker ( lb ) and the config can be generated with no extra user info. - one/many web servers, dispatching to different tomcats based on context using different workers. For this you'll need some extra info, but I would place it on the Context level ( or/and AutoWebApp ), it's much easier to have it in a single place. Again, the properties file can be generated from server.xml or sent on the wire. The goal is to have the user do minimal configuration. It's not easy, and it also mean the user will have less flexibility, but it's a good idea. Anyway - it would be great to add this to NES and apache, and IMHO it would be better if instead of spending your time parsing xml in C you would add support for virtual host in the config file ( that would be usefull for IIS, NES and Apache ). Right now virtual hosts work only with manual configuration. Costin ( I hope I didn't confused you - there is a lot of flexibility and choices, and many possibilities ) On Thu, 9 Aug 2001, Colin Wilson-Salt wrote: I've been looking at the existing web server integration stuff (both mod_jk and mod_webapp), and it seems to me that there is one significant piece missing - a NameTrans directive that takes its configuration from a separate file. I know I'm talking iPlanet here - but that's where my experience is. At the moment I'm running a bodged together iPlanet / Tomcat 4 combo where the servlet requests are http-proxied to Tomcat, but I need to to the NameTrans part myself: NameTrans fn=assign-name from=/myapp/firsturl name=tomcat NameTrans fn=assign-name from=/myapp/secondurl name=tomcat Obviously you don't want hundreds on NameTrans directives to maintain in obj.conf, and you don't want your Java developers fiddling with your web server configuration. I don't do Apache, so I don't know whether there is an equivalent issue there. It seems to me that a single configuration file that is read at web server init time, that tells the web server where the webapps are, what url prefixes they map to, and whether they are distributable etc would be a good idea. Something like: deployment connection name=serverone type=warp hosthostone/host port8081/port /connection connection name=servertwo type=warp hosthosttwo/host port8081/port /connection webapp name=myapp distributable=no url-mapping/myapp/url-mapping connections connectionserverone/connection connectionservertwo/connection /connections /webapp /deployment Does this sound sensible? I think I want this for myself anyway, so I might see if I can knock it up. The only complex thing would be parsing the file (I want to stick to C - so I don't know what I'd do about XML parsing). Does anyone have any opinions? Am I duplicating any previous work?
Re: Is anyone working on iPlanet integration?
Well, a double apology - first, I ( once again ) got into a flame, it seems the only cure is to unsubscribe from this list. Second, I missed ( at least ) Kevin Seguin, Larry Isaacs and probably few others. It's quite a large group, AFAIK it's the tomcat component with the most people contribution to it. Costin On Wed, 8 Aug 2001 [EMAIL PROTECTED] wrote: Gal Shachor. And other names who made significant contributions are: Henri Gomez Mike Anderson Dan Milstein Vasile Gaburici Costin Manolache Jean Frederic Clere and so on Some are still here, some got fed up and found better things to do ( some are in both categories ). Costin
cvs commit: jakarta-tomcat-service/winnt - New directory
jfclere 01/08/09 09:06:56 jakarta-tomcat-service/winnt - New directory
cvs commit: jakarta-tomcat-service/winnt/bin - New directory
jfclere 01/08/09 09:09:22 jakarta-tomcat-service/winnt/bin - New directory
cvs commit: jakarta-tomcat-service/winnt/lib - New directory
jfclere 01/08/09 09:09:22 jakarta-tomcat-service/winnt/lib - New directory
cvs commit: jakarta-tomcat-service/winnt/executables - New directory
jfclere 01/08/09 09:09:22 jakarta-tomcat-service/winnt/executables - New directory
cvs commit: jakarta-tomcat-service/winnt/moni - New directory
jfclere 01/08/09 09:09:22 jakarta-tomcat-service/winnt/moni - New directory
cvs commit: jakarta-tomcat-service/winnt/supcalls_nt - New directory
jfclere 01/08/09 09:09:22 jakarta-tomcat-service/winnt/supcalls_nt - New directory
cvs commit: jakarta-tomcat-service/winnt/service - New directory
jfclere 01/08/09 09:09:22 jakarta-tomcat-service/winnt/service - New directory
cvs commit: jakarta-tomcat-service/winnt/moni_nt - New directory
jfclere 01/08/09 09:09:22 jakarta-tomcat-service/winnt/moni_nt - New directory
cvs commit: jakarta-tomcat-service/winnt/signals - New directory
jfclere 01/08/09 09:09:22 jakarta-tomcat-service/winnt/signals - New directory
Re: Web server integration / NameTrans stage
Colin Wilson-Salt at [EMAIL PROTECTED] wrote: I've been looking at the existing web server integration stuff (both mod_jk and mod_webapp), and it seems to me that there is one significant piece missing - a NameTrans directive that takes its configuration from a separate file. I know I'm talking iPlanet here - but that's where my experience is. Hmm... I don't know anything about NES as of now. I don't know how it works, how it's configured, how the API looks like... NOTHING :) I suppose that JK has something like that. They rely on external configuration files. Regarding mod_webapp, external configuration files are a big -1... No-No... Configuration should be effective, minimal and integrated with the web-server... If you see how Apache works, you have only ONE line of configuration per web-application, and all the rest is taken care automatically... Pier
Re: cvs commit: jakarta-tomcat-service/winnt - New directory
[EMAIL PROTECTED] at [EMAIL PROTECTED] wrote: jfclere 01/08/09 09:06:56 jakarta-tomcat-service/winnt - New directory Jean-Frederic... I'm going to move stuff around next week :) So, when you get back from vacation, be sure to make a brand new checkout :) :) :) Pier
cvs commit: jakarta-tomcat-service/winnt/executables/vdmoniadm - New directory
jfclere 01/08/09 09:15:07 jakarta-tomcat-service/winnt/executables/vdmoniadm - New directory
cvs commit: jakarta-tomcat-service/winnt/executables/vdmonisvc - New directory
jfclere 01/08/09 09:15:07 jakarta-tomcat-service/winnt/executables/vdmonisvc - New directory
cvs commit: jakarta-tomcat-service/winnt/executables/vdmoniadm icon1.ico
jfclere 01/08/09 09:20:18 Added: winnt/executables/vdmoniadm icon1.ico Log: That is a small icon - A binary file, the rest follows soon - Revision ChangesPath 1.1 jakarta-tomcat-service/winnt/executables/vdmoniadm/icon1.ico Binary file
Re: Web server integration / NameTrans stage
The only way (that I'm aware) to do what you are suggesting is to implement a PathCheck or a Service method in the Default object block. It has been a while since I worked with these, but as I recall, every request is handed off to these functions to determine if it should be handled by a particular plugin. The PathCheck lets you check the incoming URI and see if it is one that you should handle and possibly add some additional information into the request for later processing. Depending on how (and where) the Service method is called, it can either process the request or respond that it isn't interested. The NameTrans directive has to have a specific pattern to match and can then direct the processing to different object blocks which is how the current connectors work. It is more efficient because only the requests that match a particular pattern are actually handed of to the additional processing. The Service and PathCheck methods in the Default object block are more dynamic, but will be hit for every request and so have the potential of slowing down the overall performance of the web server. Again, this is based on what I've read in the NSAPI programming guide and played with on other plugins so I could be completely off base, but it matches behavior that I've seen. Mike Anderson [EMAIL PROTECTED] 08/09/01 10:13AM Colin Wilson-Salt at [EMAIL PROTECTED] wrote: I've been looking at the existing web server integration stuff (both mod_jk and mod_webapp), and it seems to me that there is one significant piece missing - a NameTrans directive that takes its configuration from a separate file. I know I'm talking iPlanet here - but that's where my experience is. Hmm... I don't know anything about NES as of now. I don't know how it works, how it's configured, how the API looks like... NOTHING :) I suppose that JK has something like that. They rely on external configuration files. Regarding mod_webapp, external configuration files are a big -1... No-No... Configuration should be effective, minimal and integrated with the web-server... If you see how Apache works, you have only ONE line of configuration per web-application, and all the rest is taken care automatically... Pier
cvs commit: jakarta-tomcat-service/winnt/service instmain.cpp
jfclere 01/08/09 10:14:51
Modified:winnt/executables/vdmoniadm vdmoniadm.rc
winnt/executables/vdmonisvc vdmonisvc.rc
winnt/service instmain.cpp
Log:
Arrange some of the copyrights...
Revision ChangesPath
1.2 +1 -1 jakarta-tomcat-service/winnt/executables/vdmoniadm/vdmoniadm.rc
Index: vdmoniadm.rc
===
RCS file: /home/cvs/jakarta-tomcat-service/winnt/executables/vdmoniadm/vdmoniadm.rc,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- vdmoniadm.rc 2001/08/09 16:32:23 1.1
+++ vdmoniadm.rc 2001/08/09 17:14:51 1.2
@@ -295,7 +295,7 @@
VALUE FileDescription, OnServe Service Administration..\0
VALUE FileVersion, 3.0.0.1\0
VALUE InternalName, vdmoniadm\0
-VALUE LegalCopyright, Siemens AG 1998\0
+VALUE LegalCopyright, Copyright © 1998-2001, Apache Software
Foundation \0
VALUE OriginalFilename, vdmonisvc.exe\0
VALUE ProductName, OnServe\0
VALUE ProductVersion, 3.0 A00\0
1.2 +1 -1 jakarta-tomcat-service/winnt/executables/vdmonisvc/vdmonisvc.rc
Index: vdmonisvc.rc
===
RCS file: /home/cvs/jakarta-tomcat-service/winnt/executables/vdmonisvc/vdmonisvc.rc,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- vdmonisvc.rc 2001/08/09 16:32:23 1.1
+++ vdmonisvc.rc 2001/08/09 17:14:51 1.2
@@ -48,7 +48,7 @@
VALUE FileDescription, OnServe Service application.\0
VALUE FileVersion, 3.0.0.1\0
VALUE InternalName, vdmonisvc\0
-VALUE LegalCopyright, Siemens AG 1998\0
+VALUE LegalCopyright, Copyright © 1998-2001, Apache Software
Foundation.\0
VALUE OriginalFilename, vdmonisvc.exe\0
VALUE ProductName, OnServe\0
VALUE ProductVersion, 3.0 A00\0
1.2 +4 -4 jakarta-tomcat-service/winnt/service/instmain.cpp
Index: instmain.cpp
===
RCS file: /home/cvs/jakarta-tomcat-service/winnt/service/instmain.cpp,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- instmain.cpp 2001/08/09 16:32:24 1.1
+++ instmain.cpp 2001/08/09 17:14:51 1.2
@@ -1,5 +1,5 @@
/*
- * vdmoni install program, create the service OnServe
+ * jsvc.exe install program, create the service JavaService
*/
// includes
@@ -10,10 +10,10 @@
VOID Usage()
{
- cout \r\n - Copyright (C) 1998 by Siemens Nixdorf Informationssystem
AG\r\n\r\n;
+ cout \r\n - Java service installer\r\n\r\n;
cout - Usage :\r\n;
- cout To install OnServe service : InstSvc\r\n;
- cout To remove OnServe service : InstSvc -REMOVE\r\n\r\n;
+ cout To install Java service : InstSvc\r\n;
+ cout To remove Java service : InstSvc -REMOVE\r\n\r\n;
cout Use regedit if you want to change something\r\n\r\n;
cout Note that the service key is in:\r\n;
cout HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Services\\;
RE: Web server integration / NameTrans stage
But... you still need to edit the web server configuration file to deploy a web app. If the file that describes how the two pieces integrate is owned by the tomcat user, then the Java guys can look after that and the only thing that they need to do with iPlanet is use its admin tool to restart it. iPlanet is not nice to configure, it's not very forgiving (a single space in the wrong place can prevent it starting with no sensible error message), and its configuration files are typically owned by root - I want to let the webapp coders deploy their applications, but I don't want them anywhere near the web server that I've spent so long configuring and tuning. -Original Message- From: Pier P. Fumagalli [mailto:[EMAIL PROTECTED]] Sent: Thursday, August 09, 2001 17:13 To: [EMAIL PROTECTED] Subject: Re: Web server integration / NameTrans stage ... I suppose that JK has something like that. They rely on external configuration files. Regarding mod_webapp, external configuration files are a big -1... No-No... Configuration should be effective, minimal and integrated with the web-server... If you see how Apache works, you have only ONE line of configuration per web-application, and all the rest is taken care automatically... Pier
RE: cvs commit: jakarta-tomcat-service/winnt/supcalls_nt vdenv.c
it sounds like cygwin is required for this to run. is this true? is it only because jsvc depends on it? thanks! It creates the registry values needed for the environment to start jsvc.exe JAKARTA_HOME CYGWIN (You have to set it to your cygwin directory home). JAVA_HOME (You have to set it to your JAVA_HOME directory). HOSTNAME (not yet used) HOSTPORT (not yet used) I use regedit to modify these values. 5 - Using the explorer go to profiles/allusers/program/startup and add a link to vdmoniadm.exe. 6 - Reboot the machine and logon. You should see a nice icon in the System Task-bar indicating that the Java service is running. A right click on the icon calls a small menu. Restart: (not yet implemented). Configure: (not yet implemented). Stop: Stops the java service. It is still a work in progress and blabla... Have fun...
cvs commit: jakarta-tomcat-service/winnt/service instsvc.plg
jfclere 01/08/09 10:28:06 Removed: winnt/executables/vdmoniadm vdmoniadm.plg winnt/executables/vdmonisvc vdmonisvc.plg winnt/service instsvc.plg Log: These were temporary files...
Re: Web server integration / NameTrans stage
Colin Wilson-Salt at [EMAIL PROTECTED] wrote: But... you still need to edit the web server configuration file to deploy a web app. If the file that describes how the two pieces integrate is owned by the tomcat user, then the Java guys can look after that and the only thing that they need to do with iPlanet is use its admin tool to restart it. iPlanet is not nice to configure, it's not very forgiving (a single space in the wrong place can prevent it starting with no sensible error message), and its configuration files are typically owned by root - I want to let the webapp coders deploy their applications, but I don't want them anywhere near the web server that I've spent so long configuring and tuning. Oh, well, in that case, you can just the autodeploy feature I'm building for the WebApp module. Basically, everything you need to configure is a WARP connection. The warp protocol allows you to query the servlet containers what web applications are deployable, and from then all is done automatically. All you need to configure is the Tomcat 4.0 server.xml configuration file, and everything is done automatically for you... Pier
RE: Web server integration / NameTrans stage
On Thu, 9 Aug 2001, Colin Wilson-Salt wrote: iPlanet is not nice to configure, it's not very forgiving (a single space in the wrong place can prevent it starting with no sensible error message), and its configuration files are typically owned by root - I want to let the webapp coders deploy their applications, but I don't want them anywhere near the web server that I've spent so long configuring and tuning. Unless you want to fine-tune a webapplication. There are 2 ways to do what you want: either what IIS is doing ( with mod_jk reading a properties file, that is generated from server.xml and autoconfigured apps ), or via Ajp14, where the same information is sent on the wire at the initial connection time ( this is only in experimental stage right now, it seems to work fine but it needs more work ). The 2 are almost identical - same information is used. The first is easier to debug and trace, and may allow extra customizations. The second is very usefull if tomcat is on different machine, and is easier ( but a bit less flexible ). The third option, using the native config format ( i.e. the only current solution for NES, and one of the choices for Apache ) is the most powerfull and the hardest to configure. It seems you don't like this choice ( or at least you don't want this to be the only choice for NES :-), but it is the most powerfull one. It seems Pier believes only one options should be available in webapp, it's his choice. For jk we hope to have all choices available on all containers. BTW, if properties or Ajp14 are used the autoconfiguration makes sure the user _doesn't_ have to edit anything manually when he adds a webapp, so besides the initial setup it's zero lines per webapp. Unless the user wants something special, and then the web server sets the limits on what he can do. Costin
cvs commit: jakarta-watchdog-4.0/src/conf jsp-gtest.xml (fwd)
FYI, I have modified the Watchdog 4.0 management scripts to deal with the
fact that we fixed Tomcat to return HTTP/1.1 (per RFC 2616, Section 3.1).
The JSP tests really care about the *content* of the response anyway, so
the check for protocol was unnecessary.
Craig
-- Forwarded message --
Date: 9 Aug 2001 17:35:14 -
From: [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: cvs commit: jakarta-watchdog-4.0/src/conf jsp-gtest.xml
craigmcc01/08/09 10:35:14
Modified:src/conf jsp-gtest.xml
Log:
Update the Ant script controlling the JSP tests so that none of them
gratuitously fail because of differences in the HTTP protocol version
returned by the server.
Revision ChangesPath
1.9 +4 -4 jakarta-watchdog-4.0/src/conf/jsp-gtest.xml
Index: jsp-gtest.xml
===
RCS file: /home/cvs/jakarta-watchdog-4.0/src/conf/jsp-gtest.xml,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- jsp-gtest.xml 2001/07/20 23:07:56 1.8
+++ jsp-gtest.xml 2001/08/09 17:35:13 1.9
@@ -629,7 +629,7 @@
gtest request=GET
/jsp-tests/jsp/core_syntax/directives/page/session/positiveSession.jsp HTTP/1.0
debug=0 host=${host} port=${port}
- returnCode=HTTP/1.0 200 OK
+ returnCode=200
responseMatch=got true
testName=positiveSession.jsp
assertion=Test the implicit session object and call one of its methods,
specified in the Java Server Pages Specification v1.2, Sec 2.11.1
@@ -638,7 +638,7 @@
gtest request=GET
/jsp-tests/jsp/core_syntax/directives/page/session/positiveSessionDefault.jsp HTTP/1.0
debug=0 host=${host} port=${port}
- returnCode=HTTP/1.0 200 OK
+ returnCode=200
responseMatch=got true
testName=positiveSessionDefault.jsp
assertion=Test to invoke a method on the implicit session object.,
specified in the Java Server Pages Specification v1.2, Sec 2.11.1
@@ -647,7 +647,7 @@
gtest request=GET
/jsp-tests/jsp/core_syntax/directives/page/buffer/positiveBuffAutoflush.jsp HTTP/1.0
debug=0 host=${host} port=${port}
- returnCode=HTTP/1.0 200 OK
+ returnCode=200
responseMatch=5999
testName=positiveBuffAutoflush.jsp
assertion=Set autoflush to true. Use default buffer size of 8kb. Write
more than 8kb of data to the out object, specified in the Java Server Pages
Specification v1.2, Sec 2.11.1
@@ -656,7 +656,7 @@
gtest request=GET
/jsp-tests/jsp/core_syntax/directives/page/buffer/positiveBuffCreate.jsp HTTP/1.0
debug=0 host=${host} port=${port}
- returnCode=HTTP/1.0 200 OK
+ returnCode=200
responseMatch=999
testName=positiveBuffCreate.jsp
assertion=Create a buffer size of say 12kb. Keep autoflush set to
false(default).Write characters to the out object. Invoke the flush() method on out to
flush the output to the client., specified in the Java Server Pages Specification
v1.2, Sec 2.11.1
Re: cvs commit: jakarta-watchdog-4.0/src/conf jsp-gtest.xml
Craig R. McClanahan at [EMAIL PROTECTED] wrote: FYI, I have modified the Watchdog 4.0 management scripts to deal with the fact that we fixed Tomcat to return HTTP/1.1 (per RFC 2616, Section 3.1). The JSP tests really care about the *content* of the response anyway, so the check for protocol was unnecessary. Thanks for the update Craig. That fixes it :) Pier
Re: Web server integration / NameTrans stage
You probably want to start with org.apache.tomcat.modules.config.NSConfig (it's 3.3 name, I don't know where it lives in 4.0), and see what needs to be changed to go from NS-iPlanet. - Original Message - From: Colin Wilson-Salt [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, August 09, 2001 10:15 AM Subject: RE: Web server integration / NameTrans stage But... you still need to edit the web server configuration file to deploy a web app. If the file that describes how the two pieces integrate is owned by the tomcat user, then the Java guys can look after that and the only thing that they need to do with iPlanet is use its admin tool to restart it. iPlanet is not nice to configure, it's not very forgiving (a single space in the wrong place can prevent it starting with no sensible error message), and its configuration files are typically owned by root - I want to let the webapp coders deploy their applications, but I don't want them anywhere near the web server that I've spent so long configuring and tuning. -Original Message- From: Pier P. Fumagalli [mailto:[EMAIL PROTECTED]] Sent: Thursday, August 09, 2001 17:13 To: [EMAIL PROTECTED] Subject: Re: Web server integration / NameTrans stage ... I suppose that JK has something like that. They rely on external configuration files. Regarding mod_webapp, external configuration files are a big -1... No-No... Configuration should be effective, minimal and integrated with the web-server... If you see how Apache works, you have only ONE line of configuration per web-application, and all the rest is taken care automatically... Pier
Re: [PROPOSAL] Deprecation of committers...
Pier P. Fumagalli typed the following on 10:59 PM 8/8/2001 +0100 There are others that, from time to time, pop around on this mailing list, but I never saw one commit coming from them (although I have only a 6-months old archive, I would repropose this further on in the future, when some of them will definitely over the 6 months limit). I guess I fall into this category. Unfortunately I haven't had the time to spend much time on the distributed sessions stuff. At some point I would like to dig into it again, but it sounds like even if I am deprecated it won't be hard to get commit privs back. Since I'm not using my access at the moment it wouldn't both me if I'm deprecated out. Kief
Re: Addition of 'dirty' field to Session interface
Craig R. McClanahan typed the following on 12:57 PM 8/8/2001 -0700 Another possibility would be to flag the session is dirty when getAttribute() is called - it would result in unnecessary saves since it assumes the attribute was modified even when it wasn't, but it would be safer. Someone has told me (haven't confirmed personally) that some app servers treat a setAttribute() -- as opposed to getAttribute() -- as the signal to set the internal dirty flag. The idea is that, if your application modifies the internal state of an existing session attribute, then you should call session.setAttribute() again to notify the container. Yes, flagging the session is dirty on setAttribute() makes sense. I was thinking that by also flagging it on getAttribute(), you're depending less on developers to take an extra step (calling setDirty() or making another call to setAttribute()). If an attribute is retrieved from the session, it may have been modified, so make the assumption that it was just to be safe. But this could erase a lot of the benefit of the dirty flag optimization, since writes are typically more common than reads. Now that I think about it though, any time a session is used in a request, its lastAccessedTime will be updated, so the session must be considered dirty. So worrying about tracking attributes isn't necessary: the session only needs to be flagged dirty when it is retrieved. Tracking the dirty status is still a good optimization, since it ensures sessions aren't saved multiple times between requests, or after requests which never access the session. Vishy, what do you think? Kief
cvs commit: jakarta-tomcat/src/doc tomcat-ug.html
larryi 01/08/09 12:18:38 Modified:src/doc tomcat-ug.html Log: Cleaned up some syntax. Started changing some to quot; and couldn't stop myself. :) Started changing Tomcat to Tomcat 3.3 in some places. There are enough differences from older Tomcat's that the version covered by this document needs to be clear. Content updates to follow. Revision ChangesPath 1.8 +101 -102 jakarta-tomcat/src/doc/tomcat-ug.html Index: tomcat-ug.html === RCS file: /home/cvs/jakarta-tomcat/src/doc/tomcat-ug.html,v retrieving revision 1.7 retrieving revision 1.8 diff -u -r1.7 -r1.8 --- tomcat-ug.html2001/08/06 20:40:59 1.7 +++ tomcat-ug.html2001/08/09 19:18:38 1.8 @@ -1,7 +1,7 @@ !DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.01 Transitional//EN html head -!-- $Id: tomcat-ug.html,v 1.7 2001/08/06 20:40:59 larryi Exp $ -- +!-- $Id: tomcat-ug.html,v 1.8 2001/08/09 19:18:38 larryi Exp $ -- !-- Copyright 1999-2001 Apache Software Foundation -- meta http-equiv=Content-Type content=text/html; charset=iso-8859-1 link rel=stylesheet href=style.css @@ -25,11 +25,11 @@ /table -H1Tomcat User's Guide/H1 +H1Tomcat 3.3 User's Guide/H1 -pThis document is an introduction to the Tomcat servlet +pThis document is an introduction to the Tomcat 3.3 servlet container. It should be enough for anyone to install, - configure, and deploy Tomcat. As well, it answers many + configure, and deploy Tomcat 3.3, or later. As well, it answers many questions common to new users. If you have any comments or suggestions about this document don't hesitate to send them to the Tomcat a href=http://jakarta.apache.org/site/mail.html;mailing @@ -84,7 +84,7 @@ lia href=#file_placementFile placement and environment setup/a/li lia href=#starting_and_stoppingStarting and - stopping Tomcat/a + stopping Tomcat/a/li lia href=#starting_another_dirStarting multiple instances w/individual server.xml files/a/li lia href=#directory_structureTomcat directory @@ -99,7 +99,7 @@ lia href=#server_xmlserver.xml - Tomcat's main configuration file/a/li lia href=#web_xmlweb.xml - Default - deployment descriptor/abr + deployment descriptor/a/li liWeb application/context security and authorization/li litomcat-users.xml/li liJDBC realms/li @@ -122,13 +122,13 @@ Problems/a ul lia href=#error_bad_commandquot;Bad command or -filenamequot; when executing Tomcat scripts/a +filenamequot; when executing Tomcat scripts/a/li lia href=#error_8007http://webserver:8007/ -gives an HTTP 500/a +gives an HTTP 500/a/li lia href=#error_ignore_directivesApache lt;Directorygt; -and lt;Locationgt; directives ignored/a +and lt;Locationgt; directives ignored/a/li lia href=#error_web_serverWeb server won't -start when Tomcat is running/a +start when Tomcat is running/a/li /ul /li lia href=#creditsCredits/a/li @@ -179,7 +179,7 @@ unlike CGI-based scripting, e.g. perl, etc. pFrom a href=http://java.sun.com/products/servlet/;Sun's - servlet site/a: + servlet site/a:/p blockquotequot;The strongJavasupfont size=-2TM/font/sup Servlet API/strong @@ -273,59 +273,58 @@ blockquote -In the following steps, ilt;versiongt;/i will be 3.3 for the initial -Tomcat 3.3 release, and 3.3.ix/i for subsequent maintenance releases. +In the following steps, ilt;versiongt;/i will be quot;3.3quot; for the initial +Tomcat 3.3 release, and quot;3.3.ix/iquot; for subsequent maintenance releases. ul lia href=http://jakarta.apache.org/site/binindex.html;Download/a the -appropriate jakarta-tomcat-ilt;versiongt;/i binary file. +appropriate jakarta-tomcat-ilt;versiongt;/i binary file./li liUnzip the file into some directory (say /usr/local or C:\). This - should create a new subdirectory named ttjakarta-tomcat-ilt;versiongt;/itt. + should create a new subdirectory named + ttquot;jakarta-tomcat-ilt;versiongt;/iquot;/tt./li -liChange to the ttjakarta-tomcat-ilt;versiongt;/itt directory -and set a new environment variable (a name=tomcat_home_envTOMCAT_HOME/a) -to point to the root directory of your Tomcat hierarchy. The exact
Re: [PROPOSAL] Deprecation of committers...
Kief Morris at [EMAIL PROTECTED] wrote: Pier P. Fumagalli typed the following on 10:59 PM 8/8/2001 +0100 There are others that, from time to time, pop around on this mailing list, but I never saw one commit coming from them (although I have only a 6-months old archive, I would repropose this further on in the future, when some of them will definitely over the 6 months limit). I guess I fall into this category. Unfortunately I haven't had the time to spend much time on the distributed sessions stuff. At some point I would like to dig into it again, but it sounds like even if I am deprecated it won't be hard to get commit privs back. Since I'm not using my access at the moment it wouldn't both me if I'm deprecated out. You're not in the list I submitted... You posted quite a lot to this mailing list lately, and, although I didn't check the commit logs, you seem to be pretty active still :) I basically checked my 6-months archive for emails coming from the different people involved with the projects. I didn't check the CVS... :) :) :) Pier
Re: Addition of 'dirty' field to Session interface
On Thu, 9 Aug 2001, Kief Morris wrote: Craig R. McClanahan typed the following on 12:57 PM 8/8/2001 -0700 Another possibility would be to flag the session is dirty when getAttribute() is called - it would result in unnecessary saves since it assumes the attribute was modified even when it wasn't, but it would be safer. Someone has told me (haven't confirmed personally) that some app servers treat a setAttribute() -- as opposed to getAttribute() -- as the signal to set the internal dirty flag. The idea is that, if your application modifies the internal state of an existing session attribute, then you should call session.setAttribute() again to notify the container. Yes, flagging the session is dirty on setAttribute() makes sense. I was thinking that by also flagging it on getAttribute(), you're depending less on developers to take an extra step (calling setDirty() or making another call to setAttribute()). If an attribute is retrieved from the session, it may have been modified, so make the assumption that it was just to be safe. But this could erase a lot of the benefit of the dirty flag optimization, since writes are typically more common than reads. Now that I think about it though, any time a session is used in a request, its lastAccessedTime will be updated, so the session must be considered dirty. So worrying about tracking attributes isn't necessary: the session only needs to be flagged dirty when it is retrieved. Tracking the dirty status is still a good optimization, since it ensures sessions aren't saved multiple times between requests, or after requests which never access the session. If I knew that the access time had been updated but not any attributes, I could probably distribute that information pretty cheaply (without having to serialize and deserialize the attributes as well). Thus, it's probably worth distinguishing between the two cases. Vishy, what do you think? Kief Craig
cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/http HttpProcessor.java
craigmcc01/08/09 12:43:00 Modified:catalina/src/share/org/apache/catalina/connector/http HttpProcessor.java Log: Make request URIs the contain /... (or any longer series of periods) invalid. On some (all?) Windows platforms, this causes the OS to walk the directory tree just like ../../.. type sequences do. PR: Bugzilla #3062 Submitted by: [EMAIL PROTECTED] Revision ChangesPath 1.35 +9 -4 jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/http/HttpProcessor.java Index: HttpProcessor.java === RCS file: /home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/http/HttpProcessor.java,v retrieving revision 1.34 retrieving revision 1.35 diff -u -r1.34 -r1.35 --- HttpProcessor.java2001/07/26 05:31:05 1.34 +++ HttpProcessor.java2001/08/09 19:43:00 1.35 @@ -1,6 +1,6 @@ -/* * $Header: /home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/http/HttpProcessor.java,v 1.34 2001/07/26 05:31:05 remm Exp $ - * $Revision: 1.34 $ - * $Date: 2001/07/26 05:31:05 $ +/* * $Header: /home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/http/HttpProcessor.java,v 1.35 2001/08/09 19:43:00 craigmcc Exp $ + * $Revision: 1.35 $ + * $Date: 2001/08/09 19:43:00 $ * * * @@ -106,7 +106,7 @@ * * @author Craig R. McClanahan * @author Remy Maucherat - * @version $Revision: 1.34 $ $Date: 2001/07/26 05:31:05 $ + * @version $Revision: 1.35 $ $Date: 2001/08/09 19:43:00 $ */ final class HttpProcessor @@ -879,6 +879,11 @@ normalized = normalized.substring(0, index2) + normalized.substring(index + 3); } + +// Declare occurrences of /... (three or more dots) to be invalid +// (on some Windows platforms this walks the directory tree!!!) +if (normalized.indexOf(/...) = 0) +return (null); // Return the normalized path that we have completed return (normalized);
[VOTE] Tomcat 4.0-beta-7 Release Tonight ?
Just fixed this security vulnerability in 4.0 (3.2.3 isn't vulnerable, at least on Win98, but I didn't check 3.3). Therefore, I would propose to do a Beta 7 release tonight that picks up this change (and other bugfixes since Beta 6). Thanks to [EMAIL PROTECTED] for the report. Craig McClanahan -- Forwarded message -- Date: 9 Aug 2001 19:43:00 - From: [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/http HttpProcessor.java craigmcc01/08/09 12:43:00 Modified:catalina/src/share/org/apache/catalina/connector/http HttpProcessor.java Log: Make request URIs the contain /... (or any longer series of periods) invalid. On some (all?) Windows platforms, this causes the OS to walk the directory tree just like ../../.. type sequences do. PR: Bugzilla #3062 Submitted by: [EMAIL PROTECTED] Revision ChangesPath 1.35 +9 -4 jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/http/HttpProcessor.java Index: HttpProcessor.java === RCS file: /home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/http/HttpProcessor.java,v retrieving revision 1.34 retrieving revision 1.35 diff -u -r1.34 -r1.35 --- HttpProcessor.java2001/07/26 05:31:05 1.34 +++ HttpProcessor.java2001/08/09 19:43:00 1.35 @@ -1,6 +1,6 @@ -/* * $Header: /home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/http/HttpProcessor.java,v 1.34 2001/07/26 05:31:05 remm Exp $ - * $Revision: 1.34 $ - * $Date: 2001/07/26 05:31:05 $ +/* * $Header: /home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/http/HttpProcessor.java,v 1.35 2001/08/09 19:43:00 craigmcc Exp $ + * $Revision: 1.35 $ + * $Date: 2001/08/09 19:43:00 $ * * * @@ -106,7 +106,7 @@ * * @author Craig R. McClanahan * @author Remy Maucherat - * @version $Revision: 1.34 $ $Date: 2001/07/26 05:31:05 $ + * @version $Revision: 1.35 $ $Date: 2001/08/09 19:43:00 $ */ final class HttpProcessor @@ -879,6 +879,11 @@ normalized = normalized.substring(0, index2) + normalized.substring(index + 3); } + +// Declare occurrences of /... (three or more dots) to be invalid +// (on some Windows platforms this walks the directory tree!!!) +if (normalized.indexOf(/...) = 0) +return (null); // Return the normalized path that we have completed return (normalized);
Re: [VOTE] Tomcat 4.0-beta-7 Release Tonight ?
Craig R. McClanahan at [EMAIL PROTECTED] wrote: Just fixed this security vulnerability in 4.0 (3.2.3 isn't vulnerable, at least on Win98, but I didn't check 3.3). Therefore, I would propose to do a Beta 7 release tonight that picks up this change (and other bugfixes since Beta 6). I'm cool with it. Can I integrate the sources from WARP into the core Catalina distribution before the release? I'll tag also the jakarta-tomcat-connectors/webapp repository... Pier
Re: [VOTE] Tomcat 4.0-beta-7 Release Tonight ?
On Thu, 9 Aug 2001, Pier P. Fumagalli wrote: Craig R. McClanahan at [EMAIL PROTECTED] wrote: Just fixed this security vulnerability in 4.0 (3.2.3 isn't vulnerable, at least on Win98, but I didn't check 3.3). Therefore, I would propose to do a Beta 7 release tonight that picks up this change (and other bugfixes since Beta 6). I'm cool with it. Can I integrate the sources from WARP into the core Catalina distribution before the release? I'll tag also the jakarta-tomcat-connectors/webapp repository... Yep. Go ahead and integrate them. Pier Craig
cvs commit: jakarta-tomcat-connectors/webapp/java WarpConfigurationHandler.java
pier01/08/09 12:57:31
Modified:webapp/java WarpConfigurationHandler.java
Log:
Forgot to break.
Revision ChangesPath
1.12 +1 -0
jakarta-tomcat-connectors/webapp/java/WarpConfigurationHandler.java
Index: WarpConfigurationHandler.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/webapp/java/WarpConfigurationHandler.java,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -r1.11 -r1.12
--- WarpConfigurationHandler.java 2001/08/09 01:18:49 1.11
+++ WarpConfigurationHandler.java 2001/08/09 19:57:31 1.12
@@ -226,6 +226,7 @@
packet.reset();
packet.setType(Constants.TYPE_CONF_MAP_DONE);
connection.send(packet);
+break;
}
case Constants.TYPE_CONF_DONE: {
cvs commit: jakarta-tomcat-connectors/webapp/java Constants.java.in WarpResponse.java
pier01/08/09 13:02:15 Modified:webapp/java Constants.java.in WarpResponse.java Log: The HTTP protocol version doesn't need to be transfered over WARP. Revision ChangesPath 1.11 +3 -0 jakarta-tomcat-connectors/webapp/java/Constants.java.in Index: Constants.java.in === RCS file: /home/cvs/jakarta-tomcat-connectors/webapp/java/Constants.java.in,v retrieving revision 1.10 retrieving revision 1.11 diff -u -r1.10 -r1.11 --- Constants.java.in 2001/08/09 01:18:49 1.10 +++ Constants.java.in 2001/08/09 20:02:15 1.11 @@ -299,6 +299,9 @@ * RES_STATUS: The server replies with the HTTP response status for the * request. * br + * Payload description:br + * [ushort] The HTTP status of the response.br + * [string] The HTTP response message.br */ public static final int TYPE_RES_STATUS=0x20; 1.9 +0 -1 jakarta-tomcat-connectors/webapp/java/WarpResponse.java Index: WarpResponse.java === RCS file: /home/cvs/jakarta-tomcat-connectors/webapp/java/WarpResponse.java,v retrieving revision 1.8 retrieving revision 1.9 diff -u -r1.8 -r1.9 --- WarpResponse.java 2001/08/05 19:59:48 1.8 +++ WarpResponse.java 2001/08/09 20:02:15 1.9 @@ -164,7 +164,6 @@ this.packet.reset(); this.packet.setType(Constants.TYPE_RES_STATUS); -this.packet.writeString(request.getRequest().getProtocol()); this.packet.writeUnsignedShort(status); this.packet.writeString(message); this.connection.send(this.packet);
cvs commit: jakarta-tomcat-connectors/webapp/lib pr_warp.c
pier01/08/09 13:03:43
Modified:webapp/lib pr_warp.c
Log:
The HTTP version doesn't need to be passed over WARP.
Revision ChangesPath
1.13 +2 -4 jakarta-tomcat-connectors/webapp/lib/pr_warp.c
Index: pr_warp.c
===
RCS file: /home/cvs/jakarta-tomcat-connectors/webapp/lib/pr_warp.c,v
retrieving revision 1.12
retrieving revision 1.13
diff -u -r1.12 -r1.13
--- pr_warp.c 2001/07/25 22:32:05 1.12
+++ pr_warp.c 2001/08/09 20:03:43 1.13
@@ -54,7 +54,7 @@
* *
* = */
-/* @version $Id: pr_warp.c,v 1.12 2001/07/25 22:32:05 pier Exp $ */
+/* @version $Id: pr_warp.c,v 1.13 2001/08/09 20:03:43 pier Exp $ */
#include pr_warp.h
/* Initialize this provider. */
@@ -350,12 +350,10 @@
}
switch (pack-type) {
case TYPE_RES_STATUS: {
-char *prot=NULL;
char *mesg=NULL;
-p_read_string(pack,prot);
p_read_ushort(pack,status);
p_read_string(pack,mesg);
-wa_debug(WA_MARK,=== %s %d %s,prot,status,mesg);
+wa_debug(WA_MARK,=== %d %s,status,mesg);
wa_rsetstatus(r,status);
break;
}
cvs commit: jakarta-tomcat-connectors/webapp/lib pr_warp_config.c
pier01/08/09 13:04:31
Modified:webapp/lib pr_warp_config.c
Log:
Retrieve web applications mapping over WARP.
Revision ChangesPath
1.6 +30 -1 jakarta-tomcat-connectors/webapp/lib/pr_warp_config.c
Index: pr_warp_config.c
===
RCS file: /home/cvs/jakarta-tomcat-connectors/webapp/lib/pr_warp_config.c,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- pr_warp_config.c 2001/08/06 02:20:10 1.5
+++ pr_warp_config.c 2001/08/09 20:04:31 1.6
@@ -54,7 +54,7 @@
* *
* = */
-/* @version $Id: pr_warp_config.c,v 1.5 2001/08/06 02:20:10 pier Exp $ */
+/* @version $Id: pr_warp_config.c,v 1.6 2001/08/09 20:04:31 pier Exp $ */
#include pr_warp.h
wa_boolean c_check(wa_connection *conn, warp_packet *pack) {
@@ -166,6 +166,35 @@
else appl-lpth=NULL;
} else {
appl-lpth=NULL;
+}
+}
+
+/* If this application is local, we want to retrieve the allowed and
+ denied mapping list. */
+if (appl-lpth!=NULL) {
+p_reset(pack);
+pack-type=TYPE_CONF_MAP;
+p_write_int(pack,(int)appl-conf);
+n_send(conf-sock,pack);
+
+while(1) {
+if (n_recv(conf-sock,pack)!=wa_true) {
+wa_log(WA_MARK,Cannot read packet (%s:%d),WA_MARK);
+n_disconnect(conn);
+return(wa_false);
+}
+if (pack-type==TYPE_CONF_MAP_DONE) {
+wa_debug(WA_MARK,Done mapping URLs);
+break;
+} else if (pack-type==TYPE_CONF_MAP_ALLOW) {
+char *map=NULL;
+p_read_string(pack,map);
+wa_debug(WA_MARK,Allow URL mapping \%s\,map);
+} else if (pack-type==TYPE_CONF_MAP_DENY) {
+char *map=NULL;
+p_read_string(pack,map);
+wa_debug(WA_MARK,Deny URL mapping \%s\,map);
+}
}
}
cvs commit: jakarta-tomcat-connectors/webapp/apache-1.3 mod_webapp.c
pier01/08/09 13:05:36
Modified:webapp/apache-1.3 mod_webapp.c
Log:
Provide some more informations if mod_webapp was compiled with the
DEBUG flag set.
Revision ChangesPath
1.23 +9 -1 jakarta-tomcat-connectors/webapp/apache-1.3/mod_webapp.c
Index: mod_webapp.c
===
RCS file: /home/cvs/jakarta-tomcat-connectors/webapp/apache-1.3/mod_webapp.c,v
retrieving revision 1.22
retrieving revision 1.23
diff -u -r1.22 -r1.23
--- mod_webapp.c 2001/08/04 18:25:57 1.22
+++ mod_webapp.c 2001/08/09 20:05:36 1.23
@@ -57,7 +57,7 @@
/**
* @author Pier Fumagalli mailto:[EMAIL PROTECTED]
- * @version $Id: mod_webapp.c,v 1.22 2001/08/04 18:25:57 pier Exp $
+ * @version $Id: mod_webapp.c,v 1.23 2001/08/09 20:05:36 pier Exp $
*/
#include httpd.h
@@ -262,9 +262,17 @@
void wa_log(const char *f, const int l, const char *fmt, ...) {
va_list ap;
char buf[1024];
+#ifdef DEBUG
+char tmp[1024];
+#endif
va_start(ap,fmt);
+#ifdef DEBUG
+apr_vsnprintf(tmp,1024,fmt,ap);
+apr_snprintf(buf,1024,[%s:%d] %s,f,l,tmp);
+#else
apr_vsnprintf(buf,1024,fmt,ap);
+#endif
va_end(ap);
ap_log_error(f,l,APLOG_NOERRNO|APLOG_ERR,server,%s,buf);
cvs commit: jakarta-tomcat-connectors/webapp/apache-1.3 Makefile.in
pier01/08/09 13:06:49 Modified:webapp/apache-1.3 Makefile.in Log: Avoid duplicate definitions when compiling mod_webapp (the ones derived from APXS and the ones derived from APRVARS) Revision ChangesPath 1.9 +6 -5 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.8 retrieving revision 1.9 diff -u -r1.8 -r1.9 --- Makefile.in 2001/08/06 22:48:45 1.8 +++ Makefile.in 2001/08/09 20:06:49 1.9 @@ -56,7 +56,7 @@ # = # # @author Pier Fumagalli mailto:[EMAIL PROTECTED] -# @version $Id: Makefile.in,v 1.8 2001/08/06 22:48:45 pier Exp $ +# @version $Id: Makefile.in,v 1.9 2001/08/09 20:06:49 pier Exp $ include @SRCDIR@/Makedefs @@ -80,10 +80,11 @@ mod_webapp.lo: mod_webapp.c @SRCDIR@/Makedefs @$(ECHO) Compiling Apache 1.3 WebApp module @$(SHELL) $(LIBTOOL) $(LTFLAGS) --mode=compile \ - $(CC) $(CFLAGS) $(EXTRA_CFLAGS) \ - $(APXS_CFLAGS) $(APXS_CFLAGS_SHLIB) \ - -I$(APXS_INCLUDEDIR) $(CPPFLAGS) $(EXTRA_CPPFLAGS) \ - -c $ -o $@ + $(CC) $(CFLAGS) $(APXS_CFLAGS) \ + $(APXS_CFLAGS_SHLIB) \ + -I$(APXS_INCLUDEDIR) \ + $(CPPFLAGS) \ + -c $ -o $@ mod_webapp.so: mod_webapp.lo @SRCDIR@/lib/libwebapp.la @APRDIR@/libapr.la @$(ECHO) Linking Apache 1.3 WebApp Module
cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/warp Constants.java WarpConfigurationHandler.java WarpConnector.java WarpPacket.java WarpRequest.java WarpRequestHandler.java WarpResponse.java
pier01/08/09 13:08:59 Modified:catalina/src/share/org/apache/catalina/connector/warp Constants.java WarpConfigurationHandler.java WarpConnector.java WarpPacket.java WarpRequest.java WarpRequestHandler.java WarpResponse.java Log: Sources integration for Tomcat 4.0 beta 7. Revision ChangesPath 1.3 +205 -5 jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/warp/Constants.java Index: Constants.java === RCS file: /home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/warp/Constants.java,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- Constants.java2001/07/22 20:25:08 1.2 +++ Constants.java2001/08/09 20:08:58 1.3 @@ -71,7 +71,7 @@ /** * The WARP protocol minor version. */ -public static final int VERS_MINOR=9; +public static final int VERS_MINOR=10; /** * INVALID: The packet type hasn't been set yet. @@ -113,6 +113,36 @@ public static final int TYPE_CONF_WELCOME=0x01; /** + * CONF_ENUM: The client requests to the server to enumerate all + * web-applications available for a specified virtual host. In response + * to this request, the server replies with a set of CONF_ENUM messages + * terminated by a CONF_ENUM_DONE message. + * br + * Payload description:br + * [string] The virtual host name.br + * [ushort] The virtual host port.br + */ +public static final int TYPE_CONF_ENUM=0x02; + +/** + * CONF_ENUM_APPL: The server specifies the name of a web-application + * available for deployment in response to a CONF_ENUMERATE message. + * br + * Payload description:br + * [string] The web-application name.br + */ +public static final int TYPE_CONF_ENUM_APPL=0x03; + +/** + * CONF_ENUM_DONE: The server specifies all web-application names + * available for deployment for the host specified in the CONF_ENUM + * message have been transfered. + * br + * No payload:br + */ +public static final int TYPE_CONF_ENUM_DONE=0x04; + +/** * CONF_DEPLOY: The client attempts deploy a web application. * br * Payload description:br @@ -121,7 +151,7 @@ * [ushort] The virtual host port.br * [string] The web-application URL path.br */ -public static final int TYPE_CONF_DEPLOY=0x02; +public static final int TYPE_CONF_DEPLOY=0x05; /** * CONF_APPLIC: The server replies to a CONF_DEPLOY message with the web @@ -130,16 +160,56 @@ * Payload description:br * [integer] The web application unique id for this server.br * [string] The web application real path (where it's expanded).br + */ +public static final int TYPE_CONF_APPLIC=0x06; + +/** + * CONF_MAP: The client requests to the server to enumerate all mappings + * for a specified web-application. The server replies to this message + * with a serie of MAP_ALLOW and MAP_DENY packets, terminated by a + * MAP_DONE packet. + * br + * Payload description:br + * [integer] The web application unique id for this server.br + */ +public static final int TYPE_CONF_MAP=0x07; + +/** + * CONF_MAP_ALLOW: The server replies to a CONF_MAP message with this + * packet to indicate a mapping to a static page, or a resource that + * can be served autonomously by the remote end (the web server). + * br + * Payload description:br + * [string] An url-pattern as defined by the Servlet specification. */ -public static final int TYPE_CONF_APPLIC=0x03; +public static final int TYPE_CONF_MAP_ALLOW=0x08; /** + * CONF_MAP_DENY: The server replies to a CONF_MAP message with this + * packet to indicate a mapping to a resource that must be served by + * the server (servlet container). + * br + * Payload description:br + * [string] An url-pattern as defined by the Servlet specification. + */ +public static final int TYPE_CONF_MAP_DENY=0x09; + +/** + * CONF_MAP_DONE: The server replies to a CONF_MAP message with this + * packet to indicate that all servlet mappings have been successfully + * transfered to the other end + * br + * No payload:br + */ +public static final int TYPE_CONF_MAP_DONE=0x0a; + +/** * CONF_DONE: Client issues this message when all configurations have been * processed. * br * No payload:br */ -public static final int TYPE_CONF_DONE=0x04; +public static final int TYPE_CONF_DONE=0x0e;
Re: [VOTE] Tomcat 4.0-beta-7 Release Tonight ?
Craig R. McClanahan at [EMAIL PROTECTED] wrote: On Thu, 9 Aug 2001, Pier P. Fumagalli wrote: Craig R. McClanahan at [EMAIL PROTECTED] wrote: Just fixed this security vulnerability in 4.0 (3.2.3 isn't vulnerable, at least on Win98, but I didn't check 3.3). Therefore, I would propose to do a Beta 7 release tonight that picks up this change (and other bugfixes since Beta 6). I'm cool with it. Can I integrate the sources from WARP into the core Catalina distribution before the release? I'll tag also the jakarta-tomcat-connectors/webapp repository... Yep. Go ahead and integrate them. Done, jakarta-tomcat-connectors/webapp tagged with tomcat_40_b7. I'm not going to modify the Java sources anymore (maybe something will happen with the C portion of it, but it doesn't affect the Catalina distribution)... It's a GO for me... Pier
Re: [VOTE] Tomcat 4.0-beta-7 Release Tonight ?
Pier P. Fumagalli at [EMAIL PROTECTED] wrote: Craig R. McClanahan at [EMAIL PROTECTED] wrote: On Thu, 9 Aug 2001, Pier P. Fumagalli wrote: Craig R. McClanahan at [EMAIL PROTECTED] wrote: Just fixed this security vulnerability in 4.0 (3.2.3 isn't vulnerable, at least on Win98, but I didn't check 3.3). Therefore, I would propose to do a Beta 7 release tonight that picks up this change (and other bugfixes since Beta 6). I'm cool with it. Can I integrate the sources from WARP into the core Catalina distribution before the release? I'll tag also the jakarta-tomcat-connectors/webapp repository... Yep. Go ahead and integrate them. Done, jakarta-tomcat-connectors/webapp tagged with tomcat_40_b7. I'm not going to modify the Java sources anymore (maybe something will happen with the C portion of it, but it doesn't affect the Catalina distribution)... It's a GO for me... Forgot to mention... Once you do the build (tag the repo), I'm going to put a source of WebApp alongside with the regular Tomcat 4.0 distrib (as we did for B6). Pier
Re: [VOTE] Tomcat 4.0-beta-7 Release Tonight ?
+1 Amy - Original Message - From: Craig R. McClanahan [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, August 09, 2001 12:49 PM Subject: [VOTE] Tomcat 4.0-beta-7 Release Tonight ? Just fixed this security vulnerability in 4.0 (3.2.3 isn't vulnerable, at least on Win98, but I didn't check 3.3). Therefore, I would propose to do a Beta 7 release tonight that picks up this change (and other bugfixes since Beta 6). Thanks to [EMAIL PROTECTED] for the report. Craig McClanahan -- Forwarded message -- Date: 9 Aug 2001 19:43:00 - From: [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/http HttpProcessor.java craigmcc01/08/09 12:43:00 Modified:catalina/src/share/org/apache/catalina/connector/http HttpProcessor.java Log: Make request URIs the contain /... (or any longer series of periods) invalid. On some (all?) Windows platforms, this causes the OS to walk the directory tree just like ../../.. type sequences do. PR: Bugzilla #3062 Submitted by: [EMAIL PROTECTED] Revision ChangesPath 1.35 +9 -4 jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/http/Htt pProcessor.java Index: HttpProcessor.java === RCS file: /home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connecto r/http/HttpProcessor.java,v retrieving revision 1.34 retrieving revision 1.35 diff -u -r1.34 -r1.35 --- HttpProcessor.java 2001/07/26 05:31:05 1.34 +++ HttpProcessor.java 2001/08/09 19:43:00 1.35 @@ -1,6 +1,6 @@ -/* * $Header: /home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connecto r/http/HttpProcessor.java,v 1.34 2001/07/26 05:31:05 remm Exp $ - * $Revision: 1.34 $ - * $Date: 2001/07/26 05:31:05 $ +/* * $Header: /home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connecto r/http/HttpProcessor.java,v 1.35 2001/08/09 19:43:00 craigmcc Exp $ + * $Revision: 1.35 $ + * $Date: 2001/08/09 19:43:00 $ * * * @@ -106,7 +106,7 @@ * * @author Craig R. McClanahan * @author Remy Maucherat - * @version $Revision: 1.34 $ $Date: 2001/07/26 05:31:05 $ + * @version $Revision: 1.35 $ $Date: 2001/08/09 19:43:00 $ */ final class HttpProcessor @@ -879,6 +879,11 @@ normalized = normalized.substring(0, index2) + normalized.substring(index + 3); } + +// Declare occurrences of /... (three or more dots) to be invalid +// (on some Windows platforms this walks the directory tree!!!) +if (normalized.indexOf(/...) = 0) +return (null); // Return the normalized path that we have completed return (normalized);
[PATCH] TC 3.2.3 Bug #1141
I've wrapped the cookie creation in a try/catch to avoid having the
Exception kill the request. I also added some logging in the catch to log
the original cookie header string. Maybe I'll be able to find out what's
going on...
This is patched against the 3.2.3 final source.
Thanks,
--jeff
--- RequestUtil.java.orig Thu Aug 9 14:18:33 2001
+++ RequestUtil.javaThu Aug 9 14:31:31 2001
@@ -184,10 +184,23 @@
String name = token.substring(0, i).trim();
String value = token.substring(i+1, token.length()).trim();
- // RFC 2109 and bug
- value=stripQuote( value );
-Cookie cookie = new Cookie(name, value);
-cookies.addElement(cookie);
+// RFC 2109 and bug
+value=stripQuote( value );
+
+// Wrap the cookie creation in a try/catch to prevent bad
+// cookie names from killing the request -- Bug #1141
+try {
+Cookie cookie = new Cookie(name, value);
+cookies.addElement(cookie);
+}
+catch ( java.lang.IllegalArgumentException iae ) {
+
+// Log the original cookie header string, so we
+// can see what is causing this
+System.err.println(iae.getMessage() + \n +
+ Cookie Header: + cookieString);
+}
+
} else {
// we have a bad cookie just let it go
}
mod_webapp.so
Hello I have Debian unstable 2.4.7 Tomcat 4.0b6 Apache 2.0.16 I have followed the instraction on how to integrate apache + tomcat, i have build mod_webapp.so with no errors. i have added this lines to the httpd.conf LoadModule webapp_module /usr/local/apache/libexec/mod_webapp.so AddModule mod_webapp.c WebAppConnection warpConnection warp localhost:8008 WebAppMount examples warpConnection /examples/ when i start apache after tomcat i get this output Syntax error on line 980 of /usr/local/apache/conf/httpd.conf: Invalid command 'WebAppMount', perhaps mis-spelled or defined by a module not included in the server configuration ./apachectl start: httpd could not be started Has anybody had this problem before? Anybody know how to fix this? Sasha _ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp
Re: mod_webapp.so
aleksandre tartchinski at [EMAIL PROTECTED] wrote: Hello I have Debian unstable 2.4.7 Tomcat 4.0b6 Apache 2.0.16 I have followed the instraction on how to integrate apache + tomcat, i have build mod_webapp.so with no errors. i have added this lines to the httpd.conf LoadModule webapp_module /usr/local/apache/libexec/mod_webapp.so AddModule mod_webapp.c WebAppConnection warpConnection warp localhost:8008 WebAppMount examples warpConnection /examples/ when i start apache after tomcat i get this output Syntax error on line 980 of /usr/local/apache/conf/httpd.conf: Invalid command 'WebAppMount', perhaps mis-spelled or defined by a module not included in the server configuration ./apachectl start: httpd could not be started Has anybody had this problem before? Anybody know how to fix this? WebAppMount? It's WebAppDeploy (the parameters are right then) Where did you find that WebAppMount name? Pier
2 simple catalina questions
1. In server.xml, does an embeded listener take the same form as it does
in web.xml:
Connector ...
listener
listener-classmy.package.class/listener-class
/listener
/Connector
2. In the above example, should the custom jar containing
my.package.class simply be placed into the {TC_HOME}\server\lib
directory, or do I need to get it to the startup classloader some other
way?
Thanks!
- Christopher
Re: Patching GTest
Pier P. Fumagalli wrote: [pier@bubbles] ... Thanks for the visual ;-)
Re: [VOTE] Tomcat 4.0-beta-7 Release Tonight ?
Just fixed this security vulnerability in 4.0 (3.2.3 isn't vulnerable, at least on Win98, but I didn't check 3.3). Therefore, I would propose to do a Beta 7 release tonight that picks up this change (and other bugfixes since Beta 6). +1. Remy
Re: 2 simple catalina questions
On Thu, 9 Aug 2001, Christopher Cain wrote:
1. In server.xml, does an embeded listener take the same form as it does
in web.xml:
Connector ...
listener
listener-classmy.package.class/listener-class
/listener
/Connector
No, it follows the style of the other server.xml declarations instead:
* The element name is capitalized.
* The className attribute is used to identify which class should be
instantiated.
* Any other attribute names are matched up against your property setters
and they are called (with type conversions for Java native types).
So, if your listener has a setDebug(int debug) method, you can set the
listener and configure the debug level like this:
Connector ...
...
Listener className=my.package.class debug=0/
...
/Connector
An arbitrary number of properties can be set in this way.
2. In the above example, should the custom jar containing
my.package.class simply be placed into the {TC_HOME}\server\lib
directory, or do I need to get it to the startup classloader some other
way?
Yes, server/lib is the right place if your class is in a JAR
file. Unpacked classes can be placed in server/classes (which is not
created by default, but is added to the class loader if found).
Thanks!
- Christopher
Craig
cvs commit: jakarta-tomcat-4.0 RELEASE-NOTES-4.0-B7.txt
craigmcc01/08/09 17:08:19
Modified:.RELEASE-NOTES-4.0-B7.txt
Log:
Update beta-7 release notes with all current bugfixes.
Revision ChangesPath
1.2 +156 -1jakarta-tomcat-4.0/RELEASE-NOTES-4.0-B7.txt
Index: RELEASE-NOTES-4.0-B7.txt
===
RCS file: /home/cvs/jakarta-tomcat-4.0/RELEASE-NOTES-4.0-B7.txt,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- RELEASE-NOTES-4.0-B7.txt 2001/07/20 06:14:10 1.1
+++ RELEASE-NOTES-4.0-B7.txt 2001/08/10 00:08:19 1.2
@@ -3,7 +3,7 @@
Release Notes
=
-$Id: RELEASE-NOTES-4.0-B7.txt,v 1.1 2001/07/20 06:14:10 craigmcc Exp $
+$Id: RELEASE-NOTES-4.0-B7.txt,v 1.2 2001/08/10 00:08:19 craigmcc Exp $
@@ -22,6 +22,14 @@
Please report bugs and feature requests under product name Tomcat 4.
+ SECURITY VULNERABILITY FIXED: In addition to the new features and
+ bug fixes listed below, this release of Tomcat fixes a vulnerability
+ on Windows 9x platforms (at least, possibly on other Windows versions
+ as well) that causes request URLs like http://localhost:8080/.../;
+ to expose files on your disk. This vulnerability does not exist on
+ Unix platforms.
+
+
UPCOMING CHANGE NOTICE: In a future beta release of Tomcat 4.0, it
is likely that the default operational mode will be to run Tomcat
under a security manager (rather than the current default of not
@@ -44,11 +52,52 @@
General New Features:
+Documentation - Revised the installation instructions, as well as instructions
+for building from source, to reflect current dependencies.
+
+Spec Compliance - Tomcat 4 is now compliant with the changes in the Servlet 2.3
+(Proposed Final Draft 3) and JSP 1.2 (Proposed Final Draft 3) specifications.
+Further changes in the specifications are possible, but grow increasingly
+unlikely as they approach final release.
+
+Documentation - Started migrating to a new tomcat-docs web app that uses a
+standard stylesheet to manage the creation of documentation (in HTML format).
+This new web app is not yet included in the release, but a snapshot of the
+progress to date is available at:
+
+http://jakarta.apache.org/tomcat/tomcat-4.0-doc-exp/index.html
+
-
Catalina New Features:
-
+Connectors - Refactored the startup code so that Catalina can run on port 80
+(without being root) when started by JavaService or equivalent service
+managers.
+
+StandardContext / ProxyDirContext - Support the disabling of caching for
+static resource metadata.
+
+SingleSignOff Support - If you are using single sign on support with form
+based login, invalidating (or timing out) a session in one app will now sign
+the user off from all apps, as required by Servlet 2.3 PFD3.
+
+InstanceEvent - The events sent to Catalina-internal instance event listeners
+now include the request and response being processed if relevant.
+
+InstanceEvent - New event types for before and after dispatching are now
+fired when a servlet is invoked via a request dispatcher.
+
+Sessions and Requests - Internal implementation objects now support a new
+notes facility that lets Catalina components decorate them with extra
+information, without requiring creation of additional object properties, or
+exposing the information to applications by using attributes.
+
+AccessLogValve - Support a new combined logging format that includes the
+referer and user-agent headers, along with everything in the default common
+log format.
+
---
Jasper New Features:
@@ -59,7 +108,15 @@
Webapps New Features:
+SetCharacterEncodingFilter - A new Filter has been added to the /examples
+web application shipped with Tomcat, which allows you to programmatically
+determine what character set you wish to use to interpret request parameters
+for a given request, and then call request.setCharacterEncoding(). Doing this
+as a filter means you do not need to modify all of your servlets and JSP pages
+to include this functionality. Feel free to use this Filter as is, or as the
+basis for a more sophisticated implementation.
+
==
BUG FIXES AND IMPROVEMENTS:
==
@@ -69,15 +126,113 @@
Catalina Bug Fixes:
--
+WebappClassLoader - [Bugzilla #2725] Non-JAR files placed in
+/WEB-INF/lib would cause continuous reloads of a reloadable context.
+
+FileDirContext - Close the input stream after finishing copying. Otherwise,
+was causing problems deleting resources that were the source of a COPY.
+
+StandardContext
Re: [VOTE] Tomcat 4.0-beta-7 Release Tonight ?
Just fixed this security vulnerability in 4.0 (3.2.3 isn't vulnerable, at least on Win98, but I didn't check 3.3). Therefore, I would propose to do a Beta 7 release tonight that picks up this change (and other bugfixes since Beta 6). Send an email once the tag is in, so that I can build the Windows installer version. Remy
Re: Patching GTest
Christopher Cain at [EMAIL PROTECTED] wrote: Pier P. Fumagalli wrote: [pier@bubbles] ... Thanks for the visual ;-) On my terminal is all in colors... Pretty nice rainbow blue and pink :) Pier
cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/warp WarpConfigurationHandler.java
craigmcc01/08/09 17:58:53
Modified:catalina/src/share/org/apache/catalina/connector/warp
WarpConfigurationHandler.java
Log:
Fix an ArrayIndexOutOfBoundsException when processing security
constraints.
Revision ChangesPath
1.4 +2 -2
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/warp/WarpConfigurationHandler.java
Index: WarpConfigurationHandler.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/warp/WarpConfigurationHandler.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- WarpConfigurationHandler.java 2001/08/09 20:08:58 1.3
+++ WarpConfigurationHandler.java 2001/08/10 00:58:53 1.4
@@ -210,11 +210,11 @@
packet.reset();
packet.setType(
Constants.TYPE_CONF_MAP_DENY);
-packet.writeString(patt[x]);
+packet.writeString(patt[q]);
connection.send(packet);
if (Constants.DEBUG) {
logger.debug(Seurity +
- mapping \+patt[x]+
+ mapping \+patt[q]+
\);
}
}
Quick suggestion before the new beta tag
To do my connector testing, I just installed the TC4 binary on a Win98 machine (don't laugh :-) Anyway, not being very DOS/Win knowledgable, it took me a few minutes to figure out a slight problem with the Windoze startup logic that was causing it to simply spit out bad command or filename. DOS under Win98 does not like the: start Catalina .. bit, which I assume is what throws the new window under NT. Anyway, I eventually figured out to run catalina.bat with run instead of start so that it didn't use that prefix. How about a REM line in startup.bat that just lets users know to replace the start param to run under Win9x? A file comment should be a reasonably safe change to make just before a tag-n- release ... then again, it is Windoze =) - Christopher
cvs commit: jakarta-tomcat/src/doc tomcat-ug.html style.css
larryi 01/08/09 19:56:09 Modified:src/doc tomcat-ug.html style.css Log: Added some classloader information Revision ChangesPath 1.9 +99 -1 jakarta-tomcat/src/doc/tomcat-ug.html Index: tomcat-ug.html === RCS file: /home/cvs/jakarta-tomcat/src/doc/tomcat-ug.html,v retrieving revision 1.8 retrieving revision 1.9 diff -u -r1.8 -r1.9 --- tomcat-ug.html2001/08/09 19:18:38 1.8 +++ tomcat-ug.html2001/08/10 02:56:09 1.9 @@ -1,7 +1,7 @@ !DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.01 Transitional//EN html head -!-- $Id: tomcat-ug.html,v 1.8 2001/08/09 19:18:38 larryi Exp $ -- +!-- $Id: tomcat-ug.html,v 1.9 2001/08/10 02:56:09 larryi Exp $ -- !-- Copyright 1999-2001 Apache Software Foundation -- meta http-equiv=Content-Type content=text/html; charset=iso-8859-1 link rel=stylesheet href=style.css @@ -666,6 +666,104 @@ h3a name=configuring_tomcatConfiguring Tomcat/a/h3 + +pThere are two parts to Tomcat configuration:/p +ul + liConfiguring classes/li + liConfiguring the server/li +/ul + +h4Configuring Classes/h4 + +pConfiguring classes refers to configuring what classes are available and in +what manner when Tomcat is running. You may wish to add additional classes and +jars. Also, a web application may need some modification based on what Tomcat +makes available by default./p + +pThe available classes is determined by the classloader hierarchy that +Tomcat creates when it starts up. The classloader hierarchy built by Tomcat 3.3 +looks like this:/p + +table class=cltable + tr class=clt_datatd +table + tr class=clt_loadertdServer Classloader/td/tr + tr class=clt_labeltddirectory:/td/tr + tr class=clt_datatdlib/container/td/tr + tr class=clt_labeltddefault contents:/td/tr + tr class=clt_data +tdcrimson.jarbrfacade22.jarbr + jasper.jarbrjaxp.jarbrtomcat_modules.jarbrtomcat_util.jarbr + tomcat-startup.jarbrxalan.jar/td/tr + /table +/tdtdnbsp;/tdtdnbsp;/tdtdnbsp;/tdtd + table + tr class=clt_loadertdWebapp Classloader(s)/td/tr + tr class=clt_labeltddirectory:/td/tr + tr class=clt_datatdWEB-INF/classesbrWEB-INF/lib/td/tr + tr class=clt_datatd|/td/tr + tr class=clt_loadertdApps Classloader/td/tr + tr class=clt_labeltddirectory:/td/tr + tr class=clt_datatdlib/apps/td/tr + tr class=clt_labeltddefault contents:/td/tr + tr class=clt_datatdiempty/i/td/tr + /table + /td/tr + tr class=clt_datatdnbsp;/tdtd\/tdtdnbsp;/tdtd//tdtdnbsp;/td/tr + trtdnbsp;/tdtdnbsp;/tdtd +table + tr class=clt_loadertdCommon Classloader/td/tr + tr class=clt_labeltddirectory:/td/tr + tr class=clt_datatdlib/common/td/tr + tr class=clt_labeltddefault contents:/td/tr + tr class=clt_data +tdconnector_util.jarbrcore_util.jarbrjasper-runtime.jarbr + servlet.jarbrtomcat_core.jar/td/tr + /table + /td + tdnbsp;/tdtdnbsp;/td/tr + tr class=clt_datatdnbsp;/tdtdnbsp;/tdtd|/tdtdnbsp;/tdtdnbsp;/td/tr + trtdnbsp;/tdtdnbsp;/tdtd +table + tr class=clt_loadertdApplication Classloader/td/tr + tr class=clt_datatdthe CLASSPATH classloader/td/tr + tr class=clt_labeltddefault contents:/td/tr + tr class=clt_datatdtomcat.jar/td/tr + /table +/tdtdnbsp;/tdtdnbsp;/td/tr + tr class=clt_datatdnbsp;/tdtdnbsp;/tdtd|/tdtdnbsp;/tdtdnbsp;/td/tr + tr class=clt_loadertdnbsp;/tdtdnbsp;/tdtd +table + tr class=clt_loadertdJDK Extensions Classloader/td/tr + tr class=clt_labeltddirectory:/td/tr + tr class=clt_datatdijdk/i/jre/lib/ext/td/tr + /table/td + tdnbsp;/tdtdnbsp;/td/tr +/table + +pIn this classloader hierarchy, classloaders can access classes in +classloaders beneath them. They can not access classes in classloaders to the +side or above. With this in mind, a brief inspection should reveal that in +Tomcat 3.3, web applications do not have access to an XML parser by default. +The codejaxp.jar/code and codecrimson.jar/code are tucked away in the +bServer Classloader/b where they are accessible only within that classloader./p + +pAlso note that if you has a jar containing classes which depended on +codeservlet.jar/code, putting in on the CLASSPATH wouldn't work. +codeservlet.jar/code isn't accessible the bApplication Classloader/b. +This is why in Tomcat 3.3, your CLASSPATH envronment variable is ignored./p + +pThe standard way to add classes to Tomcat 3.3 is to place the classes in a +jar if they aren't already. Then place the jar in the directory that +corresponds to the appropriate classloader./p + +pA second method is available for adding classes to the bCommon
cvs commit: jakarta-tomcat-connectors/webapp/java WarpConfigurationHandler.java
pier01/08/09 19:58:01
Modified:webapp/java WarpConfigurationHandler.java
Log:
Reflecting bug found by Craig in Catalina sources. Thanks Craig :)
Revision ChangesPath
1.13 +2 -2
jakarta-tomcat-connectors/webapp/java/WarpConfigurationHandler.java
Index: WarpConfigurationHandler.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/webapp/java/WarpConfigurationHandler.java,v
retrieving revision 1.12
retrieving revision 1.13
diff -u -r1.12 -r1.13
--- WarpConfigurationHandler.java 2001/08/09 19:57:31 1.12
+++ WarpConfigurationHandler.java 2001/08/10 02:58:01 1.13
@@ -210,11 +210,11 @@
packet.reset();
packet.setType(
Constants.TYPE_CONF_MAP_DENY);
-packet.writeString(patt[x]);
+packet.writeString(patt[q]);
connection.send(packet);
if (Constants.DEBUG) {
logger.debug(Seurity +
- mapping \+patt[x]+
+ mapping \+patt[q]+
\);
}
}
Re: Vacation
Quoting Remy Maucherat [EMAIL PROTECTED]: Hi, I will be on vacation for two weeks starting this week-end. I will be back on the 26th. Where you headed, boss? Anywhere scandaleous?
Re: Quick suggestion before the new beta tag
By the TC4 binary do you mean the ZIP file or the new executable (.exe file) that includes an installer? The standard startup scripts work fine for me on my Win98 laptop ... the Catalina thing is ignored and Tomcat starts just fine in a separate window. Further, I've heard lots of other people say they run Tomcat 4 on Win98, and no other complaints about this issue. Maybe there is something wierd about your configuration? Craig On Thu, 9 Aug 2001, Christopher Cain wrote: To do my connector testing, I just installed the TC4 binary on a Win98 machine (don't laugh :-) Anyway, not being very DOS/Win knowledgable, it took me a few minutes to figure out a slight problem with the Windoze startup logic that was causing it to simply spit out bad command or filename. DOS under Win98 does not like the: start Catalina .. bit, which I assume is what throws the new window under NT. Anyway, I eventually figured out to run catalina.bat with run instead of start so that it didn't use that prefix. How about a REM line in startup.bat that just lets users know to replace the start param to run under Win9x? A file comment should be a reasonably safe change to make just before a tag-n- release ... then again, it is Windoze =) - Christopher
cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/modules/config BaseJkConfig.java ApacheConfig.java IISConfig.java NSConfig.java
larryi 01/08/09 20:57:08
Modified:src/share/org/apache/tomcat/modules/config ApacheConfig.java
IISConfig.java NSConfig.java
Added: src/share/org/apache/tomcat/modules/config BaseJkConfig.java
Log:
Some refactoring to make jk based auto-config generators consistent
as far as features.
Removed check in ApacheConfig for Ajp13Interceptor from
jakarta-tomcat-connectors.
Still need to update IISConfig.java and NSConfig.java to support the
forwardAll and noRoot attributes.
Revision ChangesPath
1.21 +10 -172
jakarta-tomcat/src/share/org/apache/tomcat/modules/config/ApacheConfig.java
Index: ApacheConfig.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/modules/config/ApacheConfig.java,v
retrieving revision 1.20
retrieving revision 1.21
diff -u -r1.20 -r1.21
--- ApacheConfig.java 2001/08/02 10:33:02 1.20
+++ ApacheConfig.java 2001/08/10 03:57:07 1.21
@@ -1,4 +1,4 @@
-/* $Id: ApacheConfig.java,v 1.20 2001/08/02 10:33:02 larryi Exp $
+/* $Id: ApacheConfig.java,v 1.21 2001/08/10 03:57:07 larryi Exp $
*
*
* The Apache Software License, Version 1.1
@@ -62,13 +62,8 @@
import org.apache.tomcat.util.io.FileUtil;
import org.apache.tomcat.util.log.*;
import java.io.*;
-import java.net.*;
import java.util.*;
-// Used to find Ajp1? connector port
-import org.apache.tomcat.modules.server.Ajp12Interceptor;
-import org.apache.tomcat.modules.server.Ajp13Interceptor;
-
/* The idea is to keep all configuration in server.xml and
the normal apache config files. We don't want people to
touch apache ( or IIS, NES ) config files unless they
@@ -90,7 +85,7 @@
*/
/**
-Generates automatic apache configurations based on
+Generates automatic apache mod_jk configurations based on
the Tomcat server.xml settings and the war contexts
initialized during startup.
p
@@ -112,7 +107,7 @@
/li
libjkConfig/b - path to use for writing Apache mod_jk conf file. If
not set, defaults to
-conf/jk/mod_jk.conf./li
+conf/auto/mod_jk.conf./li
libworkersConfig/b - path to workers.properties file used by
mod_jk. If not set, defaults to
conf/jk/workers.properties./li
@@ -122,7 +117,7 @@
libexec/mod_jk.so everywhere else./li
libjkLog/b - path to log file to be used by mod_jk./li
libjkDebug/b - JK Loglevel setting. May be debug, info, error, or emerg.
- If not set, defaults to no log./li
+ If not set, defaults to emerg./li
libjkProtocol/b The desired protocal, ajp12 or ajp13. If not
specified, defaults to ajp13 if an Ajp13Interceptor
is in use, otherwise it defaults to ajp12./li
@@ -149,10 +144,11 @@
/ul
p
@author Costin Manolache
+@author Larry Isaacs
@author Mel Martinez
- @version $Revision: 1.20 $ $Date: 2001/08/02 10:33:02 $
+ @version $Revision: 1.21 $ $Date: 2001/08/10 03:57:07 $
*/
-public class ApacheConfig extends BaseInterceptor {
+public class ApacheConfig extends BaseJkConfig {
/** default path to mod_jk .conf location */
public static final String MOD_JK_CONFIG = conf/auto/mod_jk.conf;
@@ -177,23 +173,8 @@
}
}
-public static final String JTC_AJP13_INTERCEPTOR =
-org.apache.ajp.tomcat33.Ajp13Interceptor;
-
-private File configHome = null;
private File jkConfig = null;
-private File workersConfig = null;
private File modJk = null;
-private File jkLog = null;
-
-private String jkProto = null;
-private int portInt=0;
-String tomcatHome;
-private boolean useJkMount=true;
-
-private String jkDebug=null;
-
-private boolean noRoot=true;
// ssl settings
private boolean sslExtract=true;
@@ -202,10 +183,6 @@
private String sslCipherIndicator=SSL_CIPHER;
private String sslCertsIndicator=SSL_CLIENT_CERT;
-// default is true until we can map all web.xml directives
-// Or detect only portable directives were used.
-boolean forwardAll=true;
-
public ApacheConfig() {
}
@@ -238,60 +215,10 @@
// Properties
-/** If false, we'll try to generate a config that will
- * let apache serve static files.
- * The default is true, forward all requests in a context
- * to tomcat.
Re: Quick suggestion before the new beta tag
Quoting Craig R. McClanahan [EMAIL PROTECTED]:
By the TC4 binary do you mean the ZIP file or the new executable
(.exe file) that includes an installer?
The zip.
The standard startup scripts work fine for me on my Win98 laptop ...
the Catalina thing is ignored and Tomcat starts just fine in a separate
window. Further, I've heard lots of other people say they run Tomcat 4
on Win98, and no other complaints about this issue. Maybe there is
something wierd about your configuration?
Hmmm ... I don't do that much on this box, so there's nothing too out of the
ordinary. I'm running the Sun 1.3.0 JDK, and this is the original Win98 (not
SE) with all of the current security patches.
My PATH is simply {jdk_dir}\bin, JAVA_HOME is {jdk_dir}, CLASSPATH simply has
rt.jar (for Jikes) catalina.jar, and servlet.jar (the TC4 one), and
CATALINA_HOME is set.
I've rebooted just to make sure that the ENV variables get set globally. Other
than that, it's a pretty bare-bones install. I just assumed that it was a
standard DOS thing in Win98, but I guess I'm the only one seeing it. Is my
setup pretty much the same as yours? Very strange ...
- Christopher
Re: Quick suggestion before the new beta tag
Sounds *very* similar to mine (original Win98, Sun JDK 1.3.0_02 although I
don't think that matters if it's not even executing the startup script
correctly).
I've got the usual config.sys entry to increase environment variable
space:
shell=c:\command.com c:\ /e:4096 /p
but Tomcat 4 is *much* less sensitive to this than 3.x was.
Grumble grumble ... Win98 is also the reason for tonight's release in the
first place .. the stupid OS interprets /../ type paths as the same
as an equivalent number of /../../.. entries (one level per extra dot
beyond the first two).
Craig
On Thu, 9 Aug 2001, Christopher Cain wrote:
Quoting Craig R. McClanahan [EMAIL PROTECTED]:
By the TC4 binary do you mean the ZIP file or the new executable
(.exe file) that includes an installer?
The zip.
The standard startup scripts work fine for me on my Win98 laptop ...
the Catalina thing is ignored and Tomcat starts just fine in a separate
window. Further, I've heard lots of other people say they run Tomcat 4
on Win98, and no other complaints about this issue. Maybe there is
something wierd about your configuration?
Hmmm ... I don't do that much on this box, so there's nothing too out of the
ordinary. I'm running the Sun 1.3.0 JDK, and this is the original Win98 (not
SE) with all of the current security patches.
My PATH is simply {jdk_dir}\bin, JAVA_HOME is {jdk_dir}, CLASSPATH simply has
rt.jar (for Jikes) catalina.jar, and servlet.jar (the TC4 one), and
CATALINA_HOME is set.
I've rebooted just to make sure that the ENV variables get set globally. Other
than that, it's a pretty bare-bones install. I just assumed that it was a
standard DOS thing in Win98, but I guess I'm the only one seeing it. Is my
setup pretty much the same as yours? Very strange ...
- Christopher
Re: Quick suggestion before the new beta tag
On Thu, 9 Aug 2001, Christopher Cain wrote: Quoting Craig R. McClanahan [EMAIL PROTECTED]: [snip] I've got the usual config.sys entry to increase environment variable space: shell=c:\command.com c:\ /e:4096 /p BINGO! That was it. My config.sys didn't have anything in it at all. Adding that line fixed it. Man ... there's an hour of my life I'll never get back. Sheesh ... the only thing that catalina.bat puts on your CLASSPATH is %CATALINA_HOME%\bootstrap.jar and %JAVA_HOME%\lib\tools.jar -- if Win98 can't even do that without a custom configuration setting, that's pretty lame. Grumble grumble ... Win98 is also the reason for tonight's release in the first place .. the stupid OS interprets /../ type paths as the same as an equivalent number of /../../.. entries (one level per extra dot beyond the first two). Holy ... are you serious?!? LOL! That's genius! Personally, I'm gonna test this connector and then exit this Mickey Mouse OS poste haste. I *really* feel for you guys who have to actually support a complex app on this abomination. It should be tried at the Hague for crimes against humanity. Yah, there's definitely times I wish that Java wasn't *quite* so write-once-run-anywhere ... :-). Thanks to both you guys for the assist! - Christopher Craig
Re: Quick suggestion before the new beta tag
Sounds *very* similar to mine (original Win98, Sun JDK 1.3.0_02 although I don't think that matters if it's not even executing the startup script correctly). I've got the usual config.sys entry to increase environment variable space: shell=c:\command.com c:\ /e:4096 /p but Tomcat 4 is *much* less sensitive to this than 3.x was. Grumble grumble ... Win98 is also the reason for tonight's release in the first place .. the stupid OS interprets /../ type paths as the same as an equivalent number of /../../.. entries (one level per extra dot beyond the first two). Oh, ok. It doesn't happen with NT/2k, right ? Remy
cvs commit: jakarta-tomcat-4.0 RELEASE-NOTES-4.0-B7.txt
craigmcc01/08/09 22:01:35
Modified:.RELEASE-NOTES-4.0-B7.txt
Log:
Update release notes to reflect the current status of testing mod_webapp.
Revision ChangesPath
1.3 +53 -10jakarta-tomcat-4.0/RELEASE-NOTES-4.0-B7.txt
Index: RELEASE-NOTES-4.0-B7.txt
===
RCS file: /home/cvs/jakarta-tomcat-4.0/RELEASE-NOTES-4.0-B7.txt,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- RELEASE-NOTES-4.0-B7.txt 2001/08/10 00:08:19 1.2
+++ RELEASE-NOTES-4.0-B7.txt 2001/08/10 05:01:34 1.3
@@ -3,7 +3,7 @@
Release Notes
=
-$Id: RELEASE-NOTES-4.0-B7.txt,v 1.2 2001/08/10 00:08:19 craigmcc Exp $
+$Id: RELEASE-NOTES-4.0-B7.txt,v 1.3 2001/08/10 05:01:34 craigmcc Exp $
@@ -21,7 +21,12 @@
Please report bugs and feature requests under product name Tomcat 4.
+This version of Tomcat 4 should be considered a release candidate for
+all capabilities except the mod_webapp connector. Only bugfix changes will
+be implemented before a Tomcat 4.0 final release is made available, which
+will occur when the Servlet 2.3 and JSP 1.2 specifications go final.
+
SECURITY VULNERABILITY FIXED: In addition to the new features and
bug fixes listed below, this release of Tomcat fixes a vulnerability
on Windows 9x platforms (at least, possibly on other Windows versions
@@ -30,7 +35,7 @@
Unix platforms.
- UPCOMING CHANGE NOTICE: In a future beta release of Tomcat 4.0, it
+ UPCOMING CHANGE NOTICE: In a future release of Tomcat 4.0, it
is likely that the default operational mode will be to run Tomcat
under a security manager (rather than the current default of not
using one). This may necessitate editing the policy permissions
@@ -55,10 +60,10 @@
Documentation - Revised the installation instructions, as well as instructions
for building from source, to reflect current dependencies.
-Spec Compliance - Tomcat 4 is now compliant with the changes in the Servlet 2.3
-(Proposed Final Draft 3) and JSP 1.2 (Proposed Final Draft 3) specifications.
-Further changes in the specifications are possible, but grow increasingly
-unlikely as they approach final release.
+Spec Compliance - Tomcat 4.0 is now compliant with the changes in the Servlet
+2.3 (Proposed Final Draft 3) and JSP 1.2 (Proposed Final Draft 3)
+specifications. Further changes in the specifications are possible, but grow
+increasingly unlikely as they approach final release.
Documentation - Started migrating to a new tomcat-docs web app that uses a
standard stylesheet to manage the creation of documentation (in HTML format).
@@ -189,10 +194,9 @@
walk up the directory tree and expose files, just like ../../.. type paths
would if they were not normalized.
-WARP Connector - Brought the sources of the WARP connector (used to talk with
-Apache+mod_webapp) up to date with the most recent bugfixes. Now passes all
-Watchdog and tester tests when running Apache+Tomcat (as well as when running
-Tomcat stand alone).
+WarpConnector - Brought the sources of the WARP connector (used to talk with
+Apache+mod_webapp) up to date with the most recent bugfixes. See below for
+current information about this connector.
@@ -275,3 +279,42 @@
errors when trying to use a different XML parser in a web application.
+-
+Tomcat 4.0 and Apache:
+-
+
+The binary distribution for Tomcat 4.0 includes the most recent stable version
+of the WARP connector, which is the Tomcat component that talks to mod_webapp
+inside Apache 1.3. The current state of this support is summarized as follows:
+
+* The mod_webapp connector is configured based on the contents of the
+ web.xml file for your web application. The only required per-webapp
+ configuration information in your Apache 1.3 httpd.conf file is
+ something like this:
+
+WebAppMount examples warpConnection /examples/
+
+ which causes mod_webapp to automatically recognize all of your servlet
+ mappings, security constraints, and other configuration elements.
+
+* Currently, mod_webapp forwards *all* requests under the specified
+ context path to Tomcat for processing. When Tomcat 4.0 final is released,
+ it will automatically configure itself to serve static resources
+ from Apache *unless* the resource is subject to filtering, or subject
+ to a security constraint, as defined in web.xml. No extra configuration
+ in httpd.conf will be required.
+
+* With this release, FORM-based authentication will work correctly, but
+ there is a bug that prevents BASIC authentication from operating. This
+ will be
Re: Quick suggestion before the new beta tag
Remy Maucherat wrote: Oh, ok. It doesn't happen with NT/2k, right ? Just as a curiosity, try this one on your W2K (I was told it works on NT as well): 1. Open a command prompt. 2. Run a command, that runs for a little while (e.g. ping -t some host). 3. Press F7 and ENTER repeatedly and quickly while the command runs. I wouldn't recommend doing it on a production server as it's going to reboot the system even if you aren't logged on as an admin. Works for me on W2K Pro SP2 ;-) Bojan
Re: Quick suggestion before the new beta tag
Quoting Craig R. McClanahan [EMAIL PROTECTED]: Sheesh ... the only thing that catalina.bat puts on your CLASSPATH is %CATALINA_HOME%\bootstrap.jar and %JAVA_HOME%\lib\tools.jar -- if Win98 can't even do that without a custom configuration setting, that's pretty lame. Actually, it wasn't the memory issue at all. For whatever reason, it just couldn't find the start command at all without the SHELL=c:\command.com pointer. Now why it could seemingly find every other command I've ever typed into this thing over the past few years, just not start, is anyone's guess. Man ... have I mentioned how much I absolutely LOVE having my all shell commands in one or two monolithic files, rather than two nice clean /bin /usr/bin directories with each separate binary there for the checking? Excellent design, this ... if you don't just *happen* to know where the start command lives, I guess you're just shite out of luck. Oh well, enough whining for tonight I suppose =) Yah, there's definitely times I wish that Java wasn't *quite* so write-once-run-anywhere ... :-). ANYTHING on Win is write-once-debug-anywhere ;-) Thanks again, chief! - Christopher
Re: Quick suggestion before the new beta tag
Quoting Craig R. McClanahan [EMAIL PROTECTED]: I haven't tested it myself, but the original reporter said that he suspected it *would* fail on NT. You can try it for yourself on Win2K with the following URL: http://localhost:8080/.../ If you get a directory listing of the %CATALINA_HOME%\webapps directory, then you are subject to the same security vulnerability and should upgrade. I'd like to know if it's OK under W2K, though, in order to say the right thing in the announcement email. I have the current TC4 beta installed on both an NT and Win2k machine :-) ... at work :-( I'll test them out first thing in the morning, if no one has gotten a chance to verify either or both by then (8:30am mountain). - Christopher
Re: Quick suggestion before the new beta tag
Remy Maucherat wrote: Oh, ok. It doesn't happen with NT/2k, right ? Just as a curiosity, try this one on your W2K (I was told it works on NT as well): 1. Open a command prompt. 2. Run a command, that runs for a little while (e.g. ping -t some host). 3. Press F7 and ENTER repeatedly and quickly while the command runs. I wouldn't recommend doing it on a production server as it's going to reboot the system even if you aren't logged on as an admin. Works for me on W2K Pro SP2 ;-) Ok, I try with my Win2k SP 2, and it works perfectly Sigh Remy
cvs commit: jakarta-tomcat-4.0/webapps/ROOT index.html
craigmcc01/08/09 22:40:43 Modified:catalina/src/share/org/apache/catalina Globals.java webapps/ROOT index.html Added: .RELEASE-NOTES-4.0-B8.txt Log: Prepare for beta-8 (if there is a need for one). Revision ChangesPath 1.1 jakarta-tomcat-4.0/RELEASE-NOTES-4.0-B8.txt Index: RELEASE-NOTES-4.0-B8.txt === Apache Tomcat Version 4.0 Beta 8 Release Notes = $Id: RELEASE-NOTES-4.0-B8.txt,v 1.1 2001/08/10 05:40:43 craigmcc Exp $ INTRODUCTION: This document describes the changes that have been made in the current beta release of Apache Tomcat, relative to the previous release. Bug reports should be entered at the bug reporting system for Jakarta projects at: http://nagoya.apache.org/bugzilla/ Please report bugs and feature requests under product name Tomcat 4. This version of Tomcat 4 should be considered a release candidate for all capabilities except the mod_webapp connector. Only bugfix changes will be implemented before a Tomcat 4.0 final release is made available, which will occur when the Servlet 2.3 and JSP 1.2 specifications go final. UPCOMING CHANGE NOTICE: In a future release of Tomcat 4.0, it is likely that the default operational mode will be to run Tomcat under a security manager (rather than the current default of not using one). This may necessitate editing the policy permissions file ($CATALINA_HOME/conf/catalina.policy) if your web applications require permissions that are not enabled by default (such as connecting to network ports). You are urged to test your applications with Tomcat 4.0-b5 running under the security manager now, so that this upcoming change will not be disruptive. To do so, start Tomcat 4.0 with the command $CATALINA_HOME/bin/catalina.sh start -security (Unix) or %CATALINA_HOME%\bin\catalina start -security (Windows). NEW FEATURES: General New Features: - Catalina New Features: - --- Jasper New Features: --- Webapps New Features: == BUG FIXES AND IMPROVEMENTS: == -- Catalina Bug Fixes: -- Jasper Bug Fixes: - Webapps Bug Fixes: - KNOWN ISSUES IN THIS RELEASE: -- Tomcat 4.0 and XML Parsers: -- Previous versions of Tomcat 4.0 exposed the XML parser used by Jasper (the JAXP/1.1 reference implementation) to web applications. This is no longer the case, because Jasper loads its parser with a new class loader instead. Keep the following points in mind when considering how to use XML parsers in Tomcat 4.0 and your web applications: * If you wish to make the JAXP/1.1 RI XML parser available to all web applications, simply move the jaxp.jar and crimson.jar files from the $TOMCAT_HOME/jasper directory to the $TOMCAT_HOME/lib directory. * If you wish to make another XML parser that is JAXP/1.1-compatible available to all web applications, install that parser into the $TOMCAT_HOME/lib directory and remove jaxp.jar and crimson.jar from the $TOMCAT_HOME/jasper directory. It has been reported that Xerces 1.3.1 can be used in this fashion, but 2.x alpha releases can not be. * If you wish to use an XML parser (such as Xerces) in the WEB-INF/lib directory of your web application, this should now be possible, because of the modified JAXP 1.1 parser mentioned below. WARNING: Tomcat 4.0 now ships with a modified version of the JAXP/1.1 (Final) jaxp.jar and crimson.jar files in the jasper subdirectory. The sealed attribute has been removed from the manifest file for these two JARs, to avoid package sealing violation errors that were caused by them in a JDK 1.3 environment. You MUST NOT replace these files with a different (or later) release of JAXP, unless that later release has had the sealed attribute removed, or you will encounter package sealing violation errors when trying to use a different XML parser in a web application. - Tomcat 4.0 and Apache: - The binary distribution for Tomcat 4.0 includes the most recent stable version
