Naoki Ando $B$OIT:_$K$7$F$*$j$^$9!#(B
(B (B (B (B2004/11/08 $B$+$iIT:_$K$7$F$*$j$^$9!#(B2004/11/10 $B$K5"<R$$$?$7$^$9!#(B (B $B$4LBOG$r$*$+$1$7$^$9$,5"<R$7$^$7$F$+$i!"JVEz$$$?$7$^$9!#(B $B59$7$/$*4j$?$7$^$9!#(B (B (B (B (B* (BPRIVILEGED AND CONFIDENTIAL: This communication, including attachments, is (Bfor the exclusive use of addressee and may contain proprietary, (Bconfidential and/or privileged information. If you are not the intended (Brecipient, any use, copying, disclosure, dissemination or distribution is (Bstrictly prohibited. If you are not the intended recipient, please notify (Bthe sender immediately by return e-mail, delete this communication and (Bdestroy all copies. (B* (B (B (B- (BTo unsubscribe, e-mail: [EMAIL PROTECTED] (BFor additional commands, e-mail: [EMAIL PROTECTED]
Re: Naoki Ando $B$OIT:_$K$7$F$*$j$^$9!#(B
Please unscribe me. Thanks. Kaniz ** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [VOTE] Removal of mod_jk for Apache 2.0 from jakarta-tomcat f or T omcat 3.3
Hi Henri, I appreciate your efforts concerning the connectors. My position is that Tomcat 3.3 needs to have stable Ajp13 connectors for Apache 1.3, IIS, and to the extent we can, Netscape. A connector for Apache 2.0 should come out of jakarta-tomcat-connectors instead of jakarta-tomcat. Given that connectors were part of 3.2.x releases, I'm very reluctant to remove all of them from 3.3. Since we are approaching an attempt to release, I need to impose the restriction on the connectors that no features be added and only safe fixes be applied. I believe this restriction is best imposed on the jakarta-tomcat tree at this time and not jakarta-tomcat-connectors where Apache 2.0 is ongoing. If there are bug fixes in J-T-C that would benefit the J-T connectors, and they are safe and easy to apply, then they are worth considering to port. If one is needed, but may not be safe, please let me know of the issue. Otherwise, don't bother back porting J-T-C changes to J-T. I plan to go ahead and delete the J-T Apache 2.0 support once we know there isn't anything there that we need to port to J-T-C. You may be the best judge as to when the deletion can occur. If you could let me know, or suggest how I might check, I would appreciate it. I don't anticipate doing much, if any, maintenance on the connectors after the Tomcat 3.3 release. So hopefully, this should be a temporary pain, and shouldn't be that painful since the J-T connectors should be stable already (given there is some recent work on input chunking that we hope to have debugged soon, perhaps already. Thanks Keith). If there are issues where I shouldn't consider them stable, please let me know so we can address them. Thanks, Larry -Original Message- From: GOMEZ Henri [mailto:[EMAIL PROTECTED]] Sent: Monday, September 10, 2001 4:39 AM To: [EMAIL PROTECTED] Subject: RE: [VOTE] Removal of mod_jk for Apache 2.0 from jakarta-tomcat f or T omcat 3.3 +1 Let me comment at little. I'm currently working in porting changes in JT to JTC and from JTC to JT. For example, recent change in AJP13 chunk support in JT are not in JTC and latest stuff for Apache 2.0.26-dev not in JT. Let me say that it's just a nightmare to work on two branches (but that's allready a known problem :) Could we go a step farther and concentrate on just J-T-C. My question is, why not working today only in JTC and make use regular snapshot of JT instead of trying to maintain 2 sets of code ? Pier is allready doing that for mod_webapp and have removed (correct Pier ?) all the connector part from Tomcat 4.0 tree, and is using JTC snapshot of WA at each TC 4.0 release ... - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6
RE: [VOTE] Removal of mod_jk for Apache 2.0 from jakarta-tomcat f or T omcat 3.3
I spent some quality time with emacs and merge, comparing j-t-c and j-t versions of jk. So far things look very good, all fixes in j-t seems to be already in j-t-c. The only big difference ( that makes difficult to comapare ) is ajp13, but it seems we are ok there. Henri - could we undo the ajp13.c changes, for example by copying the current ajp13 from j-t and re-doing the autoconf changes ? Having ajp_common is nice, but I think we would be better if we keep ajp13 unchanged and let ajp14 evolve without having common code with ajp13. The protocols are not backward compatible, and they shouldn't anyway. Only major fixes should be merged back into j-t, the code there is stable and it's far better to keep it that way as it reduces the pressure on j-t-c. You can treat this as a branch - because if we drop j-t/src/native and use j-t-c, then we'll have to create a branch for the stable release. Of course, the nice thing is that most changes in j-t-c/jk will happen in ajp14 and probably a new jni connector ( that I'm planning ), so releasing a j-t-c should be much easier ( it'll have the same stable code as j-t, plus extra features ). BTW, since j-t-c/jk works for both 3.3 and 4.0, it would be nice if we could plan a release of the jk connector ( or at least milestone/alpha or beta ) sometime shortly after 3.3 and 4.0 are out ( so it can rely on the stable environment and be tested with it ) Costin On Mon, 10 Sep 2001, Larry Isaacs wrote: Hi Henri, I appreciate your efforts concerning the connectors. My position is that Tomcat 3.3 needs to have stable Ajp13 connectors for Apache 1.3, IIS, and to the extent we can, Netscape. A connector for Apache 2.0 should come out of jakarta-tomcat-connectors instead of jakarta-tomcat. Given that connectors were part of 3.2.x releases, I'm very reluctant to remove all of them from 3.3. Since we are approaching an attempt to release, I need to impose the restriction on the connectors that no features be added and only safe fixes be applied. I believe this restriction is best imposed on the jakarta-tomcat tree at this time and not jakarta-tomcat-connectors where Apache 2.0 is ongoing. If there are bug fixes in J-T-C that would benefit the J-T connectors, and they are safe and easy to apply, then they are worth considering to port. If one is needed, but may not be safe, please let me know of the issue. Otherwise, don't bother back porting J-T-C changes to J-T. I plan to go ahead and delete the J-T Apache 2.0 support once we know there isn't anything there that we need to port to J-T-C. You may be the best judge as to when the deletion can occur. If you could let me know, or suggest how I might check, I would appreciate it. I don't anticipate doing much, if any, maintenance on the connectors after the Tomcat 3.3 release. So hopefully, this should be a temporary pain, and shouldn't be that painful since the J-T connectors should be stable already (given there is some recent work on input chunking that we hope to have debugged soon, perhaps already. Thanks Keith). If there are issues where I shouldn't consider them stable, please let me know so we can address them. Thanks, Larry -Original Message- From: GOMEZ Henri [mailto:[EMAIL PROTECTED]] Sent: Monday, September 10, 2001 4:39 AM To: [EMAIL PROTECTED] Subject: RE: [VOTE] Removal of mod_jk for Apache 2.0 from jakarta-tomcat f or T omcat 3.3 +1 Let me comment at little. I'm currently working in porting changes in JT to JTC and from JTC to JT. For example, recent change in AJP13 chunk support in JT are not in JTC and latest stuff for Apache 2.0.26-dev not in JT. Let me say that it's just a nightmare to work on two branches (but that's allready a known problem :) Could we go a step farther and concentrate on just J-T-C. My question is, why not working today only in JTC and make use regular snapshot of JT instead of trying to maintain 2 sets of code ? Pier is allready doing that for mod_webapp and have removed (correct Pier ?) all the connector part from Tomcat 4.0 tree, and is using JTC snapshot of WA at each TC 4.0 release ... - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6
RE: [VOTE] Removal of mod_jk for Apache 2.0 from jakarta-tomcat f or T omcat 3.3
I just finished merging all the chunked encoding support for ajp13 into j-t-c and was about to checkin. I'll hold off until we decide about this: | Henri - could we undo the ajp13.c changes, for example by copying the | current ajp13 from j-t and re-doing the autoconf changes ? Having Keith
Re: [VOTE] Removal of mod_jk for Apache 2.0 from jakarta-tomcat f or Tomcat 3.3
On Monday 10 September 2001 14:05, Pier Fumagalli wrote: [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: On Mon, 10 Sep 2001, Pier Fumagalli wrote: GOMEZ Henri [EMAIL PROTECTED] wrote: Ryan to became more than just a contributer : This is the third time we agree on something in less than 24 hours. This implies that either I'm getting old, or just plain silly... Now, if you could agree on merging mod_webapp and mod_jk, that would be something... Slowww down... :) If mod_jk wants to start using APR, I believe we're talking, otherwise, I'm done with cross-platform porting, I live it to Ryan Oh no you don't. I did the cross-platform stuff. I wrote APR to get awar from it. Ryan __ Ryan Bloom [EMAIL PROTECTED] Covalent Technologies [EMAIL PROTECTED] --
Re: [VOTE] Removal of mod_jk for Apache 2.0 from jakarta-tomcat f or Tomcat 3.3
On Monday 10 September 2001 14:51, [EMAIL PROTECTED] wrote: On Mon, 10 Sep 2001, Pier Fumagalli wrote: This is the third time we agree on something in less than 24 hours. This implies that either I'm getting old, or just plain silly... Now, if you could agree on merging mod_webapp and mod_jk, that would be something... Slowww down... :) If mod_jk wants to start using APR, I believe we're talking, otherwise, I'm done with cross-platform porting, I live it to Ryan :) Mod_jk will use APR - that's certain. The only question is when and how to do the transition without affecting the stability of the code. Having an APR1.0 out is one of the requirements - I don't think we can release mod_jk, even from j-t-c, with dependencies on un-released library. There are already 2 proposals for how to do that - one with preserving the current common as a temporary solution, until we make sure it works with IIS/NES, and the other with removing the common utils and hoping things will work with IIS/NES. Right now the APR/common is not the main itch - it'll become pretty soon, at least for me ( I need mmap for the new connector ) I'm actually right now working on the thread locks for Windows, and then I am going to start agitating for an APR release. We should have APR 1.0 out the door soon-ish. I am hoping to have it released sometime in the next month or two. :-) Ryan __ Ryan Bloom [EMAIL PROTECTED] Covalent Technologies [EMAIL PROTECTED] --
Re: [VOTE] Removal of mod_jk for Apache 2.0 from jakarta-tomcat f or Tomcat 3.3
On Monday 10 September 2001 15:22, Pier Fumagalli wrote: Ryan Bloom [EMAIL PROTECTED] wrote: MMAP is the other scary stuff in APR, the new code (without Ralph's libmm) it no more than one month old... I need it for load balancing, but I want to double check with the guys in CA next week and see what they tell me before publishing anything.. Actually, MMAP has been in APR for a long time, it is just shared memory that is new. My bad... :) And, the shared memory code has been stressed in Apache for the last month. Also the shared memory code is basically just the important stuff from the MM library. My last status was 2 weeks ago when I last saw David, and he said wait for a little longer still... So, can I assume that little longer is over? I think so. The problem back then, was that he needed APR to be available before he could do anything with apr-util, but we were cleaning APR before trying to clean apr-util, and it just didn't work. That was a BeOS-only problem though. Ryan __ Ryan Bloom [EMAIL PROTECTED] Covalent Technologies [EMAIL PROTECTED] --
Re: [VOTE] Removal of mod_jk for Apache 2.0 from jakarta-tomcat f or Tomcat 3.3
En réponse à [EMAIL PROTECTED]: On Mon, 10 Sep 2001, Pier Fumagalli wrote: GOMEZ Henri [EMAIL PROTECTED] wrote: Ryan to became more than just a contributer : This is the third time we agree on something in less than 24 hours. This implies that either I'm getting old, or just plain silly... Now, if you could agree on merging mod_webapp and mod_jk, that would be something... I'm ok for that, may be by merging ajp14 and warp (ajp20). We could have this protocol implementation in mod_jk and mod_webapp :) I'm serious here... Benefits : - with mod_jk, you'll gain AP1.3/AP2.0/IIS/NES/IPLANET/DOMINO, fault-tolerance, load-balancing, JNI and a good old and known modules. - with mod_webapp, you're right on the future with goodies like APR. And may be tomcat 4.0 could also add ajp13 support from works in JTC ? The best of both world PS: Something goes crasy these days, on tomcat list, what do you think about this Pier (known as my worst enemy :) - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6
Re: [VOTE] Removal of mod_jk for Apache 2.0 from jakarta-tomcat f or Tomcat 3.3
I'm actually right now working on the thread locks for Windows, and then I am going to start agitating for an APR release. We should have APR 1.0 out the door soon-ish. I am hoping to have it released sometime in the next month or two. :-) That's the last objection to use APR instead of current native works in jk (ie jk_pool). As soon there will be an APR, release we could start mod_jk translation to APR (and yes MANY MANY MANY code cleanup). - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6
Re: [VOTE] Removal of mod_jk for Apache 2.0 from jakarta-tomcat f or Tomcat 3.3
Gomez Henri wrote: [snip] PS: Something goes crasy these days, on tomcat list, what do you think about this Pier (known as my worst enemy :) Something is indeed a little bizarre on the list today, mon ami. Maybe because Craig isn't here to keep us in line =) a) There are now four key people seriously discussing a partial merge of mod_jk and mod_webapp b) Henri and Pier are agreeing on all sorts of things c) The 3.3 guys are congratulating the 4.0 guys and vice-versa d) There have been about 15 votes in last 24 hours e) _I'm_ the short-tempered one, for a change The only reason I know for sure that the world is still spinning is that Jon is still vetoing things ;-) - Christopher /** * Pleurez, pleurez, mes yeux, et fondez vous en eau! * La moitié de ma vie a mis l'autre au tombeau. *---Corneille */
Re: [VOTE] Removal of mod_jk for Apache 2.0 from jakarta-tomcat f or Tomcat 3.3
On Monday 10 September 2001 16:15, Christopher Cain wrote: Gomez Henri wrote: [snip] PS: Something goes crasy these days, on tomcat list, what do you think about this Pier (known as my worst enemy :) Something is indeed a little bizarre on the list today, mon ami. Maybe because Craig isn't here to keep us in line =) a) There are now four key people seriously discussing a partial merge of mod_jk and mod_webapp b) Henri and Pier are agreeing on all sorts of things c) The 3.3 guys are congratulating the 4.0 guys and vice-versa d) There have been about 15 votes in last 24 hours e) _I'm_ the short-tempered one, for a change The only reason I know for sure that the world is still spinning is that Jon is still vetoing things ;-) Well, I'm new to the list, but I like to veto things too. Somebody point me at something I can veto... :-) Ryan __ Ryan Bloom [EMAIL PROTECTED] Covalent Technologies [EMAIL PROTECTED] --
Re: [VOTE] Removal of mod_jk for Apache 2.0 from jakarta-tomcat f or Tomcat 3.3
Ryan Bloom [EMAIL PROTECTED] wrote: Well, I'm new to the list, but I like to veto things too. Somebody point me at something I can veto... :-) You can always veto your committer status... :) :) :) Pier
Re: [VOTE] Removal of mod_jk for Apache 2.0 from jakarta-tomcat f or Tomcat 3.3
Gomez Henri [EMAIL PROTECTED] wrote: I'm ok for that, may be by merging ajp14 and warp (ajp20). Ok... I can agree with that... We could have this protocol implementation in mod_jk and mod_webapp :) Sure do... I'm serious here... Me too... - with mod_jk, you'll gain AP1.3/AP2.0/IIS/NES/IPLANET/DOMINO, fault-tolerance, load-balancing, JNI and a good old and known modules. Yeah... - with mod_webapp, you're right on the future with goodies like APR. And may be tomcat 4.0 could also add ajp13 support from works in JTC ? Ok... I have no clue on how JK works, but fairly know how to take the shit out on TC side... I'll give a shot to JK and AJPv13, run watchdog and tester, at the same time, I'd like for you to look at WebApp and tell me what's wrong with it... Why don't we keep a NON-APR (JK), and progress works on APR based on WebApp? Joining AJPv14 and WARP? The best of both world Definitely... PS: Something goes crasy these days, on tomcat list, what do you think about this Pier (known as my worst enemy :) I believe it's because we are all so tired about fighting, and going out with the two trees (3.3 and 4.0) more or less at the same time, offloaded the pressure _a_lot_... And we don't want to be bitchy with each other? Pier (feeling awkward!)
Re: [VOTE] Removal of mod_jk for Apache 2.0 from jakarta-tomcat f or Tomcat 3.3
Christopher Cain [EMAIL PROTECTED] wrote: Something is indeed a little bizarre on the list today, mon ami. Maybe because Craig isn't here to keep us in line =) No, I believe we have to thank Jon for that... I believe that raising another flame war at this point made us all realize that probably we _could_ work together somehow... The releases are out/planned, a big relief valve... We might not agree on ANYTHING, but a) There are now four key people seriously discussing a partial merge of mod_jk and mod_webapp Oh yes... b) Henri and Pier are agreeing on all sorts of things Weirdest 24 hours ever (well, since me and Peter Donald got along, anyhow!) c) The 3.3 guys are congratulating the 4.0 guys and vice-versa Well, a release 's a release :) d) There have been about 15 votes in last 24 hours More than that e) _I'm_ the short-tempered one, for a change No, you're not... The only reason I know for sure that the world is still spinning is that Jon is still vetoing things ;-) Ah, that's NEVER going to change... Pier
RE: F....
Agreed! Let Costin and the others make their job and then let code talk. Have fun, Paulo Gaspar -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Friday, December 22, 2000 12:55 To: [EMAIL PROTECTED] Subject: Re: F Whoever wants to develop on tomcat 4 does so. Whoever wants to develop on tomcat 3 does so. +1 Eventually a winning container will emerge. Forcing people to abandon the current, production release will not work - they'll just go elsewhere, that won't help anyone. If everyone concentrates on reusable code... whatever, it's Xmas, go to the pub.
RE: F....
-Original Message- From: Jon Stevens [mailto:[EMAIL PROTECTED]] Sent: Thursday, December 21, 2000 23:26 Tomcat 3.2 has *only* happened because Tomcat 4.0 wasn't ready. And I wonder when is it going to be. That is why I want the 3.3 alternative. Remember the history of Tomcat 4.0 and the fact that if Sun didn't donate a bunch of cruft software, we would have spent the time working on JServ 2.0 which is now what Tomcat 4.0 is. The fact of the matter is that because we had to deal with 3.x and support improving it that delayed the development of 4.0 to not being ready until now. So, a wrong decision was taken accepting Tomcat 3 instead of JServ 2??? Wrong decisions are possible at Tomcat then. So, why are you deffending voted decisions as the "irrefutable true path"? Have fun, Paulo Gaspar
Re: F**k It. (off topic)
I don't mean to sound as though I am a prude, but we do a lot of our consulting at customer sites, much of it face-to-face with the customer's staff and management. I can control what messages I read and when but I cannot control when people are in my office and when the message alert with the Subject: line pops up on the screen. I can't do much to diffuse the anger but I would like to ask that we try to reserve our anger (and expletives), when appropriate, to the message body rather than the Subject: line so that I don't have to act like I was caught browsing porn sites every time my customers walk into my office. Thanks in advance.
Re: F**k It. (off topic)
[EMAIL PROTECTED] wrote: I don't mean to sound as though I am a prude, but we do a lot of our consulting at customer sites, much of it face-to-face with the customer's staff and management. I can control what messages I read and when but I cannot control when people are in my office and when the message alert with the Subject: line pops up on the screen. I can't do much to diffuse the anger but I would like to ask that we try to reserve our anger (and expletives), when appropriate, to the message body rather than the Subject: line so that I don't have to act like I was caught browsing porn sites every time my customers walk into my office. Thanks in advance. Exact same scenerio here. I second that.
Re: F... It.
The future of Tomcat 3.3 seems to be outside Apache now. It's really sad. Sorry, but that's not what I said Henry. Last month I even came up with a proposal that got accepted (but never turned to reality) on how to handle this situation... But it seems to me, that everyone here is more interested in flaming others rather than read and discuss... And this sucks... I'm not saying to kick the 3.3 proposal out, I'm just saying that, from what I see 3.3 is as different from 3.2 as 4.0 is, it is a different container. And because of this, rules for revolution and evolution are given: - old container = bugfixes, improvements (TC3.2) - current container = developement (Catalina) - new container(s) = proposals (whatever you want for 5.0) Again ?? Then what about tomcat3.2 - is it as different from 3.1 as 3.3 is from 3.2? Is there any change in 3.3 that you feel is wrong ? You can send your -1 now, with the technical arguments for that. I already accepted the -1 on implementing Servlet2.3 - even if it wasn't on technnical but political reasons, and I'm open to any other changes. Take the "changes" file, find something you feel is "making 3.3 as different from 3.2 as 4.0 is" and send it to the list. Evolution doesn't mean everything is frozen and you make only small changes here and there. And making tomcat3.3 faster, cleaner and more modular than 3.2 requires a number of changes. Generic statements are easy to make - what do you think is part of 3.2 architecture and isn't part of 3.3 ? Yes, some interfaces were removed - because they were duplicating what Interceptor is doing ( and the interfaces were introduced after 3.1 for the same reason, making the code cleaner ). It's one thing to make the code more modular and cleaner, and another thing to "change the architecture" and the design patterns. Costin
Re: F....
on 12/21/2000 2:18 PM, "[EMAIL PROTECTED]" [EMAIL PROTECTED] wrote: Tomcat3.2 is a big step forward versus Tomcat3.1 - but it still have many issues - take a look at the ContextManager in 3.3, compare it with 3.2 - there are still many undefined behaviors, even code from 3.0. Tomcat 3.2 has *only* happened because Tomcat 4.0 wasn't ready. Remember the history of Tomcat 4.0 and the fact that if Sun didn't donate a bunch of cruft software, we would have spent the time working on JServ 2.0 which is now what Tomcat 4.0 is. The fact of the matter is that because we had to deal with 3.x and support improving it that delayed the development of 4.0 to not being ready until now. It is this duplication of effort that needs to stop. We need to quit sitting back and trying to support something that should have been dead long ago. -jon
Re: F....
I have been following this insane tomcat 4 vs tomcat 3 debate with increasing amazement. I cannot understand why this has become such a big issue. Attempting to tell an open source developer what to write is pretty much counter to ESR's cited prime motivation for open source development - scratching a personal itch! If Costin (bless his soul) wants to make TC3 a better product, then he has my own profound thanks! As a user of tomcat (I use tomcat every day as part of my job) am very keen to see tomcat 3.x development continue as long as tomcat 4 falls short of release quality. Until IIS integration and SSL client certificate support are considered release quality in tomcat 4, I am keen to see them developed on tomcat 3. In fact, I believe that the time to abandon tomcat 3 development will come at around the point that new features are able to reach release quality as fast on tomcat 4 as on tomcat 3. The technology used in tomcat 3 is perfectly current. Forcing people into participating in development of a bleeding edge product in order to add features to tomcat seems pretty mercurial. Tomcat 3 is just becoming a premium quality product. There are two or three features still to be added to completely satisfy my own requirements of a servlet container. If we abandon development now in favour tomcat 4, tomcat will remain a bleeding edge product and may never reach the mainstream release quality that I for one would like to see. What I suggest is this: Whoever wants to develop on tomcat 4 does so. Whoever wants to develop on tomcat 3 does so. Versions are managed in a similar manner to the linux development/stable trees, with code from TC4 merged back into TC3 whenever the TC3 guys feels that this enhances the product. (And no complaining about the tomcat 3 guys 'copying' the TC4 guys - that is kind of the point of open source!) Cheers and Merry Christmas! --- Aaron Knauf Implementation Consultant Genie Systems Ltd Auckland, New Zealand Ph. +64-9-573 3310 x812, email: [EMAIL PROTECTED] http://www.geniesystems.com Jon Stevens [EMAIL PROTECTED] 22/12/2000 11:26 Please respond to tomcat-dev To:[EMAIL PROTECTED] cc: Subject:Re: F on 12/21/2000 2:18 PM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Tomcat3.2 is a big step forward versus Tomcat3.1 - but it still have many issues - take a look at the ContextManager in 3.3, compare it with 3.2 - there are still many undefined behaviors, even code from 3.0. Tomcat 3.2 has *only* happened because Tomcat 4.0 wasn't ready. Remember the history of Tomcat 4.0 and the fact that if Sun didn't donate a bunch of cruft software, we would have spent the time working on JServ 2.0 which is now what Tomcat 4.0 is. The fact of the matter is that because we had to deal with 3.x and support improving it that delayed the development of 4.0 to not being ready until now. It is this duplication of effort that needs to stop. We need to quit sitting back and trying to support something that should have been dead long ago. -jon
Re: F....
Well, I am not that good at getting all this flames ( and to be honest I'm not used to get the "thanks" that I got lately - mostly in private mail - it looks like a very different world, and an wonderful Christmas gift for me ) In any case, I'll try to stay away from further arguments - I know now that I'm doing the right thing, and until I finish the development and what I started there is no point in endless discussions. I'm very close, and if I stay out of mail I'll probably be ready to the first milestone in early January. When it'll be ready I'll make the proposal and then you can vote whatever you feel, based on the quality of the code or your private interests. As long as there is an open development branch in jakarta-tomcat tree and I am a commiter I'll accept any critics for code that I write, but I don't think Pier or Jon have any authority or right to tell me what to do or to not write code, for any reason. This is open source development and as long as they don't prove that my code is bad, I'll keep coding. If they don't like it - I'm sure they can ask for a vote to remove my account ( or just do it ). I think I did a decent job during the tomcat3.2 development ( not perfect, of course, because I'm not perfect either ) - and enough users and fellow developers feel I'm still doing a good job on 3.3 - so the argument of "community united against 3.3 " or "that's the community decision" doesn't seem to hold water. As for: Tomcat 3.2 has *only* happened because Tomcat 4.0 wasn't ready. Well, thank you for letting it happen ( and thanks for letting us doing development for a year and so without too much s**t ). As for resources - remember that in open source you must go get them, and it's quite a bit of competition for smart people. If tomcat 3.x is able to get smart people involved you should say thanks, and not to tell them they're stupid. And as an open source developer you should remember that code lives and dies on it's own quality and the quality of the people who contribute to it. Remember the history of Tomcat 4.0 and the fact that if Sun didn't donate a bunch of cruft software, we would have spent the time working on JServ 2.0 Yes, a bunch of cruft software, with a good design and some great ideas. Tomcat3.0 had pretty bad code, 3.1 was stable and usable ( IMHO ), 3.2 is faster and a bit cleaner - not too bad for a "cruft" software ( while 4.0 is still, after a year, "the next big thing" ). That's probably another proof that in software, the design is what matters the most. QED. As of JServ 2.0 - it has in common with JServ 1.0 the same as Tomcat4.0 has with Tomcat 3.x - the name. If you remember I spent some time on the jserv list trying to improve the design, and I also spent lots of time after Catalina was announced pointing problems with the design - I don't think you have too many contributors who spent so much time on it. I gave up on Jserv2.0, and I gave up on Catalina - either I can't present my ideas or nobody was listening. ( you can check the archives - like the endless flame-war about how un-important is the web server or how bad is to do in-process java ) which is now what Tomcat 4.0 is. The fact of the matter is that because we had to deal with 3.x and support improving it that delayed the development of 4.0 to not being ready until now. "we had to deal with 3.x " "we had to support improving it" Damn, I thought we are still individuals - and most of your mail talks about "we". Are you talking for ASF ? For your company ? For you and your friends ? Or for us, the tomcat comunity ? And one more thing - it's very important for me to 'discharge' myself from having tomcat 3.x as my "baby": - the original design is done by a certain James ( AFAIK ). And it's damn good, better than any other container I know. - most of the server adapter is done by Pier, Stefanno, Jon - the mod_jserv code - and Gal - the new mod_jk, based on mod_jserv. And there are very good pieces of code - yes, not too much comments, but still great code. - most of the bug fixes were done by countless contributors, and most of the commits are either Larry or Nacho. Probably they should feel the most that tomcat3 is their baby, as they spent lots of time caring for it ( while I was just playing with it ). - Logging - Alex, based on initial ideas from Anil ( both had many other contributions ). I didn't liked it initially, but it is a very good contribution with some great ideas in it. - sandbox - Glenn. That's the area I felt I want to contribute the most, but Glenn did it faster and better. - SSL adapter - based on Harish's ideas - Interceptor architecture ( the main architectural thing I added to tomcat ) - is copied from Apache, I don't know who is the original author but unfortunately it's not my child. - most of the refactoring is again based on Apache design ( with a lot of inspiration from Apache2.0 - take a look at the MPM modules, etc ) - The
