Re: New committer: Jean-Jacques Clar
I'm definitely a +1 on this. Since I changed jobs, I haven't been able to keep up like I would like, and Jean-Jacques has stepped in to help. Having worked directly with him, his is a great fit, especially since he is already a httpd and an apr committer, I think he can be a great help on mod_jk and mod_jk2 and any other Apache related plugins as well. Mike Anderson I'd like to nominate Jean-Jacques Clar [EMAIL PROTECTED] as committer for the JTC connectors. Jean-Jacques works for Novell where I met him already; he's there working with the Apache and Tomcat stuff, and since Mike left the company there's now no other commiter from Novell anymore with karma for the Tomcat stuff. Jean-Jacques is already commiter of httpd, and I think now also of apr, so I believe he's a good candidate. Guenter. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jk 1.2.6 release - need more binaries
Sorry I took so long, but the NetWare binaries are signed and posted based on the zip files generated by Guenter. I just built against the latest tag (JK_1_2_6_rel) and tested the generated NLMS before plugging them into Guenter zip file layouts. I did update the netscape zip to put the unzipped files in the correct place. Mike Anderson [EMAIL PROTECTED] 7/26/2004 4:56:19 AM Hi to all, For jk 1.2.6 the following binaries are allready available : Windows (ISAPI/JK for AP 1.3.31/JK for AP2 2.0.50) Linux (JK for Fedora Core 2 Apache 2.0.50, for Suse 8.0 Apache 2.0.50 PPC, for Suse 9.1 Apache 2.0) Solaris (JK for Apache 1.3.31 EAPI/STANDARD) iSeries (AS/400 V5R2 and UP) We need macosx and netware, solaris / Apache 2.x Thanks to commiters to upload them to Apache dist directory and don't forget to sign the binaries with you PGP/GPG key. Regards - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jk2 2.0.4 tagged
Henri, I've got the NetWare Apache 2 binary built and done a quick test of it. I've sent it to Guenter and Norm to get their ok. If you would like it earlier, it is at http://jakarta.apache.org/~mmanders Thanks, Mike Anderson [EMAIL PROTECTED] 3/25/2004 8:44:34 AM Henri Gomez wrote: Jess Holle wrote: Is there a source tarball for 2.0.4 available for download somewhere yet? -- Jess Holle Henri Gomez wrote: jk2 2.0.4 has been tagged. jk2_2_0_4 We're now in HEAD at 2.0.5-dev yes : http://jakarta.apache.org/~hgomez/ Hi to all, What's the status of the various binaries ? I've done the Fedora 1, Suse 9.0 and Suse SLES 8.0 (PPC) and I'm waiting for others bins (Mladen, Kurt, Mike ?) Regards - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/jk/native2 BUILD.txt
Looks good. Mike Anderson [EMAIL PROTECTED] 3/19/2004 8:26:57 AM hgomez 2004/03/19 07:26:57 Modified:jk/native2 BUILD.txt Log: Update to track Guenter Knauf remarks on Netware Revision ChangesPath 1.3 +13 -1 jakarta-tomcat-connectors/jk/native2/BUILD.txt Index: BUILD.txt === RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native2/BUILD.txt,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- BUILD.txt 19 Mar 2004 13:37:10 - 1.2 +++ BUILD.txt 19 Mar 2004 15:26:57 - 1.3 @@ -44,5 +44,17 @@ * Netware --- Guenter / Mike ? +Buid the JK2 connector for NetWare platform. + +The current NWNGUmakefile uses the same build system as Apache2 self for NetWare target. +Simply extract the downloaded archive, and follow the guideline which describes compilation of Apache2 self. + +After you have compiled Apache2 (this is mandatory for now since the prebuild process must have finished) +you can simply call the makefile with 'make -f NWGNUmakefile', this builds the connector for Apache2 in a +release or debug subdirectory, dependent if you specify to build a debug version or not. + +It is recommended to use Metrowerks CodeWarrior compiler for now; although the connector builds with GCC +for NetWare, it is not tested yet if it works - there are known issues with a bitfied and alignment which +have to be solved. + - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Vote] Guenter Knauf as commiter
A BIG +1. Guenter is awesome. Mike Anderson [EMAIL PROTECTED] 03/17 1:41 am Hi to all, jk2 2.0.4 seems in a good shape and I'd like to thanks all of you commiter, and tomcat-dev members for your feedback, patches and time. I'd like to see Guenter Knauf promoted to commiter since he provided us may fine patches on jk2 and help make this release happen. We need more and more people involved in the native side of jakarta-tomcat-connectors and Guenter show us these lasts week that he's a good candidate. Vote please, he's got of course my +1. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Vote] Guenter Knauf as commiter
[EMAIL PROTECTED] 03/17 10:04 am Mike Anderson wrote: A BIG +1. Guenter is awesome. And he's working on/for Novell ;-) Which is the only reason I didn't propose him myself. I didn't want to seem to have favorites based on platforms :-) Guenter does look at multiple platforms and has provided valuable patches for more than just NetWare. He definitely has helped improve the NetWare side of things though :-) Mike Anderson - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_jk 1.2.6 release
I'd like to see this since Henri's timeout fixes really help some issues that we've seen with apps that hang Tomcat threads. It might be good to wait until the POST data issues are resolved (see threads titled POST recovery in JK and JK2 HEAD and Mod_JK2 - Default Worker) Mike Anderson [EMAIL PROTECTED] 2/13/2004 2:13:03 PM I have noticed a number of bug fixes and patches to mod_jk 1.2. Whenever you think it is ready I can act as the release manager for a mod_jk 1.2.6 if you want me to. Regards, Glenn -- Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PATCH] ./native/netscape/nsapi.dsp - remove obsolete files
[EMAIL PROTECTED] 2/11/2004 2:11:08 AM Mike Anderson a écrit : It's fine by me. Günter is correct that MSVC will create these as necessary and you can build without them. I'd do it, but I'm clueless about the proper procedure in CVS (being a Windows/NetWare weenie:-) I'm learning though. I'm using Eclipse and it rocks in the CVS area :) I better get it and try it then, especially since Novell (my paycheck :-) is now joined Eclipse. Mike Anderson [EMAIL PROTECTED] 2/9/2004 5:05:53 AM Günter Knauf a écrit : Hi, the patch below removes the obsolete files from the project file; in addition I'd suggest to remove both *.dsw files from ./jk/native/netscape and ./jk/native/jni folders cause they are not needed - MSVC creates then self. removed, should I do the same for isapi ? I think that would be appropriate. These files are basically just the workspace settings and they aren't needed to build the project. Mike Anderson - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PATCH] ./native/netscape/nsapi.dsp - remove obsolete files
It's fine by me. Günter is correct that MSVC will create these as necessary and you can build without them. I'd do it, but I'm clueless about the proper procedure in CVS (being a Windows/NetWare weenie:-) I'm learning though. Mike Anderson [EMAIL PROTECTED] 2/9/2004 5:05:53 AM Günter Knauf a écrit : Hi, the patch below removes the obsolete files from the project file; in addition I'd suggest to remove both *.dsw files from ./jk/native/netscape and ./jk/native/jni folders cause they are not needed - MSVC creates then self. Commited Thanks Mike/Mladen, ok to remove *.dsw ? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: cvs commit: jakarta-tomcat-connectors/jk/native2/common jk_channel_socket.c
+1. Two reasons I haven't 1. I'm not a CVS expert and don't want to screw it up :-) 2. The only reason I patched it was because someone else (Henri I believe) was concerned about removing it and this was a more conservative approach. I did comment out that line to make sure that it would compile, but left it active when I checked it in. Mike Anderson [EMAIL PROTECTED] 2/3/2004 8:11:34 AM From: mmanders Modified:jk/native2/common jk_channel_socket.c Log: Fix problem with port higher than 32K. Provided by Guenter Knauf. Fixed compile problem for NetWare even though this isn't built for NetWare (or any other platform.) jk_channel_socket is depriciated, and it won't compile at all. at line 74 you have: #error jk_channel_socket is deprecated the entire file should be removed from CVS. MT. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jk2 2.0.4 release plan
I'll be happy to deliver zips instead of NLMS. for NetWare. Henri (and others) since we are tagging and releasing jk2 can/should we do the same for jk since I know there is added functionality (Ping/Pong and timeouts) there as well? Thanks, Mike Anderson [EMAIL PROTECTED] 2/3/2004 9:27:14 AM Hi, Since many people ask for a jk2 release, 2.0.4, I'll act as release manager if nobody else want to take the job before Friday. great, thanks! Comments welcome two things I would like to discuss: 1) I would like to see all binaries packed to tar.gz or zip; this is definitely better in two ways: the original file timestamp keeps intact, and if the download is broken normally the archiver reports that. Oh, I've just checked, and this is only true for win32 and netware with mod_jk, with mod_jk2 win32 has zip... please Mike, can you put up zip files instead of renamed NLMs - also with future mod_jk releases? 2) ask for a reason why the file extension was not changed to .so on Win32 when Apache 1.3.15 moved to this...? thanks, Guenter. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jk2 2.0.4 release plan
I think Guenter is asking that we change mod_jk2 do be .so. Right now we build a .dll (at least if we build from the project files) but it would be easy to change this to .so and I'd be happy to do it. Mike Anderson [EMAIL PROTECTED] 2/3/2004 9:57:00 AM Günter Knauf a écrit : Hi, Since many people ask for a jk2 release, 2.0.4, I'll act as release manager if nobody else want to take the job before Friday. great, thanks! Comments welcome two things I would like to discuss: 1) I would like to see all binaries packed to tar.gz or zip; Well it could be done easily, if nobody object, I'll choose .gz for Unixes and .zip for Windows. this is definitely better in two ways: the original file timestamp keeps intact, and if the download is broken normally the archiver reports that. Oh, I've just checked, and this is only true for win32 and netware with mod_jk, with mod_jk2 win32 has zip... please Mike, can you put up zip files instead of renamed NLMs - also with future mod_jk releases? 2) ask for a reason why the file extension was not changed to .so on Win32 when Apache 1.3.15 moved to this...? Do you want it to revert to .dll ? On my Windows box the Apache 2.0.47 came with module named .so and not .dll. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PATCH] ./native2/common/jk_channel_apr_socket.c - use apr_port_t instead of short for port
Committed.
Mike Anderson
[EMAIL PROTECTED] 2/2/2004 10:29:26 AM
Hi Henri,
Do you know what's about the ./native2/common/jk_channel_socket.c
file?
Does soemone still use it since APR is now mandatory, or can we
remove
it?
If it stays then we should also patch the port there to 'unsigned
short'...
Yes, it should be removed but the conservative approach will be to
have a patch for unsigned short
here we go:
http://www.gknw.com/test/jk_channel_socket.c.diff
# Patch to solve
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17579
#
--- ./jk/native2/common/jk_channel_socket.c.origThu Jan 29 18:23:28
2004
+++ ./jk/native2/common/jk_channel_socket.cMon Feb 02 18:19:28 2004
@@ -100,7 +100,7 @@
int ndelay;
struct sockaddr_in addr;
char *host;
-short port; /* Should be unsigned - big ports will fail */
+unsigned short port;
int keepalive;
int timeout;
};
@@ -116,7 +116,7 @@
*/
static int JK_METHOD jk2_channel_socket_resolve(jk_env_t *env, char
*host,
- short port,
+ unsigned short port,
struct sockaddr_in
*rc);
static int JK_METHOD jk2_channel_socket_close(jk_env_t *env,
jk_channel_t *ch,
@@ -276,7 +276,8 @@
/** private: resolve the address on init
*/
-static int JK_METHOD jk2_channel_socket_resolve(jk_env_t *env, char
*host, short port,
+static int JK_METHOD jk2_channel_socket_resolve(jk_env_t *env, char
*host,
+ unsigned short port,
struct sockaddr_in
*rc)
{
int x;
@@ -285,7 +286,7 @@
/* for now use the correct type, in_addr_t */
in_addr_t laddr;
-rc-sin_port = htons((short)port);
+rc-sin_port = htons((unsigned short)port);
rc-sin_family = AF_INET;
/* Check if we only have digits in the string */
Guenter.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Jk2 object model
I'm definitely interested in helping with this but feel I'm out of the loop a little. What areas would be best for me to research (JMX, jchannels, current mod_jk/mod_jk2 architecture, etc.) to be the most help? I'm somewhat familiar with the mod_jk stuff from supporting it on NetWare, and have started looking at mod_jk2 (it now mostly works on NetWare with Apache 2) but I know I'm behind in some of the other areas that have been mentioned. Where can I help? Mike Anderson [EMAIL PROTECTED] 1/11/2004 2:17:12 AM From: Costin Manolache Sent: 11. sije*anj 2004 2:36 To: Tomcat Developers List Subject: Re: Jk2 object model But this time I'd like to spend a month or so doing 'real' design without the single line of code. If we manage to put and describe our needs on the paper, the coding itself will took insignificant amount of time. If this plan shows that 90% of the existing codebase can be reused; even better. The first thing ( IMO ) is to decide on what improvements we need on the lower layer so it can satisfy any additional needs you may have - configuration, performance, integration with a wider set of applications, etc. We can do that for sure. Depends on how we approach to the 'evolution'. We can either try to find out how to 'adapt' the existing codebase or 'use' from the existing codebase. I would like to see a design or plan, or what ever you name it, that wouldn't limit itself from the start with the choose of JK, JK2 or webapp as a starting point, but rather use all of them as a knowledge-base foundation. Again, the major question is are there any developer needs and willing for that. I'll try to make some diagrams and some docs that will show what I have on my mind. This may even show that I've completely 'miss the subject' :-). MT. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Jk2 object model
I agree that the current connectors (jk and jk2) are fairly stable and done because they just work. The hardest part in using them is that there is a lot of duplicated setup between the Java/Tomcat side and the webserver configuration just to get things working. Then, when you add a new webapp into Tomcat, you have to remember to update the webserver configuration to handle the application. I like what Mladen said here: The concept (approach) as I see it is to be able to make a connector (integrator), that would allow the zero-based-configuration. Meaning that loading a module (filter) will automatically map the Tomcat web space to the web server. No matter if the TC was started in or out of the process, and no matter how much clustered instances exists on different nodes. Can we do this by evolving mod_jk or mod_jk2? I don't know. I believe it is possible and agree with Costin that this is probably the better way to go because this is what our users recognize as the connector of choice. Look at what happened with mod_webapp. I think that Pier and and Jean-Frederic did some great work on this, but the community (developers and users) never really got behind it. I don't know if that is because it was too revolutionary or what. I'm just worried that if we break too far from jk, we'll end up going nowhere. If we can evolve mod_jk or mod_jk2 to allow zero-based-configuration as Mladen suggests, I think that is the path that we should follow. If we have to revolt :-) and re-architect, we need to make sure that what we produce is soo much better that people can't wait to get it and help plug it into their web server. This includes getting it running and working on as many OS platforms and webservers as possible right up front. If there is developer interest for that, I'm willing to 'shake the things'. I'm (finally :-) ready to start diving in and help shake things up. aside I got stuck doing the management thing for a couple of years so I couldn't (didn't :-( ) contribute as much but I'm back on this pretty much full time now - as an engineer, not a manager :-). /aside Mike Anderson Sr. Software Engineer [EMAIL PROTECTED] Novell, Inc., The leading provider of Net business solutions http://www.novell.com [EMAIL PROTECTED] 1/8/2004 10:16:03 AM From: Costin Manolache So my suggestion ( deja vue ? ) is to use evolution :-). A change in the OO model ( if needed ) or fixing/improving the current one is not as big change as it seems - it's mostly in initialization code. How about 'revolution'? On the other hand how does the evolution differs from revolution? Javaspaces, other protocols, other transports and other servers can be added at any time - but I think it would be vital to _add_ them to an existing base instead of adding yet another new connector. I hate the word connector. I would like to name that new thing integrator (jakarta-tomcat-integrator, how that sounds?) It would IMO better describe that new approach (at least the one I have on my mind). and... If we don't put ourselfs out from 'reusable' concept, nothing new will ever be done thought. Trying to reclyle something, as you nicely said stable and done, is poinntless from the '(r)evolution' perspective. Either we'll do (like Monty Pyton's said) something completely different, or we'll be once again asking ourselfs the same questions for year or so, and the guys will still use the JK or swith to something else. MT. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Kurt Miller as commiter
+1 He's done a great job moving this forward. Mike Anderson [EMAIL PROTECTED] 11/11/2003 8:26:49 AM Hi to all, I would like to propose you a new tomcat commiter, Kurt Miller which as proposed many usefull patches for JK2. Since we want to deprecated jk and focus jk2, we need more people involved on jk2. Vote please. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jk/jk2 - time for apr
I'm +1 on moving jk2 (native2) to APR. I haven't had a lot of time to play with jk2, but I have seen that there are some issues with it on NetWare (something about it allocating stuff when Apache 2 initializes it's 1st load and then expecting that stuff to still be around when it comes up for real.) If jk2 is going to be the direction moving forward (which I believe is appropriate) I (or someone here at Novell) will have to address that before we can fully support it. Hopefully, moving to APR will ease that somewhat. Mike Anderson [EMAIL PROTECTED] 10/15/2003 9:48:40 AM jean-frederic clere a écrit : Henri Gomez wrote: Mladen Turk a écrit : +1 to use the APR as mandatory for the mod_jk. You can rename it to the mod_jk2 after that easily :-) Heu, the idea is to make jk2 (native2) apr mandatory. We'll keep jk as it is today. * the plan - update jk2 (native2) to use APR only - port jk add-ons like ping/pong to jk2 - test, test and re-test - mark jk as deprecated The rule will be to use the latest APR release, ie the one which goes with the latest Apache 2.0 release. We could handle more recent APR via : /* deprecated with apr 0.9.3 */ #include apr_version.h #if (APR_MAJOR_VERSION == 0) \ (APR_MINOR_VERSION = 9) \ (APR_PATCH_VERSION 3) #define apr_filepath_name_get apr_filename_of_pathname #endif It will make jk2 ideally suited for Apache 2, and since we could find apr.dll for Windows Box, it should be usable with IIS (Domino ?). I'd like to have comments from Nacho, JF Clere and Mike Anderson who are working of jk on others platforms/webservers. Using APR is a good idea but that is a lot of work. I have APR on all my strange platforms so no problem for me :-) iSeries is another quite exotic platform even if Rochester friends does a great job on Apache 2.0 integration on OS/400 ;) I was quite unhappy with the -1 on APR/mod_webapp but all the problems of APR years ago have contribued to make mod_webapp deprecated... At this time there wasn't an official APR release or official Apache 2 release, and webapp was using APR from HEAD CVS (with frequent changes). Now the situation is stabilized since major Linux distributions have Apache 2.0 bundled by default, so APR is allready available. We have to be carefull with the threads... Specialy if we want to add the feature to (re)start Tomcat automaticly from httpd. We should, allways, be very carefull with threads ;) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] release mod_jk 1.2.5
Here's my vote. Mike Anderson [EMAIL PROTECTED] 9/25/2003 6:59:10 AM The test results are in. No problems have been reported with the mod_jk 1.2.5 test release. ballot [ X] +1 release mod_jk 1.2.5 and I will help by building binaries for _NetWare Apache and Enterprise Server_ [ ] +0 release mod_jk 1.2.5 [ ] -0 please don't release, reason __ [ ] -1 you can't release because of __ /ballot Voting closes saturday morning. If the vote is to release, I will release the source over the weekend. Regards, Glenn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_jk 1.2.5 test release source distribution
There is one minor change to jk_version.h so that the module reports that it is version 1.2.5 instead of 1.2.5-dev. If you already cheated and modified that locally, or you don't care what it reports, you should be fine. Mike Anderson [EMAIL PROTECTED] 9/25/2003 8:00:54 AM The test release at cvs.apache.org/~glenn is what will be released with no changes and does reflect the source which was tagged as mod_jk_1_2_5. So yes, you can use binaries built from that source as mod_jk 1.2.5 release binaries. Regards, Glenn Jess Holle wrote: Were there any changes since the test release, i.e. does the tagging reflect (minus release notes, etc) the test release? [I'm asking as I've built binaries for all platforms I need from the test release and would like to avoid rebuilding all of them] Glenn Nielsen wrote: Glenn Nielsen wrote: Henri Gomez wrote: Glenn, could you tag JTC 1.2.5 so I could commit my work on JTC ? I would like to see modjk 1.2.5 tagged/released before committing this. I was waiting on a report for Windows before releasign, we now have that. I'll post a release vote shortly. mod_jk_1_2_5 has been tagged in CVS, the HEAD is now mod_jk 1.2.6-dev. Glenn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_jk 1.2.5 test release source distribution
Looks like Gleen was ahead of the game (as usual :-) and I was confused between what was in CVS and his tarball. Sorry for my misinformation. [EMAIL PROTECTED] 9/25/2003 8:38:51 AM Actually from my reading of jk_version.h this change was already made in the test release. [And the version string shows up as 1.2.5 on Windows.] Mike Anderson wrote: There is one minor change to jk_version.h so that the module reports that it is version 1.2.5 instead of 1.2.5-dev. If you already cheated and modified that locally, or you don't care what it reports, you should be fine. Mike Anderson [EMAIL PROTECTED] 9/25/2003 8:00:54 AM The test release at cvs.apache.org/~glenn is what will be released with no changes and does reflect the source which was tagged as mod_jk_1_2_5. So yes, you can use binaries built from that source as mod_jk 1.2.5 release binaries. Regards, Glenn Jess Holle wrote: Were there any changes since the test release, i.e. does the tagging reflect (minus release notes, etc) the test release? [I'm asking as I've built binaries for all platforms I need from the test release and would like to avoid rebuilding all of them] Glenn Nielsen wrote: Glenn Nielsen wrote: Henri Gomez wrote: Glenn, could you tag JTC 1.2.5 so I could commit my work on JTC ? I would like to see modjk 1.2.5 tagged/released before committing this. I was waiting on a report for Windows before releasign, we now have that. I'll post a release vote shortly. mod_jk_1_2_5 has been tagged in CVS, the HEAD is now mod_jk 1.2.6-dev. Glenn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_jk 1.2.5 test release source distribution
I have tested this source with Apache 1.3.28 and Netscape on NetWare 6 and Apache 2 on NetWare 6.5. No problems found. Mike Anderson [EMAIL PROTECTED] 9/14/2003 6:09:29 AM Thanks Kurt! It would be nice to see more reports for other OS/web servers before the final release is done. Glenn Kurt Miller wrote: From: Glenn Nielsen [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, September 07, 2003 12:26 AM Subject: mod_jk 1.2.5 test release source distribution I have generated a test release source distribution for mod_jk 1.2.5, you can find it at: http://jakarta.apache.org/~glenn/jakarta-tomcat-connectors-jk-1.2.5-src.tar.gz Please build and test on as many OS/web servers as possible. I have already tested on Solaris7/8 Sparc. If there are no problems with this source release I will call for a release vote Friday 9/12 and release Monday 9/15 if the vote passes. Regards, Glenn I have tested the test release on OpenBSD i386 and sparc64. No problems have been found. Regards, -Kurt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: in_addr_t and Linux 2.2
So, I was waiting for all of the changes before trying to recompile for NetWare and the current in_addr_t changes are causing Metrowerks to complain. I should have tried it as soon as it checked in, but wanted to try building with all of the changes. Sorry :-(. I'm trying to resolve it now so that we don't have to go through this after you grab a release. I'll hurry. Mike Anderson [EMAIL PROTECTED] 9/4/2003 1:57:52 PM Henri Gomez wrote: Glenn Nielsen a écrit : FYI, I have put building a test mod_jk 1.2.5 source distribution on hold pending Henri's work on IPV6. Henri, please let me know when you think we are ready for another test source dist. We may add the configure stuff to determine if in_addr_t is available. I'll take a look at it right now. BTW, IPV6 will be added in 1.2.6 (or later), so don't delay release for it OK, so are we ready for a test source release? Glenn -- Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: in_addr_t and NetWare (was in_addr_t and Linux 2.2)
Ok, I've committed the fix the has the exception for NetWare. I tried a bunch of different things and this was the only thing that work for all of the webserver on NetWare (Netscape, Apache 1.3, and Apache 2.0). Glenn, where did you learn such patience:-)? Thanks for keeping this moving forward. Mike Anderson [EMAIL PROTECTED] 9/5/2003 8:24:52 AM So, I was waiting for all of the changes before trying to recompile for NetWare and the current in_addr_t changes are causing Metrowerks to complain. I should have tried it as soon as it checked in, but wanted to try building with all of the changes. Sorry :-(. I'm trying to resolve it now so that we don't have to go through this after you grab a release. I'll hurry. Mike Anderson [EMAIL PROTECTED] 9/4/2003 1:57:52 PM Henri Gomez wrote: Glenn Nielsen a écrit : FYI, I have put building a test mod_jk 1.2.5 source distribution on hold pending Henri's work on IPV6. Henri, please let me know when you think we are ready for another test source dist. We may add the configure stuff to determine if in_addr_t is available. I'll take a look at it right now. BTW, IPV6 will be added in 1.2.6 (or later), so don't delay release for it OK, so are we ready for a test source release? Glenn -- Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release mod_jk 1.2.5
[EMAIL PROTECTED] 8/1/2003 4:39:27 AM No problems have been reported since the last test source distribution of mod_jk 1.2.5 was made available for testing July 26. ballot Please vote on a release of mod_jk 1.2.5: [ X] +1 release, and I will help build binaries for NetWare Apache 1.3/NetWare Apache 2.0/NetWare Enterprise_ os/web server [ ] +0 ok to release [ ] -0 release, but I still have a problem with _ [ ] -1 don't release, there is a problem with _ /ballot The votes will be counted Monday August 4 and the source dist release made if the vote passes. Regards, Glenn Mike Anderson - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_jk 1.2.4 test release distribution available
I've built and testing against apache 1.3.27, apache 2.0.45, and netscape on NetWare. It's all good :-) Mike Anderson [EMAIL PROTECTED] 6/2/2003 5:04:50 AM Has anyone had a chance to build and test the mod_jk 1.2.4 distribution below? THe only person I heard from was Henri who reported a typo in the docs. It would be nice to build and test this on as many OS/web servers as possible before release. Thanks, Glenn Glenn Nielsen wrote: I have created a test mod_jk 1.2.4 distribution and placed it in my home page at: http://cvs.apache.org/~glenn/jakarta-tomcat-connectors-jk-1.2.4-src.tar.gz Please build and test this release. If there are no problems with it I will publish it as an official release. Thanks, Glenn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_jk 1.2.3 release
I'm +1 for this as well and would like to get a fix in for the Apache modules. I will be happy to build and post NetWare modules in either case. I wanted to run my fix by Henri (and anyone else interested) first since he made the change based on a patch sent in. Basically, the change was how mod_jk is filling in the port. The change was from apr_sockaddr_port_get(port, r-connection-local_addr) (at least in the Apache 2 version - something similar in Apache 1.3) to ap_get_server_port(r). The comment says something about /* XXX: à la jk2 */ but when I looked in the jk2 code, it is still doing it the old way (looking in JTC/jk/native2/server/apache2/jk_service_apache2.c). In my testing, the new way only returns the default port for the server (i.e. the first Listen/Port directive) unless a VirtualHost section exists. If I have multiple ports opened that are providing the same content without an explicit VirtualHost (very common on NetWare for 80 and 443), the ap_get_server_port always returns 80 (or whatever the default port is). the apr_sockaddr_port_get appears to always return the correct port reguardless of whether or not there is a VirtualHost defined. To make a long story short, I'd like to put this back to the original call which had the comment /* get the real port (otherwise redirect failed) */. This has actually been validated in my testing. I just didn't want to break someone else if there was a different reason for the patch. Thanks, Mike Anderson [EMAIL PROTECTED] 3/17/2003 6:50:31 AM Thanks. It isn't ready yet. I tried over the weekend running Apache 2/mod_jk-1.2.3-dev on a production site. With my recent commits it is running much better, but it is still failing at least once a day. Argh! I'll have to go back once again and see if I can reproduce the failure on a test system. Glenn Henri Gomez wrote: Glenn Nielsen wrote: Henri Gomez wrote: Glenn Nielsen wrote: It has been a while since a mod_jk 1.2 release was done. There have been a number of bug fixes and a few minor feature enhancements. I just did some commits to fix some bugs I was seeing with mod_jk 1.2 and Apache 2.0. Some of these will also improve the connector for other web servers. (Better handling of aborted clients) I just upgraded one of our production sites from Apache 1.3 mod_jk 1.2.2 to Apache 2.0 mod_jk 1.2.3-dev. So far everything is looking good. I really wanted to add support for using the APR to implement a global tomcat socket connector pool. There just doesn't seem to be any easy way to do it without major code refactoring. Argh! JK2 is our target, with APR +/- mandatory. Perhaps we could do a mod_jk 1.2.3 release in two weeks or so? That should give adequate time for testing. +0 Good idea but don't have time to do the RI. Would you like doing it ? What is required to do the release? Do you have any notes on how to do connector releases? The usual part are : - tag JTC - make a source tarball, and keep only jk related stuff (see the contents of jk 1.2.2 tarball) - make binaries (I'll do the linux, may be Nacho or Mladen could make the windows/IIS and Mike Anderson the netware. - Make the announce. The only platforms I could build binaries for is Solaris 7/8 x86/sparc. Regards, Glenn -- Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Someone fix this...
DOH! Sorry. Thats what you get when you get a Non-Unix weanie to play around on a Unix box. I knew that I've had to do this in the past but completely spaced it for this. This should be fixed now. Mike Anderson [EMAIL PROTECTED] 10/29/02 03:51PM send_files failed to open /builds/jakarta-tomcat-connectors/jk/release/v1.2.0/bin/netware/mod_jk_1.3.n lm.asc: Permission denied send_files failed to open /builds/jakarta-tomcat-connectors/jk/release/v1.2.0/bin/netware/mod_jk_2.0.4 2.nlm.asc: Permission denied send_files failed to open /builds/jakarta-tomcat-connectors/jk/release/v1.2.0/bin/netware/nsapi_rd.nlm .asc: Permission denied Files not mirrored... Pier -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: [VOTE] Release Plan for Apache Tomcat 4.1
[X] +1 I approve this plan, and will help [ ] +0 I approve this plan, but can't help [ ] -0 I am not in favor of this plan [ ] -1 I am against this plan, because: I will try and get the NetWare plugins for the JK2 stuff built and posted. Mike Anderson -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Native Connector problems
The problem is that the default cache size is one and in the ajp_init function in jk_ajp_common.c we return from inside of an if when we initialize the cache so the secrect member of the structure never gets initialized. This caused some GPFs in certain cases on some of my builds. I've checked in the fix. All I did was move the line that initializes secret up above the if statement. Remy, would it be possible to relabel jk_ajp_common.c rev. 1.24 as the rev for tomcat_402? I've built and tested this fix on NetWare and the resolved my GPFs and bad behavior talking to older installations of Tomcat (i.e. 3.3). I was able to use the same module to talk to Tomcat 4.0.2 and Tomcat 3.3 from the same instance of the web server. I love it when a plan comes together :-) Mike Anderson [EMAIL PROTECTED] 02/12/02 05:19PM One of the last changes on the connector ( the secret ) introduced a bug, when worker_cache is enabled. The secret will not be initialized, and that may creates all kind of serious problems. Could you detail the problem ? -- 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: [4.0.2] [VOTE] Final release
[X] +1 - I support this release and I will help [ ] +0 - I support this release [ ] -0 - I do not support this release, because: I'll build NetWare mod_jk connectors. Mike Anderson -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [Vote] New committer: Eric Rescorla
+1 Thanks for the great work Eric. Mike Anderson [EMAIL PROTECTED] 12/07/01 08:11AM As you may know, Eric Rescorla is one the few specialists in SSL in the world, author of one of the few SSL bible books and he have also created the excellent OpenSource JSSE alternative, PureTLS. He strike back in adapting PureTLS to Tomcat, today Tomcat 3.3, and so I would like to propose him as a new committer. Votes please? -- 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: isapi_redirect.dll in ajp13-tc4.0
This fix was checked in on 11/19/2001.
Thanks,
Mike Anderson
[EMAIL PROTECTED] 12/04/01 06:32AM
Hello.
I tried building jakarta-tomcat-connectors-2003.tar.gz for ISAPI
and stepped into some trouble and fixed it.
I tried building jk/native/iis . Not working right away, after some
tracking down, I found out that one of the function pointer calls
were failing because of a calling sequence mismatch between the
caller and callee. On Windows, JK_METHOD is defined to one of those
VC++ keywords that change the stack frame. The keyword existed on the
caller side, but not the callee side. The functions are the virtual
functions of the jk_env type.
On the caller side, JK_METHOD was set.
[from jk_env.h]
struct jk_env {
...
jk_env_objectFactory_t *
(JK_METHOD *getFactory)( jk_env_t *env, char *type, char *name );
/** Register a factory for a type ( channel, worker ).
*/
void (JK_METHOD *registerFactory)(
jk_env_t *env, char *type, char *name,
jk_env_objectFactory_t factory);
On the callee side, it was not set.
[from jk_env.c]
static jk_env_objectFactory_t * jk_env_getFactory(
jk_env_t *env,
char *type,
char *name );
static void JK_METHOD jk_env_registerFactory(jk_env_t *env,
char *type,
char *name,
jk_env_objectFactory_t fact);
..
static jk_env_initEnv( jk_env_t *env, char *id ) {
/* env-logger=NULL; */
/* map_alloc( env-properties ); */
env-getFactory= (void *)jk_env_getFactory;
env-registerFactory= (void *)jk_env_registerFactory;
..
Removing the (void *) cast where the function table is set will
reveal
that the assignment is between incompatible pointer types.
Taking away the cast and either adding JK_METHOD on the function
declaration and implementation, or taking it away from the pointer
variable declarations, this can be solved.
I tried to see if this still remains in the cvs but the server seems
to
be overloaded or something. I couldn't check.
--
Hideo Takahashi
Business Solutions Division, Hitachi Ltd.
http://www.hitachi.co.jp/Div/bisd
--
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 versions
[EMAIL PROTECTED] 12/03/01 01:53PM On Mon, 3 Dec 2001 [EMAIL PROTECTED] wrote: On Mon, 3 Dec 2001, GOMEZ Henri wrote: Ok, let's release mod_jk to 1.2 and start 2.0. For 1.2 we have 2 choices: - Branch it at Nov 15 ( or around ), i.e. before jk_channel and the new stuff ( that will be part of jk2.0 ) was added. After reading the commit log - most changes related to jk_channel, jk_registry, etc are pretty safe ( as they don't change any logic ). We could actually release Jk1.2 using the main tree - if everyone is comfortable with that. If not - Oct21 is probably a good point to branch ( the release date for 3.3 ). I'm afraid that we need to go back to an earlier date and re-port some fixes. The main reason is because the default 3.3 workers.properties still reference ajp12 which the current codebase no longer supports. This causes the plugins to fail during initialization since the ajp12_worker_factory isn't even in the main tree. Either that, or we add ajp12 support back in long enough to do a release. I'll be happy to help either way. There are few fixes for ebcdic support and few small things that would have to be re-applied. Costin Mike Anderson -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] Release Tomcat 3.2.4
Vote to release the tomcat_32 branch as Tomcat 3.2.4. [X] +1. I agree with the proposal and I will help support the release. [ ] +0. I agree with the proposal but I will not be able to help support the release. [ ] -0. I don't agree with the proposal but I won't stop the release. [ ] -1. I disagree with the proposal and will explain my reasons. Mike Anderson -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PROPOSAL] Tomcat 3.2.4 release
-- Vote: Tomcat 3.2.4 Release Plan [X] +1 I am in favor of the release, and will help support it [ ] +0 I am in favor of the release, but am unable to help support it [ ] -0 I am not in favor of the release [ ] -1 I am against this proposal (must include a reason). -- Mike Anderson
Re: [ANNOUNCEMENT] Tomcat 3.3 Final Released
NetWare connectors are now available. Mike Anderson [EMAIL PROTECTED] 10/22/01 02:16PM At long last, Tomcat 3.3 has reached Final Release and is available for download. With its refactored set of core classes and modules, it offers a number of new features, better performance, and more flexible configuration over its predecessors. Also, it can be updated with add-on modules. The PasswordPrompter add-on module is a simple example and is available with this release. You can download the release from: http://www.apache.org/dist/jakarta/jakarta-tomcat/release/v3.3 Note: As of this moment, RPMs and netware connectors have not been added to the web site. They will appear in the near future. As a Tomcat 3.x release, it remains a reference implementation of the Servlet 2.2 and JSP 1.1 specifications. Note however that altering Tomcat's behavior with respect to the Servlet 2.2 and JSP 1.1 specifications invalidates its status as a reference implementation. Since the configuration improvements often involve differences from earlier Tomcat 3.2.x releases, you are strongly encouraged to review the readme file in Tomcat's doc directory. Especially section 5. NEW FEATURES AND CHANGES IN THIS RELEASE where some of the important differences are listed. A lot of new content has been added to the tomcat-ug.html. In addition, serverxml.html has been added to the site to provide reference information about the modules. If you upgrade to Tomcat 3.3, these documents are the first place to look for information about how to use Tomcat 3.3. To log problems or bugs, as well as submit patches, please refer to: http://jakarta.apache.org/site/bugs.html When logging bugs to Bugzilla, please specify the Product as Tomcat 3 and the Version as 3.3 Final. Also, supplying a test case will greatly improve our ability to address the problem. Please do so if at all possible. Thanks, Larry Isaacs P.S. I would like to thank the countless people who have contributed to the Tomcat 3.3 development. A special thanks goes to Costin Manolache who did the majority of the refactoring and is responsible in large part for many of the improvements you will find in Tomcat 3.3.
Re: [VOTE] New Committer
+1 Welcome Patrick. Mike Anderson [EMAIL PROTECTED] 10/17/01 10:02PM I would like to nominate Patrick Luby [EMAIL PROTECTED] for committer status. His recent contributions include several security-manager-related patches and documentation help, and appears keen to tackle the Admin Apps functionality as well. I think he would make an excellent addition to the team. Votes please? - Christopher /** * Pleurez, pleurez, mes yeux, et fondez vous en eau! * La moitié de ma vie a mis l'autre au tombeau. *---Corneille */
Re: [VOTE] New Committer: Bojan Smojver
+1 Keep up the good work Bojan! [EMAIL PROTECTED] 09/17/01 05:43AM I would like to propose Bojan Smojver as a committer. He has supplied a number of patches as well as done useful testing. I think he would make good addition to the Jakarta team. Vote, please... Larry Isaacs
Re: Remaining Tomcat 3.3 Issues
You can hunt me down, just use tranquilizers when you find me :-) All of the modifications for graceful restart were done in the 3.3 codebase. Most of them were done by Henri Gomez. I just put in a couple of patches for error conditions. 3.2.x still doesn't have these fixes in them, but they have been ported to JTC (from what I can see looking at the code.) Do we want to back port them to 3.2.x or just use JTC once 3.3 is released? Mike Anderson [EMAIL PROTECTED] 09/13/01 02:01PM I don't think they ever got back-ported to 3.2.x, but I don't know for sure. The files include: mod_jk.c[R1.9],jk_ajp13_worker.c[R1.8]. You'll have to hunt down Mike Anderson for the details. I just remember the commits. - Original Message - From: Larry Isaacs [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, September 13, 2001 1:06 PM Subject: RE: Remaining Tomcat 3.3 Issues Thanks. Do you know if just 3.3 was affected or 3.2.x as well? If you can give me a clue as to what was changed, I can try to determine this. Larry -Original Message- From: Bill Barker [mailto:[EMAIL PROTECTED]] Sent: Thursday, September 13, 2001 3:15 PM To: [EMAIL PROTECTED] Subject: Re: Remaining Tomcat 3.3 Issues I interpreted #111 to be the graceful restart clean-up problem that was fixed some months ago. - Original Message - From: GOMEZ Henri [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, September 13, 2001 12:13 PM Subject: RE: Remaining Tomcat 3.3 Issues 7. Evaluate whether anything should be done to deal with the use of non-thread-safe DateFormat and related classes. The Date used in Http10 connector response, is allready handled by stuff I commited some time ago which use a speed hack and return allready processed date String if it was processed in the same second removing need to use SimpeDateFormat at each hit. format1123() in org\apache\tomcat\util\buf\DateTool But the request.getDateHeader(Date) in facade is still using DateTool.parseDate(value) in DateTool which need to be synchronized. Question: should we sync in facade or in DateTool ? 1798 Tomcat 3.2.2b5 with Apache and ajp13 stops responding after This one is very difficult to reproduce (I never succeed). We need more information on configuration. May be related with CHUNKED. I'd like to see bug reporter to test against latest TC 3.3 8. We need to remove or optionally disable the shutdown support in Ajp13Interceptor. This allows configuring a password protected Ajp12Interceptor shutdown to be the only shutdown available. Having Ajp13 or Ajp12 shutdown from a distant machine is dangerous. We should use Ajp13 as link between web-server and tomcat and use Ajp12 accepting only from localhost. 9. Some files under src/native have embedded CR's, i.e. Unix files would have CRLF and Windows files would have CRCRLF's. These need to be fixed. Couldn't we say that ALL src in native will be only in Unix mode ? 11. Make sure we are okay with mod_jk not supporting Apache's rewrite in Tomcat 3.3's mod_jk. I'm fine with not supporting it, but I want to include some justification in the documentation to avoid some of the why don't you questions. As said Costin, making mod_jk using uri or unparsed_uri is not difficult, but we have here 2 situations. Strict respect of spec (unparsed) or mod_rewrite compatibility. Why not let the final user decide and create a new JkOptions directive (easy). ie : JkOptions +ForwardUnparsedURI = strict spec respect JkOptions -ForwardUnparsedURI = rewrite compatibility 111 after httpd reload mod_jk fails to find a worker BugRat Repo Didn't know this one but must be easy to handle 2333 Nor Oth PC [EMAIL PROTECTED] NEW HTTP Reason will be destroyed in header using AJP12 Some patch was sent some time ago and even if AJP12 is somewhat deprecated, I should try to commit the provided patch. 2550 Ajp13 Connection hanging on static content. Should take a look at this one even. Majority of users use Apache to handle static data but it must be investigated (I) 2927 Nor Oth PC [EMAIL PROTECTED] NEW ArrayIndexOutOfBoundsException when accessing ajp13 I take care of this I will update the RELEASE-PLAN-3.3 tomorrow with the previous schedule and these issues, updating as needed base on discussion that occurs before then. These issues are the driving force for when RC1 and RC2 can be built and posted. The dates previously voted on are still the targets, but may slip as needed to deal with these issues. I plan to go through (possibly with some help) all the Tomcat3 bugs. Where I find bugs for earlier Tomcat's that have not been addressed for Tomcat 3.3, I will do what I can to address them. I
Re: [VOTE] Removal of mod_jk for Apache 2.0 fromjakarta-tomcat for Tomcat 3.3
+1 JTC is the best place for this since it can be kept up to date with an appropriate version of APR and Apache 2.0. Mike Anderson [EMAIL PROTECTED] 09/07/01 12:44PM I agree with Costin's suggestion to remove the Apache 2.0 version of mod_jk from jakarta-tomcat for Tomcat 3.3. This would occur after any bug fixes missing from jakarta-tomcat-connectors were ported. It makes much more sense to have it live only in jakarta-tomcat-connectors where it can quickly respond to changes. I don't plan much maintenance on the connectors once Tomcat 3.3 is released. VOTE: [ ] +1 REMOVE: Apache 2.0 mod_jk should be removed from jakarta-tomcat for Tomcat 3.3 [ ] -1 KEEP: Apache 2.0 mod_jk should be kept in jakarta-tomcat for Tomcat 3.3 My vote is +1. Cheers, Larry -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Friday, September 07, 2001 2:17 PM To: [EMAIL PROTECTED] Subject: RE: cvs commit: jakarta-tomcat-connectors/webapp/apache-2.0 mod_w ebapp.c On Fri, 7 Sep 2001, GOMEZ Henri wrote: Don't forget that many of us must evaluate a KNOWN Apache 2.0 in real environnement. The most known are Apache sites which use the released version 2.0.24 :) We could do that a each release (2.0.24/2.0.25) but not in real-time ;) Probably the correct solution is somewhere in the middle. I agree with Henri that using the HEAD is extremely difficult for both developers and potential users who want to help testing or just evaluate 2.0+jk. However sticking with an old snapshot and not testing with the HEAD is also bad. Having more frequent 'stable' snapshots of 2.0 would be IMHO the best solution, and keeping jk in sync with the latest snapshot wouldn't be that difficult. At least we could get reproductible behavior - and more determinism. So my proposal for jk would be to use snapshots - regardless of alpha or beta status. When the dust settles on a 2.0 change and a new alpha/beta snapshot is released - we can update our APIs. BTW, giving the amount of change in 2.0 - what about removing the 2.0 jk connector from 3.3, and relying on j-t-c for a 2.0 connector ? Right now the jk code in jakarta-tomcat is supposed to be 'stable', and only clear bug fixes are ported back. The 2.0 module can't be considered stable ( since it changes all the time ) - and what could be released with 3.3 will be certainly out of sync the next day. Should we call a vote on this ? Costin
Re: [VOTE] Release Plan for Tomcat 3.3 (final release)
[EMAIL PROTECTED] 09/10/01 08:51AM Hi All, I propose to update the RELEASE-PLAN-3.3 with the schedule shown below to finish the release of Jakarta Tomcat 3.3. = Tomcat 3.3 Final Release Plan Ballot = [X] +1I am in favor of this plan, and will help [ ] +0I am in favor of this plan, but am unable to help [ ] -0I not in favor of this plan [ ] -1I am opposed to this plan, and my reason(s) are: Mike Anderson
Re: [VOTE] New commiter Ryan Bloom
+1 Welcome! Mike Anderson [EMAIL PROTECTED] 09/10/01 10:24AM I would like to propose Ryan Bloom as commiter in Tomcat, and particulary on jakarta-tomcat-connector. Ryan is one of the dev leader in Apache 2.0 and contributed many patch for both mod_jk and mod_webapp, showing us that connectors avoid politics :) Vote, please - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6
Re: [VOTE] New Tomcat Committer
+1 [EMAIL PROTECTED] 08/24/01 02:20PM As Jon informally did last week or so, I'd like to formally propose Christopher Cain [EMAIL PROTECTED] as a committer on Tomcat. He's contributed lots of useful discussion, patches, and documentation (particularly in the area of SSL-based things) and wants to do more. Votes, please? Craig
Re: Native configuration changes.
[EMAIL PROTECTED] 08/15/01 09:51AM Hi, Playing with the JNI connector, I found few simple ways to make it easier to set it up. Larry, Mike - let me know if you're ok ( and if you can take care of the doc part ). 1. JniConnector will be included in server.xml ( un-commented ). I added code inside to detect if tomcat is started in jni mode, and will stay silent if not. I'm ok with this. It would make it easier for users to be able to confiure if they only had to go to one place. 2. If we place all DLLs/SOs in TOMCAT_HOME/bin/native, I've added code that will set the library path automatically ( including so/dll/nlm extensions ). Also cleaner messages if the file is not there. Another great idea. 3. Same can be used to simplify mod_jk config, it's easier for ApacheConfig to generate this location instead of ApacheHome/libexec ( or modules/, depends on apache version ). See comments below. 4. The user will configure: - conf/jk/workers.properties: add 'inprocess' to the list of workers, set workers.java_home, ps, etc. ( quite easy IMHO ) - conf/server.xml: ApacheConfig jkProtocol=inprocess / - start tomcat ( so it can regenerate auto-config files in jni mode ) - start apache The problem with this is that when you start tomcat outside of Apache, it isn't really doing anything but generating the auto-config files. They whole idea of the JNI connector is that the web server starts its own version of Tomcat by instantiating a JVM inprocess. Even if you have an external Tomcat process running, the webserver wouldn't be talking to that one via JNI. This also means that you basically have to kill the Tomcat process that you start up by hand, plus, when Apache starts up it's version of Tomcat, it would probably overwrite the auto-config file as it came up which might cause some additional headaches. IMHO it's much simpler and cleaner - Larry, it's your call, the changes are easy on the java side - but docs need to be synchronized and we're quite late. Is it worth it ? Other than the auto-config stuff, I think changes you've proposed are valid, and I could try to sync the docs with these changes. Since we haven't heard any complaints about the JNI connector yet, and it hasn't worked until just now, I'm not sure if we want to mess with it at this point, or wait until we can look at some of the auto-configuration work being done with ajp14 and/or mod_webapp that would allow a lot more dynamic configuration with the plugin handling determining which url's it should be handling dynamically. Costin Mike
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
Re: Date in HTTP headers
+1 Mike Anderson [EMAIL PROTECTED] 07/26/01 12:03PM Hi, TC 3.2.3 and 3.3b1 didn't send the actually the Date header in http 1.0 connector. RFC2616 indicate that the Date header should be present. What's your opinion adding it to both implementation ? FYI, Tomcat 4.0 send the Date header :)
Re: bug? does getRemoteAddr() work in tc3.3-beta 1?
Clayton, This does seem to be a bug with the Http10Interceptor (or associated classes) :-( It does work correctly from a webserver :-) Could you please enter a bug in bugzilla http://nagoya.apache.org/bugzilla/enter_bug.cgi?product=Tomcat%203 so we can track it for 3.3 release? I'm sure it's probably a fairly easy fix but I'll have to trace it through the code (unless you wanted to.) Mike Anderson [EMAIL PROTECTED] 07/25/01 09:51AM Can someone check this bug? Of all functions to lose temporarily from version 3.2.2, this one is particularly important to me, as I use the remote IP address for security issues. It's easy to check. Just got to the exampels at localhost:8080/examples and execute Snoop and check the Remote Host Address for your IP address.
Re: Exception in UDecoder..
Martin, This was fixed in Tomcat 3.3 Milestone 4 (and Beta 1). Mike Anderson [EMAIL PROTECTED] 07/25/01 10:38AM Does anyone know about this (using Milestone 3 btw). Has it anything to do with the M$ encoding scheme and should I try to fix it ? Mvgr, Martin java.lang.ArrayIndexOutOfBoundsException at org.apache.tomcat.util.buf.UDecoder.convert(UDecoder.java:99) at org.apache.tomcat.util.http.Parameters.processParameters(Parameters.java:385 ) at org.apache.tomcat.core.Request.handlePostParameters(Request.java:411) at org.apache.tomcat.facade.HttpServletRequestFacade.getParameterValues(HttpSer vletRequestFacade.java:254) at com.cubicinternational.components.scheduler.EditSchedule.EditSchedule(EditSc hedule.java:59) at com.cubicinternational.components.scheduler.EditSchedule.doPost(EditSchedule .java:48) at javax.servlet.http.HttpServlet.service(HttpServlet.java) at javax.servlet.http.HttpServlet.service(HttpServlet.java) at org.apache.tomcat.facade.ServletHandler.doService(ServletHandler.java:500) at org.apache.tomcat.core.Handler.service(Handler.java:223) at org.apache.tomcat.facade.ServletHandler.service(ServletHandler.java:448) at org.apache.tomcat.core.ContextManager.internalService(ContextManager.java:82 6) at org.apache.tomcat.core.ContextManager.service(ContextManager.java:739) at org.apache.tomcat.modules.server.Ajp13Interceptor.processConnection(Ajp13Int erceptor.java:162) at org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:435) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.jav a:505) at java.lang.Thread.run(Thread.java:484)
Re: Separating Service code from Tomcat 4.0
[ ] +1 - Do it, and I can help [X] +0 - Do it, but I can't help [ ] -0 - Do it, even if [ ] -1 - Don't do it, because My comments: Haven't even looked at it but I trust Pier :-) Mike Anderson
RE: [PATCH] Ajp13 wrong Response
Henri, Check what I just checked in to TC3.3. I'm pretty sure it is a more comprehensive fix for the same issue. We had seen this internally and needed a fix for it and so I just committed my fix. Mike Anderson [EMAIL PROTECTED] 07/10/01 01:58AM I'll study carefully this one to see if he didn't broke the recovery stuff added to handle case where tomcat is restarted... Thanks - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 -Original Message- From: William Barker [mailto:[EMAIL PROTECTED]] Sent: Monday, July 09, 2001 8:58 PM To: [EMAIL PROTECTED] Subject: [PATCH] Ajp13 wrong Response This fixes the problem reported by Angel Aray in thread 23795. The diff is against TC3.3 M4. What was happening is that the user hitting the stop button in the browser was invoking the re-try broken connection logic. This totally freaks out the proxy server who now thinks that the re-sent page is actually the page for a different request.
Re: [PROPOSAL] Tomcat 4.0-beta-6 Release on Thursday07/19/2001
Please vote on a Tomcat 4.0-beta-6 Release: [ ] +1 - I support this proposal, and will actively assist [X] +0 - I support this proposal, but do not have time to assist [ ] -0 - I do not support this proposal, but am not going to resist :-) [ ] -1 - I oppose this proposal (backed by reasons and/or workarounds) Mike Anderson
Problems with reloading contexts
I think I've found a problem with reloading in 3.3. When a the ROOT context is reloaded, it seems to blow away mappings to the other contexts, making them unavailable. To demonstrate this, I performed the following steps: 1. Bring up Tomcat (this is the easy part :-) 2. From a browser, access http://127.0.0.1:8080/servlet/SnoopServlet. We get a valid page back. 3. From a browser, access http://127.0.0.1:8080/examples/servlet/RequestInfoExample. We get a valid page back. 4. Change to $TOMCAT_HOME\webapps\ROOT\WEB-INF\classes and touch (or recompile) SnoopServlet.class. 5. Repeat step 2. We get a valid page back, and logging shows that we remove context DEFAULT:/ROOT and then readd it. 6. Repeat step 3. Now we get a 404 error and logging shows that we don't know anything about an examples context. If I touch the RequestInfoExample.class file, we do shutdown and reload the DEFAULT:/examples context, and examples and ROOT still work. This works ok on 3.2.2 (and 3.2.3) but it fails on 3.3m3 (earliest build still available in the binary area for 3.3) and with the current codebase from CVS. I'll continue to look into this, but I wanted to post it so that anyone else that has a little time, or more knowledge than me in this area (pretty much all of you ;-) could take a look and see what's going on. Plus, I'm going on vacation for the next 2 weeks and I'm not sure how much time I'll be able to look at it. Mike Anderson
Re: [jtc - jk] jk_version.h
+1 Since I would have to do something similar in the Makefile.nw for NetWare, I'd lots rather see the login in jk_version.h. Mike Anderson [EMAIL PROTECTED] 06/26/01 12:59AM GOMEZ Henri wrote: so, forgive me if this is a stupid question, but... how is jk_version.h generated on windows? do i need to install cygwin stuff and run buildconf.sh/configure? Good point Kevin :) May be just by editing it ;) Should move the logic of version out from configure and to jk_version.h (Any way I was not very happy to have to commit configure.in when the j-t-c version changes).
Re: [jtc - jk] jk_version.h
That should have been logic instead of login :-) [EMAIL PROTECTED] 06/26/01 09:21AM +1 Since I would have to do something similar in the Makefile.nw for NetWare, I'd lots rather see the login in jk_version.h. Mike Anderson [EMAIL PROTECTED] 06/26/01 12:59AM GOMEZ Henri wrote: so, forgive me if this is a stupid question, but... how is jk_version.h generated on windows? do i need to install cygwin stuff and run buildconf.sh/configure? Good point Kevin :) May be just by editing it ;) Should move the logic of version out from configure and to jk_version.h (Any way I was not very happy to have to commit configure.in when the j-t-c version changes).
Re: question about the reloading of servlet
There was a problem with the reload code on 3.2.2. Since reloading has been rewritten for 3.3, you can try that or you can get the latest source from the tomcat_32 branch and use it. The fix is in org.apache.tomcat.core.ServletWrapper.java if you just want the one file. [EMAIL PROTECTED] 06/25/01 09:51AM hello, I have Tomcat 3.2.2, Apache 1.3.19 and mod_jk. One of my user is currently developing a servlet, and change very frequently this one. from times to times, Tomcat stops reloading it, and I have to restart it. Is it normal ? Why does he stop reloading ? I have read numerous posts on this subject, including ones telling that the reloading of servlet is difficult, since the classes are loaded into a JVM, which doesn't accept easily to change a loaded class into memory... So, my question is: Will the reloading working well in future versions of Tomcat (should I try catalina ?), or should I suggest another way of developing servlet to my user ? Thanks a lot __ | Henri Delebecque[EMAIL PROTECTED] | | Webmaster | | Supelec Tel (33) 01.69.85.14.91 | | 3 rue Joliot-Curie | | Plateau de Moulon Fax:(33) 01.69.85.12.34 | | 91190 Gif sur Yvette| | FRANCE | |_|
Re: 3.3: nightly, updating the parser, options
+1 Mike Anderson Senior Software Engineer Platform Services Group [EMAIL PROTECTED] Novell, Inc., the leading provider of Net services software www.novell.com [EMAIL PROTECTED] 06/21/01 02:18AM Hi, I'm working on restoring the nightly buildtest, probably this evening we'll have them ( I was close last night ). Few issues, need feedback: - I would like to update to the latest jaxp, we are still building with jaxp1.0 ( it's about the default build, of course you can build/use whatever you want ). - There are few module options that are set for backward compatibility right now, but it would be very usefull otherwise. One is the autodeploy ( detect when the .WAR file changes, and redeploy and reload the context - same as if a .class file changes ). The other is the vhost-based layout for the webapps dir ( use webapps/virtual.host.com/context, with DEFAULT as keyword for the main host ). That would allow easier auto-configuration for virtual hosts. ( as you should know, the location of webapp and it's behavior can be easily controlled in server.xml, it's just a matter of setting the default). In the configurations, I would also like to change the log options in examples to go to the default logger ( instead of examples.log ). I am going to fix some modules to use the context logger for all the messages where a context is available ( so a context log file will have all the informations related with a context, and the main logger will be used only for bad requests and server-wide events. ). I think this is the correct behavior, but that would mean people will no longer see the /examples logs in the console window. Costin
RE: cvs commit: jakarta-tomcat build.xml
No problem. Big fat hairy lie Of course I would never make
a mistake like that /Big fat hairy lie unless of course I
actually try to modify the code :-)
Mike Anderson
[EMAIL PROTECTED] 06/19/01 01:23AM
doh, thanks Mike..
Saludos ,
Ignacio J. Ortega
-Mensaje original-
De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Enviado el: martes 19 de junio de 2001 2:35
Para: [EMAIL PROTECTED]
Asunto: cvs commit: jakarta-tomcat build.xml
mmanders01/06/18 17:34:38
Modified:.build.xml
Log:
Updated conditionals for commons-dbcp. This will now build
properly even if jakarta-commons isn't available.
Revision ChangesPath
1.135 +29 -30jakarta-tomcat/build.xml
Index: build.xml
===
RCS file: /home/cvs/jakarta-tomcat/build.xml,v
retrieving revision 1.134
retrieving revision 1.135
diff -u -r1.134 -r1.135
--- build.xml 2001/06/17 18:59:39 1.134
+++ build.xml 2001/06/19 00:34:37 1.135
@@ -38,10 +38,16 @@
property name=jakarta-tomcat-jasper
location=${ws}/jakarta-tomcat-jasper /
+
+ property name=jakarta-commons
+location=${ws}/jakarta-commons /
!-- External packages we depend on --
!-- Tomcat depends on:
- - Ant ( latest binary install in jakarta-ant-1.3 )
+ - Ant ( latest 1.3 binary install in jakarta-ant,
peer to jakarta-tomcat )
+ - jakarta-tomcat-connectors ( latest src, peer to
jakarta-tomcat )
+ - jakarta-tomcat-jasper ( latest src, peer to
jakarta-tomcat )
+ - jakarta-commons (optional, latest src, peer to
jakarta-tomcat )
- Jaxp ( optional, the jar files from ant can be
used instead )
- Jsse ( optional )
--
@@ -54,18 +60,6 @@
property name=ant.lib value=${ant.home}/lib/
property name=jsse.lib value=${jsse.home}/lib/
- path id=commons-dbcp
-fileset dir=../jakarta-commons/dbcp
-include name=**/build/*.jar/
-/fileset
-fileset dir=../jakarta-commons/pool
-include name=**/build/*.jar/
-/fileset
-fileset dir=../jakarta-commons/collections
-include name=**/build/*.jar/
-/fileset
- /path
-
!-- Binaries checked in ( servlet.jar is not likely to change,
the 2.2 spec is final --
property name=servlet22.jar value=bin/servlet22.jar/
@@ -80,8 +74,7 @@
available property=jsse.present
file=${jsse.lib}/jsse.jar/
available property=commons-dbcp.present
-
classname=org.apache.commons.dbcp.DriverManagerConnectionFactory
- classpathref=commons-dbcp/
+
file=${jakarta-commons}/dbcp/dist/commons-dbcp.jar /
available property=jdk12.present
classname=java.security.PrivilegedAction/
available property=jakarta-tomcat-connectors-present
@@ -109,6 +102,7 @@
target name=msg.jtj unless=jakarta-tomcat-jasper-present
fail message=Can't find jakarta-tomcat-jasper
repository, you must check it out before building tomcat /
/target
+
target name=init
depends=detect,msg.jdk12,msg.jsse,msg.jtc,msg.jtj,msg.commons-dbcp
/target
@@ -380,23 +374,26 @@
/target
- target name=commons-prepare if=commons-dbcp.present
-!--
+ target name=commons-prepare depends=prepare
if=commons-dbcp.present
+ !-- Because of way the build.xml files are set up, we
can't call them from
+ inside this file. They need to be run before this
script is executed
+ if you want the PooledJDBCRealm code to be built.
ant
antfile=../jakarta-commons/collections/build.xml target=dist/
ant antfile=../jakarta-commons/pool/build.xml
target=dist/
ant antfile=../jakarta-commons/dbcp/build.xml
target=dist/
---
-copy todir=${tomcat.build}/lib/container flatten=yes
-fileset dir=../jakarta-commons/dbcp
-include name=**/build/*.jar/
-/fileset
-fileset dir=../jakarta-commons/pool
-include name=**/build/*.jar/
-/fileset
-fileset dir=../jakarta-commons/collections
-include name=**/build/*.jar/
-/fileset
-/copy
+--
+echo message=copying commons jars/
+copy todir=${tomcat.build}/lib/container flatten=yes
+fileset dir=../jakarta-commons/dbcp
+include name=**/dist/*.jar/
+/fileset
+fileset dir=../jakarta-commons/pool
+include name=**/dist/*.jar/
+/fileset
+fileset dir=../jakarta-commons/collections
+include name=**/dist/*.jar/
+/fileset
+/copy
/target
Re: [PROPOSAL] Update to Tomcat 3.3 release schedule
+1 [EMAIL PROTECTED] 06/17/01 02:54PM Hi, Continuing to adapt the Tomcat 3.3 schedule to available time and needs, I propose the following changes to the current RELEASE-PLAN-3.3: Add a Milestone 4: Code Freeze/Tag Date: June 20, 2001 Release Manager:Larry Isaacs This release contains a switch to using jakarta-tomcat-connectors for some utility classes. It also uses jakarta-tomcat-jasper for building jasper34, which will be enabled as the default JSP handler. The internal jasper33 will be enabled as the default JSP handler for future releases of Tomcat 3.3. Known issues in order of priority: 1. Jasper34 needs to be stable. 2. Watchdog and internal test need to be passing all tests. 3. Build documentation need to be updated to document new dependencies on jakarta-tomcat-connectors and jakarta-tomcat-jasper. Change the Beta 1 Freeze Date to July 11. Change the Beta 2 Freeze Date to July 18. Change the Final Release August 1. Cheers, Larry
Re: Plans for Tomcat 3.2.3 and later
+1 Marc, You did a great job pulling together 3.2.2. I'll be happy to work on issues in 3.2.3. Mike Anderson [EMAIL PROTECTED] 06/14/01 09:49AM Now that Tomcat 3.2.2 is out it's time to starting thinking about 3.2.3. My thoughts are to have a release for 3.2.3 in three or four months. This will be strictly a bug fix release. The only hard and fast release requirements are to fix any specification compliance issues that may be discovered in 3.2.2 and that are no regression failures. Beyond that, any bugs are fair game and 3.2.3 will roll these up into a public release. I'll volunteer to be the release manager for this release (unless someone else is crazy enough to want the job). Any discussion? Comments? I'll put together a formal release plan in the next couple days. Marc Saegesser
Re: [j-t-c] OS poll = [j-t-c] webserver poll
Netscape Enterprise 3.5(+) on NetWare. Apache 1.3 on NetWare. Apache 1.3 on Win2K and Linux to verify fixes. Probably be looking at IIS on Win2K but not currently. Mike Anderson [EMAIL PROTECTED] 06/13/01 02:57AM Here is the result of the j-t-c OS poll : - OPERATING SYSTEM -- USERS - - REF - - AS/400 - AS/400 V4R5 1 = 1 - BS2000 - BS2000 / 3901 = 1 - FreeBSD - FreeBSD 4.0 STABLE / x861 FreeBSD 4.2 / x86 2 = 3 - HP - HP-UX 10.0 1 = 1 - Linux - Gnu Linux 1 Linux 2.2.15 / SPARC1 Redhat 6.2 / x863 Redhat 7.0 / x863 Redhat 7.1 / x866 Slackware 7.1 / x86 1 Suse 7.0 / x86 1 Suse 7.1 / x86 1 = 17 - Mac - MacOS/X 10.0.3 1 MacOS/9 9.1 1 = 2 - Reliant - ReliantUnix 5.45/5.43 / Mips1 = 1 - Sun/Solaris - Solaris 2.6 1 Solaris 2.7 1 Solaris 2.8 2 Solaris 7 / x86 1 Solaris 7 / SPARC 2 Solaris 8 / x86 2 Solaris 8 / SPARC 2 SunOS 5.8 / Sparc64 1 = 12 - Windows - Window NT 3 Window 2000 Pro 5 Window 2000 Pro+Cygwin / x861 Windows 98 SE 1 Windows Millenium 1 = 11 Conclusion: Linux is clearly the most referenced, with Solaris / Windows immediate followers. FreeBSD (no OpenBSD ?) is the next one (apache.org prefs OS). MacOS appears (thks Pier), HPUX, ReliantUnix. Some exotics systems (AS/400 - BS2000). On the AS/400, you could allready use an Apache HTTP Server. IBM announced that this port will soon accept externals modules. May be even an APR port. I'll track this OS :) Surprizingly, no vote for AIX. Now which webservers are you using : - Apache 1.3(Apache, Apache/SSL or Apache-mod_ssl) - Apache 2.0 - Domino - IIS 4/5/2000 - JNI - Netscape/IPlanet This quick poll will help us know on which direction must be put the most effort. I bet for Apache 1.3 on Unix boxes - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6
Re: Help with Code in jk_nwmain.c.
You don't need jk_nwmain if you are building on HPUX11.00. This file is only
for the NetWare platform. That is why there is an #ifdef NETWARE around
the whole thing.
Mike Anderson
Senior Software Engineer
Platform Services Group
[EMAIL PROTECTED]
Novell, Inc., the leading provider of Net services software
www.novell.com
[EMAIL PROTECTED] 06/08/01 02:01PM
I am trying to compile mod_jk in HPUX11.00 in 32 bit mode. I am using
Tomcat3.2.1
I am getting these error messages saying:
./jk/jk_nwmain.c line 62 -unexpected void
./jk/jk_nwmain.c line 64 TSR_THREAD undefined.
What am I doing wrong???
Thanks,
Joyce
Code from jk_nwmain.c
==
static void main();
#ifdef NETWARE
/*
* NATIVE_MAIN
*/
/*
* INCLUDES
*/
#include stdio.h
#include nwthread.h
#include netdb.h
NETDB_DEFINE_CONTEXT
/*
* main ()
*
* Main entry point -- don't do much more than I've provided
*
* Entry:
*
* Exit:
*Nothing
*/
void main ()
{
ExitThread (TSR_THREAD, 0);
}
#elif HPUX11
/*
* NATIVE_MAIN
*/
/*
* INCLUDES
*/
#include stdio.h
#include pthread.h
#include netdb.h
NETDB_DEFINE_CONTEXT
/* # Can I generate an error --- yes if not remmed out */
/*
* main ()
*
* Main entry point -- don't do much more than I've provided
*
* Entry:
*
* Exit:
*Nothing
*/
void main()
{
ExitThread (TSR_THREAD, 0);
}
#endif
Re: [j-t-c] OS poll
Windows 2000 - primary build/development platform for NetWare RedHat 7.0 for verifying changes I make don't kill someone else :-) Mike Anderson [EMAIL PROTECTED] 06/11/01 06:54AM Hi, A quick poll to get informations about OS used by j-t-c developpers users ... I: Redhat 6.2 / 7.1 - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6
Re: More on ajp14
I agree that even if you have option b) working, option a) is the correct way to go so that we don't break backwards compatibility. Mike Anderson Senior Software Engineer Platform Services Group [EMAIL PROTECTED] Novell, Inc., the leading provider of Net services software www.novell.com [EMAIL PROTECTED] 06/04/01 06:24AM Hi to all, The work in still on progress on AJP14 and I've got new questions on ajp14. 1) AJP14 could be considered like an evolution of AJP13. Basically the same protocol but with added commands. AJP13 use the 'AB' chars in start of protocol, what about using something like 'DE' in the case of AJP14. It will help detect and fixes problem when trying to use AJP14 on AJP13. Smarted servlet engine could even route the incorrect ajp protocol 2) Servlet 2.3 (I can't get the Proposed Final Draft 2) add as requirement cipher_suite and key_size. cipher_suite is allready present in current ajp13. I've added key_size to a test ajp13 but adding it to current ajp13 may break compatibility since I'll add a command #11 in the ajp13 stream, something which will not be understand by current ajp13 java implementation. So what to do now ? a) Freeze the ajp13 in all branches and add the key_size only in ajp14 b) add key_size to ajp13 in mod_jk (in jtc) and in all the java implementations ? I've done the b) case, and so I've adapated mod_jk (native) and ajp13 (java for TC 4.0) on jakarta-tomcat-connector to recognize and use the new command. I attached the diff :) Even if I've worked on the b) case, I think it will be more secure to use a) and freeze ajp13 now Just to keep compatibility with TC 3.2.2 which are now closed to new features an which didn't require the Servlet 2.3 compatibility. - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6
Re: [VOTE] New Committer: Andy Armstrong
+1 [EMAIL PROTECTED] 06/04/01 08:53AM i'd like to propose Andy Armstrong as a new committer. he has provided a connector for the lotus domino webserver (http://free.tagish.net/domino-tomcat/index.jsp) which has recently been incorporated into jakarta-tomcat-connectors. please vote :) -kevin.
[PATCH] for mod_jk/ajp13 memory leaks.
I found some more memory leaks in mod_jk. The biggest one is in mod_jk.c when there is a virtual host section in httpd.conf. Multiple conf structures are allocated, but only one was being cleaned up. Another leak was in jk_ajp13_worker.c. We were calling jk_open_pool on the endpoint object and never calling jk_close_pool when the endpoint was shut down. The attached diff files are against the latest tomcat_33 branch. If anyone is interested, I'd be happy to provide the same diffs for tomcat_32 and the tomcat-jakarta-connectors project. I'd also be happy to enter a bug if necessary. Thanks, Mike Anderson Senior Software Engineer Platform Services Group [EMAIL PROTECTED] Novell, Inc., the leading provider of Net services software www.novell.com mod_jk.diff jk_ajp13_worker.diff
Re: [VOTE] Final release of Tomcat 3.2.2
+1 Great job pulling it all together Marc! Mike Anderson [EMAIL PROTECTED] 05/18/01 01:30PM The latest beta cycle for Tomcat 3.2.2 has completed with no new bugs identified. As the release manager I propose that we release the tomcat_32 branch as Tomcat 3.2.2. Please indicate your vote for the release using the ballot below. I will tabulate and post the results of this vote on Friday, May 25. At that time, if the vote has passed, I will tag, build and distribute the release. The vote must pass by majority approval which means the proposal must receive at least three +1 votes and more +1 votes than -1 votes. Marc Saegesser - Vote to release the tomcat_32 branch as Tomcat 3.2.2. [ ] +1. I agree with the proposal and I will help support the release. [ ] +0. I agree with the proposal but I will not be able to help support the release. [ ] -0. I don't agree with the proposal but I won't stop the release. [ ] -1. I disagree with the proposal and will explain my reasons.
[PATCH] For mod_jk.c (tomcat_3.2.2)
Attached is a patch for mod_jk.c to more cleanly handle a bad path for the workers.properties file. Currently, this is handled in jk_init and if the call to map_read_properties fails, then we just call jk_error_exit which in turn calls exit(1). This causes some problems on NetWare because we don't go through all of the Apache cleanup code and so we can't restart Apache. The attached patch just places a stat call in jk_set_wroker_file to test for the workers.properties file. Since this is called during the configuration file parse, the error is reported earlier and allows Apache the shutdown cleanly. I've built and tested this for NetWare, Linux, and Windows. Mike Anderson Senior Software Engineer Platform Services Group [EMAIL PROTECTED] Novell, Inc., the leading provider of Net services software www.novell.com Index: mod_jk.c === RCS file: /home/cvspublic/jakarta-tomcat/src/native/apache1.3/Attic/mod_jk.c,v retrieving revision 1.7.2.3 diff -u -r1.7.2.3 mod_jk.c --- mod_jk.c2001/02/17 05:24:00 1.7.2.3 +++ mod_jk.c2001/04/04 22:18:23 @@ -477,8 +477,11 @@ server_rec *s = cmd-server; jk_server_conf_t *conf = (jk_server_conf_t *)ap_get_module_config(s-module_config, jk_module); +struct stat statbuf; conf-worker_file = worker_file; +if (stat(worker_file, statbuf) == -1) +return "Can't find the workers file specified"; return NULL; }
[PATCH] [Bug 1001] - available() method on ServletInputStreamalways returns 0
I noticed that this bug was marked RESOLVED/LATER and was wondering if there was any
way to get this into 3.2.2 since that is the version that is closest to being
released. I've already found 2 ways to fix this issue but am willing to abide by the
groups decision and concentrate on getting this into the 3.3 release instead.
The 2 ways to fix this are:
1. In BufferedServletInputStream, implement an available() method that returns limit
- bytesRead or 0 whichever is greater. The limit class variable is set to the value
of the Content-Length header and bytesRead is the number of bytes read since limit was
set (see the attached diff1.txt). This is the easy fix but doesn't address the
feature of available that says it will return the number of bytes that can be read
"without blocking". Obviously, if there is a large amount of data, a read will most
likely block at some point depending on how much is asked for, however this prevents a
condition where one of the adapters returns 0 because a read hasn't actually been
requested from the webserver.
2. Update BufferedServletInputStream to call reqA.available and then update the
following files to provide this interface:
Request.java
RequestImpl.java
HttpRequestAdapter.java
Ajp12ConnectionHandler.java
Ajp13ConnectorRequest.java
JNIConnectionHandler.java
MsgConnector.java
TcpConnector.java
Each of these classes would need to provide an appropriate available() method. I've
also done the work on these files as well (see the attached diff2.txt) but noticed
that since some of the protocols (particularly AJP13) actually have to request a read
to fill their internal buffer, the adapter (i.e. Ajp13ConnectorRequest.java) will
return a 0 if doRead is called and it exactly empties the internal buffer. Also the
JNIRequestAdapter (in JNIConnectionHandler.java) makes a native call back into the
webserver to do the reads and so available is implemented similar to #1 above; it just
returns the max of contentLength - bytesRead or 0. This was because I'm not sure of a
way to imp
After testing both of these, implementation 1 is actually faster and more reliable.
Typically if someone is calling available and they get back a 0, they would block the
thread anyways and so it makes some sense to let it block on the read plus it gets
around the issue of an adapter requiring one of it's read methods to be called to
actually have something available.
Any response positive or negative would be appreciated so that I know where to focus
my energy (i.e. 3.2.2 or 3.3).
Index: BufferedServletInputStream.java
===
RCS file:
/home/cvspublic/jakarta-tomcat/src/share/org/apache/tomcat/core/Attic/BufferedServletInputStream.java,v
retrieving revision 1.8
diff -u -r1.8 BufferedServletInputStream.java
--- BufferedServletInputStream.java 2000/05/26 17:32:04 1.8
+++ BufferedServletInputStream.java 2001/03/21 21:03:59
@@ -151,6 +151,10 @@
}
}
+public int available() throws IOException {
+return Math.max((limit - bytesRead), 0);
+}
+
// /**
// * @deprecated Not part of Servlet API, without it we can avoid a lot of GC.
Index: BufferedServletInputStream.java
===
RCS file:
/home/cvspublic/jakarta-tomcat/src/share/org/apache/tomcat/core/Attic/BufferedServletInputStream.java,v
retrieving revision 1.8
diff -u -r1.8 BufferedServletInputStream.java
--- BufferedServletInputStream.java 2000/05/26 17:32:04 1.8
+++ BufferedServletInputStream.java 2001/03/21 21:04:23
@@ -151,6 +151,10 @@
}
}
+public int available() throws IOException {
+return reqA.available();
+}
+
// /**
// * @deprecated Not part of Servlet API, without it we can avoid a lot of GC.
Index: Request.java
===
RCS file:
/home/cvspublic/jakarta-tomcat/src/share/org/apache/tomcat/core/Request.java,v
retrieving revision 1.46
diff -u -r1.46 Request.java
--- Request.java2000/06/22 19:49:35 1.46
+++ Request.java2001/03/21 21:05:31
@@ -274,6 +274,9 @@
public int doRead( byte b[], int off, int len ) throws IOException;
+// provide a way to overload available from InputStream
+public int available() throws IOException;
+
// Internal methods
/** Support for "pools"
*/
Index: RequestImpl.java
===
RCS file:
/home/cvspublic/jakarta-tomcat/src/share/org/apache/tomcat/core/Attic/RequestImpl.java,v
retrieving revision 1.52.2.7
diff -u -r1.52.2.7 RequestImpl.java
--- RequestImpl.java2001/03/15 19:00:37 1.52.2.7
+++ RequestImpl.java2001/03/21 21:05:41
@@ -818,6 +818,11 @@
return -1;
}
+// provide a way to
Re: [PATCH] [Bug 1001] - available() method onServletInputStreamalways returns 0
Costin, Thanks for the response. I agree that available is supposed to return how many bytes can be returned without a read() on the "primary". The second diff file has patches that implement available this way for everything except the JNI connector. My only concern with this (2nd) set of patches was that the AJP13 connector would return how much was available in it's own buffer but that buffer was never reloaded unless a read was requested the exhausts the buffer and still wanted more data. The only way I could see to get around this was to either have available return the total number of bytes that could be read (bad because a read will most likely block) or implement refillBuffer as an asynchronous method that would actually fill the buffer in the background based on some signal from the main thread. That type of implementation could also be used to clean up the JNI connector as well. I just didn't want to introduce that level of complexity this close to release ;-) I'll wait to here from Marc and start looking at the 3.3 code to what it will take there. Mike [EMAIL PROTECTED] 03/21/01 03:23PM Mike, I'm not sure I understand ( not your mail - the "available" definition ). Isn't availabe supposed to return how many bytes can be returned without a read() on the "primary" source ( that would block ) ? What you describe is slightly different - and I'm not sure it's a good idea. In any case, I would prefer the second choice - have the protocol return what it has in it's buffers ( if any ). Of course, a big question is what is available :-) If the data has been read by Apache but not yet sent to tomcat - is it available ? Probably so ( AFAIK this shouldn't happen - actual read from network is driven by a tomcat request and no data is buffered on apache ). But that would be a bit too complex even for 3.3 ( but may be implemented in a future ajp14 ) I don't think this would have any significant impact on code stability - since you replace a method that returns 0 to something a bit more acurate, and I see no problem with adding a patch to 3.3 ( 3.2 is quite close to a release, it's up to Marc to decide ). But I'm a bit concerned about the corectness of the result. Costin On Wed, 21 Mar 2001, Mike Anderson wrote: I noticed that this bug was marked RESOLVED/LATER and was wondering if there was any way to get this into 3.2.2 since that is the version that is closest to being released. I've already found 2 ways to fix this issue but am willing to abide by the groups decision and concentrate on getting this into the 3.3 release instead. The 2 ways to fix this are: 1. In BufferedServletInputStream, implement an available() method that returns limit - bytesRead or 0 whichever is greater. The limit class variable is set to the value of the Content-Length header and bytesRead is the number of bytes read since limit was set (see the attached diff1.txt). This is the easy fix but doesn't address the feature of available that says it will return the number of bytes that can be read "without blocking". Obviously, if there is a large amount of data, a read will most likely block at some point depending on how much is asked for, however this prevents a condition where one of the adapters returns 0 because a read hasn't actually been requested from the webserver. 2. Update BufferedServletInputStream to call reqA.available and then update the following files to provide this interface: Request.java RequestImpl.java HttpRequestAdapter.java Ajp12ConnectionHandler.java Ajp13ConnectorRequest.java JNIConnectionHandler.java MsgConnector.java TcpConnector.java Each of these classes would need to provide an appropriate available() method. I've also done the work on these files as well (see the attached diff2.txt) but noticed that since some of the protocols (particularly AJP13) actually have to request a read to fill their internal buffer, the adapter (i.e. Ajp13ConnectorRequest.java) will return a 0 if doRead is called and it exactly empties the internal buffer. Also the JNIRequestAdapter (in JNIConnectionHandler.java) makes a native call back into the webserver to do the reads and so available is implemented similar to #1 above; it just returns the max of contentLength - bytesRead or 0. This was because I'm not sure of a way to imp After testing both of these, implementation 1 is actually faster and more reliable. Typically if someone is calling available and they get back a 0, they would block the thread anyways and so it makes some sense to let it block on the read plus it gets around the issue of an adapter requiring one of it's read methods to be called to actually have something available. Any response positive or negative would be appreciated so that I know where to focus my energy (i.e. 3.2.2 or 3.3).
The available method for ServletInputStream subclasses(tomcat_32 branch)
In working with some internal groups, we have some classes that perform file uploads (anyone heard of GroupWise Webaccess?). One of the things they have done in their servlets that handle this is call the available method on the ServletInputStream so that they can delay the thread for a small amount of time if there isn't anything available to be read from the socket. This allows the machine and other threads to do other processing, and allows the thread that wants to read the data to gracefully handle a client prematurely shutting down the connection. This functionality works on other servlet engines (JServ, WebSphere, Novell Servlet Gateway) but doesn't work on Tomcat because the available() method was never implemented in any of the subclasses. So when availabe() is called, it just resolves down to java.io.InputStream which is documented as returning 0 because subclasses should override this method. There are 2 ways to fix this: 1. In BufferedServletInputStream, implement an available() method that returns limit-bytesRead or 0 whichever is greater. The limit class variable is set to the value of the Content-Length header and bytesRead is the number of bytes read since limit was set. (See the attached patch). This is the easy fix but doesn't address the feature of available that says it will return the number of bytes that can be read "without blocking". Obviously, if there is a large amount of data, a read will most likely block at some point depending on how much is asked for. 2. Update BufferedServletInputStream to call reqA.available and then update the following files to provide this interface: Request.java RequestImpl.java HttpRequestAdapter.java AJP12RequestAdapter.java Ajp13RequestAdapter.java JNIRequestAdapter.java Each of these classes would need to provide an appropriate available() method. I'm willing to figure this out and implement #2 if it is deemed the better approach and only provided #1 because it was a "quick" fix. I'm also willing to figure this out for the 3.3 tree for either implementation. I would like to get it into the 3.2.2 branch since that is what most of use here are currently using. Any response (other than flames:-) appreciated. diff.out
[PATCH] for mod_jk.c in tomcat_32 branch
Here is a patch for mod_jk.c to free up all allocated memory during shutdown. NetWare
complains about unreleased resources so I found what was being allocated and added an
exit_handler to free it up.
Mike Anderson
Senior Software Engineer
Platform Services Group
[EMAIL PROTECTED]
Novell, Inc., the leading provider of Net services software
www.novell.com
Index: mod_jk.c
===
RCS file: /home/cvspublic/jakarta-tomcat/src/native/apache1.3/Attic/mod_jk.c,v
retrieving revision 1.7.2.2
diff -u -r1.7.2.2 mod_jk.c
--- mod_jk.c2000/10/05 06:32:21 1.7.2.2
+++ mod_jk.c2001/02/08 16:34:25
@@ -862,6 +862,7 @@
#endif
if(wc_open(init_map, conf-log)) {
+map_free(init_map); // we don't need this any more so free it
return;
}
}
@@ -895,6 +896,18 @@
return DECLINED;
}
+static void exit_handler (server_rec *s, ap_pool *p)
+{
+ jk_server_conf_t *conf =
+ (jk_server_conf_t *)ap_get_module_config(s-module_config, jk_module);
+
+ wc_close(conf-log);
+ uri_worker_map_free((conf-uw_map), conf-log);
+ map_free((conf-uri_to_context));
+ if (conf-log)
+ jk_close_file_logger((conf-log));
+}
+
static const handler_rec jk_handlers[] =
{
{ JK_MAGIC_TYPE, jk_handler },
@@ -920,7 +933,7 @@
NULL, /* [10] logger */
NULL, /* [3] header parser */
NULL, /* apache child process initializer */
-NULL, /* apache child process exit/cleanup */
+exit_handler, /* apache child process exit/cleanup */
NULL/* [1] post read_request handling */
#ifdef EAPI
/*
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: Posting 3.3 native binaries snapshot
Keith, Could I send you 3.3 binaries for NetWare to put out there as well? Mike Anderson Senior Software Engineer Platform Services Group [EMAIL PROTECTED] Novell, Inc., the leading provider of Net services software www.novell.com [EMAIL PROTECTED] 02/02/01 10:56AM With all the changes to mod_jk, I'd like to post these binaries to the jakarta site: builds/jakarta-tomcat/native-3.3/linux/i386/mod_jk.so and ... /win32/i386/mod_jk.dll Any objections? These connectors won't be build nightly, but they will allow people to use the changes we've made so far. Keith - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: 3.2.2 Release?
I don't have commit access so can't help there, but I would like to get the 3.2 versions of the NetWare binaries updated in the builds area (builds/jakarta-tomcat/release/) If we do get nightly builds or do a milestone, or whatever, who should the lucky :-) recipient be? Mike Anderson Senior Software Engineer Platform Services Group [EMAIL PROTECTED] Novell, Inc., the leading provider of Net services software www.novell.com [EMAIL PROTECTED] 02/02/01 11:24AM Can someone who has functioned as a release manager for a dot release give me a quick overview of what's involved? I may be able to find the time, but I'm not totally clear on the scope of what needs to happen. I don't think Milestone releases would make sense -- from what it says on http://jakarta.apache.org/site/binindex.html, those sound like they should really be steps towards a major release of new functionality, not snapshots of bug fixes in a released product. Nightly builds I would be fine with, however. -Dan [EMAIL PROTECTED] wrote: I'm in the same boat right now. I'd love to a 3.2.2 released but I'm way too busy right now to manage a release. What about a "milestone" ? It doesn't have all the requirements of a release. I can add a nightly build of 3.2.x to my scripts too ? ( it'll not be a "blessed" release, but people who need the patches can use it ). Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] -- Dan Milstein // [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
[PATCH] for NetWare
Attached are some patched files and a diff file for NetWare. These have been diffed
against the latest version in the jakarta-tomcat tree. The jk_util.c and
jk_nsapi_plugin.c are the same fixes that have been put into the tomcat-32 branch and
I will submit the ApacheConf.java to the tomcat-32 branch as well.
diff.txt - diffs of the files
jk_util.c - Fixes a problem when shutting down the webserver on NetWare. The exit
thread only has a 16k stack so we dynamically allocate the log buffer so that we don't
blow the stack.
jk_nsapi_plugin.c - Fixes a problem with the netbuf_getbytes function not being
available on NetWare 5.x.
ApacheConfig.java - Updated to write a correct mod_jk.conf-auto for NetWare.
Thanks
Mike Anderson
Senior Software Engineer
Platform Services Group
[EMAIL PROTECTED]
Novell, Inc., the leading provider of Net services software
www.novell.com
cvs -z9 -q diff jk_nsapi_plugin.c (in directory
D:\Jakarta-3.3\jakarta-tomcat\src\native\mod_jk\netscape\)
Index: jk_nsapi_plugin.c
===
RCS file: /home/cvspublic/jakarta-tomcat/src/native/mod_jk/netscape/jk_nsapi_plugin.c,v
retrieving revision 1.1
diff -r1.1 jk_nsapi_plugin.c
191c191,193
#ifdef netbuf_getbytes
---
/* Until we get a service pack for NW5.1 and earlier that has the latest */
/* Enterprise Server, we have to go through the else version of this code*/
#if defined(netbuf_getbytes) !defined(NETWARE)
cvs -z9 -q diff jk_util.c (in directory
D:\Jakarta-3.3\jakarta-tomcat\src\native\mod_jk\common\)
Index: jk_util.c
===
RCS file: /home/cvspublic/jakarta-tomcat/src/native/mod_jk/common/jk_util.c,v
retrieving revision 1.2
diff -r1.2 jk_util.c
196a197,201
#ifdef NETWARE
/* On NetWare, this can get called on a thread that has a limited stack so */
/* we will allocate and free the temporary buffer in this function */
char *buf;
#else
197a203
#endif
211a218,221
buf = (char *) malloc(HUGE_BUFFER_SIZE);
if (NULL == buf)
return -1;
229a240,242
#ifdef NETWARE
free(buf);
#endif
cvs -z9 -q diff ApacheConfig.java (in directory
D:\Jakarta-3.3\jakarta-tomcat\src\share\org\apache\tomcat\modules\config\)
Index: ApacheConfig.java
===
RCS file:
/home/cvspublic/jakarta-tomcat/src/share/org/apache/tomcat/modules/config/ApacheConfig.java,v
retrieving revision 1.2
diff -r1.2 ApacheConfig.java
124a125,131
} else if( System.getProperty( "os.name" ).startsWith("NetWare")) {
// NetWare is a special case
pw.println("LoadModule jserv_module modules/JServ.nlm");
mod_jk.println("LoadModule jk_module modules/mod_jk.nlm");
mod_jk.println();
mod_jk.println("JkWorkersFile \"" + new File(tomcatHome,
WORKERS_CONFIG).toString().replace('\\', '/') + "\"");
mod_jk.println("JkLogFile \"" + new File(tomcatHome,
JK_LOG_LOCATION).toString().replace('\\', '/') + "\"");
jk_util.c
jk_nsapi_plugin.c
ApacheConfig.java
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: [VOTE] Tomcat 3.3 Release Plan
Larry, [X] +1I am in favor of this plan and will help [ ] +0I am in favor of this plan, but am unable to help [ ] -0I am not in favor of this plan [ ] -1I am against this plan being executed, and my reason is: Mike Anderson Senior Software Engineer Platform Services Group [EMAIL PROTECTED] Novell, Inc., the leading provider of Net services software www.novell.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Call for volunteers
Costin, I was planning on doing #4 (along with the netscape plugin) for NetWare. Mike Anderson Senior Software Engineer Platform Services Group [EMAIL PROTECTED] Novell, Inc., the leading provider of Net services software www.novell.com [EMAIL PROTECTED] 01/19/01 09:05AM snip... 4. Testing/Building/mod_jk: If you use tomcat with a web server, we need help making sure it works fine and eventually getting a compiled version of mod_jk for your platform ( if you use a "special" OS or configuration ). snip... -- Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [SECURITY] Security Vulnerabilities in Tomcat 3.1 and 3.2
[EMAIL PROTECTED] 12/11/00 06:19PM Over the last three days, a review of published and soon-to-be-published reportsof security vulnerabilities in Tomcat has uncovered a series of problems in the3.1 final release, and a couple of less serious (but still significant) problemsin 3.2. Please vote (quickly) on the following two issues:Proposal #1: Release a Tomcat 3.1.1 that fixes *only* the security problems. . . . +1Proposal #2: Release a Tomcat 3.2.1 that fixes the following security problemsplus the patches committed to date.. . . +1 If possible, I would like to see the two patches that I posted (and sent to Craig) for NetWare in the 3.2.1 build. They only affect the native connectors on NetWare, but there are several people inside and outside of Novell that are starting to use Tomcat 3.2. If not, I'll try and keep as many of these as I know about up to date with what I build until the patches are checked in. Either way, security fixes are more important. Craig Mike Anderson Senior Software Engineer Platform Services Group [EMAIL PROTECTED] Novell, Inc., the leading provider of Net services software www.novell.com
Re: BugRat Report #557 has been filed.
This sounds like an DNS issue. One of the things that the Netscape plugin does is try to resolve the remote host name (jk_nsapi_plugin.c line 405). This forces a DNS lookup which is notorious for having problems on NetWare. There are a couple of ways around it. 1. Make sure that the file sys:\etc\resolv.cfg exists and contains correct information for the domain the server is in. This is where DNS will go to try and resolve addresses to names. 2. If feasable, and the above isn't working, add all the address to name mappings to sys:\etc\hosts. This is the first place that DNS looks to try and resolve an address. 3. Install DNS/DHCP on the server and configure it as your DNS server. I have't done this so I'm not sure of all that is involved here. If you update any of the files, you will need to restart the NetWare server to have it recognize the changes. Hope this helps. Mike AndersonSenior Software EngineerPlatform Services Group[EMAIL PROTECTED]Novell, Inc., the leading provider of Net services softwarewww.novell.com [EMAIL PROTECTED] 12/08/00 04:53PM Bug report #557 has just been filed.You can view the report at the following URL: http://znutar.cortexity.com/BugRatViewer/ShowReport/557REPORT #557 Details.Project: TomcatCategory: Bug ReportSubCategory: New Bug ReportClass: swbugState: receivedPriority: highSeverity: seriousConfidence: confidentialEnvironment: Release: 3.2 JVM Release: 1.17B Operating System: Netware OS Release: 5.1 SP1 Platform: Intel PentiumSynopsis: Slow performance in redirection for netscapeDescription:Hi.The omcat is fast on netware so is even the webserver from novell.But when using the redirection nsapi_rd.nlm it seems like it is poceesign th request fast and sends it to Tomcat.But to recieve the answer is not working that great.It takes extremly long time, so there must be something in the pass module nsapi_rd.nlm/peter
Re: [VOTE] Tomcat 3.2 Final Release (!) and OngoingMaintenance Plan
[EMAIL PROTECTED] 11/27/00 06:00PM Dear TOMCAT-DEV folks,Well, it appears that we successfully licked a large number of the problems with3.2-beta-8, without introducing any serious new regressions. Therefore, I'dlike to ask that we vote on the following three propositions:(1) Build and release Tomcat 3.2 final on Wednesday 11/29/2000 ... +1. The README has been updated reguarding the requirement of JSSE for building (see the thread on EmbededTomcat.java requires jsse) but it sounds like Stefan Freyr has submitted a patch that removes this requirement. Would it be possible to get this in? If not, then 3.2.1 ( or 3.3?) would be fine.(2) Ongoing Support Plan for Tomcat 3.2... +1.(3) Release Manager for Tomcat 3.2.x Maintenance Releases... +1. Youda man Craig ;-) Please respond with your votes on these three proposals by 5pm Pacific TIme onWednesday, November 29, 2000.Thanks!Craig McClanahanMike Anderson Senior Software EngineerPlatform Services Group[EMAIL PROTECTED]Novell, Inc., the leading provider of Net services softwarewww.novell.com
Re: Tomcat working with Netscape Enterprise Server on Solaris
nsapi.h is included with the webserver install. It will be in an include directory underneath the main netscape directory. Mike Anderson [EMAIL PROTECTED] 11/16/00 04:55PM I tried "make -f Makefiel.solaris" in jakarta-tomcat/src/native/iis_netscapedirectory,and got the following error:jk_nsapi_plugin.c:71: nsapi.h: No such file or directory*** Error code 1make: Fatal error: Command failed for traget 'jk_nsapi_plugin.o'I used the souce code from release 3.1. There is no nsapi.h in thisdirectory. Any help is highly appreciated. Joan
