RE: Tomcat 3.3 / 4.0 confusion, rant and plan...
Yes, We saw many reference of code to be fixed on 3.3. Now that some want to kill 3.3 and directly play with 4.0, the risk of having a 3.x branch (the current branch) falling in 'unsupported software land' is VERY HIGH. This is open source - it's supported as long as some developers are supporting it :-) As long as people are using it, the source code and license will keep it alive. Sorry but for now the only existing and used branch is 3.x (3.1 and 3.2b) We need a URGENTLY a 3.2 release (with a bug lists) and start the 3.3 beta. +1 As soon as 3.2 is released I'll make a proposal to freeze 3.3 in 2-4 weeks. Right now 3.3 is almost ready for feature freeze, but we'll need to merge all the small bug fixes that went into 3.2. ( ready for feature freeze doesn't mean is ready for release !- it has old and new bugs, but the major changes are almost done ). As I said earlier, I don't think we'll need a 3.4 or more changes in the core very soon - unless somone finds a use case that can't be implemented with the current architecture or a big performance improvement that requires a core change. After 3.3 we can have minor ( dot.dot ) releases or just provide updated interceptors. ( that doesn't means 3.x is ended, just that it'll be stable enough as a framework, and future development can be done without braking backward compatibility and in separate modules ) Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 3.3 / 4.0 confusion, rant and plan...
Liam Magee [EMAIL PROTECTED] wrote: I have been a long-time silent listener on this list, and use Tomcat 3.1 in a production environment. I have been greatly appreciative of the hard work gone into the software to date, and respect that its development is on a volunteer basis. But I fully concur with the sentiments of this posting - for the past couple of months it's been completely unclear as what the development path and release schedule for Tomcat looks like (3.2?, 3.3?, 4.0?). I would like to continue to use Tomcat, and eventually have time to get more involved in its development, but the lack of any obvious plan and schedule leaves companies like ours considering whether we need to fall back to commercial offerings to get any kind of reliability or accountability for the direction of releases. Again, I respect that the basis of this project is volunteer-driven, but it is possible to get a balance between the democratic impulses of OSS and a more rigorous project management approach to 'deliverables'? Let me wear my "foundation member" hat for a while, try to make a point of the current situation, and explain something that is obvious for long-time developers, but might not be so clear for newcomers. First of all let's clear up a long time issue (I reply to webmaster@jakarta too, and this question keeps popping up) What is Tomcat? Tomcat, the Jakarta Apache flagship product, is (as the web site states) the Reference Implementation for the Java Servlet and JavaServer Pages Technologies. Let's try to explain this a little bit: Tomcat is NOT a servlet engine and it is NOT a JSP engine/compiler; Tomcat is the union of those two separate technologies. Some confusion have arised in the past because in the 3.x tree Tomcat is the name of BOTH the servlet engine AND of the full distribution. But, recognized this problem, in the new 4.x tree we changed things to make better understand this distiction: "Catalina" is the servlet engine, "Jasper" is the JSP engine/compiler and "Tomcat" is the union of those two. What does this mean? This means that, at the end, you will be able to download Catalina (if you need only servlets), Jasper (if you want to use JSPs on ANY servlet engine, even on Allaire's JRun hopefully), or Tomcat (if you want to use the full distribution from Apache). Why all this confusion? Why do we need Tomcat? Can't we just have "Catalina" and "Jasper"? No, we can't... Because Tomcat (the full product) is the reference implementation of the Java Community Process' JSR-53, so, one JSR, one specification, one name, one distribution... (Ok, I have to save this one for all the webmaster@jakarta emails). Now, to explain a little bit how we are organized, let me say that we're far from the time when we were a bunch of kids playing at Java.Apache.ORG with JServ. Now we are part of the Apache Software Foundation, and because of that, we have to obey to some rules. Most of our self-imposed regulations were derived by the invaluable experience gathered by the HTTPD project (the web-server) and that was absorbed by all other branches of the foundation by osmosis. We have a voting process, a vetoing process, a list of people who have the right, and the due (I would like to underline this!) to vote on issues. This all is clearly described in our "Guidelines" page, please READ it, because that's the LAW in this community. Once an issue is found (a new release, a new codebase, anything that needs a general agreement), all the committers (people with access to the CVS) are asked for a vote. And when a decision is took, it's a responsibility of those voting committers to maintain what was promised. (Yes, if you're a committer, you have responsibilities in front of the community... Again, we're far from the old JServ days). Now, to sum up what happened in the last few months: Some of us (in particular Craig, me, Jon, Remy and others) weren't feeling comfortable with the Tomcat 3.x (Servlet Engine) codebase. Craig, the main author of what would have become JServ 2.0, asked the permission to create a new propositive servlet engine, we voted, and the "Catalina" proposal was created. When Servlet 2.3 and JSP 1.2 came along, this community was asked to vote again, on what codebase would have been used for this new reference implementation: we had to choose between Tomcat 3.x (Servlet Engine) and Catalina, and we decided to adopt Catalina as our next-generation servlet engine. In those last few days, I've seen emails going around with a "Tomcat 3.3" label stamped upon them, and that's when I started to wonder, and get confused. This community didn't vote for a Tomcat 3.3 release, nor we were asked what we were thinking about such a thing. Puzzled, I started asking around, and, aparently, what was clear in the past (Tomcat 3.2 release and then Tomcat 4.0) was all screwed up. For what concerns me, Tomcat 3.3 doesn't exist as an Apache Project. It was not voted upon, and it is in direct
Re: Tomcat 3.3 / 4.0 confusion, rant and plan...
Luke Holden [EMAIL PROTECTED] wrote: What is the status of the Tomcat 4.0 web connector for apache (if any)? ARRGGH :) :) :) :) You know how to make me suffer... A beta will be available soon Pier - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 3.3 / 4.0 confusion, rant and plan...
"Pier P. Fumagalli" wrote: What is the status of the Tomcat 4.0 web connector for apache (if any)? ARRGGH :) :) :) :) You know how to make me suffer... A beta will be available soon hahahaha :) Well is there any way I can help? Although slightly new to java Ive been programming for a number of years. (I mainly program in c/c++ and php).. however I have recently cought onto the java language and I really enjoy it. I would love to help in any way I can :) -- Luke - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 3.3 / 4.0 confusion, rant and plan...
"Pier P. Fumagalli" wrote: So, I'm proposing this plan, and please vote on 2 and 4 (1 and 3 were already voted upon with a bunch of +1s)... 1) Release Tomcat 3.2 final (soon, please!) +1 2) Create a new proposal tree alongside with Catalina (new name to avoid confusion, please) +0 3) Release Tomcat 4.0 (with Catalina, as we all decided) +1 4) Decide wether Tomcat 5.0 will be Catalina based or "whatever" new proposal comes along. -1, way too early to consider this Get the Tomcat 4.0 Apache mod_warp connector committed. +1, ;-) -- 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]
RE: Tomcat 3.3 / 4.0 confusion, rant and plan...
For what concerns me, Tomcat 3.3 doesn't exist as an Apache Project. It was not voted upon, and it is in direct contrast with what this community decided.rg I'm probably wrong, but I don't remember a vote that said Tomcat 3.2 was a new development over Tomcat 3.1. I thought it was clear that Tomcat 3.1 was an "unfinished" work and Tomcat 3.2 was necessary step down the road to finishing Tomcat's mission to provide an RI for the servlet 2.2/JSP 1.1 specs. In my opinion, Tomcat 3.2 doesn't finish the job. It has enough bugs and out of spec issues that it can't claim to be a "finished" RI. rantAnd it certainly wasn't left in a releasable state when work on it was for the most part abandoned by most everybody back in early summer./rant:-) So for the near term, I plan to put my efforts to "finishing" the Servlet 2.2/JSP 1.1 RI. At this point, my preference is to put that effort into Tomcat 3.3 as opposed to continuing to fix Tomcat 3.2. Though, if there is to be only a Tomcat 3.2 release and no Tomcat 3.3, I would prefer to not release the current Tomcat 3.2 and treat the MAIN branch as Tomcat 3.2.;-) I think Jakarta should provide a "quality" RI for the Servlet 2.2/JSP 1.1 specs, and in the future a "quality" RI for the Servlet 2.3/JSP 1.2 specs. IMHO, to release what we have now as the RI for 2.2/1.1 and say this is as good as the RI gets, would reflect badly on Jakarta. I admit to being selfish in this opinion. It is SAS Institute's intention to use Tomcat with our Java IDE. SAS has enough customers that do not jump on cutting edge technology, that 2.2/1.1 will be in use for a long while. We have a need for a solid Tomcat 3.x implementation, both as the RI and as a "well behaved" web server. This is where I will put my Tomcat 3.x efforts before moving on to Tomcat 4.0. Others are welcome to put their effort where it most interests them. Cheers, Larry Isaacs - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Tomcat 3.3 / 4.0 confusion, rant and plan...
Sorry again, but this time I have to vote -1 on a "new" Tomcat 3.3, expecially before 3.2 final is out of the door. The NEXT major release is going to be Tomcat 4.0, based on Catalina, as we all agreed on months ago. The impression I got from reading the dev list was that 4.x was where everyone was going to be focussing, one 3.x was in a rockin' good state. Isn't that what happened to JServ? I thought the JServ page said something like, "JServ is only bug fixes from now on - go get Tomcat" ? I can't find where I read that now, so maybe I didn't, but I sure thought I did ;) Also, whatever the result of this discussion, we should most definitely have Pier's stuff on the main page (jakarta home and Tomcat home). From an, "I've never seen Tomcat before" being faced with two downloads, which one would you grab, seeing 3.1, 3.2b6 and 4.0M4 available? Maybe 3.2b6 if you're familiar with the software development process. It can confuse people who want to contribute as well. Who is the webmaster for jakarta? The project is very much alive and kicking, but there hasn't been a news update since July! I wouldn't say there there's no news considering the PHP home page ducking =) has updates when new betas are released. Maybe the main page should be a combined news/description page like the Java-Apache home. The list of products on the right with a description and release number? That's hella cool! - r - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Tomcat 3.3 / 4.0 confusion, rant and plan...
"I've never seen Tomcat before" being faced with two downloads, which one would you grab, seeing 3.1, 3.2b6 and 4.0M4 available? "being faced with two downloads, which of these three would you grab?" I think next time I won't get up at 6 am =) I think Jakarta should provide a "quality" RI for the Servlet 2.2/JSP 1.1 specs, and in the future a "quality" RI for the Servlet 2.3/JSP 1.2 specs. IMHO, to release what we have now as the RI for 2.2/1.1 and say this is as good as the RI gets, would reflect badly on Jakarta. FWIW I'm in total agreement here. I think the major functionality that was planned should be implemented, all the known killer bugs fixed up, etc. As a long-time (since early summer =) advocate of Tomcat, I would have a tough time explaining to people, "Well, 3.x is sort of this unfinished thing that they weren't happy with, so they started 4.x". To me, that DOES give the impression that the Tomcat project is indeed what Pier said exactly it is NOT: kids playing around in the org tree. - r - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 3.3 / 4.0 confusion, rant and plan...
Sorry Pier, but I don't think I'm doing anything wrong. I worked ( pretty hard ) on the last year or so on tomcat. I worked ( pretty hard ) convincing other people to contribute. Tomcat 3.1 is better that tomcat 3.0 ( or the old JWSDK ). Tomcat 3.2 ( as it was few months ago ) is better than tomcat3.1. It's not perfect - but it's better. There are fundamental problems ( that are present in other containers as well, even worse !), and 3.3 is going to fix them. I don't care how it'll be called, or where it'll stay ( an Apache Fundation member asked me to go to SourceForge and stop using the name "tomcat" - and Pier is asking me to make it a "revolution" and change the name to something else, as Tomcat is no longer correct ). The fundamental problems are: - can't support charset detection ( i.e. the encoding of the URI ) - there is a limit on performance because of excessive use of Strings - the code still need improvements in the modular structure. I have no idea why tomcat 3.2 hasn't been released - it's not my decision. As far as I'm concerned 3.2 is over ( for me ) - it's a step forward, but (as 3.1 ) it isn't perfect. I don't know any "critical" bug in 3.2 that wasn't in 3.1 also. Regarding the "confusion" of using "tomcat" ( i.e. 2 different codebases with the same name ) - well, I don't quite understand how it is my fault, but I'm going to work on the current ( "evolutionary" ) codebase, whatever you decide to call it. If mighty Apache Members or PMC decide to ban this project, or to change it's name - so be it. You can also revoke my account on locus - feel free to do it, it seems my presence there is less and less wanted. As long as my account still works ( and I'm still a commiter ), I'll continue to work as before - if the code I commit is buggy, please -1 it. I don't think I need a vote to add new features to tomcat 3.3 ( that are present in catalina ) - after all none of that was "proposed" or "voted" on the other codebase. Regarding the implementation of Servlet2.3 and JSP1.2 - I'm curious to see how will you "spin" this, but I think it's important to support the latest specs, and tomcat3 was designed with "facades" from beginning - ask Duncan why. To conclude ( I hope my last mail on this topic ) - I think tomcat3 is very good container, has a very good desing, and I don't think Apache "politics" and Apache hierarchies can stop good code for beeing developed. Costin P.S. I am not allowed to say anything about tomcat 4.0 or catalina, but I do hope that open source magic will work and people will compare the 2 architectures and decide what works better. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Tomcat 3.3 / 4.0 confusion, rant and plan...
time explaining to people, "Well, 3.x is sort of this unfinished thing that they weren't happy with, so they started 4.x". To me, that DOES give the 3.x and 4.x are 2 different servlet containers, with very different design. The only confusing thing is the fact that the same name is used for both, and the number looks like 4 is a continuation of 3. Which one is better should be based on code reading and real-world testing, not on the number that is stick on it. ( BTW, the feature set is very different, the core design is different and of course the performance is different too ) Again, I don't remember when Apache decided to throw away a particular design and codebase and the reasons behind it, but if Members decide so I don't think I can do too much about it. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Tomcat 3.3 / 4.0 confusion, rant and plan...
So what are our goals, anyhow ? I think we should concentrate on the following goals (in this order): 1) Provide a quality RI of Servlet 2.2/JSP 1.1. This is something that Tomcat 3.0 claimed to be, but until now we are still not quite sure ! 2) Provide a production quality implementation of Servlet 2.2/JSP 1.1, so the users don't have to ask "JServ ot Tomcat ?". 3) Provide support for future versions of the specifications, as both RI and production quality environment. Now, how do individual versions of Tomcat meet these goals ? Tomcat 3.1 meets neither, IMHO. Tomcat 3.2 does not meet 3), and it meets 1) much better than 3.1, enen though not perfectly. Are we happy with this ? Can we release 3.2 as it is now, or do we want to be 100% sure that we have 1) or even 2) ? Tomcat 4.x meets all, but it's not going to happen for a while. From this I think that clearly there is need for further development in the 3.x codebase, until we fully meet 1) and 2). Namely, we should release 3.2 ASAP. I consider it a big mistake that we (including myself) stopped development of 3.2 and didn't finish it yet. And I wouldn't want us to make the same mistake for 3.3: we don't necessarily need more features and new specification support in 3.3, particularly if that's going to delay the delivery of goal 2) (which should also happen ASAP). So 3.3 makes sense, but without support for the new specs, webdav etc. If we never finish what we started, then (as Rob said) we are a bunch of kids playing around in the org tree. My 2 Kc. Petr - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Tomcat 3.3 / 4.0 confusion, rant and plan...
I'd like to speak up about this briefly. Catalina/Tomcat-4.0 may be the future which is fine, but Tomcat is now being used in production settings. We've been testing the 3.2b* releases and the performance is better than 3.1 which is important for us. The performance of 3.3 is supposed to be better still. Catalina may have the perfect design, but I can't say anything about that because I haven't gotten time to look at the code. From previous emails though, it sounds like the supporting code such as Apache httpd connectors may not be ready yet, let alone tested. Mod_jk wasn't perfect at the last time that I tested it, but it was functional. What am I saying? Tomcat 3.x may not be perfect yet, but it has the supporting software in place and working. Catalina may have the perfect embedded http server, but that is of no interest to us. We need the speed and flexibility of the Apache httpd. What I'm asking is will Catalina be ready for production usage any time soon? Has it been tuned for speed yet? As for 3.3, I see it as a finish of what 3.2 started. We don't need Servlet 2.3 yet, so that isn't important to us. What we need is stability and performance. Once 3.2 is in production use, people will find bugs and problems. Thats the nature of software. I think that should be the real place of 3.3. Take what has been done as far as performance, and the fixes for bugs and spec compliance issues from 3.2 and put them in 3.3 and release that. I think that perhaps the choice between the 3.x architecture and the Catalina proposal may have been a little premature. Catalina doesn't have the supporting features yet that the 3.x series has. We can't do a head-to-head comparison between the two because Catalina doesn't have the connectors in place yet. I would like to thank Costin and everybody involved in the 3.x series. They took a non-optimal code base and turned it into something suitable for production use. They got it up and running soon enough that it has been able to get traction in the industry and let us develop applications based off the newer specifications. They made the way for Tomcat 4.0, whatever code that may be. I don't think that code that works now should be thrown away until the code that is intended to replace it is ready to replace it. Paul Frieden On Sat, 4 Nov 2000 [EMAIL PROTECTED] wrote: time explaining to people, "Well, 3.x is sort of this unfinished thing that they weren't happy with, so they started 4.x". To me, that DOES give the 3.x and 4.x are 2 different servlet containers, with very different design. The only confusing thing is the fact that the same name is used for both, and the number looks like 4 is a continuation of 3. Which one is better should be based on code reading and real-world testing, not on the number that is stick on it. ( BTW, the feature set is very different, the core design is different and of course the performance is different too ) Again, I don't remember when Apache decided to throw away a particular design and codebase and the reasons behind it, but if Members decide so I don't think I can do too much about it. Costin - 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: Tomcat 3.3 / 4.0 confusion, rant and plan...
Everyone, I see no reason why Tomcat 3.x and 4.x have to be mutually exclusive. As far as I can tell, Tomcat 3.x is Servlet 2.2, and Tomcat 4.x is Servlet 2.3. It's as simple as that. Yes, the vote did happen. You now have Tomcat 4.x, and that is what I am using, and it is awesome! Craig, you rock! But, if there are spec compliance issues WRT Tomcat 3 and Servlet 2.2, then I believe development on the 3.x tree MUST continue, until Tomcat 3.x truly IS the RI of Servlet 2.2. Anything else would not make sense. The numbering (3.2, 3.3) does not matter. If you look at the httpd part of the ASF, they have been working on 1.3.x, as well as 2.x. What they did is they chose to only maintain the 1.3.x tree if Apache was not compliant with something in the HTTP spec itself, or bug fixes. They voted as a group to do any and all new feature development in the 2.x tree, and that is what they are doing. Since the 2.x tree creation, they have released 1.3.13, 1.3.14, and they are working on 1.3.15. Development has stopped, but bug fixing continues. 90% of the httpd work that goes on is in the 2.x tree, but the 1.3.x tree is alive, and will be for quite awhile. AFAIK, you guys voted to make Catalina the engine of choice for Tomcat in its Servlet 2.3 implementation, and you are doing that. I would say that the majority of development should eventually be on Catalina, but if Tomcat 3.x has spec issues, those should be fixed, unless you have also voted that Catalina is the RI for Servlet 2.2 as well. FWIW, the httpd people are EXTREMELY against any new features in the 1.3.x tree, but they do not stop new releases for bug fixes or spec-compliance issues. I think that should be the same type of thing here. Just my non-voting $.02. Scott Sanders - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 3.3 / 4.0 confusion, rant and plan...
On Fri, 3 Nov 2000, Pier P. Fumagalli wrote: Sorry for starting what it might end up as a long flamewar, but reading almost 500 emails on the list I ended up a little confused... Also, in a bunch of side discussions, but related always to the same topic, I feel there's something wrong going around here... Question: WHAT THE HACK IS TOMCAT 3.3 ??? I'm not disagreeing with you Pier, but I will say I believe that there are 2 possible ways to interpret the current situation, and I do not think I'm the only one who thinks this. 1) The fact that there are smart software developers out there contributing to Tomcat 3.x codebase and not necessarily contributing to the 4.0 codebase is a failure of the Jakarta Apache community to obtain sufficient buy-in from those people. The division of resources in this situation is what should be avoided at all cost, because this is the one major limitation OSS has: division of finite resources within a community because of forking. I would assume one of ASF goals is to prevent this. 2) Or alternatively, anything beyond Tomcat 3.1 refects that Tomcat 3.1 is a "rolling beta", which means the "code-train" is in such bad shape that the developers are throwing track in front of it as it moves forward. Not a good thing. Or maybe we have a combination between the two. At any rate, ASF should rule clearly whether to let the code-train of 3.x roll off the track, whether to let it continue to roll on track but away from it's auspices, or to support the two code bases as is. By doing nothing ASF implicitly supports the latter, which is counterintuive to ASF's entire raison d'etre. my $0.02 -Nick - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 3.3 / 4.0 confusion, rant and plan...
"Pier P. Fumagalli" wrote: Sorry for starting what it might end up as a long flamewar, but reading almost 500 emails on the list I ended up a little confused... Also, in a bunch of side discussions, but related always to the same topic, I feel there's something wrong going around here... Thanks Pier for bringing this issue to a vote. Based on the other replies to this mail, it seems to me like the majority wants Tomcat 3.x to be the RI for Servlet 2.2/JSP 1.1, with production quality of course, and Tomcat 4.x the RI for Servlet 2.3/JSP 1.2. That's what makes most sense to me. The devil may be in the details, but I hope we can make it so. [...] So, I'm proposing this plan, and please vote on 2 and 4 (1 and 3 were already voted upon with a bunch of +1s)... 1) Release Tomcat 3.2 final (soon, please!) +1000. Sam promised a release candidate a couple of weeks back, but it didn't happen (I'm sure for a good reason). If Sam doesn't have the time to do this now, maybe someone else who's familiar with the release procedures can step up to the task? When the release candidate is available, we should make sure it's tested quickly (I promise to do so with a number of JSP applications I have handy). Only serious regression bugs should be allowed to force another candidate cycle. For the future, I suggest we document the release procedures and put them in CVS so it's easier for someone to help out with this if the appointed release manager can't do it for any reason. 2) Create a new proposal tree alongside with Catalina (new name to avoid confusion, please) -1, two code bases is more than enough ;-) If we can agree that Tomcat 3.x is the RI for Servlet 2.2/JSP 1.1 *only*, it makes sense for this code base to continue for bug fixes and improvements that are in support of these spec versions. I would have preferred to call these releases 3.2.1, 3.2.2 etc. instead of 3.3, but it's not all that important. Costin, Larry and others have put a lot of effort into 3.3, and even though I have not tested it yet myself, based on comments from others it's much better than 3.2 so lets take advantage of all that hard work and make sure it's released as the next 2.2/1.1 RI instead of hiding it in a new proposal branch. 3) Release Tomcat 4.0 (with Catalina, as we all decided) +1, but this will take some time since the new specs will not be final until next year, likely Q2. 4) Decide wether Tomcat 5.0 will be Catalina based or "whatever" new proposal comes along. -1, let's focus on 3.x and 4.x for now. Hans -- Hans Bergsten [EMAIL PROTECTED] Gefion Software http://www.gefionsoftware.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 3.3 / 4.0 confusion, rant and plan...
"Craig R. McClanahan" wrote: [...] Therefore, I'm going to spend the weekend integrating all the bug reports and fixes I can find into 3.2 -- please check the CVS commit reports and remind me of any that I miss. In particular, I would like people to check out the changes to MOD_JSERV and MOD_JK ... I don't have great facilities to test these exhaustively, so I'm going to be taking the word of some of the patch poster. Maybe we can get a release candidate available by midweek? Are you saying what I hope you're saying, that you're stepping in as release manager for 3.2 to make sure it gets released quickly? If so, thousands of thanks! Hans -- Hans Bergsten [EMAIL PROTECTED] Gefion Software http://www.gefionsoftware.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 3.3 / 4.0 confusion, rant and plan...
Hans Bergsten wrote: "Craig R. McClanahan" wrote: [...] Therefore, I'm going to spend the weekend integrating all the bug reports and fixes I can find into 3.2 -- please check the CVS commit reports and remind me of any that I miss. In particular, I would like people to check out the changes to MOD_JSERV and MOD_JK ... I don't have great facilities to test these exhaustively, so I'm going to be taking the word of some of the patch poster. Maybe we can get a release candidate available by midweek? Are you saying what I hope you're saying, that you're stepping in as release manager for 3.2 to make sure it gets released quickly? I don't care who does the actual release (I will if Sam can't and everyone else is OK with that), but I want to stop having to say "I dunno" when people ask about 3.2. If so, thousands of thanks! Hans -- Hans Bergsten [EMAIL PROTECTED] Gefion Software http://www.gefionsoftware.com Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 3.3 / 4.0 confusion, rant and plan...
I believe development on the 3.x tree MUST continue, until Tomcat 3.x truly IS the RI of Servlet 2.2. Anything else would not make sense. The numbering (3.2, 3.3) does not matter. You will find that the 3.3 tree is pretty nearly as big an architectural change (from 3.2) as is 4.0 (rather than just being maintenance / bug fixes like the Apache 1.3 / 2.0 example) ... but it's still academic because no one seems to want to finish what they started. If that is the case (ANY architectural changes), I agree with you, Craig. That is IMHO a 'bad idea'. Tomcat 3.x should really just be fixing enough of the code to conform to the spec. Scott Sanders - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Tomcat 3.3 / 4.0 confusion, rant and plan...
Some non-committer 2c here from me. Both of these things... From Nick: 1) The fact that there are smart software developers out there contributing to Tomcat 3.x codebase and not necessarily contributing to the 4.0 codebase is a failure of the Jakarta Apache community to obtain sufficient buy-in from those people. The division of resources in this situation is what should be avoided at all cost, because this is the one major limitation OSS has: division of finite resources within a community because of forking. I would assume one of ASF goals is to prevent this. and from Scott: If that is the case (ANY architectural changes), I agree with you, Craig. That is IMHO a 'bad idea'. Tomcat 3.x should really just be fixing enough of the code to conform to the spec. I agree with, and it sounds like a vote is in order. Besides, I feel better when everyone plays together =) But irrespective of the outcome, and I think Craig agrees or else he wouldn't be doing what he's doing right now; Tomcat 3.2 should be out-the-door asap. - r - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Tomcat 3.3 / 4.0 confusion, rant and plan...
Everyone wants a TC3.2 -- I believe the only major concerns over the past couple weeks have been expressed in this snippet from a week ago: - snip - It seemed that the last outstanding issue was the compilation under JDK 1.1, but that should be fixed now. So is there still something that needs to be fixed ? I would really appreciate if the release could happen within the next few days. Thanks Petr session/cookie and other patches (date spinlock and one more i think) have not been integrated...can someone dump em in and release b7 or final ? -Ys- [EMAIL PROTECTED] - snip - We should make sure anything major such as this has been integrated. Let us debate the necessity of 3.3 (or at least something to fix 3.2 bugs) after 3.2 Final is released. But I believe there is a definite demand for something to replace JServ in *production* environments *right now*, and that requires active bug-fixing development. That probably also points to Tomcat 3.2.x or 3.3, 3.x... Thanks, Michael Percy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 3.3 / 4.0 confusion, rant and plan...
That's a very interesting discussion, I certainly learned a lot from it. So, tomcat3.3 is confusing and shouldn't be called tomcat because catalina is tomcat. And while tomcat3.2 was ok, and nobody complained that the performance increased several times and a lot of features were added, for tomcat3.3 it's no longer permitted to add features, but only bug fixes ? I don't get it - so servlet2.3 is "reserved" for catalina, and no other container is allowed to implement it? Or at least not tomcat ? While it was ok for catalina to implement 2.2 ? And while it was ok to add features for 3.2, I can't do that for 3.3? Regardless if those features are useful or not, or if _USERS_ will benefit from that, and more importantly - I'm not asking for features but willing to implement them myself ? So if I'll implement a servlet2.3 facade for tomcat3.3 - I'll not be able to release it or check it in ? Can I still use my own home page or a public web site ? Regarding the 3.2 - there is no critical bug in 3.2 AFAIK, or at least watchdog passes and 3.2 doesn't seem to crash or behave worse than 3.1. After I finish with the big changes ( required to support charsets and performance ) I'll start fixing the remaining bugs. So far it seems everyone is certain about how bad 3.3 is and how good 4.0 is, and you may be right - but I do hope that you spent the required time to understand both. To be honest, starting a revolution seems the best thing for me - the precedent is already set, I'll no longer have to follow the "JDK1.1 compatible" rule, no need to support or worry about backward compatibility, and all the freedom I need. I can also follow Craig's request and move it outside of Apache. That would mean I ( as a developer spending free hours on the project ) will be able to write code without worry about the politics and ASF members and PMCs and all the upper management. I'll think about all this, but one thing is certain - I'm very disappointed with what happens here. Costing - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Tomcat 3.3 / 4.0 confusion, rant and plan...
Costin is an avid developer devoted to this project and technology, and you are fools to lose him and fork the project. I think it is possible that many contributors (present and potential future) will follow him. He is one of the few major contributors not employed by Sun. I don't see why there cannot be a compromise in this matter to avoid project forking... what, truly, are the alternatives? Nothing good. And what is the real agenda here, anyway... Mike - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 3.3 / 4.0 confusion, rant and plan...
Michael Percy [EMAIL PROTECTED] wrote: Costin is an avid developer devoted to this project and technology, and you are fools to lose him and fork the project. Costin is a great guy, I have nothing personal against him... I was so happy when he got his green card last week because I consider him as a friend, first. But that doesn't mean that we have different ideas on many topics. [...] He is one of the few major contributors not employed by Sun. Err... Have you ever tried sending emails to [EMAIL PROTECTED] ? Pier - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 3.3 / 4.0 confusion, rant and plan...
The problem of the division of finite resources remains. Costin, would you consider bringing your brains into the 4.0 tree? Is 3.3 that good that it should weigh in _against_ (as a competeing implementation) 4.0? Pier, Craig, have you done all you can to get Costin "on-board" with 4.0? I just feel it a shame that Costin has this obvious empassioned pride of ownership in Tomcat and is sort of getting punished for it. I'm not saying it's malice, but it does seem somewhat insensitive. On Sat, 4 Nov 2000, Pier P. Fumagalli wrote: Michael Percy [EMAIL PROTECTED] wrote: Costin is an avid developer devoted to this project and technology, and you are fools to lose him and fork the project. Costin is a great guy, I have nothing personal against him... I was so happy when he got his green card last week because I consider him as a friend, first. But that doesn't mean that we have different ideas on many topics. [...] He is one of the few major contributors not employed by Sun. Err... Have you ever tried sending emails to [EMAIL PROTECTED] ? Pier - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Nicolaus Bauman Software Engineer Simplexity Systems - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 3.3 / 4.0 confusion, rant and plan...
What about this: - I start a new revolution in tomcat3.2 space ( proposals/something ), and all the implementation of 2.3 and all controversial stuff will go there ( i.e. all new features, like dav, http1.1, resource caching, the new SMTP and POP3 protocols - since any feature will be in fact just an interceptor plus the implementation itself ) - in tomcat3.3 we'll only have bug fixes, no other features. Tomcat3.3 will continue to be servlet2.2/jsp1.1, etc If the "revolution" rules still apply ( and I hope this is the case), there is no "vote" or procedure for revolutions, and any developer is free to work on whatever he likes. My preference is ( as you know ) to continue with the current stable codebase. That will be ( hopefully ) the last time we have this problem - I don't think we'll need any core change after 3.3 ( the code is very small now, and almost all work is delegated to modules - so it's very little that may change ). After that we can follow the 3.3.1, etc - again, only bug fixes. IMHO it's a decent proposal - I'll try to think of a name ( or names ) for the new "module-revolutions" - and everyone should be happy ( with some bad memories, maybe ). That will also allow to take more agressive steps in improving tomcat3 ( since the "revolution" branch will be less visible and the pressure will be lower ). It's cool to be revolutionar ( even if I still believe evolution is the way to go). Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 3.3 / 4.0 confusion, rant and plan...
"Pier P. Fumagalli" wrote: Hans Bergsten [EMAIL PROTECTED] wrote: "Pier P. Fumagalli" wrote: Sorry for starting what it might end up as a long flamewar, but reading almost 500 emails on the list I ended up a little confused... Also, in a bunch of side discussions, but related always to the same topic, I feel there's something wrong going around here... Thanks Pier for bringing this issue to a vote. Based on the other replies to this mail, it seems to me like the majority wants Tomcat 3.x to be the RI for Servlet 2.2/JSP 1.1, with production quality of course, and Tomcat 4.x the RI for Servlet 2.3/JSP 1.2. That's what makes most sense to me. The devil may be in the details, but I hope we can make it so. James might be an "instigator", but I'm for sure _THE_ "troublemaker" :) :) I fully agree with you on that. Let me explain better my position: ;-) I have NOTHING against a Tomcat 3.3 release, if we want to call it 3.3. The thing I am against is having two different releases of "Tomcat" (3.3 and 4.0) having the same features and capabilities... We're in total agreement on this. [...] Servlet 2.0? Apache JServ (Actually, we might end up moving it to Jakarta as an "historic" piece of code when Java.Apache.ORG dies) Servlet 2.1? (fuck, we don't have it, any volunteer?) Servlet 2.2/JSP 1.1? Tomcat 3.x (3.2, 3.3, 3.4, 3.5 and so on, as long as there's people willing to deveop it) Servlet 2.3/JSP 1.2? Tomcat 4.x Servlet NEXT? When they come out, we'll see what we have in our hands and we'll decide This _IS_ clear Right. Hans -- Hans Bergsten [EMAIL PROTECTED] Gefion Software http://www.gefionsoftware.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 3.3 / 4.0 confusion, rant and plan...
[EMAIL PROTECTED] wrote: What about this: - I start a new revolution in tomcat3.2 space ( proposals/something ), and all the implementation of 2.3 and all controversial stuff will go there ( i.e. all new features, like dav, http1.1, resource caching, the new SMTP and POP3 protocols - since any feature will be in fact just an interceptor plus the implementation itself ) Okay, if you feel strongly about not working with the Tomcat 4.x code base. This revolution branch would, however, not change the decision to use the Tomcat 4.x code base for Servlet 2.3/JSP 1.2. The earliest it could be considered would be for the next version of the specs. - in tomcat3.3 we'll only have bug fixes, no other features. Tomcat3.3 will continue to be servlet2.2/jsp1.1, etc Agree. If the "revolution" rules still apply ( and I hope this is the case), there is no "vote" or procedure for revolutions, and any developer is free to work on whatever he likes. My preference is ( as you know ) to continue with the current stable codebase. I've noticed ;-) I'm okay with another revolution branch, as long as we're clear about which spec versions Tomcat 3.x and Tomcat 4.x supports. [...] It's cool to be revolutionar ( even if I still believe evolution is the way to go). Sometimes evolution just doesn't work ;-) Anyway, if this makes everyone happy, I'm all for it. Hans -- Hans Bergsten [EMAIL PROTECTED] Gefion Software http://www.gefionsoftware.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 3.3 / 4.0 confusion, rant and plan...
Pier P. Fumagalli wrote: If you want to go on and make a 3.3, do it, but if you want to implement Servlet 2.3 in that release, you'll get my -1... Whether I personally agree with 3.x design or not, as an ASF member myself, I believe that it is important to protect Costin's right to pursue it. It was not terribly long ago that what became Catalina was controversial. - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 3.3 / 4.0 confusion, rant and plan...
- Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, November 04, 2000 4:27 PM Subject: Re: Tomcat 3.3 / 4.0 confusion, rant and plan... And why not: Servlet2.0 - Tocmat3.3 Servlet2.1 - Tomcat3.3 Servlet2.2 - Tomcat3.3 Servlet2.3 - Tomcat3.3 Servlet.next - Tomcat3.3 I don't agree. Having : Servlet2.0 - TocmatNext Servlet2.1 - TomcatNext Servlet2.2 - TomcatNext Servlet2.3 - TomcatNext Servlet.next - TomcatNext is very fine. I don't think people want anything but bug fixes (and perhaps a few more features) for Tomcat 3.2 and eventually 3.3. And even: "I have old servlet2.2 apps, and some new servlet3.0 apps, and there are some incompatibilities between 3.0 servlet API and 2.2, what can I do ? " - Tomcat3.3 Anyway, I'll be more than happy to remove the 2.3 facade from tomcat2.2 if that it's your concern. But I don't think you can stop me ( or someone else ) from implementing a 3.x Interceptor that plugs in a 2.3 ( or Servlet.Next ) into tomcat. If the rules for "revolution" are still accepted, I'll do that in a /proposal tree, if not - I'll do it on my home page. I think it's the right thing to do, instead of rewriting everything again and again. I think that would be the best. Now, a few points : - The main branch in the jakarta-tomcat tree is broken, and is also a bug mess right now. I think it needs to be fixed so that it complies more with the objectives set for TC3.3. - If it was possible to avoid code duplication for as many components as possible it would be great ;) Fixes / improvements are really hard to merge otherwise. Since I think the main point of disagreement is the servlet engine core, that should be doable. That's the main issue here, and that's what I think it's wrong in your table - the code should be reusable, and supporting multiple facades is not only easy, but it's important for future. Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 3.3 / 4.0 confusion, rant and plan...
- I start a new revolution in tomcat3.2 space ( proposals/something ), and all the implementation of 2.3 and all controversial stuff will go there ( i.e. all new features, like dav, http1.1, resource caching, the new SMTP and POP3 protocols - since any feature will be in fact just an interceptor plus the implementation itself ) Okay, if you feel strongly about not working with the Tomcat 4.x code base. This revolution branch would, however, not change the decision to use the Tomcat 4.x code base for Servlet 2.3/JSP 1.2. The earliest it could be considered would be for the next version of the specs. Well, if it's a revolution it can implement anything - including 2.3. It's not going to be the "RI", of course. Again, support for 2.3 is just an independent module that doesn't have to be included in the default distribution. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Tomcat 3.3 / 4.0 confusion, rant and plan...
I have been a long-time silent listener on this list, and use Tomcat 3.1 in a production environment. I have been greatly appreciative of the hard work gone into the software to date, and respect that its development is on a volunteer basis. But I fully concur with the sentiments of this posting - for the past couple of months it's been completely unclear as what the development path and release schedule for Tomcat looks like (3.2?, 3.3?, 4.0?). I would like to continue to use Tomcat, and eventually have time to get more involved in its development, but the lack of any obvious plan and schedule leaves companies like ours considering whether we need to fall back to commercial offerings to get any kind of reliability or accountability for the direction of releases. Again, I respect that the basis of this project is volunteer-driven, but it is possible to get a balance between the democratic impulses of OSS and a more rigorous project management approach to 'deliverables'? Regards, Liam Magee. -Original Message- From: Pier P. Fumagalli [mailto:[EMAIL PROTECTED]] Sent: Saturday, 4 November 2000 4:27 PM To: [EMAIL PROTECTED] Subject: Tomcat 3.3 / 4.0 confusion, rant and plan... Sorry for starting what it might end up as a long flamewar, but reading almost 500 emails on the list I ended up a little confused... Also, in a bunch of side discussions, but related always to the same topic, I feel there's something wrong going around here... Question: WHAT THE HACK IS TOMCAT 3.3 ??? I believe that this developer community once agreed that Tomcat 4.0 _will_be_ the next major release of the Apache Software Foundation servlet engine, but, since a couple of weeks, I see a proliferation of emails talking about Tomcat 3.3. Here is where I'm getting confused... When did we vote about having a dual codebase for two different servlet engines at the same time??? Because I've never seen such a discussion taking place... Also, it seems ridiculous (at least to me) to start talking about what will be the next release of the 3.x tree (3.3) when 3.2 is not yet out of the door, and as far as I've read (but I might have missed some emails) Beta-6 is not even compiling... Sorry, but as a long time ASF member, and one of the first kids involved in the glorious JServ, I feel that things here are getting a little bit screwed up. Are we going to screw our release cycles? Are we going out to the public with TWO servlet engines equal in features, but different in codebases? Are we all going NUTS? Sorry again, but this time I have to vote -1 on a "new" Tomcat 3.3, expecially before 3.2 final is out of the door. The NEXT major release is going to be Tomcat 4.0, based on Catalina, as we all agreed on months ago. But, I'm not _only_ a pain in the ass... I see there are some developers who prefer to work on the 3.x tree, rather than helping out on the 4.0, so, instead of cutting their wings and forcing them to fork the project, I propose to them what was proposed to Craig in february. The "Rules for Evolution and Revolutions" still stands still, as one of the major constitution documents for this community (James, WTF, post it somewhere!!! :) and IMNSHO needs to be used... I suggest to whoever is interested in further developement of the 3.3 tree to create a new proposal, as Craig did with Catalina, and stick it on the "proposals" directory in the CVS. And start working from it. I'm more than open to see, after Tomcat 4.0 sees light, to reconsider the effort, and maybe switching codebase again for what will be Tomcat 5.0. So, I'm proposing this plan, and please vote on 2 and 4 (1 and 3 were already voted upon with a bunch of +1s)... 1) Release Tomcat 3.2 final (soon, please!) 2) Create a new proposal tree alongside with Catalina (new name to avoid confusion, please) 3) Release Tomcat 4.0 (with Catalina, as we all decided) 4) Decide wether Tomcat 5.0 will be Catalina based or "whatever" new proposal comes along. My 0.02 $... Take care... Pier - 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]
