[TC4] How to know when tomcat is properly shut down? (fwd)
Since nobody answered on tomcat-user, I'll just forward this one here (since I think it actually belongs here in the first place..) -- Forwarded message -- Date: Tue, 20 Nov 2001 18:14:20 +0100 (MET) From: Endre Stølsvik [EMAIL PROTECTED] Reply-To: Tomcat Users List [EMAIL PROTECTED] To: Tomcat user list [EMAIL PROTECTED] Subject: [TC4] How to know when tomcat is properly shut down? The catalina.sh and related scripts all start the Bootstrap.java class and asks it to shut down Catalina. This script, if successful in connecting to the shutdown port of Catalina, returns immediately. This whether or not there is 8953289527 pending database commits or whatever that has to be done before things actually are properly shut down. This is highly undesirable, and I would love if it were possible to shut down catalina and then chill untill it actually has shut down. This is especially important when shutting down the entire server, as the database shutdown might be the next in line, in which case everything breaks.. Of course, it would also be very nice if one could know if Catalina has properly come up. It could for example write a boolean file when the server has initialized all webapps, and then delete the same file right before the main method of Catalina exits on shutdown. Or one could use Bootstrap with argument -waitForUp or something.. --- And yes, Henri's init.d scripts also just fake this, waiting in just 2 seconds, which is too short time, and therefore the restart option of the init.d script is flawed. The shutdown part of it doesn't wait at all, so you might end up shutting the server physically down (read as: killing all the java threads w/o cleaning up) before tomcat has finished shutting down. Mvh, Endre -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 4994] New: - Tomcat needs a mechanism for clean and certain shutdown
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4994. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4994 Tomcat needs a mechanism for clean and certain shutdown Summary: Tomcat needs a mechanism for clean and certain shutdown Product: Tomcat 3 Version: 3.2.3 Final Platform: All OS/Version: All Status: NEW Severity: Normal Priority: Other Component: Config AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I've searched the web and posted this to tomcat-user without finding a solution, so I'm entering it here hoping that it might be considered a useful feature request. I'm entering this against 3.2.3 only because that it the version we're using at present. I believe that the same problem exists in Catalina. This problem stops us being able to use Tomcat for operational purposes. Other than that, we are very happy with Tomcat. Cheers, Andy. Hi all, I have a problem with stopping Tomcat reliably, initially as part of an NT system shutdown though I think the problem applies independent of OS. As best I understand it, when Tomcat is stopped by the conventional means (i.e. org.apache.tomcat.startup.Tomcat -stop) the stop action returns before the running Tomcat server has actually completed. This causes me a problem. When this action is part of a system shutdown we can end up with the Tomcat shutdown process failing to complete, before it gets killed. Given that our contexts can be running database updates, this is not a good situation. We're using Tomcat 3.2.3 at present and need to run on Java 1.3. The specific problem is on NT, but I believe that the root cause is the way Tomcat stop works, making it is OS independent. That is, it opens a connection via AJP12, sends a 'stop' message, and exits. If there is an acknowledgement of this from the stopping process, it is returned a good time before the final exit occurs. (Sorry for the uncertainty, I should have but haven't looked at the source yet). On *nix there would be some simple if in-elegant work-around based on sleeping the shutdown process. Even that doesn't seem to be available on NT. We've tried various NT service options (e.g. JavaService from Alexandria) and IIS in-process set-up, but none of them actually wait for Tomcat to exit. We've not tried the Jakarta NT Service as it is currently marked as not working on Java 1.3. So what we have not found is a way to shutdown Tomcat cleanly which waits for it to actually shutdown before returning, and allowing the system shutdown to continue. We could code up our own wrapper for start and stop but would prefer not to (we want to be able to run with existing Tomcat installations). Finally, some questions: 1. Is there another standard mechanism for stopping Tomcat which will wait for it to really shutdown? 2. Is there a parameter to org.apache.tomcat.startup.Tomcat -stop which would do this? 3. If not, are there changes in the Stop process in 3.3 or 4.0, which might help me? 4. If not, is anyone aware of this being considered as an enhancement to Tomcat? 5. If this is an issue for other people, and an enhancement to 'stop' would make sense, then let me know. I hope we could contribute it. Thanks for reading this. Any useful input on will be appreciated. Andy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Where IS mod_webapp ??
Endre Stølsvik wrote: On Tue, 20 Nov 2001, Chad Johnson wrote: | The WebApp Module has a little webpage. Take a look here. | | http://nagoya.apache.org/~pier/ Thanks! But I'd also like a more stable release. How do I get that? Take a look at http://jakarta.apache.org/builds/jakarta-tomcat-4.0/release/v4.0.1/bin/ Here you'll find a stable version of mod_webapp (in the linux, macosx, win32, solaris subdir). - And this is *WAY* underdocumented!! Just search the mailinglist archives ;-) Gerard -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
mod_webapp apache2 problems:
All of the particulars: uname -a = SunOS shaka 5.8 Generic_108529-12 i86pc i386 i86pc gcc -v = gcc version 2.95.3 20010315 (release) java -version = java version 1.4.0-beta3 Server version: Apache/1.3.22 (Unix) Server built: Nov 20 2001 12:00:29 Server version: Apache/2.0.29-dev Server built: Nov 20 2001 16:24:29 jakarta-tomcat-4.0 jakarta-tomcat-connectors CVS checkout on 11/21/01 Quick Synopsis of error (apache 2.0): Syntax error on line 2 of /opt/apache/conf/mod_webapp.conf: Invalid port number (p1) No Port statement found Apache 1.3.22 configured as: CFLAGS=-DEAPI \ ./configure --with-apr=/home/bpm/compile_area/httpd-2.0/srclib/apr \ --with-apxs=/opt/apache/bin/apxs \ --with-java \ --with-tomcat=/opt/jakarta-tomcat \ --enable-debug Apache 1.3.22 configured as: ./configure --with-apr=/home/bpm/compile_area/httpd-2.0/srclib/apr \ --with-apxs=/opt/apache2/bin/apxs \ --with-java \ --with-tomcat=/opt/jakarta-tomcat \ --enable-debug This is my mod_webapp.conf: --BEGIN-- WebAppConnection warpConnection warp shaka:8008 WebAppDeploy examples warpConnection /examples/ WebAppDeploy velexample warpConnection /veloExample/ WebAppDeploy forumdemowarpConnection /forumdemo/ WebAppDeploy cocoonwarpConnection /cocoon/ WebAppInfo /webapp-info --END-- For apache 2.0: /opt/apache2/bin/apachectl configtest [Wed Nov 21 08:54:00 2001] 3938 (wa_main.c:77) WebApp Library initializing [Wed Nov 21 08:54:00 2001] 3938 (wa_main.c:81) Initializing APR [Wed Nov 21 08:54:00 2001] 3938 (pr_info.c:66) INFO provider initialized [Wed Nov 21 08:54:00 2001] 3938 (pr_warp.c:62) WARP provider initialized [Wed Nov 21 08:54:00 2001] 3938 (wa_main.c:101) WebApp Library initialized [Wed Nov 21 08:54:00 2001] 3938 (wa_config.c:167) Created connection warpConnection (Prov: warp Param: shaka:8008) Syntax error on line 2 of /opt/apache/conf/mod_webapp.conf: Invalid port number (p1) No Port statement found Ok, for apache 1.3.22: /opt/apache/bin/apachectl configtest [Wed Nov 21 08:54:08 2001] 3941 (wa_main.c:77) WebApp Library initializing [Wed Nov 21 08:54:08 2001] 3941 (wa_main.c:81) Initializing APR [Wed Nov 21 08:54:08 2001] 3941 (pr_info.c:66) INFO provider initialized [Wed Nov 21 08:54:08 2001] 3941 (pr_warp.c:62) WARP provider initialized [Wed Nov 21 08:54:08 2001] 3941 (wa_main.c:101) WebApp Library initialized [Wed Nov 21 08:54:08 2001] 3941 (wa_config.c:167) Created connection warpConnection (Prov: warp Param: shaka:8008) [Wed Nov 21 08:54:08 2001] 3941 (wa_config.c:126) Created virtual host shaka:80 [Wed Nov 21 08:54:08 2001] 3941 (wa_config.c:100) Created application examples in path /examples/ [Wed Nov 21 08:54:08 2001] 3941 (wa_main.c:187) Application examples deployed for http://shaka:80/examples/ (Conn: warpConnection) [Wed Nov 21 08:54:08 2001] 3941 (wa_config.c:100) Created application velexample in path /veloExample/ [Wed Nov 21 08:54:08 2001] 3941 (wa_config.c:100) Created application forumdemo in path /forumdemo/ [Wed Nov 21 08:54:08 2001] 3941 (wa_config.c:100) Created application cocoon in path /cocoon/ [Wed Nov 21 08:54:08 2001] 3941 (pr_info.c:83) Provider is configuring _INFO_ with parameter [Wed Nov 21 08:54:08 2001] 3941 (wa_config.c:167) Created connection _INFO_ (Prov: info Param: ) [Wed Nov 21 08:54:08 2001] 3941 (wa_config.c:100) Created application _INFO_ in path /webapp-info/ [Wed Nov 21 08:54:08 2001] 3941 (pr_info.c:91) Provider is deploying _INFO_ for http://shaka:80/webapp-info/ (Conn: _INFO_) Syntax OK So, what happened so that Apache 2.0 doesn't work? -- Brian Millett Enterprise Consulting Group Shifts in paradigms (314) 205-9030 often cause nose bleeds. [EMAIL PROTECTED] Greg Glenn -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: mod_webapp apache2 problems:
On Wed, Nov 21, 2001 at 09:22:02AM -0600, Brian P Millett wrote: Quick Synopsis of error (apache 2.0): Syntax error on line 2 of /opt/apache/conf/mod_webapp.conf: Invalid port number (p1) No Port statement found Oooh, I bet it is related to the change that we committed to set port to 0 internally to represent that the port for the virtual server should be the port the connection actually comes in on. It's now done dynamically by the core at run-time per connection if port == 0 - which is the default for vhosts. When the connection is actually received, the port will be the correct value. I'll take a gander at compiling webapp and posting a patch. Can you verify with gdb or whatnot that wa_cvirtualhost is getting p=0? -- justin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 4545] - Webapp connector seg faults under an SSL connection
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4545. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4545 Webapp connector seg faults under an SSL connection [EMAIL PROTECTED] changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 4982] - HTC files aren't being attached
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4982. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4982 HTC files aren't being attached --- Additional Comments From [EMAIL PROTECTED] 2001-11-21 08:45 --- I don't understand this bug at all, since it's written in IE (instead of English). It could be a problem with MIME types declaration for the 'HTC' type. Static file serving by itself appears to be working very well. I would need a test case to be able to investigate the bug further (IE gurus, feel free to step in). -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 5004] New: - /a/b/c/nonexistent.jsp - a file and directory chain created. attack risk
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5004. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5004 /a/b/c/nonexistent.jsp - a file and directory chain created. attack risk Summary: /a/b/c/nonexistent.jsp - a file and directory chain created. attack risk Product: Tomcat 4 Version: 4.0.1 Final Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: Jasper AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Both for Tomcat 3.3 and 4.0.1 if we do a request /a/b/c/nonexistent.jsp while such file does not exist in the temporary dir where the compiled jsp-s are stored a/b/c directory chain is created and a file some empty or 1-byte size file is created with a name derived from nonexistent.jsp. (the file name differes between 3.3 and 4.0.1) Now imagine that someone does the following request 1/1/1/1/1/1 .. (32 directories) .. 1/1/1.jsp this will cause creation of 32 directories and 1 file. Then imagine he calls 2/2/2/... 2/2.jsp 3/3/3/ 3/3.jsp and so forth. Every request will trigger creation of 32 directory and 1 file. On some file systems it can happen that 1 directory may take 4kb of disk space. That is 4 x 32 = 128kb per request. 2 requests per second x 3600 - over 900 Mb per hour. This is a significant disk space leakage. This how a potential dos attack against Tomcat can be constructed -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 5005] New: - /a/b/c/nonexistent.jsp - a file and directory chain created. attack risk
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5005. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5005 /a/b/c/nonexistent.jsp - a file and directory chain created. attack risk Summary: /a/b/c/nonexistent.jsp - a file and directory chain created. attack risk Product: Tomcat 3 Version: 3.3 Final Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: Jasper AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Both for Tomcat 3.3 and 4.0.1 if we do a request /a/b/c/nonexistent.jsp while such file does not exist in the temporary dir where the compiled jsp-s are stored a/b/c directory chain is created and a file some empty or 1-byte size file is created with a name derived from nonexistent.jsp. (the file name differes between 3.3 and 4.0.1) Now imagine that someone does the following request 1/1/1/1/1/1 .. (32 directories) .. 1/1/1.jsp this will cause creation of 32 directories and 1 file. Then imagine he calls 2/2/2/... 2/2.jsp 3/3/3/ 3/3.jsp and so forth. Every request will trigger creation of 32 directory and 1 file. On some file systems it can happen that 1 directory may take 4kb of disk space. That is 4 x 32 = 128kb per request. 2 requests per second x 3600 - over 900 Mb per hour. This is a significant disk space leakage. This how a potential dos attack against Tomcat can be constructed The bug has been reported as #5004 for Tomcat 4.0.1 -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 4982] - HTC files aren't being attached
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4982. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4982 HTC files aren't being attached [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2001-11-21 08:50 --- This is not a bug. I found the solution for it , as sugegsted by [EMAIL PROTECTED], to test the mime-types. Adding the following lines to the web.xml file solves the problem : mime-mapping extensioncss/extension mime-typetext/css/mime-type /mime-mapping mime-mapping extensionhtc/extension mime-typetext/x-component/mime-type /mime-mapping Sorry for not finalizing other options before submitting this bug. Best regards and many thanks for the help , Avner Cohen. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 5004] - /a/b/c/nonexistent.jsp - a file and directory chain created. attack risk
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5004. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5004 /a/b/c/nonexistent.jsp - a file and directory chain created. attack risk --- Additional Comments From [EMAIL PROTECTED] 2001-11-21 08:51 --- This bug has been reported as bug 5005 for tomcat 3.3 -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
mod_jk milestones
Hi, I would like to put some labels on the CVS tree for mod_jk and start taking 'milestone' snapshots. The first 'label' would be retroactive - it should match tomcat4.0.1 release ( for 4.0 users to have something stable/labeled ). This tag is almost identical with what 3.3 uses, the only major diference between j-t-c and 3.3 is the ajp14 protocol that was introduced in j-t-c. I would like to get to a second milestone in mid-december. The major goal is to cleanup the code and allow more extensibility/hooks. This should eventually result in the first release of mod_jk as a separate component. The focus will be on interfaces ( the object-like system used by jk ), and should also be the first step toward APR-based implementation. Please send your vote/opinion/time frame. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: mod_webapp apache2 problems:
Justin Erenkrantz wrote: On Wed, Nov 21, 2001 at 09:22:02AM -0600, Brian P Millett wrote: Quick Synopsis of error (apache 2.0): Syntax error on line 2 of /opt/apache/conf/mod_webapp.conf: Invalid port number (p1) No Port statement found Oooh, I bet it is related to the change that we committed to set port to 0 internally to represent that the port for the virtual server should be the port the connection actually comes in on. It's now done dynamically by the core at run-time per connection if port == 0 - which is the default for vhosts. When the connection is actually received, the port will be the correct value. I'll take a gander at compiling webapp and posting a patch. Can you verify with gdb or whatnot that wa_cvirtualhost is getting p=0? -- justin p=0 :( The port is svr-port the hostname svr-server_hostname (svr=cmd-server) It is used before any connections... -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
jk_handler
mod_jk provides the communication between the web server and tomcat. It does so by using a number of abstractions: jk_service: represents the request and the callbacks supported by the web server. jk_endpoint: abstracts the callbacks supported by tomcat. The communication is done by passing messages. Each side has a dispatcher that receive message and calls the right method. AJP13 supports a minimal set of callbacks - only what's required to forward the request and get the response. AJP14 adds more - authenticating the connection and a discovery mechanism allowing auto-configuration of jk. There are more callbacks that were discussed, and a number of possible optimizations and features could be added. My proposal is to abstract the callback using jk_handle ( on the C side ), AjpHandler ( Java side ). The java side was already implemented for Ajp14 ( not perfect yet, just a start ). I would like to change the current Ajp13 connector to use the same model and callbacks ( Ajp14 is backward compatible, we now duplicate some code ). On C side, the handlers will implement a similar interface. The current object factory ( used to create workers, channels ) will also be used to register handlers. The 3 callbacks in jk_service and the discovery callback in ajp14 will implement the jk_handler interface. Right now the server adapter is implementing the jk_service interface - the change is quite small, the same methods will be used, just with a different initialization. The main benefit is that we'll be able to easily add more callbacks with minimal code changes. A second benefit will be that the code will be easier to understand, and the same abstractions will be used in both java and C side. I'm ( reasonably ) confident this change will have minimal impact on code stability. What do you think ? Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: mod_webapp apache2 problems:
Justin Erenkrantz wrote: On Wed, Nov 21, 2001 at 09:22:02AM -0600, Brian P Millett wrote: Quick Synopsis of error (apache 2.0): Syntax error on line 2 of /opt/apache/conf/mod_webapp.conf: Invalid port number (p1) No Port statement found Oooh, I bet it is related to the change that we committed to set port to 0 internally to represent that the port for the virtual server should be the port the connection actually comes in on. It's now done dynamically by the core at run-time per connection if port == 0 - which is the default for vhosts. When the connection is actually received, the port will be the correct value. I'll take a gander at compiling webapp and posting a patch. Can you verify with gdb or whatnot that wa_cvirtualhost is getting p=0? Put in a print statement, for the args going to wa_cvirtualhost: n=shaka, p=0 hope this helps -- Brian Millett Enterprise Consulting Group Shifts in paradigms (314) 205-9030 often cause nose bleeds. [EMAIL PROTECTED] Greg Glenn -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-4.0/catalina/src/conf web.xml
remm01/11/21 09:36:52 Modified:catalina/src/conf web.xml Log: - Add MIME type for htc. Submitted by Avner Cohen. Revision ChangesPath 1.31 +4 -0 jakarta-tomcat-4.0/catalina/src/conf/web.xml Index: web.xml === RCS file: /home/cvs/jakarta-tomcat-4.0/catalina/src/conf/web.xml,v retrieving revision 1.30 retrieving revision 1.31 diff -u -r1.30 -r1.31 --- web.xml 2001/10/29 17:39:49 1.30 +++ web.xml 2001/11/21 17:36:52 1.31 @@ -444,6 +444,10 @@ mime-typeapplication/mac-binhex40/mime-type /mime-mapping mime-mapping +extensionhtc/extension +mime-typetext/x-component/mime-type +/mime-mapping +mime-mapping extensionhtm/extension mime-typetext/html/mime-type /mime-mapping -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-4.0/catalina/src/conf web.xml
remm01/11/21 09:37:36 Modified:catalina/src/conf Tag: tomcat_40_branch web.xml Log: - Add MIME type for htc. Submitted by Avner Cohen. Revision ChangesPath No revision No revision 1.22.2.7 +4 -0 jakarta-tomcat-4.0/catalina/src/conf/web.xml Index: web.xml === RCS file: /home/cvs/jakarta-tomcat-4.0/catalina/src/conf/web.xml,v retrieving revision 1.22.2.6 retrieving revision 1.22.2.7 diff -u -r1.22.2.6 -r1.22.2.7 --- web.xml 2001/10/22 21:28:54 1.22.2.6 +++ web.xml 2001/11/21 17:37:36 1.22.2.7 @@ -448,6 +448,10 @@ mime-typeapplication/mac-binhex40/mime-type /mime-mapping mime-mapping +extensionhtc/extension +mime-typetext/x-component/mime-type + /mime-mapping + mime-mapping extensionhtm/extension mime-typetext/html/mime-type /mime-mapping -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Jk and APR
This has been discussed many times, and the only conclusion was that we should and will change mod_jk to use APR, but no clear plans were decided. My proposal is quite simple and require minimal code change. Mod_jk consist of a number of interfaces. We already added a channel interface that will abstract the communication ( which is where most of the platform dependent code is ). None of the interfaces is OS-dependent - only the implementations. So for all new code/workers/channels we can use APR. Mod_jk will still work without APR ( at least in the near future ), but not all features will be available. For the build process: we should use apr as a regular library. We'll use whatever is built into apache2.0, without modification. APR is supposed to eliminate the need for OS-specific code and configure - that means we can use a simpler makefile ( and/or the new ant based build). Does it sounds reasonable ? Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 5004] - /a/b/c/nonexistent.jsp - a file and directory chain created. attack risk
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5004. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5004 /a/b/c/nonexistent.jsp - a file and directory chain created. attack risk --- Additional Comments From [EMAIL PROTECTED] 2001-11-21 10:00 --- Next time, please use [EMAIL PROTECTED] to report security problems or potential security problems. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 4988] - Tomcat hangs after auto-start
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4988. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4988 Tomcat hangs after auto-start --- Additional Comments From [EMAIL PROTECTED] 2001-11-21 10:04 --- I'll need some test case to fix this, otherwise, I'll mark the bug as WORKSFORME and assume some kind of problem with the JDBC driver. Do you use the service installed by the installer, or is it the jk service ? What do you mean by Tomcat hangs ? Does the VM crash ? Does the server stop responding ? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 4990] - Allow a flag to the standard manager to specify sessions should be serialized or not
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4990. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4990 Allow a flag to the standard manager to specify sessions should be serialized or not [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2001-11-21 10:07 --- The 'saveOnRestart' attribute should do that. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/realm LocalStrings_es.properties
remm01/11/21 10:04:22
Modified:catalina/src/share/org/apache/catalina/realm
LocalStrings_es.properties
Log:
- Update the spanish strings.
Submitted by Vicente Salvador vicentesalvador at netscape.net
Revision ChangesPath
1.2 +28 -22
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/realm/LocalStrings_es.properties
Index: LocalStrings_es.properties
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/realm/LocalStrings_es.properties,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- LocalStrings_es.properties2000/12/31 16:30:35 1.1
+++ LocalStrings_es.properties2001/11/21 18:04:22 1.2
@@ -1,28 +1,34 @@
-# $Id: LocalStrings_es.properties,v 1.1 2000/12/31 16:30:35 nacho Exp $
+# $Id: LocalStrings_es.properties,v 1.2 2001/11/21 18:04:22 remm Exp $
# language es
# package org.apache.catalina.realm
-memoryRealm.alreadyStarted=Este Reino ya ha sido inicializado
-memoryRealm.authenticateFailure=Autentificacion fallida para el usuario {0}
-memoryRealm.authenticateSuccess=Autentificacion correcta para el usuario {0}
-memoryRealm.hasRoleFailure=El usuario {0} no tiene el rol {1}
-memoryRealm.hasRoleNone=Ningun usuario tiene el rol {0}
-memoryRealm.hasRoleSuccess=El usuario {0} tiene el rol {1}
-memoryRealm.hasRoleUser=El usuario {0} no existe en la base de datos de este reino
-memoryRealm.loadExist=El archivo {0} de usuarios no existe
-memoryRealm.loadPath=Caragando el archivo de usuarios {0}
-memoryRealm.notStarted=Este Reino ya no ha sido aun inicializado
-jdbcRealm.alreadyStarted=Este Reino ya ha sido inicializado
-jdbcRealm.authenticateFailure=Autentificacion fallida para el usuario {0}
-jdbcRealm.authenticateSuccess=Autentificacion correcta para el usuario {0}
-jdbcRealm.authenticateSQLException=Hubo una SQLException en authenticate: {0}
-jdbcRealm.hasRoleFailure=El usuario {0} no tiene el rol {1}
-jdbcRealm.hasRoleSuccess=El usuario {0} tiene el rol {1}
-jdbcRealm.hasRoleSQLException=Hubo una SQLException en hasRole: {0}
-jdbcRealm.notStarted=Este Reino ya no ha sido aun inicializado
-jdbcRealm.checkConnectionDBClosed=La conexion con la base de datos es nula o fue
esta cerrada. Intentando reabrirla.
-jdbcRealm.checkConnectionDBReOpenFail=La reapertura de la base de datos fallo.La
base de datos podria estar parada.
-jdbcRealm.checkConnectionClassNotFoundException=Clase del driver JDBC {0} no
encontrada
+jaasRealm.accountExpired=El usuario {0} NO ha sido autentificado porque ha expirado
su cuenta
+jaasRealm.authenticatedSuccess=El usuario {0} ha sido autentificado con éxito
+jaasRealm.credentialExpired=El usuario {0} NO ha sido autentificado porque ha
expirado su credencial
+jaasRealm.failedLogin=El usuario {0} NO ha sido autentificado porque ha fallado el
login
+jaasRealm.loginException=Login exception authenticating username {0}
+jdbcRealm.authenticateFailure=El usuario {0} NO ha sido autentificado correctamente
+jdbcRealm.authenticateSuccess=El usuario {0} ha sido autentificado correctamente
+jdbcRealm.close=Excepción al cerrar la conexión a la base de datos
+jdbcRealm.exception=Excepción al realizar la autentificación
+jdbcRealm.open=Excepción abriendo la conexión a la base de datos
+jndiRealm.authenticateFailure=Autentificación fallida para el usuario {0}
+jndiRealm.authenticateSuccess=Autentificación correcta para el usuario {0}
+jndiRealm.close=Excepción al cerrar la conexión al servidor de directorio
+jndiRealm.exception=Excepción al realizar la autentificación
+jndiRealm.open=Excepción al abrir la conexión al servidor de directorio
+memoryRealm.authenticateFailure=Autentificación fallida para el usuario {0}
+memoryRealm.authenticateSuccess=Autentificación correcta para el usuario {0}
+memoryRealm.loadExist=El fichero de usuarios {0} no ha podido ser leido
+memoryRealm.loadPath=Cargando los usuarios desde el fichero {0}
+memoryRealm.readXml=Excepción mientras se leia el fichero de usuarios
+realmBase.algorithm=El algoritmo digest {0} es invalido
+realmBase.alreadyStarted=Este dominio ya ha sido inicializado
+realmBase.digest=Error procesando las credenciales del usuario
+realmBase.hasRoleFailure=El usuario {0} NO tiene el rol {1}
+realmBase.hasRoleSuccess=El usuario {0} tiene el rol {1}
+realmBase.notStarted=Este dominio aún no ha sido inicializado
+
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 4887] - catalina / LocalStrings_es.properties needs update
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4887. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4887 catalina / LocalStrings_es.properties needs update [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2001-11-21 10:21 --- I applied the patch. Thanks ! -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-4.0 build.xml
remm01/11/21 10:24:05
Modified:.build.xml
Log:
- Make it possible to run the installer target separately.
- Improve the condition (no need for full.dist + won't be run without NSIS)
Revision ChangesPath
1.52 +2 -2 jakarta-tomcat-4.0/build.xml
Index: build.xml
===
RCS file: /home/cvs/jakarta-tomcat-4.0/build.xml,v
retrieving revision 1.51
retrieving revision 1.52
diff -u -r1.51 -r1.52
--- build.xml 2001/11/13 16:57:21 1.51
+++ build.xml 2001/11/21 18:24:05 1.52
@@ -214,7 +214,7 @@
!-- = DIST: Create Windows Installer === --
- target name=installer depends=dist, dist-source
+ target name=installer depends=dist, dist-source, prepare-release
description=Create Windows installer if=execute.installer
echo message=Builds a Windows installer based on Nullsoft Installer/
echo message=NSIS must be installed in the default directory/
@@ -270,9 +270,9 @@
target name=prepare-release
condition property=execute.installer
and
-equals arg1=${full.dist} arg2=on /
os family=windows /
available file=${javaservice.home}/bin/JavaService.exe /
+available file=${nsis.home}\makensis.exe /
/and
/condition
/target
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 5007] New: - Build From Source Instructions Misleading And Servletapi4 Needs Symlink
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5007. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5007 Build From Source Instructions Misleading And Servletapi4 Needs Symlink Summary: Build From Source Instructions Misleading And Servletapi4 Needs Symlink Product: Tomcat 4 Version: 4.0.1 Final Platform: PC OS/Version: Linux Status: NEW Severity: Normal Priority: Other Component: Unknown AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I have just built Tomcat 4.0.1 from source. I did not do a full.dist. There is 1 area whhere the instructions seems misleading or incorrect, and 1 place I needed to add a symlink. 1) The BUILDING.txt includes jndi in the optional section, but it isnt really - as ant detect puts it in the required section. 2) The ancillary distribution jakarta-servletapi-4 required a symlink docs-dist/docs in for the final stages of the Tomcat build to work. I built servletapi from source too. The only optional component I added was jsse-1.0.2. I encountered the same problems on Freebsd 4.4. P.s : otherwise great product -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
which WarpConnector.java is correct?
The WarpConnector.java files in jakarta-tomcat-connector/warp/java is not even close to the jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/warp/WarpConnector.java. Which is the correct one? This is for cvs co 11/21/01 @ 12:00 pm CST. -- Brian Millett Enterprise Consulting Group Shifts in paradigms (314) 205-9030 often cause nose bleeds. [EMAIL PROTECTED] Greg Glenn -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/ajp/tomcat33 Ajp14Interceptor.java
costin 01/11/21 12:49:55
Modified:jk/java/org/apache/ajp Ajp13.java Ajp14.java AjpHandler.java
NegociationHandler.java RequestHandler.java
jk/java/org/apache/ajp/test TestAjp13.java
jk/java/org/apache/ajp/tomcat33 Ajp14Interceptor.java
Log:
Removing a lot of duplicated code, update everything.
I tested with both 4.0.1 and 3.3 - it seems to work fine with both 13 and 14,
but I probably left few debug statements in.
This is not 'complete', there are still many things to clean up and make
sure we can use mod_jk ajp14 with both 13 and 14 servers and to start
integrating the 1.4 callbacks into 4.0.1.
Based on the feedback on the 'jk_handler' proposal, the code will be greatly
simplified and enhanced in the next few weeks.
Revision ChangesPath
1.19 +118 -622 jakarta-tomcat-connectors/jk/java/org/apache/ajp/Ajp13.java
Index: Ajp13.java
===
RCS file: /home/cvs/jakarta-tomcat-connectors/jk/java/org/apache/ajp/Ajp13.java,v
retrieving revision 1.18
retrieving revision 1.19
diff -u -r1.18 -r1.19
--- Ajp13.java2001/10/10 06:35:22 1.18
+++ Ajp13.java2001/11/21 20:49:54 1.19
@@ -103,15 +103,8 @@
public static final int MAX_SEND_SIZE = MAX_PACKET_SIZE - H_SIZE - 4;
// Prefix codes for message types from server to container
-public static final byte JK_AJP13_FORWARD_REQUEST = 2;
public static final byte JK_AJP13_SHUTDOWN = 7;
-// Prefix codes for message types from container to server
-public static final byte JK_AJP13_SEND_BODY_CHUNK = 3;
-public static final byte JK_AJP13_SEND_HEADERS = 4;
-public static final byte JK_AJP13_END_RESPONSE = 5;
-public static final byte JK_AJP13_GET_BODY_CHUNK= 6;
-
// Error code for Ajp13
public static final int JK_AJP13_BAD_HEADER= -100;
public static final int JK_AJP13_NO_HEADER = -101;
@@ -120,109 +113,18 @@
public static final int JK_AJP13_BAD_BODY = -104;
public static final int JK_AJP13_INCOMPLETE_BODY = -105;
-// Integer codes for common response header strings
-public static final int SC_RESP_CONTENT_TYPE= 0xA001;
-public static final int SC_RESP_CONTENT_LANGUAGE= 0xA002;
-public static final int SC_RESP_CONTENT_LENGTH = 0xA003;
-public static final int SC_RESP_DATE= 0xA004;
-public static final int SC_RESP_LAST_MODIFIED = 0xA005;
-public static final int SC_RESP_LOCATION= 0xA006;
-public static final int SC_RESP_SET_COOKIE = 0xA007;
-public static final int SC_RESP_SET_COOKIE2 = 0xA008;
-public static final int SC_RESP_SERVLET_ENGINE = 0xA009;
-public static final int SC_RESP_STATUS = 0xA00A;
-public static final int SC_RESP_WWW_AUTHENTICATE= 0xA00B;
-
-// Integer codes for common (optional) request attribute names
-public static final byte SC_A_CONTEXT = 1; // XXX Unused
-public static final byte SC_A_SERVLET_PATH = 2; // XXX Unused
-public static final byte SC_A_REMOTE_USER = 3;
-public static final byte SC_A_AUTH_TYPE = 4;
-public static final byte SC_A_QUERY_STRING = 5;
-public static final byte SC_A_JVM_ROUTE = 6;
-public static final byte SC_A_SSL_CERT = 7;
-public static final byte SC_A_SSL_CIPHER= 8;
-public static final byte SC_A_SSL_SESSION = 9;
-public static final byte SC_A_SSL_KEYSIZE = 11;
-
-// Used for attributes which are not in the list above
-public static final byte SC_A_REQ_ATTRIBUTE = 10;
-
-// Terminates list of attributes
-public static final byte SC_A_ARE_DONE = (byte)0xFF;
-
-// Translates integer codes to names of HTTP methods
-public static final String []methodTransArray = {
-OPTIONS,
-GET,
-HEAD,
-POST,
-PUT,
-DELETE,
-TRACE,
-PROPFIND,
-PROPPATCH,
-MKCOL,
-COPY,
-MOVE,
-LOCK,
-UNLOCK,
-ACL,
-REPORT,
-VERSION-CONTROL,
-CHECKIN,
-CHECKOUT,
-UNCHECKOUT,
-SEARCH
-};
-
-// id's for common request headers
-public static final int SC_REQ_ACCEPT = 1;
-public static final int SC_REQ_ACCEPT_CHARSET = 2;
-public static final int SC_REQ_ACCEPT_ENCODING = 3;
-public static final int SC_REQ_ACCEPT_LANGUAGE = 4;
-public static final int SC_REQ_AUTHORIZATION = 5;
-public static final int SC_REQ_CONNECTION = 6;
-public static final int SC_REQ_CONTENT_TYPE= 7;
-public static final
cvs commit: jakarta-tomcat-4.0 tomcat.nsi
remm01/11/21 13:04:52 Modified:.tomcat.nsi Log: - Update the install script after figuring out out to handle parameters in functions in NSIS (use the stack, assembly style ...). Using functions avoids code duplication, and will maybe allow enhancing further the env detection. - Add findJavaPath function: returns the JDK path. - Add findJVMPath function: returns the full path to the JVM DLL. - NSIS 1.67 recommended. Revision ChangesPath 1.21 +80 -47jakarta-tomcat-4.0/tomcat.nsi Index: tomcat.nsi === RCS file: /home/cvs/jakarta-tomcat-4.0/tomcat.nsi,v retrieving revision 1.20 retrieving revision 1.21 diff -u -r1.20 -r1.21 --- tomcat.nsi2001/11/17 22:32:30 1.20 +++ tomcat.nsi2001/11/21 21:04:52 1.21 @@ -1,6 +1,6 @@ ; Tomcat 4 script for Nullsoft Installer -; $Id: tomcat.nsi,v 1.20 2001/11/17 22:32:30 remm Exp $ +; $Id: tomcat.nsi,v 1.21 2001/11/21 21:04:52 remm Exp $ Name apache-tomcat-4.1 Caption Apache Tomcat 4.1 @@ -11,6 +11,7 @@ BGGradient 00 80 FF InstallColors FF8080 00 +InstProgressFlags smooth colored Icon main.ico UninstallIcon uninst.ico @@ -32,7 +33,7 @@ InstallDir $PROGRAMFILES\Apache Tomcat 4.1 InstallDirRegKey HKLM SOFTWARE\Apache\Apache Tomcat 4.1 -Section Tomcat 4.1 (required) +Section Tomcat (required) SectionIn 1 2 3 @@ -49,17 +50,9 @@ File webapps\*.xml File /r webapps\ROOT - ReadEnvStr $2 JAVA_HOME + Call findJavaPath + Pop $2 - IfErrors 0 FoundJDK - - ClearErrors - - ReadRegStr $1 HKLM SOFTWARE\JavaSoft\Java Development Kit CurrentVersion - ReadRegStr $2 HKLM SOFTWARE\JavaSoft\Java Development Kit\$1 JavaHome - - FoundJDK: - CopyFiles $2\lib\tools.jar $INSTDIR\common\lib 4500 SectionEnd @@ -67,24 +60,10 @@ Section NT Service (NT/2k/XP only) SectionIn 3 - - ReadEnvStr $1 JAVA_HOME - IfFileExists $1\jre\bin\hotspot\jvm.dll 0 TryJDK14 -StrCpy $2 $1\jre\bin\hotspot\jvm.dll -Goto EndIfFileExists - TryJDK14: -StrCpy $2 $1\jre\bin\server\jvm.dll - EndIfFileExists: - - IfErrors 0 FoundJDK - ClearErrors + Call findJVMPath + Pop $2 - ReadRegStr $1 HKLM SOFTWARE\JavaSoft\Java Runtime Environment CurrentVersion - ReadRegStr $2 HKLM SOFTWARE\JavaSoft\Java Runtime Environment\$1 RuntimeLib - - FoundJDK: - SetOutPath $INSTDIR\bin File /oname=tomcat.exe bin\tomcat.exe @@ -113,21 +92,13 @@ SectionEnd -Section Tomcat 4.1 Start Menu Group +Section Tomcat Start Menu Group SectionIn 1 2 3 - ReadEnvStr $2 JAVA_HOME - - IfErrors 0 FoundJDK - - ClearErrors + Call findJavaPath + Pop $2 - ReadRegStr $1 HKLM SOFTWARE\JavaSoft\Java Runtime Environment CurrentVersion - ReadRegStr $2 HKLM SOFTWARE\JavaSoft\Java Runtime Environment\$1 JavaHome - - FoundJDK: - SetOutPath $SMPROGRAMS\Apache Tomcat 4.1 CreateShortCut $SMPROGRAMS\Apache Tomcat 4.1\Tomcat Home Page.lnk \ @@ -162,9 +133,9 @@ SectionEnd -SectionDivider +SectionDivider documentation and examples -Section Tomcat 4.1 Documentation +Section Tomcat Documentation SectionIn 1 3 SetOutPath $INSTDIR\webapps @@ -195,9 +166,9 @@ SectionEnd -SectionDivider +SectionDivider developer resources -Section Tomcat 4.1 Source Code +Section Tomcat Source Code SectionIn 3 SetOutPath $INSTDIR @@ -235,8 +206,32 @@ ClearErrors - Call doUpdate + Call findJavaPath + Pop $1 + MessageBox MB_OK Using Java Development Kit found in $1 +FunctionEnd + + +Function .onInstSuccess + + ExecShell open '$SMPROGRAMS\Apache Tomcat 4.1' + +FunctionEnd + + +; = +; FindJavaPath Function +; = +; +; Find the JAVA_HOME used on the system, and put the result on the top of the +; stack +; Will exit if the path cannot be determined +; +Function findJavaPath + + ClearErrors + ReadEnvStr $1 JAVA_HOME IfErrors 0 FoundJDK @@ -256,18 +251,56 @@ Abort NoAbort: -MessageBox MB_OK Using Java Development Kit found in $1 + ; Put the result in the stack + Push $1 + FunctionEnd -Function .onInstSuccess +; +; FindJVMPath Function +; +; +; Find the full JVM path, and put the result on top of the stack +; Will exit if the path cannot be determined +; +Function findJVMPath - ExecShell open '$SMPROGRAMS\Apache Tomcat 4.1' + ReadEnvStr $1 JAVA_HOME + IfFileExists $1\jre\bin\hotspot\jvm.dll 0 TryJDK14 +StrCpy $2 $1\jre\bin\hotspot\jvm.dll +Goto EndIfFileExists + TryJDK14: +StrCpy
DO NOT REPLY [Bug 5007] - Build From Source Instructions Misleading And Servletapi4 Needs Symlink
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5007. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5007 Build From Source Instructions Misleading And Servletapi4 Needs Symlink --- Additional Comments From [EMAIL PROTECTED] 2001-11-21 13:26 --- 1) BUILDING.txt indeed requires some work to fix some inconsistencies. The one in the HEAD branch also seem to imply that all the dependencies are required (which is not the case). 2) I think defining a servlet.home property would have gotten the job done (see build.properties.sample). -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 4966] - request.getParameter(String) SOMETIMES fail to parse the querystring
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4966. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4966 request.getParameter(String) SOMETIMES fail to parse the querystring --- Additional Comments From [EMAIL PROTECTED] 2001-11-21 13:29 --- Have you checked in the access logs that all the requests were indeed specifying the parameters ? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: which WarpConnector.java is correct?
Brian P Millett wrote: The WarpConnector.java files in jakarta-tomcat-connector/warp/java is not even close to the jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/warp/WarpConnector.java. Which is the correct one? This is for cvs co 11/21/01 @ 12:00 pm CST. AFAIK active development of mod_webapp is taking place in jakarta-tomcat-connectors cvs module. Gerard -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: jk_handler
Hi Costin, What about modifying mod_jk so that it can dynamically load .so files (or .dll on windows) that export well-known method names, so that one doesn't need to recompile mod_jk to add different functionality/protocols etc. ? -Mike - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, November 21, 2001 9:29 AM Subject: jk_handler mod_jk provides the communication between the web server and tomcat. It does so by using a number of abstractions: jk_service: represents the request and the callbacks supported by the web server. jk_endpoint: abstracts the callbacks supported by tomcat. The communication is done by passing messages. Each side has a dispatcher that receive message and calls the right method. AJP13 supports a minimal set of callbacks - only what's required to forward the request and get the response. AJP14 adds more - authenticating the connection and a discovery mechanism allowing auto-configuration of jk. There are more callbacks that were discussed, and a number of possible optimizations and features could be added. My proposal is to abstract the callback using jk_handle ( on the C side ), AjpHandler ( Java side ). The java side was already implemented for Ajp14 ( not perfect yet, just a start ). I would like to change the current Ajp13 connector to use the same model and callbacks ( Ajp14 is backward compatible, we now duplicate some code ). On C side, the handlers will implement a similar interface. The current object factory ( used to create workers, channels ) will also be used to register handlers. The 3 callbacks in jk_service and the discovery callback in ajp14 will implement the jk_handler interface. Right now the server adapter is implementing the jk_service interface - the change is quite small, the same methods will be used, just with a different initialization. The main benefit is that we'll be able to easily add more callbacks with minimal code changes. A second benefit will be that the code will be easier to understand, and the same abstractions will be used in both java and C side. I'm ( reasonably ) confident this change will have minimal impact on code stability. What do you think ? Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: jk_handler
En réponse à [EMAIL PROTECTED]: mod_jk provides the communication between the web server and tomcat. It does so by using a number of abstractions: jk_service: represents the request and the callbacks supported by the web server. jk_endpoint: abstracts the callbacks supported by tomcat. The communication is done by passing messages. Each side has a dispatcher that receive message and calls the right method. AJP13 supports a minimal set of callbacks - only what's required to forward the request and get the response. AJP14 adds more - authenticating the connection and a discovery mechanism allowing auto-configuration of jk. There are more callbacks that were discussed, and a number of possible optimizations and features could be added. My proposal is to abstract the callback using jk_handle ( on the C side ), AjpHandler ( Java side ). Excellent. The java side was already implemented for Ajp14 ( not perfect yet, just a start ). I would like to change the current Ajp13 connector to use the same model and callbacks ( Ajp14 is backward compatible, we now duplicate some code ). On C side, the handlers will implement a similar interface. The current object factory ( used to create workers, channels ) will also be used to register handlers. The 3 callbacks in jk_service and the discovery callback in ajp14 will implement the jk_handler interface. Right now the server adapter is implementing the jk_service interface - the change is quite small, the same methods will be used, just with a different initialization. The main benefit is that we'll be able to easily add more callbacks with minimal code changes. A second benefit will be that the code will be easier to understand, and the same abstractions will be used in both java and C side. I'm ( reasonably ) confident this change will have minimal impact on code stability. What do you think ? Very good ideas, everything which make mod_jk more modular should be included. I love the callback and abstract concept. Let's go with it, my +100 - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 5007] - Build From Source Instructions Misleading And Servletapi4 Needs Symlink
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5007. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5007 Build From Source Instructions Misleading And Servletapi4 Needs Symlink --- Additional Comments From [EMAIL PROTECTED] 2001-11-21 23:00 --- with respect to 2), I think you are right, I used servlet.home=../servletapi-4, when ../servletapi-4/dist may well have been the story. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Triple initialization of Catalina/mod_webapp
This is a followup to a message I posted to the user list which describes some undesirable behavior of Tomcat 4.0.1 (unrelated to use of mod_webapp). My application's build process currently generates the deployment descriptor for my web app from many files which contain snippets of the final web.xml. After generation of the deployment descriptor (as $SRC_DIR/conf/web.xml), it is then copied into the appropriate sub directory of my webapps tree. At this point, I should be able to launch Catalina (using a $CATALINA_BASE of $SRC_DIR/site and $CATALINA_HOME of /usr/share/tomcat4). However, the file $SRC_DIR/conf/web.xml is read in before $CATALINA_BASE/webapps/myapp/WEB-INF/web.xml. Since both these files contain the same content, my web app is initialized multiple times. That the conf/web.xml relative to my current working directory is used at all at seems like undesirable behavior to me. If a conf/web.xml file is going to be looked for at all, at the very least it could be looked for relative to $CATALINA_BASE. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[ANNOUNCEMENT] Tomcat 3.2.4 Released
Jakarta Tomcat 3.2.4 is now available for download at http://www.apache.org/dist/jakarta/jakarta-tomcat/release/v3.2.4-beta-1 Tomcat 3.2.4 fixes bugs found since the Tomcat 3.2.3 release in July, 2001. See the RELEASE-NOTES file for details on bug fixes and changes in this release. Barring the need for critical security updates, this will be the last release of the Tomcat 3.2.x branch. Future Jakarta development for the Servlet 2.2/JSP 1.1 specification will be based on Tomcat 3.3. Marc Saegesser -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Where IS mod_webapp ??
Chad Johnson wrote: Hey, Pier can correct me on this, but I believe mod_webapp is still beta quality. So grabbing whats in CVS is a safe bet. The binarys that come with Tomcat 4.0.1 have some bugs that have since been corrected (ie only being able to reference web apps in $CATALINA_HOME/webapps). I don't think Pierre will correct you very soon, because I believe he's gonna be offline for quite some time (I read somewhere he's gonna travel a lot). But I believe you're correct on this one, grabbing something from cvs (or a nightly build) is better, because a few import bugs have been fix in cvs, but not in the version that's included in Tomcat4.0.1. Maybe someone of the Tomcat developers (that's why I'm cc-en this to tomcat-dev) could update the official version, or are there any bugs to be fixed in cvs? Gerard -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Where IS mod_webapp ??
Gerard van Enk wrote: Chad Johnson wrote: Hey, Pier can correct me on this, but I believe mod_webapp is still beta quality. So grabbing whats in CVS is a safe bet. The binarys that come with Tomcat 4.0.1 have some bugs that have since been corrected (ie only being able to reference web apps in $CATALINA_HOME/webapps). I don't think Pierre will correct you very soon, because I believe he's gonna be offline for quite some time (I read somewhere he's gonna travel a lot). But I believe you're correct on this one, grabbing something from cvs (or a nightly build) is better, because a few import bugs have been fix in cvs, but not in the version that's included in Tomcat4.0.1. Maybe someone of the Tomcat developers (that's why I'm cc-en this to tomcat-dev) could update the official version, or are there any bugs to be fixed in cvs? I have noted 5 bugs that I am trying to fix (4367, 4925, 4559 and 2941) and I have marked 4545 as fixed. A Big one with Apache-2.0 is due to some changes in httpd-2.0. But I think it would not be bad to make a release even with some opened bugs , the old release is a little too old. Any comments? Gerard -- To unsubscribe: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles with the list: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Where IS mod_webapp ??
jean-frederic clere wrote: Gerard van Enk wrote: Chad Johnson wrote: Hey, Pier can correct me on this, but I believe mod_webapp is still beta quality. So grabbing whats in CVS is a safe bet. The binarys that come with Tomcat 4.0.1 have some bugs that have since been corrected (ie only being able to reference web apps in $CATALINA_HOME/webapps). I don't think Pierre will correct you very soon, because I believe he's gonna be offline for quite some time (I read somewhere he's gonna travel a lot). But I believe you're correct on this one, grabbing something from cvs (or a nightly build) is better, because a few import bugs have been fix in cvs, but not in the version that's included in Tomcat4.0.1. Maybe someone of the Tomcat developers (that's why I'm cc-en this to tomcat-dev) could update the official version, or are there any bugs to be fixed in cvs? I have noted 5 bugs that I am trying to fix (4367, 4925, 4559 and 2941) and I have marked 4545 as fixed. The first one (4367) doesn't contain a lot of info, I am running Apache and mod_webapp without segfaults. A Big one with Apache-2.0 is due to some changes in httpd-2.0. But I think it would not be bad to make a release even with some opened bugs , the old release is a little too old. Any comments? I think it's a good idea to make a release. Gerard -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Where IS mod_webapp ??
On 21/11/2001 10:15 pm, Gerard van Enk [EMAIL PROTECTED] wrote: Any comments? I think it's a good idea to make a release. I'm on a plane ATM, but +1 for me, J.F., would you be R.M. for this one? Pier -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
