RE: [VOTE] Committer Status for Marc Saegesser (was: Re: 3.x subm itters [was RE: [MY_OPINION] Tomcat 3.x])
+1 "Pour la plupart des hommes, se corriger consiste à changer de défauts." -- Voltaire
Commiters WHO and WHERE
Hi to all commiters, Many new commiters these days came with christmas. After all the noise about TC 3.3, It could be nice to know where each commiter (oldies and newbies) plan to works : There is still now, 3 projects (Sorry jon ;-) : TOMCAT 3.2: TOMCAT 3.3: TOMCAT 4.0: Could each commiter add itself on projects he will contribute and indicate on which parts : In my case : TOMCAT 3.2: RPM packaging, mod_jk, ajp12/ajp13, ssl stuff doc, french localization TOMCAT 3.3: RPM packaging, mod_jk, ajp12/ajp13, ssl stuff doc, french localization TOMCAT 4.0: RPM packaging, mod_webapp, ssl stuff doc, french localization This will clarify certainly who do what. May be we will discover there is sufficiant resource to keep support on 3.2, 3.3 and 4.0. I'll stats answers and give a daily report.
Re: [MY_OPINION] Tomcat 3.x
Sam Ruby [EMAIL PROTECTED] wrote: GOMEZ Henri wrote: I remember the hard discution about spinaker on xerces mailing-list and IBM became more open after Sun position. But in the Tomcat case we have Sun on one side and individuals on the others. Not really the same condition. Hello Sam ?-) Tomcat 3.0 was clearly a Sun project. Most of the design discussions were held in conference rooms in Sun. The release was made with virtually no prior discussion on the mailing list (remember sideswiped?). And we, as the newly formed Apache Software Foundation, accepted that code in donation as a point of start for the Jakarta Project. I was there, in that meeting room, that day when we outlined how the process would have evolved, with Jon, Stefano and Brian. And I was there, on stage at JavaONE, when Patricia Sueltz announced the spinoff of the project againg with Jon, Stefano and Brian. If that has been a wrong decision, we four are the people to blame... Fairly or unfairly, a number of Sun people felt excluded from participating in Xerces. That's a slightly different thing, but again is not Sun or IBM to blame, is the people behind that thing (oh shit, I'm one of them! Again!) None of this is the case for any current release of Tomcat. In particular, I personally do not feel like I am being denied an opportunity to contribute to Tomcat 3.2.2, 3.3, or 4.0. And let's consider that Catalina is the good old Apache-JServ 2.0 who was never released... I believe that for all of us who started this thing Catalina is our little child. At that time none of us were paid to work on Servlet Engines, what happened later has a very small relevance... Yes, many of the people working on Catalina are employed by Sun. Arguably, in many cases (including Craig), they are employed by Sun because they work on Catalina, not the other way around. Yes, I now work at Sun, and let me tell you guys, it's fucking fun. I'm not working there because I like Sun, or I'm a Sun fanatic. Yes, I use Solaris, but I'd rather work at Apple if it was for my preference. They were simply the right kids with the right offer at the right time... Can you blame Sun for that? I can't, they saved my butt as an Open Source developer, paying me to work on what I wanted to (shit, why Apple is not interested in Tomcat?) And let me tell you that hiring me and Craig was probably their worst mistake, as we don't shut up and say "yes" to whatever our managers say. Actually, it's all the way around, we make so much noise that Jim sometimes hates us :) :) We're open source developers first... Pier -- Pier Fumagalli http://www.betaversion.org/ mailto:[EMAIL PROTECTED]
Re: [MY_OPINION] Tomcat 3.x
Jon Stevens [EMAIL PROTECTED] wrote: on 12/19/2000 10:48 AM, "Larry Isaacs" [EMAIL PROTECTED] wrote: If Tomcat 3.3 can prove it is as stable as Tomcat 3.2.x and is more spec compliant than 3.2.x, Why does it have to be called Tomcat 3.3? Why not Tomcat 3.2.x+1? Because it's architecture is so much different from 3.2 :) I think it would be a disservice to not release it as the final RI for Servlet 2.2/JSP 1.1. I'm not suggesting that we not release it. If the architecture doesn't change, neither do I :) Pier -- Pier Fumagalli http://www.betaversion.org/ mailto:[EMAIL PROTECTED]
Re: Fuck It.
Jon Stevens [EMAIL PROTECTED] wrote: To: Costin and the rest of you who commented. You obviously know what is best and have shown me that I simply have my head up my ass and I'm just a complete jerk and I should stop now and just let you do whatever you want. I give up. All of my previous -1 votes are now +1. Have fun. It's sad, my friend, to see you giving up like this. We've traveled a long way together, from my very first steps in open-source land in January 1998, to our marvelous meeting at the first ApacheCON in October 1998, the Jakarta room meeting, all JavaONEs, and all we did together to bring this project where it is right now. It's sad, because you are the real light who guided my path from Italy to here, from being a nobody to be somehow recognized by this community. And it's even worse because you are FUCKING RIGHT! It makes me puke to read comments like the one that James Cook sent "My personal impression of you is in the toilet now", or Gomez Henri "IBM == xml.apache.org and SUN == jakarta.apache.org". Where were you KIDS when we were fighting the big corporations to have them looking into open source, to contribute significant parts of their technologies to the Foundation, where were you while we were changing this world? You were home, and one day, you looked up on your browser, saw a thing called Jakarta and started weening if things weren't as nice as you wanted them. Now, I believe that _I_ deserve some respect, and even if all your comments were not directly targeted to me, they hurt as if they were. Jon, you might be annoying and obnoxious at times, but those kids don't even care about reading what you're writing... What do I see? A fucking mess, and help me God, because now I'm not shutting up until this whole shit is solved. Let's start from the always recurring problem, Tomcat 3.3: I'm so glad to hear that people like Paul Frieden (the only person that did put some salt in what he said) are using Tomcat 3.2 in their products. That makes me feel alive, that makes the work we made in the last three year worth something. You're completely right Paul. I don't want you to loose one single cent of your investment. Being a member of the ASF, you have my personal warranty that it won't happen. I'm not asking to drop any kind of support from the 3.x tree, neither to close the bug-fixing process. But let's see what is _exactly_ happening: from what I see in the commit messages, it seems to me that even if on an evolutionary track, the container structure is completely different between 3.2 and 3.3. The architecture is almost as different as 3.2 and 4.0. What does it mean? That if you, Paul, are going to pick up 3.3 as your next servlet engine, you will probably have to fight with more or less the same quantity of issues you would have to deal with if you picked up 4.0. So, here we are: bugs... Let's see a little bit what's happening in the 3.x tree. Who is actually FIXING the 3.2 bugs and trying to get a better container on the old architecture? Not certainly Costin, Nacho or the others, they are all so busy in rearchitecting the container, and back-porting features from 4.0 that they don't have time to maintain the old codebase. Kudos go to Craig, and his team (apart from me, since I'm working on other sides of the code in 4.0) to find those bugs and fix them. And of course he's doing that while he's trying to get 4.0 out of the door. Sorry Costin, but I feel betrayed by you. Two weeks ago we had a pleasant conversation in your office, and I was looking straight to your face when you told me that 3.3 would have been a bug-fix and performance only update of 3.2. This is not what's happening. You're not fixing them, you're re-architecting a new container on the ashes of 3.2, but you are not doing what you promised ME, you're not supporting your baby... You're going against what we decided and agreed upon. You are loosing my respect, my friend... So, here I stand, my vote is a big -1 on a 3.3 as a newly architected servlet container, +1 on fixing bugs on 3.2 (actually 3.2.1 since Craig excellently pulled out all those security issues), +1 on improving performances on 3.2.1 (and I don't care if it's going to be called 3.2.2, 3.3 or 3.9, fuck release numbers on 3.x) and a big +1 on Catalina as the base servlet container for 4.0 no matter what this is our future, whether you like it or not. All other containers, please wait for a 5.0. And for once, so, my votes are in disagreement with you, Jon... :) As one of the people behind the scenes since before each of you got here, I believe my vote counts, and now, please prove me wrong. Pier -- Pier Fumagalli http://www.betaversion.org/ mailto:[EMAIL PROTECTED]
RE: [MY_OPINION] Tomcat 3.x
And we, as the newly formed Apache Software Foundation, accepted that code in donation as a point of start for the Jakarta Project. I was there, in that meeting room, that day when we outlined how the process would have evolved, with Jon, Stefano and Brian. And I was there, on stage at JavaONE, when Patricia Sueltz announced the spinoff of the project againg with Jon, Stefano and Brian. If that has been a wrong decision, we four are the people to blame... Please, nobody is to blame. You and others have made Tomcat a credible alternative to PRODUCTS like WebSphere or WebLogic. Sun give code to the Apache Foundation and whatever the original code was (design, coding, ...) you have made it involving and it's certainly better now that before. None of this is the case for any current release of Tomcat. In particular, I personally do not feel like I am being denied an opportunity to contribute to Tomcat 3.2.2, 3.3, or 4.0. And let's consider that Catalina is the good old Apache-JServ 2.0 who was never released... I believe that for all of us who started this thing Catalina is our little child. At that time none of us were paid to work on Servlet Engines, what happened later has a very small relevance... Nobody say that Cataline/JServ2 is a bad piece of software. The original thread as derived since I and others 3.x commiters just want to see Tomcat 3.3 code to be evolution of 3.2. I never say that TC 3.3 is better than TC 4.0/JServ 2.0, I just say that TC 3.3 is much more easier to understand than 3.2 and since it didn't require a JDK 1.2, it will be much more suited for low end configuration. Costin (certainly an old assembler hacker) have done a great job in optimizing many area of the code. It will be a pitty to see this works trashed. Yes, I now work at Sun, and let me tell you guys, it's fucking fun. I'm not working there because I like Sun, or I'm a Sun fanatic. Yes, I use Solaris, but I'd rather work at Apple if it was for my preference. They were simply the right kids with the right offer at the right time... Can you blame Sun for that? I can't, they saved my butt as an Open Source developer, paying me to work on what I wanted to (shit, why Apple is not interested in Tomcat?) Sun has hired the right developpers for the right project. May be OpenSource will became also a good way for corporations to detect talentuous peoples. The question is not why didn't Apple contact you but why didn't IBM or WebLogic didn't try to hire you ;-))) And let me tell you that hiring me and Craig was probably their worst mistake, as we don't shut up and say "yes" to whatever our managers say. Actually, it's all the way around, we make so much noise that Jim sometimes hates us :) :) We're open source developers first... When you hire in a cooporation an OpenSource fellow, you hire more than one developper, you hire a community ;-) At least IBM and Sun have understood that. I hope that will be the end of this thread. But as a side effect I notice that many people offers to help on TC 3.2 or 3.3, and some goes commiters. Long life to Apache Foundation. Merry Christmas and an Happy New Year to all of you ;-)
Re: Fuck It.
Nicely put
Re: Tomcat 3.3
Hello, I've been reading both this and the dev list for about a month and asking/answering the more well put user questions (meaning I don't do to well on the ones that just say "Tomcat 3.x.x doesn't work on linux) and nothing else). I'd like to contribute to a tomcat, but since there are three of them I'm not horribly sure where to start. I know 4.0 is a rearchitecture and 3.2.x is basically the old architecture, and that 3.3 is probably less supported than 4.0 (in that sun will probably package 4.0 in the next major j2ee). But, that being the case (and I know I'm touching on a sore spot) what will be the lifespan of 3.3. There've been a few messages on this subject but all of them were a bit too hotheaded for me to gain the information I desired from them. I know this is somewhat of a partisan issue and the lines have been drawn, but just delving in I'd guess 3.2.x would probably not be the best place to start (even though I'm using it) as being unfamiliar with the code and it being supposidly "the worst" code of the 3, I'd probably learn it in time to see it go out of fashion (though I'm guessing, without a real idea what the planned lifespan is). I'm guessing 4.0 might be a bit hard to get into as I picture the major decisions being made in a sun boardroom somewhere in cupertino where i'd not have the time to make it to and probably wouldn't be invited anyhow... But is 3.3 going to have a long enough lifespan to make it worth my while? Is help needed there? I probably prefer to start out with bug fixes as its easier to get into "if you do this than this breaks". So some direction (preferrably without the partisan slant) would be very helpful. Thanks, Andy __ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://im.yahoo.com
RE: Fuck It.
And it's even worse because you are FUCKING RIGHT! It makes me puke to read comments like the one that James Cook sent "My personal impression of you is in the toilet now", or Gomez Henri "IBM == xml.apache.org and SUN == jakarta.apache.org". Where were you KIDS when we were fighting the big corporations to have them looking into open source, to contribute significant parts of their technologies to the Foundation, where were you while we were changing this world? You were home, and one day, you looked up on your browser, saw a thing called Jakarta and started weening if things weren't as nice as you wanted them. I sent a couple of hours a mail about commenting TC3 and TC4/JServ2 and all the thanks for you to have provided such an alternative. But the mail arrived just too late, and get back flame on us. I couldn't speak for others but I'm just 35 years old and in OpenSource for at least 6 years. I started to help in both coding and lobbying for OpenSource use when a co-worker (died now) René Cougnenc (a friend of Remy Card ext2 creator) went at job to install on a Dell 486sx25, five disks with a pre 0.98 Linux system. The alpha networking code crashed our Sun's network and we have to take a look in source to locate the problem. Since that time I promoted OpenSource products in all the companies I worked for. I've done that for Linux, GCC, PERL and Apache HTTP server. Just to note that I'm not really a kid and that I've done my part of job in pushing the OpenSource concept. Thanks to my actual employeer (SLIB), I could even spend time during my job to package some RPMs to help others users (everyone is not a developper) to install and discovers many OpenSourced products (from jakarta.apache.org, xml.apache.org or others). Because I think that OpenSource will gain much more users with easy to use packaged solutions than with great design and coding. That's my VISION. You could take a look at ftp://ftp.falsehope.com/home/gomez/ to see what I've done on packaging. Let's start from the always recurring problem, Tomcat 3.3: I'm so glad to hear that people like Paul Frieden (the only person that did put some salt in what he said) are using Tomcat 3.2 in their products. That makes me feel alive, that makes the work we made in the last three year worth something. I also use Tomcat 3.2 on production servers. I use it since the first M1. So when I'm worried about production, deployement, memory conso, I speak d'experience. You're completely right Paul. I don't want you to loose one single cent of your investment. Being a member of the ASF, you have my personal warranty that it won't happen. I'm not asking to drop any kind of support from the 3.x tree, neither to close the bug-fixing process. But let's see what is _exactly_ happening: from what I see in the commit messages, it seems to me that even if on an evolutionary track, the container structure is completely different between 3.2 and 3.3. The architecture is almost as different as 3.2 and 4.0. What does it mean? That if you, Paul, are going to pick up 3.3 as your next servlet engine, you will probably have to fight with more or less the same quantity of issues you would have to deal with if you picked up 4.0. I hope to see 3.2 tree maintened for some times. It's the reason why I switched for ApacheJserv to 3.2M1 after a little step by the now dead Tomcat 3.1. So, here we are: bugs... Let's see a little bit what's happening in the 3.x tree. Who is actually FIXING the 3.2 bugs and trying to get a better container on the old architecture? Not certainly Costin, Nacho or the others, they are all so busy in rearchitecting the container, and back-porting features from 4.0 that they don't have time to maintain the old codebase. Sorry but all my recent commits were for the 3.2 base. I even adapt some patches from 3.3 source tree (ajp). I add french localized messages to 3.2 but still not to 3.3. Kudos go to Craig, and his team (apart from me, since I'm working on other sides of the code in 4.0) to find those bugs and fix them. And of course he's doing that while he's trying to get 4.0 out of the door. You could note that I also package RPM for Tomcat 4.0 even if the build is told so complex. I spend time on that project too. Sorry Costin, but I feel betrayed by you. Two weeks ago we had a pleasant conversation in your office, and I was looking straight to your face when you told me that 3.3 would have been a bug-fix and performance only update of 3.2. This is not what's happening. You're not fixing them, you're re-architecting a new container on the ashes of 3.2, but you are not doing what you promised ME, you're not supporting your baby... You're going against what we decided and agreed upon. You are loosing my respect, my friend... I'm sorry to see two friends in such situation for a piece of code. Catalina is your baby, TC 3.3 is Costin baby why couldn't you find a way to consiliate the 2 babies. I'm
RE: Fuck It.
Gomez Henri wrote: The future of Tomcat 3.3 seems to be outside Apache now. It's really sad. As Pier recently said on another mailing list "You can't stop open source developers...". Is this really what everybody wants? I'm sure it could be made to happen. And quickly upgraded to the latest servletapi. And gather a substantial following. Obviously a fork is a nightmare scenario. It is an ironic twist. One has to wonder if such a fork is inevitable. Not for any technical reason. But rather because those that worked so hard to create the place where everyone was to come together have become intolerant of exactly the spirit that makes open source successful. Innovation. Exploration. Revolution. And, yes, dead ends. My recommendation: put your energies into the proposal that most gets your juices flowing. Keep the discussion to the technical merits. I propose to commiters to vote to drop my COMMITER STATUS. Note to other PMC/ASF members - we should probably institute a mandatory 48 hour cooling off period before requests such as the one above are considered. - Sam Ruby
RE: ajp13 evolution or ajp14
Way back to technic ;-) Great too see that. May be the last time :-( I think Dan is the authority in this, but I'll add my 2c anyway. - it's not a bad idea - as long as it's an option That's could be a secured ajp13 or ajp14 ?-) - maybe there are ways to do it without too much code change - you can use tunnels ( and you can get that done even in hardware ). Cryptography is slow and hard to implement it the right way, so I would rather prefer to use existing solutions. I used such solutions with ssh tunnels (like CVS at apache.org) but I really like to have a built-in solution. I know also a little SSL since I produced sometimes ago the SSL Proxy jonama (http://www.multimania.com/jonama/), but SSL is just too slow at conect time and SSH is also a little too hard. I was thinking a more simple algorithm, ie: DES with known keys. But there is a great SSH job in Java done by mindterm (http://www.mindbright.se/mindterm/) and also fine crypto (www.cryptix.org) - Having a group of URLs sent over a different protocol is certainly a good thing ( for example you could have the encrypted tunnel on a different port ) - and should be coordinated with the load balancing stuff ( where it can also be usefull) Yep... - BTW, SSH or SSL tunnels are very easy to set and available to most people. Yes but it is an out of the box solution. I really like having a integrated solution. - Proably the best contribution to resolve this problem will not be code added to mod_jk, but a documentation describing how to do that with available tools, and maybe some way to automate it. Easy under Redhat boxes, with some OpenSSL and OpenSSH RPM. May be later I could send some doc about ?
[Fwd: Tomcat 3.3]
Hello, I've been reading both this and the dev list for about a month and asking/answering the more well put user questions (meaning I don't do to well on the ones that just say "Tomcat 3.x.x doesn't work on linux) and nothing else). I'd like to contribute to a tomcat, but since there are three of them I'm not horribly sure where to start. I know 4.0 is a rearchitecture and 3.2.x is basically the old architecture, and that 3.3 is probably less supported than 4.0 (in that sun will probably package 4.0 in the next major j2ee). But, that being the case (and I know I'm touching on a sore spot) what will be the lifespan of 3.3. There've been a few messages on this subject but all of them were a bit too hotheaded for me to gain the information I desired from them. I know this is somewhat of a partisan issue and the lines have been drawn, but just delving in I'd guess 3.2.x would probably not be the best place to start (even though I'm using it) as being unfamiliar with the code and it being supposidly "the worst" code of the 3, I'd probably learn it in time to see it go out of fashion (though I'm guessing, without a real idea what the planned lifespan is). I'm guessing 4.0 might be a bit hard to get into as I picture the major decisions being made in a sun boardroom somewhere in cupertino where i'd not have the time to make it to and probably wouldn't be invited anyhow... But is 3.3 going to have a long enough lifespan to make it worth my while? Is help needed there? I probably prefer to start out with bug fixes as its easier to get into "if you do this than this breaks". So some direction (preferrably without the partisan slant) would be very helpful. Thanks, Andy __ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://im.yahoo.com
Re: Fuck It.
they were. Jon, you might be annoying and obnoxious at times, but those kids don't even care about reading what you're writing... Too bad all this is on an open mailing list where the mails can be read again and again - and people may form their own opinions. _exactly_ happening: from what I see in the commit messages, it seems to me that even if on an evolutionary track, the container structure is completely different between 3.2 and 3.3. The architecture is almost as different as 3.2 and 4.0. It's sad that on this list so many people are experts in spinning facts and politics. This is a _false_ statement, or a gross misunderstanding of what "architecture" means and what "refactoring" means. The _architecture_, _ideas_ and _patterns_ in tomcat3 are the same - the code, code organization changed. I just had to deal with a major change in Apache2.0 - it seems some time ago they reorganized the whole tree, moved apr in a different repository, etc. Is this a different architecture ? And looking back to Apache1.3 - most of the concepts are still there - you have more flexibility with the hooks and mpms, but I hope you're not claiming that moving from 1.3 to 2.0 will be as hard as moving from Apache to IIS. And one more - Tomcat3.2 is also a refactoring of Tomcat3.1. Refactoring == improving code readability, better organization - same design. If tomcat3.2 is indeed "better" and user are well served by moving from 3.1 to 3.2 - the same will be true for 3.3 others, they are all so busy in rearchitecting the container, and back-porting features from 4.0 that they don't have time to maintain the old That's even worse - all the flames that start up whenever code from 4.0 is reused in 3.x. What's the problem ??? Are you afraid of "featurism" ( i.e. are good for 4.0 but bad for 3.3 ) ? It's open source code, and it's right to reuse it instead of reinventing the wheel. If someone writes a JAAS authenticator for 4.0 - why not making it available to 3.3 users too ? After all, if 4.0 is "better", that's because of the architecture, not because of the features - or else next spin will be that people should use 4.0 because of all the features. In any case, I made clear that all those "features" will not be checked into 3.3 - but on an external tomcat-contrib-like repository. This is not what's happening. You're not fixing them, you're re-architecting a new container on the ashes of 3.2, but you are not doing what you promised ME, you're not supporting your baby... Take a look at "changes" in tomcat 3.3. It's a description of all the "evolutions" from 3.2 to 3.3. Too bad I haven't done the same when I worked on 3.2. You can also take a look at commit messages - yes, some are big ( code moved around for better organization ), and some deprecated interfaces are removed ( is this an "architecutre change" ? They were introduced in 3.2, 3.1 or 3.0 to help refactoring, and "evolved" into something better ). Costin __ Do You Yahoo!? Yahoo! Shopping - Thousands of Stores. Millions of Products. http://shopping.yahoo.com/
RE: ajp13 evolution or ajp14
Way back to technic ;-) Great too see that. May be the last time :-( I hope not - it's great working with you :-) - it's not a bad idea - as long as it's an option That's could be a secured ajp13 or ajp14 ?-) AFAIK ajp13 can be extended in a backward-compatible way ( or at least it should be ) by adding new packet ids. I wouldn't mind an ajp14, mod_jk is based on the idea that there is no "perfect" protocol, but I would try first to extend 13 ( I'm not even sure if this is possible - if not then we need a 14). I used such solutions with ssh tunnels (like CVS at apache.org) but I really like to have a built-in solution. I know also a little SSL since I produced sometimes ago the SSL Proxy jonama (http://www.multimania.com/jonama/), but SSL is just too slow at conect time and SSH is also a little too hard. I'll take a look. I was thinking a more simple algorithm, ie: DES with known keys. AFAIK both SSL and SSH are using DES after the initial connection is set up ( or IDEA, or other symatrical alghoritm - some faster than DES ). Also ( based on 3-4 old memories ) you could extend both protocols with other encryption alghoritms. - BTW, SSH or SSL tunnels are very easy to set and available to most people. Yes but it is an out of the box solution. I really like having a integrated solution. Having it "bundled" with tomcat is very hard - encryption is allways a problem. Easy under Redhat boxes, with some OpenSSL and OpenSSH RPM. May be later I could send some doc about ? Check it in - as long as we are still commiters :-) Costin __ Do You Yahoo!? Yahoo! Shopping - Thousands of Stores. Millions of Products. http://shopping.yahoo.com/
RE: Fuck It.
tree. Who is actually FIXING the 3.2 bugs and trying to get a better container on the old architecture? Not certainly Costin, Nacho or the Please be carefull when you write something about anybody, have a look at commits please... Henri, P. Delisle and I are the only ones here that had contribute to ALL present versions of Tomcat, *ALL* dont forget that, and i feel involved on ALL of them, if this is a waste of my poor capacities , well no problem i do with my time what i want , i do not admit opinions on that.. You were kids, are kids, and will be kids, regardles of your age, if you continue playing with invaluable items as is the confidence of your people ( as i am like it or not, i'm in your side dont forget that ). And you are losting my confidence with every flame you put in public lists. We are all here for another reason that hear you scream. I'm too old ( 35 FYI ) to believe that the volume of your voice gives you more reason than i have, no. I believe that architecture of 3.3 is right one. Why we are not talking about that ? because there arent technical arguments against my believes ? are you truly sure that tomcat 4.0 is right when perfomace comes to discussion ? well i think this is the stuff that matters, and nobody can assure that until products mature and are compared in a controlled environment. It seems that putting this thread under technical glass i can not find any bit of technical arguments, i need to go at least 6 month back to read something techincal about it. Saludos , Ignacio J. Ortega
RE: Fuck It.
Correct me if I'm wrong, but maybe the whole focus of 3.3 / 3.2.x thing, is that neither of them will be all that they could be because the resources are so limited and divided. Of what value would enhancing JServ to the point of technical perfection, be right now when it is clearly not the direction things are headed? To me, if someone said, "i want to make all these great changes to JServ" I'd be like, "ok sure, but no one is going to use it since it's old school. Why not help out the people on 3.2.x or 4.0?" HOWEVER! 3.1 and 3.2.1 are being used by LOTS of people, so lots of people would benefit by releasing a killer 3.2.x or 3.3 or 3.9 as Pier puts it. In this regard, I can totally agree with the general idea of "making 3.2.x better!" But, and forgive me if everyone understands and realizes this, all of these changes will come at a price - namely slower development of the agreed-upon "future of Tomcat." If committers didn't think TC 4.0 was the future, and didn't want to work on, then why all of the +1s? As well, there will be less time for the necessary bug fixes and performance enhancements for the 3.2.x line, the introduction of even more bugs that are fixed even more slowly as more code is changed/added/removed. Sure "they will come in time" but will they? During all that time, I end up with a functionally-equivalent container that's more technically sound underneath, but with more bugs (because the old ones are there while all of the new changes were taking place, and the newly-introduced ones as well). So how is the user better off at the point that 3.2.x/3.x is released? So at the end of all of this, we have slowed development of 4.0 while we end up with a functionally equivalent container to 3.2.1, but with more bugs, and more people's time having to be spent fixing those bugs instead of contributing to 4.0, which I'm sure will be all the rage, as 3.2 is. This also goes back to a philosophical question - How many big "changes" (architectural or not) before someone is "happy" with the code? I worked with a developer who chronically rewrote the things he worked on "to get them perfect." As a result, he never progressed, continually outputting things that were functionally identical, just written differently. Do the end-users care? Nope. Even for a 5-10% performance enhancement? Who's to say... Anyways, just my 2c. I don't really care who does what or when or whatever, or how perfect the code is or what. "I want" a container NOW that has very little bugs, and works the way it should (adheres to the spec, etc.). Personally, I don't care if it's spaghetti or what, so long as when I install it, it's easy to configure, does what it should, and does it well. Yeah, and I think anyone who spends time contributing to open source, at work or not, is a Good Person(tm) =) So know that people everywhere, everyday, appreciate the efforts and expertise of people like Costin, Craig, Pier, Larry, Henri, Remy, Sam, Pottymouth-Jon =b, James, and I'm sorry I can't remember all of the committers off the top of my head. Good day, - Rob Slifka
RE: Fuck It.
On Thu, 21 Dec 2000, Rob S. wrote: Correct me if I'm wrong, but maybe the whole focus of 3.3 / 3.2.x thing, is that neither of them will be all that they could be because the resources are so limited and divided. Of what value would enhancing JServ to the point of technical perfection, be right now when it is clearly not the direction things are headed? To me, if someone said, "i want to make all these great changes to JServ" I'd be like, "ok sure, but no one is going to use it since it's old school. Why not help out the people on 3.2.x or 4.0?" HOWEVER! 3.1 and 3.2.1 are being used by LOTS of people, so lots of people would benefit by releasing a killer 3.2.x or 3.3 or 3.9 as Pier puts it. In this regard, I can totally agree with the general idea of "making 3.2.x better!" i second this. good,stable, bug free servlet engine now with load balancing - tomcat 3.2.x (equivalent to apache 1.3.x) development, future release servlet engine with sessions in permanent storage - tomcat 4.x (equiv. to apache 2.x) Merge the 3.3 code tree with 3.2 and make it better..dropping 3.3 is much better than struggling with a dead end tree/codebase and it will make 3.2.x better for all. Any project should have only ONE development path..just like linux 2.3.x-2.4.x and one stable like linux 2.2.x...any other simply wastest resources which arent available in the first place. -Ys- [EMAIL PROTECTED]
help for EJB
We are soft ware developers(Calrion systems (P)Ltd. , Cochin ,Kerala, India).Now we are developing application in EJB under weblogic server. We required to deploy the application (what we developed in EJB under weblogic server)in Tomcat server. Please give me a step by step Instructions for the deployment of EJB application in Tomcat server 1.Will tomcat server support EJB? 2. Is it required any additional support program, to support EJB in Tomcat,? Boby Michael
Tomcat 3.2.1 bug if not root-context defined.
Tomcat 3.2.1 fails to deliver a resource, if no root-context is defined in serverl.xml. If you do not define the root-context "" in server.xml and request a non-existing resource, Tomcat will loop forever in PrefixMapper.getLongestPrefixMatch() trying to find a Container for "". Bye, Klaus.
Re: Tomcat 3.2.1 bug if not root-context defined.
Hi Klaus, I ran into this as well and thought it was particular to the way that Tomcat is integrated with Enhydra. I think I have a fix for it. I'll try to get a patch together and post it soon. Shawn Klaus Friedel wrote: Tomcat 3.2.1 fails to deliver a resource, if no root-context is defined in serverl.xml. If you do not define the root-context "" in server.xml and request a non-existing resource, Tomcat will loop forever in PrefixMapper.getLongestPrefixMatch() trying to find a Container for "". Bye, Klaus. -- Shawn McMurdo mailto:[EMAIL PROTECTED] Lutris Technologieshttp://www.lutris.com Enhydra.Orghttp://www.enhydra.org
Re: How to do my own JSP processing
Christian Mallwitz wrote: Hi, I want to write a servlet that reads JSP files from somewhere outside the servlets web application context, compiles them to a location outside the servlets web application (if necessary) and then invokes the compiled servlet class. I started looking at org.apache.jasper.servlet.JspServlet for a start but it looks really messy. Besides the Jasper classes lack some documentation to put it mildly ... :-) What should I really look at and what things do I have to look out for? The result should work similar to using request dispatchers include() but with more control over it (especially response header generation, response buffering, etc.) Tag lib stuff should work seemless in all the pages. Sounds like you are planning on inventing your own variant of a servlet+JSP server, since you're wanting to change or ignore many of the spec requirements. And you will end up with an app that will only run in your own server. Unless you like building servers as a hobby, you've got a *lot* of hard work ahead of you. I would suggest you look at how you can architect your application *within* the requirements of the servlet and JSP specs. That way, you can focus on writing an app rather than a server, and have some assurance that you can run that app elsewhere if and when you outgrow Tomcat. Thanks Christian -- Christian Mallwitz INTERSHOP Communications Germany Senior Software Engineerphone: +49 3641 50 3453 Craig McClanahan
Re: Changes to the servletapi build.xml file
This is definitely the place ... thanks Sean! Jon Stevens has committed some changes to the servletapi build scripts. I will take a look and merge your ideas for anything he missed. Craig Sean wrote: I had to made changes to the build.xml file to get it to work with the latest version of any. I was not sure if this was the place to submit these changes. I have attached my modified build.xml file. It works great ... let me know if there are any problems or if this is the wrong forum to submit this. When I tried using the old one I got errors with the depreciated copyDir command that is used in it. Sean
Re: Tomcat 3.3
Andy wrote: But, that being the case (and I know I'm touching on a sore spot) what will be the lifespan of 3.3. Since a proposal to publish a "Tomcat 3.3" has never been formally presented and voted on, the only logically correct answer is "I don't know." Depending on the results of a vote, it could be anything from "it will never be released (as Tomcat -- the code is free for anyone to do what they want with)" to "live long and prosper". Given the current emotionally charged climate, I would not suggest that anyone propose a vote on 3.3 at the moment :-). [snip] I'm guessing 4.0 might be a bit hard to get into as I picture the major decisions being made in a sun boardroom somewhere in cupertino where i'd not have the time to make it to and probably wouldn't be invited anyhow... I'm guessing (well, not really -- it's pretty obvious :-) you haven't studied your history very well. For an interesting bit of background, you might go check out the CVS repository for Apache JServ at http://java.apache.org and select the branch labelled "JSERV1_1DEV". (Yes, it started before there was a 1.1 release of Apache JServ). Note the dates on those files (early to mid 1999, before the Sun contribution of Tomcat was announced). Go look at the source, and you will see the recognizable architecture that is Catalina (the servlet container part of Tomcat 4.0) today. For the record, Sun hired me in March, 2000, so that I could work on Tomcat full time instead of it just being a hobby (as it was when the original code was written). :-) Andy Craig McClanahan
Re: help for EJB
Boby Micheal wrote: We are soft ware developers(Calrion systems (P)Ltd. , Cochin ,Kerala, India).Now we are developing application in EJB under weblogic server. We requiredto deploy the application (what we developed in EJB under weblogic server)in Tomcat server. Please give me a step by step Instructions for the deployment ofEJB application in Tomcat server 1.Will tomcat server support EJB? No, not directly. 2. Is it required any additional support program, to support EJB in Tomcat,? Yes. You need to get either Enhydra Enterprise at http://www.enhydra.org or jBoss at http://www.jboss.org and then follow the appropriate directions. Shawn Boby Michael ?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" /> -- Shawn McMurdo mailto:[EMAIL PROTECTED] Lutris Technologies http://www.lutris.com Enhydra.Org http://www.enhydra.org
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: Fuck It.
"Pier P. Fumagalli" wrote: Where were you KIDS when we were fighting the big corporations to have them looking into open source, to contribute significant parts of their technologies to the Foundation, where were you while we were changing this world? You were home, and one day, you looked up on your browser, saw a thing called Jakarta and started weening if things weren't as nice as you wanted them. Nice. Now as a newcomer who wishes to give back to the community, do you think that this makes me feel more welcome or less? Why don't you just post a big sign that says, "If you were not here in the beginning, you are irrelevent. Go Away." That would probably be a slightly more effective means of keeping new developers away than simply making fun of them. Now, I believe that _I_ deserve some respect, and even if all your comments were not directly targeted to me, they hurt as if they were. Jon, you might be annoying and obnoxious at times, but those kids don't even care about reading what you're writing... I assume that I fall under that auspise since I also called Jon out directly. And yes, as I stated in no uncertain terms, many times I do _not_ care about reading what Jon writes. Many of his posts are so demeaning to whomever they addressed that it is difficult to read them all the way through, quite literally. It makes me uncomfortable to see well-meaning people treated like that. And trust me, I received enough private mail on the subject to assure you that I am far from the only one. The bottom line is, Jon is currently getting no more and no less than he gives everyone else. hear that people like Paul Frieden (the only person that did put some salt in what he said) Hey, thanks =) technical arguments/replies snipped due to my position as a whining, snot-nosed little kiddie who stumbled across Jakarta a mere six months ago and can therefore not possibly have anything meaningful to say As one of the people behind the scenes since before each of you got here, I believe my vote counts, and now, please prove me wrong. This post is a better example of my original point than I could possibly dream up, and it has nothing to do with the technical merits of the architecture. Sam is right on the money. Do you think that this little scuttle over 3.x vs. 4.x will be too terribly important six months from now? Probably not. What will be is the one or two or ten developers who eventually decided to contribute their limited time and resources to a different OSS project because this one is getting too contentious for their tastes. There are other great projects out there to get involved in, and whether or not a project has some fun people to work with, as opposed to everyone treating each other like shit when they disagree, is definitely a consideration for most of us. Pier - Chirstopher
Re: [T4][Classloaders][PATCH Suggestion] Bug in toURL() and new URL(x,x,x,x)
Stuart Roebuck wrote: In the course of fixing a problem I was having getting Apache Cocoon to run, I came across a bug in Java in the File.toURL() method. This fault, combined with the use of the URLClassLoader resulted in a classloading issue. Stuart, I'm trying to create a simple, reproducible test case that causes Tomcat 4.0 to fail because of this -- but so far, I have not been able to. For example, I would assume that the following scenario should fail due to this problem: * Run on Linux (RH 6.2) + JDK 1.2.2 * Do *not* set the CATALINA_HOME environment variable * Set current directory to where Tomcat 4.0 is installed * Start it by typing "./bin/catalina.sh start". This would cause CATALINA_HOME (and therefore the "catalina.home" system property) to be set to "./bin/..", which would cause all the URLs in the "system" class loader -- the one created from JAR files in the "bin" directory -- to have absolute pathnames with ".." in them, which should trigger this problem. Yet, it still runs correctly. Can you help me identify a failure case? Craig
Re: Fuck It.
Not true at all. 3.x only implements Servlet API 2.2 and 4.0 implements Servlet API latest and greatest. On top of it, I (and others) would be STRONGLY -1 for adding Servlet API 2.3 support to 3.x within the Jakarta project. That is why Costin has already agreed and stated that he will fork that addition to another location. Therefore, as long as 3.x does not have support for 2.3, it is a dead end solution IMHO and adding support for 2.3 within 3.x would be a duplication of effort since we already have a 2.3 container (hence the reason why I am -1 and why Costin has already stated he plans to fork that addition somewhere else). Thanks Jon, you are right about this and I now agree with you that servlet 2.3 support for tomcat 3.x shouldn't be developed as part of this project, but as an independent module. But you can look at the good side - people using Tomcat3.2 will have a smooth transition from Servlet2.2 to Servlet2.3, and why not even further in the future. Tomcat3.3 is designed to allow multiple facades - while it'll be only a servlet 2.2 container, people can make a Servlet2.3 module available and you will be able to do a gradual transition ( and when all your applications are 2.3 you could switch to another 2.3 container ). And ( in case someone will flame that "this is an architecture change in 3.3" ) - this design was part of tomcat from 3.0 and before - but the implementation was pretty bad, and only in 3.3 we can take advantage of this architecture. ( and no, it's not my idea, I actually believed it's a bad idea when I first saw it ). Speaking of future, the same thing can happen when the next servlet spec is released - and again you could use tomcat3.3 to have a smooth future. I know how painfull it is to upgrade a production server - how many small things will stop working and many things will be different. Yes, a Servlet2.3 container should run any 2.2 servlet - but will this be true for Servlet 3.0 ( or 2.4 or whatever will be next ) ? ( not to mention that there are still 2.2 servlets that have problems moving from one 2.2 container to another :-) And another "read of the future" - you can be sure you'll have a better and better container as we move forward. Having more than one solution is allways better then having only one, and as long as none is perfect I'm sure some synergy can exist ( or at least I'm trying to learn and reuse as much as possible from 4.0 - so whatever will happen in the future in 4.0 can happen in 3.3 too ) Costin
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: Tomcat session replicator
Shai, I apologize for not responding to you earlier ... substantive discussions are getting a little lost in the noise at the moment. For some reason, my Netscape mail reader won't let me intersperse comments -- so I've put them at the end. I think I read into your earlier comment that you'd be interested in being a committer to work on this stuff. If you're still interested, you've got my +1. Craig [EMAIL PROTECTED] wrote: Hi, Two weeks ago I posted note here saying Im going to write patch for Tomcat 3.2 to support redundancy, in manner of having session information stored between reloads and shared between tomcat instances. In order to support tomcat redundancy I thought on implementing that in two phases: (dumping) While shutting down Tomcat it will save sessions in file and reload them while going up. This feature will allow restarting tomcat without loosing state. (replication) Sending session from one Tomcat to another (AKA: buddy). This will allow the session to have backup on another machine. mod_jkwill send user connection requests to the second machine while the original machine is unavailable. Number 1. above is already implemented, and 2. is going to be finish soon. The question I have is: Should I implement the session replicator listener as stand-alone connector, or incorporate in into Ajpv13? This will require adding two commands to the protocol implementation. Options: Stand-alone connector. This will require another listener. Incorporate it into Ajp13. Incorporate it into Ajp13 and calling it Ajp14. Other ideas? Implementation details will be followed soon. Shai Fultheim Chief Technology Officer BRM Seed E-Mail: [EMAIL PROTECTED] Mobile: 972-53-866-459 Office: 972-2-5891-459 The biggest problem I have with integrating session replication into AJPxx is that it means this will only work if you're running Apache connected, versus when Tomcat is running stand alone. Even in that environment, does the Apache instance really need to know what's going on? Wouldn't it just be a case of updating the cookie to include the new "router" information when you migrate a session from one JVM to another? Personally, I'd like to see a session migration mechanism that works between the "back end" Tomcat instances. There are probably few enough of those (in most use cases) that you can maintain a spiderweb of persistent connections that is used only to communicate session migration information. Just as a small technical detail -- the servlet spec says that an application *must* run within a single JVM unless it marks itself as distributable/> in the deployment descriptor -- don't forget to check for that. As to what version of Tomcat to work on, no matter what the future holds it seems like the current 3.2 code base is not really appropriate for major innovation. I would only point out that the 4.0 architecture has an interface (org.apache.catalina.Store) behind which session migration stuff can easily be hidden -- as well as support for persistence, swapping, and other advanced features -- without modifying the remainder of the servlet container. Several other folks have expressed interest in working on this at various times, so collaboration would be quite useful. Craig McClanahan
[humor] Why should I care what color the bikeshed is?
http://www.freebsd.org/FAQ/misc.html#BIKESHED-PAINTING -jon
Getting around Facade
I am interested in calling toString on a Request, but am prevented from this by the Facade wrapping infrastructure. I understand the security reasons for this, but want to see the stringified Request. I tried getting the Context and creating a SimpleFacadeManager, but I got some run time errors when I tried to getRealRequest and toString that. Anyone have some simple code for working around the Facade (or know how to turn it off from a setting)? Thanks in advance, Seth
help EJB
We are soft ware developers(Calrion systems (P)Ltd. , Cochin ,Kerala, India).Now we are developing application in EJB under weblogic server. We required to deploy the application (what we developed in EJB under weblogic server)in Tomcat server. Please give me a step by step Instructions for the deployment of EJB application in Tomcat server 1.Will tomcat server support EJB? 2. Is it required any additional support program, to support EJB in Tomcat,? Boby Michael
BugRat Report #646 has been filed.
Bug report #646 has just been filed. You can view the report at the following URL: http://znutar.cortexity.com/BugRatViewer/ShowReport/646 REPORT #646 Details. Project: Tomcat Category: Bug Report SubCategory: New Bug Report Class: swbug State: received Priority: high Severity: critical Confidence: public Environment: Release: 3.2.1 JVM Release: jdk1.2.2 Operating System: win32 OS Release: 4.0 Platform: NT Synopsis: Ctx( ): IOException in: R( + /index.html + null) socket write error (code=10053) Description: I just downloaded Tomcat 3.2.1 and try to access localhost:8080/index.html and get the following error on every access. Ctx( ): IOException in: R( + /index.html + null) socket write error (code=10053) Not sure if it is a bug or I am not doing something right? Thanks Title: BugRat Report # 646 BugRat Report # 646 Project: Tomcat Release: 3.2.1 Category: Bug Report SubCategory: New Bug Report Class: swbug State: received Priority: high Severity: critical Confidence: public Submitter: _Anonymous ([EMAIL PROTECTED]) Date Submitted: Dec 21 2000, 01:58:08 CST Responsible: Z_Tomcat Alias ([EMAIL PROTECTED]) Synopsis: Ctx( ): IOException in: R( + /index.html + null) socket write error (code=10053) Environment: (jvm, os, osrel, platform) jdk1.2.2, win32, 4.0, NT Additional Environment Description: Report Description: I just downloaded Tomcat 3.2.1 and try to access localhost:8080/index.html and get the following error on every access. Ctx( ): IOException in: R( + /index.html + null) socket write error (code=10053) Not sure if it is a bug or I am not doing something right? Thanks How To Reproduce: null View this report online...
Re: Fuck It.
on 12/21/2000 11:11 AM, "[EMAIL PROTECTED]" [EMAIL PROTECTED] wrote: Tomcat3.3 is designed to allow multiple facades - while it'll be only a servlet 2.2 container, people can make a Servlet2.3 module available and you will be able to do a gradual transition ( and when all your applications are 2.3 you could switch to another 2.3 container ). That is a bad "excuse" as all 2.3 containers need to be backward compatible with 2.2. It is part of the spec. You actually end up clarifying that little fact below. Let me also state that after having just migrated a fairly complex Turbine based application from Tomcat 3.x to 4.0, I can state that I had to make absolutely NO changes to any of my files in order to do this. I'm not worried about the future being on top of Tomcat 4.x. Speaking of future, the same thing can happen when the next servlet spec is released - and again you could use tomcat3.3 to have a smooth future. I know how painfull it is to upgrade a production server - how many small things will stop working and many things will be different. And I'm 100% sure you will be able to use 4.0 as a base for future Servlet API's as well. What is your point here? Yes, a Servlet2.3 container should run any 2.2 servlet - but will this be true for Servlet 3.0 ( or 2.4 or whatever will be next ) ? ( not to mention that there are still 2.2 servlets that have problems moving from one 2.2 container to another :-) You can't promise that for Tomcat 3.3. If you go away, there is absolutely no promise that someone else will pick up and implement whatever the latest spec is on top of Tomcat 3.x. However, you CAN promise that someone will do it on Tomcat 4.x because that is the direction that Sun is going and Sun will pay someone to do it as long as J2EE is around (which I don't see it going away any time soon, if anything, it is getting larger and more important with the .NET crap). And another "read of the future" - you can be sure you'll have a better and better container as we move forward. Having more than one solution is allways better then having only one, and as long as none is perfect I'm sure some synergy can exist ( or at least I'm trying to learn and reuse as much as possible from 4.0 - so whatever will happen in the future in 4.0 can happen in 3.3 too ) Very true, but not under the ASF because you will be forked elsewhere as you have already stated. p.s. I hear that Resin is a very good container. That doesn't stop the ASF from providing one as well. Competition is good. I like forks and your fork would be the first fork of the Tomcat platform. I am totally +1 on that without a doubt because it proves that the people here at the ASF are producing quality code. thanks, -jon
Re: Fuck It.
"Rob S." wrote: Of what value would enhancing JServ to the point of technical perfection, be right now when it is clearly not the direction things are headed? To me, if someone said, "i want to make all these great changes to JServ" I'd be like, "ok sure, but no one is going to use it since it's old school. [...] Thanks Rob. You EXACTLY hit the point... When we started the Jakarta project, what happened to JServ? NOTHING, it's still there, kicking asses since two years with no maintainers because Tomcat was the way to go... We developers got it, understood it, and carried on with our decisions, even if to someone that was a wrong one. And what happened? Of course Craig felt left out in that, he was writing JServ 2.0, but he said "yes" to Jakarta, and because of that, he simply dropped the old container, until he came along and made the Catalina proposal... And now that's the way to go, that's what we decided, that's what I want to see happen. Pier -- Pier Fumagalli [EMAIL PROTECTED] http://www.betaversion.org/~pier
Re: Tomcat 3.3
"Craig R. McClanahan" wrote: Andy wrote: But, that being the case (and I know I'm touching on a sore spot) what will be the lifespan of 3.3. Since a proposal to publish a "Tomcat 3.3" has never been formally presented and voted on, the only logically correct answer is "I don't know." Depending on the results of a vote, it could be anything from "it will never be released (as Tomcat -- the code is free for anyone to do what they want with)" to "live long and prosper". Kinda hard to go on. Given the current emotionally charged climate, I would not suggest that anyone propose a vote on 3.3 at the moment :-). I'd say you might have just invited it. [snip] I'm guessing 4.0 might be a bit hard to get into as I picture the major decisions being made in a sun boardroom somewhere in cupertino where i'd not have the time to make it to and probably wouldn't be invited anyhow... I'm guessing (well, not really -- it's pretty obvious :-) you haven't studied your history very well. Other than reading the site and newsgroups without actually being here x years ago, its not as if there is a "Complete history of tomcat". And honestly I probably would find it a bit dry. (see Shakespeare's "Loves Labours Lost" for more entertaining reading). I'm just trying to find a starting point. For an interesting bit of background, you might go check out the CVS repository for Apache JServ at http://java.apache.org and select the branch labelled "JSERV1_1DEV". (Yes, it started before there was a 1.1 release of Apache JServ). Note the dates on those files (early to mid 1999, before the Sun contribution of Tomcat was announced). Go look at the source, and you will see the recognizable architecture that is Catalina (the servlet container part of Tomcat 4.0) today. Cool. For the record, Sun hired me in March, 2000, so that I could work on Tomcat full time instead of it just being a hobby (as it was when the original code was written). :-) My comments were not directed at you, I appologize if I offended anyone as was not my intention. My desire is to get involved in a piece of open source software I actually use (therefore can have the time to study and contribute to in my free time without getting a divorce G), working for a money has been taking the fun out of computers so I wanted to work for something else. Again, no offense was intended, I was just summing up the best conclusions I could come up with from reading the newsgroups. Maybe the best thing would be if one of the commiters gave me a piece of their bug they don't feel like finding. From your comments I have a question: Has 4.0 been voted on ? ( if this is politically charged please read this in the context it is intended which is NOT controversy, I'm a programmer not a political type)... If it will indeed be released and maintained and contributions are welcome than maybe that's a good starting point. Thanks, Andy _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
Re: Fuck It.
GOMEZ Henri wrote: 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) And for once, so, my votes are in disagreement with you, Jon... :) As one of the people behind the scenes since before each of you got here, I believe my vote counts, and now, please prove me wrong. I don't want to appear as a someone disturbing the Tomcat Project, it's really sad to see that Jon show as a personal attack some answers on TC 3.3. Your comments were to the overall Jakarta and XML projects, and being a father for both of them, it made me feel so sad. As now taking you an example on my email makes you feel sad. With one line it's like you washed away years of work and commitment of many people including me. With one line I washed away your involvement on this project... I propose to commiters to vote to drop my COMMITER STATUS. And I'm sorry, but I'm going to vote -1 on this. What we did in the last years stays there in the records, no matter what we say. Our work and commitment on the project was untouched by your one line, you invaluable contribution on packaging and distributing was untouched by my one line. I'm sorry but English is not my primary lang, and I couldn't really express 'le fond de ma pensée' on this. English is not my primary language too, and many many times I can't express what I feel exactly. But I've been here long enough to see that no matter what we say around here, what lasts is our contributions to the project. And I've been here long enough to know how to understand and digest flamewars Where would I be now if I dropped out when Ed Korthof wrote me and Stefano "Enjoy your cathedral" two years ago? Pier -- Pier Fumagalli [EMAIL PROTECTED] http://www.betaversion.org/~pier
Re: Fuck It.
Sam Ruby wrote: Pier Fumagalli wrote: So, here I stand, my vote is a big -1 on a 3.3 as a newly architected servlet container Pier, I beg of you to reconsider. Read my email in detail... Read that phrase. I don't vote -1 on 3.3. I vote -1 if 3.3 is based on a new architecture would introduce more bugs and differences as 4.0 is doing. I was not present in the ApacheCon in 1998. Nor was I in the room when the Jakarta decision was made. Nor was I on the state at JavaONE, when Patricia Sueltz made the announced with you, Jon, Stefano, and Brian. I love myself :) Sometimes I can just be sooo poethic :) :) :) I can tell you that from my perspective, after all that transpired - and a merge twelve months ago - Jakarta Tomcat was hardly an open source project. It took a lot of hard work to make it open and viable. And a lot more that those four mentioned above were involved. No, I disagree. I might have not contributed to the Tomcat 3.x tree (hey, I'm stupid, I can't understand that code, I admit it), but the Sun folks - including Costin - were always very open and tried hardly to build this community. And they succedeed, we wouldn't be here arguing about this whole mess if they didn't. Pier, take a step back. Look at where servlets were as a technology two years ago. One year ago. Today. Project where you think they will be one year from now, two years from now. Do you really believe that irreparable harm is going to come from today's explorations and fleshing out possible alternatives - particularly since this is all being done in the open and under a license that would very much encourage code sharing and reuse? No, again, read my posts on this topic Sam, I'm not asking anyone to fork or go away. Shit, all I'm saying is that we decided that Catalina was the container for 4.0, and that Tomcat 3.2 and its container would have been a bug-fix and performance increase only. I don't want a fork. All I'm saying is that, if 3.3 is -as I see it- a major rearchitecture of the container that would introduce more bugs, and support issues, that should be done as a proposal, to be evaluated for Tomcat.NEXT. I very much believe the contrary - that the only potential irreparable harm that can come from this is the stifling of innovation. And I'm not here to stop innovation. Shit, I didn't say no when we dropped JServ in favour of Tomcat, even if it was MY baby. And I'm not saying NO to other proposals for the next generation of Tomcat. Pier, Is now the right time, and is this the right way to fight this particular battle? No, it's not... It's too late, and I already written "closed" on this chapter at least 2 times. But it seems that part of this community is not considering the "closed" word with the same strength another part does I don't personally care whether any particular change made by any committer is described as a bug fix, a feature enhancement, or an architectural change - these descriptions, after all, are subjective. Bug fix and feature enhancements are one thing, and architectural changes ARE another... You IBM folks taught me that when I was working there :) :) My suggestion is that discussion returns to the technical merits of the various approaches, and exploration of ways in which the various branches can exploit and cannibalize the best ideas from each other. Independent of the labels currently associated with each proposal. Agreed. And AGAIN, all I say, if anyone wants to make a proposal for a new Servlet Container, please, our CVS is open, the mailing list is here, and we're all going to examine it for Tomcat.NEXT. But now 3.x is bugfix only and 4.0 is development, wasn't this what we agreed upon? Pier -- Pier Fumagalli [EMAIL PROTECTED] http://www.betaversion.org/~pier
Re: Fuck It.
Sam Ruby wrote: As Pier recently said on another mailing list "You can't stop open source developers...". And I'm not here to stop them... Proove me wrong :) :) :) Is this really what everybody wants? I'm sure it could be made to happen. And quickly upgraded to the latest servletapi. And gather a substantial following. Obviously a fork is a nightmare scenario. Not _everytime_ (from the different *BSD forks something good came out, FreeBDS) :) :) It is an ironic twist. One has to wonder if such a fork is inevitable. Not for any technical reason. But rather because those that worked so hard to create the place where everyone was to come together have become intolerant of exactly the spirit that makes open source successful. Innovation. Exploration. Revolution. And, yes, dead ends. My recommendation: put your energies into the proposal that most gets your juices flowing. Keep the discussion to the technical merits. That's what I keep saying from months, Sam. I keep saying let's fix the bugs on 3.x and improve its performance. You don't want to do that? Help us develop 4.0 and Catalina. You don't even want to do that either? Create a proposal and work on it, I'll be the first to analyze it when Tomcat.NEXT comes along. Pier -- Pier Fumagalli [EMAIL PROTECTED] http://www.betaversion.org/~pier
Re: Fuck It.
GOMEZ Henri wrote: It's more a question than a request. I was really sad with Pier reaction. I really don't want to appear as a someone disturbing the Tomcat Project. As I don't want to appear as someone who gave up Jakarta and XML to Sun and IBM respectively... And that's what you said... As many others today, I wonder about the future of OpenSource and projects independance when corporations like IBM and Sun put (or hire) so many of the core developpers. You can't blame a company for saving my butt when I was about to be torn away from what I did in the last years... And everything is going to be great until developers keep their own integrity towards open-source, even sometimes going against their employer. I'm not afraid to start a war at Sun if that's nedeed, as I'm scared to start one here. But sometimes I need to do it. It's a great thing that such companies goes to opensource. But if major decisions are allready taken behind the scene, there is a real risk for OpenSource. Don't worry. No decisions are taken "behind the scenes" in some corporate offices by managers and such. I wouldn't be working in one of them :) :) :) Pier -- Pier Fumagalli [EMAIL PROTECTED] http://www.betaversion.org/~pier
Re: Tomcat 3.3
Andy wrote: Maybe the best thing would be if one of the commiters gave me a piece of their bug they don't feel like finding. The interim bug reporting system we are using http://znutar.cortexity.com has tons of outstanding bugs. I would not bother with the Tomcat 3.1 bugs -- anyone who is using 3.1 is strongly urged to upgrade to 3.2. The easiest way to find them is go to the Viewer, then "Display all bug reports in a specific project", then select "Tomcat". (The 4.0 bugs are supposed to be under "Catalina" and "Jasper", but not everyone does it that way, so you have to check the "Tomcat" list as well.) Everyone using 3.2 or 3.2.1 in production would be incredibly appreciative if bugs on it were found and fixed, and a 3.2.2 release was prepared. Submit a few bug fixes, and you'll probably find yourself nominated as a committer if you're interested :-). As for future versions, it should be obvious what I spend my time on -- everyone of course is free to do what they want in that respect. From your comments I have a question: Has 4.0 been voted on ? ( if this is politically charged please read this in the context it is intended which is NOT controversy, I'm a programmer not a political type)... If it will indeed be released and maintained and contributions are welcome than maybe that's a good starting point. Yes, in September 2000 the vote to use Catalina as the basis for Tomcat 4.0 took place on the TOMCAT-DEV mailing list. The votes would be in the mailing list archives (and yes, the web site can do a better job of pointing people to where various archives of TOMCAT-DEV can be found -- updating the web site is yet another useful way to contribute). Welcome! Thanks, Andy Craig _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
Re: Fuck It.
Costin Manolache wrote: they were. Jon, you might be annoying and obnoxious at times, but those kids don't even care about reading what you're writing... Too bad all this is on an open mailing list where the mails can be read again and again - and people may form their own opinions. Oh, that's why I flame people on the ML and not mailbomb them privately! _exactly_ happening: from what I see in the commit messages, it seems to me that even if on an evolutionary track, the container structure is completely different between 3.2 and 3.3. The architecture is almost as different as 3.2 and 4.0. It's sad that on this list so many people are experts in spinning facts and politics. And surely you're a master on this... How you're able to twist facts and promises is somehow intriguing. This is a _false_ statement, or a gross misunderstanding of what "architecture" means and what "refactoring" means. The _architecture_, _ideas_ and _patterns_ in tomcat3 are the same - the code, code organization changed. Doesn't seem like that to me... I just had to deal with a major change in Apache2.0 - it seems some time ago they reorganized the whole tree, moved apr in a different repository, etc. Is this a different architecture ? Apache 2.0 is not yet OUT in final... Try to go down in HTTP land and build a 1.4 on the ashes of 1.3 but with a whole new architecture.. I wonder what the peeps down there would say... others, they are all so busy in rearchitecting the container, and back-porting features from 4.0 that they don't have time to maintain the old That's even worse - all the flames that start up whenever code from 4.0 is reused in 3.x. What's the problem ??? Are you afraid of "featurism" ( i.e. are good for 4.0 but bad for 3.3 ) ? That's TWISTED. Holy shit, you don't even care about supporting our users. Jesus Lord! Every single feature you back port from 4.0 will need to be supported in BOTH 3.3 and 4.0 and that means doubling our efforts in bug tracking and issue solving. You're not even doing that for 3.2, why the hack would you care to do it for 3.3. The 3.2.1 release, MAJOR SECURITY HOLES was made by Craig while dodging a M5 release for Catalina... DO YOU SEE THAT? YOU ARE THE FIRST ONE WHO FUCKING DROPPED 3.2 TO GO ON 3.3. Take a look at "changes" in tomcat 3.3. It's a description of all the "evolutions" from 3.2 to 3.3. Too bad I haven't done the same when I worked on 3.2. You can also take a look at commit messages - yes, some are big ( code moved around for better organization ), and some deprecated interfaces are removed ( is this an "architecutre change" ? They were introduced in 3.2, 3.1 or 3.0 to help refactoring, and "evolved" into something better ). Costin, if you want to work on an evolutionary track, go on and help Craig in supporting 3.2 and making it better. If you want to go on your own do a 3.3, I don't care what you do in your time. But my -1 stands on 3.3 and +1 on bugfixing 3.2. You didn't prove me wrong. Pier -- Pier Fumagalli [EMAIL PROTECTED] http://www.betaversion.org/~pier
Re: Tomcat 3.3
"Craig R. McClanahan" wrote: For the record, Sun hired me in March, 2000, so that I could work on Tomcat full time instead of it just being a hobby (as it was when the original code was written). :-) And thank you for not accepting my offer at that time, otherwise you would be working on Business Processes right now, and not on Catalina... Pier -- Pier Fumagalli [EMAIL PROTECTED] http://www.betaversion.org/~pier
BugRat Report #648 has been filed.
Bug report #648 has just been filed. You can view the report at the following URL: http://znutar.cortexity.com/BugRatViewer/ShowReport/648 REPORT #648 Details. Project: Tomcat Category: Bug Report SubCategory: New Bug Report Class: swbug State: received Priority: medium Severity: critical Confidence: public Environment: Release: Tomcat 3.2 JVM Release: JDK 1.3 Operating System: Windows NT4.0 OS Release: NT4 service Pack 6 Platform: Windows Synopsis: When a connectino is reset, tomcat should retry sending the response object instead of re-executing the entire jsp. Description: When a when a jsp response is asked to be resent because of a "connection reset by peer" only the response object should be resent again. Currently the JSP is re-executed, which can lead to unpredictable results if the jsp is requesting or changing data on a 3rd process. Consider: jsp code: snip someServer = (ServerInterface)Naming.lookup(serverURL); someServer.incrementConnections(); snip If the jsp is executed again because of a connection reset, then incrementConnecions() will be executed again. This is not desired behavior. Title: BugRat Report # 648 BugRat Report # 648 Project: Tomcat Release: Tomcat 3.2 Category: Bug Report SubCategory: New Bug Report Class: swbug State: received Priority: medium Severity: critical Confidence: public Submitter: Christian Mattix ([EMAIL PROTECTED]) Date Submitted: Dec 21 2000, 03:25:36 CST Responsible: Z_Tomcat Alias ([EMAIL PROTECTED]) Synopsis: When a connectino is reset, tomcat should retry sending the response object instead of re-executing the entire jsp. Environment: (jvm, os, osrel, platform) JDK 1.3, Windows NT4.0, NT4 service Pack 6, Windows Additional Environment Description: Report Description: When a when a jsp response is asked to be resent because of a "connection reset by peer" only the response object should be resent again. Currently the JSP is re-executed, which can lead to unpredictable results if the jsp is requesting or changing data on a 3rd process. Consider: jsp code: someServer = (ServerInterface)Naming.lookup(serverURL); someServer.incrementConnections(); If the jsp is executed again because of a connection reset, then incrementConnecions() will be executed again. This is not desired behavior. View this report online...
Re: Fuck It.
Christopher Cain wrote: "Pier P. Fumagalli" wrote: Where were you KIDS when we were fighting the big corporations to have them looking into open source, to contribute significant parts of their technologies to the Foundation, where were you while we were changing this world? You were home, and one day, you looked up on your browser, saw a thing called Jakarta and started weening if things weren't as nice as you wanted them. Nice. Now as a newcomer who wishes to give back to the community, do you think that this makes me feel more welcome or less? Why don't you just post a big sign that says, "If you were not here in the beginning, you are irrelevent. Go Away." That would probably be a slightly more effective means of keeping new developers away than simply making fun of them. That was not my intent, sometimes I just get too epic :) :) :) What I wanted to say is that when decisions are made, even if in an open source project, you have to stick with them. That's why new developers are "hinted" to read the list for a while before coming along and trying to revolution the whole thing. I assume that I fall under that auspise since I also called Jon out directly. And yes, as I stated in no uncertain terms, many times I do _not_ care about reading what Jon writes. Many of his posts are so demeaning to whomever they addressed that it is difficult to read them all the way through, quite literally. It makes me uncomfortable to see well-meaning people treated like that. And trust me, I received enough private mail on the subject to assure you that I am far from the only one. The bottom line is, Jon is currently getting no more and no less than he gives everyone else. And that's wrong... Why sending you email privately? Come on out, my old flameproof vest is on, and kids, you don't even know how much I can take. Get out, tell me I'm an ignorant idiot (Duncan, what was that? Arrogant Pig? I believe that's how you've been called somewhere else! :) :) All I ask you guys it to prove me wrong. Prove me that 3.3 is not a new servlet container, prove me that it's just bugfix and performance. Give me some damn facts. hear that people like Paul Frieden (the only person that did put some salt in what he said) Hey, thanks =) technical arguments/replies snipped due to my position as a whining, snot-nosed little kiddie who stumbled across Jakarta a mere six months ago and can therefore not possibly have anything meaningful to say Did I overlook one of your emails? Subject please, since you posted 6 times on this mailing list and the first time in september. Were you around when 4.0 was voted on? As one of the people behind the scenes since before each of you got here, I believe my vote counts, and now, please prove me wrong. This post is a better example of my original point than I could possibly dream up, and it has nothing to do with the technical merits of the architecture. Sam is right on the money. Do you think that this little scuttle over 3.x vs. 4.x will be too terribly important six months from now? Probably not. What will be is the one or two or ten developers who eventually decided to contribute their limited time and resources to a different OSS project because this one is getting too contentious for their tastes. There are other great projects out there to get involved in, and whether or not a project has some fun people to work with, as opposed to everyone treating each other like shit when they disagree, is definitely a consideration for most of us. Go back, read the archives and take a look to what I said when we voted on tomcat 4.0. Then go again and read what I proposed Costin for his new servlet container. Cute, now I'm the bad guy. I like this position... You still didn't proove me wrong. Pier -- Pier Fumagalli [EMAIL PROTECTED] http://www.betaversion.org/~pier
[tomcat-4.0] Session Creation Slowness
Ok, I put a whole bunch of logging into Turbine to see *exactly* what line
of code is causing the slowness that I keep reporting here and I have now
found it...
Log.note ("RunDataFactory: 11");
// Get the HttpSession object.
data.setSession ( data.getRequest().getSession(true) );
Log.note ("RunDataFactory: 12");
As you can see above, essentially, all that is happening is that I'm storing
an instance of the HttpSession object within the RunData object. Marking
things as "true" causes the redirect to happen, so there is another
request...
[Thu Dec 21 13:34:15 PST 2000] -- NOTICE -- RunDataFactory: 11
[Thu Dec 21 13:35:01 PST 2000] -- NOTICE -- RunDataFactory: 12
...
[Thu Dec 21 13:35:03 PST 2000] -- NOTICE -- RunDataFactory: 11
[Thu Dec 21 13:35:03 PST 2000] -- NOTICE -- RunDataFactory: 12
As you can see above the first request through this code takes bloody
FOREVER and the second one is quite fast.
The really *INSANE* part about all of this is that people have checked
Scarab out of CVS themselves on the SAME JVM (1.3 on Windows) and don't see
any real slowness at all (approx 4-5 seconds).
So, Craig, can we please try to do something about this? There has got to be
something wrong with either my setup or something else (I really don't think
this is entirely a classloader issue anymore). I also have this great
slowdown on MacOSX as well.
If you want to duplicate it, you can check Scarab out of CVS and do it
yourself. I have re-done the CVS tree and it is very easy to get things up
and running (even without a database installed...just ignore that part of
the README.txt file).
http://scarab.tigris.org/
thanks,
-jon
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: Fuck It.
Quoting Nacho [EMAIL PROTECTED]: Please be carefull when you write something about anybody, have a look at commits please... Henri, P. Delisle and I are the only ones here that had contribute to ALL present versions of Tomcat, *ALL* dont forget that, and i feel involved on ALL of them, if this is a waste of my poor capacities , well no problem i do with my time what i want , i do not admit opinions on that.. Yes, that's 100% true. I can't figure out why Pier included you in this. You were kids, are kids, and will be kids, regardles of your age, if you continue playing with invaluable items as is the confidence of your people ( as i am like it or not, i'm in your side dont forget that ). And you are losting my confidence with every flame you put in public lists. We are all here for another reason that hear you scream. I'm too old ( 35 FYI ) to believe that the volume of your voice gives you more reason than i have, no. I believe that architecture of 3.3 is right one. Why we are not talking about that ? because there arent technical arguments against my believes ? are you truly sure that tomcat 4.0 is right when perfomace comes to discussion ? As far as I know, someone has still to point out why Catalina would be inherently slower than TC 3. I really can't figure that out. Is it the intuitive feeling that C-style design + C looking code performs faster that object oriented code with a nice design ? I don't see any optimization in TC 3 which couln't be intrduced in Catalina, whether it's the delayed char conversion or the recyclable buffers. Remy
Re: Fuck It.
Quoting Costin Manolache [EMAIL PROTECTED]: That's even worse - all the flames that start up whenever code from 4.0 is reused in 3.x. What's the problem ??? Are you afraid of "featurism" ( i.e. are good for 4.0 but bad for 3.3 ) ? It's open source code, and it's right to reuse it instead of reinventing the wheel. If someone writes a JAAS authenticator for 4.0 - why not making it available to 3.3 users too ? For the same reason the JServ guys aren't making them available for JServ, I suppose. After all, if 4.0 is "better", that's because of the architecture, not because of the features - or else next spin will be that people should use 4.0 because of all the features. That has been one of your three arguments for a while. Actually, I think that right now TC 3.3 has an edge feature-wise because of the web connectors. Remy
Re: [tomcat-4.0] Session Creation Slowness
Jon Stevens wrote:
Ok, I put a whole bunch of logging into Turbine to see *exactly* what line
of code is causing the slowness that I keep reporting here and I have now
found it...
Log.note ("RunDataFactory: 11");
// Get the HttpSession object.
data.setSession ( data.getRequest().getSession(true) );
Log.note ("RunDataFactory: 12");
As you can see above, essentially, all that is happening is that I'm storing
an instance of the HttpSession object within the RunData object. Marking
things as "true" causes the redirect to happen, so there is another
request...
[Thu Dec 21 13:34:15 PST 2000] -- NOTICE -- RunDataFactory: 11
[Thu Dec 21 13:35:01 PST 2000] -- NOTICE -- RunDataFactory: 12
This is the first session create since the webapp was started, right?
Currently, that is when the RNG is initialized.
...
[Thu Dec 21 13:35:03 PST 2000] -- NOTICE -- RunDataFactory: 11
[Thu Dec 21 13:35:03 PST 2000] -- NOTICE -- RunDataFactory: 12
And this is the behavior you would see after the first one.
As you can see above the first request through this code takes bloody
FOREVER and the second one is quite fast.
The really *INSANE* part about all of this is that people have checked
Scarab out of CVS themselves on the SAME JVM (1.3 on Windows) and don't see
any real slowness at all (approx 4-5 seconds).
That's definitely strange ... 4-5 seconds is my experience even on much slower
hardware, on both 1.2.2 and 1.3.
So, Craig, can we please try to do something about this? There has got to be
something wrong with either my setup or something else (I really don't think
this is entirely a classloader issue anymore). I also have this great
slowdown on MacOSX as well.
This part isn't. Aleady on my TODO list is moving the RNG initialization to
webapp startup time -- that will normally hide it for a 4-5 second delay, but
certainly won't fix a 45-second delay.
If you want to duplicate it, you can check Scarab out of CVS and do it
yourself. I have re-done the CVS tree and it is very easy to get things up
and running (even without a database installed...just ignore that part of
the README.txt file).
http://scarab.tigris.org/
You mean it's not just "check out, compile, and run"??? :-) :-)
Will do.
thanks,
-jon
Craig
RE: [tomcat-4.0] Session Creation Slowness
This is probably due to the new SecureRandom-based session IDs.
There is an option to turn that off somewhere.
-Original Message-
From: Jon Stevens [mailto:[EMAIL PROTECTED]]
Sent: Thursday, December 21, 2000 1:47 PM
To: tomcat-dev
Cc: [EMAIL PROTECTED]
Subject: [tomcat-4.0] Session Creation Slowness
Ok, I put a whole bunch of logging into Turbine to see *exactly* what line
of code is causing the slowness that I keep reporting here and I have now
found it...
Log.note ("RunDataFactory: 11");
// Get the HttpSession object.
data.setSession ( data.getRequest().getSession(true) );
Log.note ("RunDataFactory: 12");
As you can see above, essentially, all that is happening is that I'm storing
an instance of the HttpSession object within the RunData object. Marking
things as "true" causes the redirect to happen, so there is another
request...
[Thu Dec 21 13:34:15 PST 2000] -- NOTICE -- RunDataFactory: 11
[Thu Dec 21 13:35:01 PST 2000] -- NOTICE -- RunDataFactory: 12
...
[Thu Dec 21 13:35:03 PST 2000] -- NOTICE -- RunDataFactory: 11
[Thu Dec 21 13:35:03 PST 2000] -- NOTICE -- RunDataFactory: 12
As you can see above the first request through this code takes bloody
FOREVER and the second one is quite fast.
The really *INSANE* part about all of this is that people have checked
Scarab out of CVS themselves on the SAME JVM (1.3 on Windows) and don't see
any real slowness at all (approx 4-5 seconds).
So, Craig, can we please try to do something about this? There has got to be
something wrong with either my setup or something else (I really don't think
this is entirely a classloader issue anymore). I also have this great
slowdown on MacOSX as well.
If you want to duplicate it, you can check Scarab out of CVS and do it
yourself. I have re-done the CVS tree and it is very easy to get things up
and running (even without a database installed...just ignore that part of
the README.txt file).
http://scarab.tigris.org/
thanks,
-jon
Re: Tomcat 3.3
Yeah i saw that. I'm planning a few updates. Jon Stevens wrote: on 12/21/2000 1:13 PM, "Craig R. McClanahan" [EMAIL PROTECTED] wrote: updating the web site is yet another useful way to contribute). It is even documented on how to do that! http://jakarta.apache.org/site/jakarta-site2.html :-) -jon -- Honk if you love peace and quiet. _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
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: TC 3.2 - Better logging messages when something bad happens?
Thanks for the reply, From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] David Rees wrote: Anyone have any technical comments on the message below? I think that printing a stack dump in this case can be very useful, but someone else may have a different view. For developers, you certainly want to be able to see the stack traces. However, many developers do *not* want such cruft showing to users -- so it was made configurable (thanks to the efforts of Larry Isaacs) -- see the ContextManager attribute called "showDebugInfo" in the conf/server.xml file. It looks like this case was missed. I'm +1 on adding a stack trace, but it should be made conditional just like other stack traces are. OK, I'll see if I can get some time to create a proper patch for this case, then (unless someone beats me to it, I probably won't have time until after X-Mas) -Dave
mod_webapp / mod_jk
Pier, I wanted to ask you some questions about mod_webapp, and how you might see it working with mod_jk. I seem to have become the default ajp13 / mod_jk expert, and people have been asking for various extensions. I'm reluctant to invest much work in mod_jk/ajp13, given that TC 4.0 is using mod_webapp. However, what would seem to make sense to me would be the following course of action: - Write connectors for TC 4.0 which talk ajp13, the mod_jk JNI protocol, and possibly ajp12. I would be very interested in doing this work. I believe it wouldn't take me very long, given that I could adapt the current 3.3 code wholesale (much of which I understand in detail). Then, TC 4.0 would suddenly be able to talk to all the web servers which mod_jk talks to: Apache 1.3, Apache 2.0, Netscape, IIS, AOLServer. This would be a huge win, and would (I believe) dramatically accelerate the adoption of TC 4. It would also provide a very smooth upgrade path to current users. The only disadvantage would be that we wouldn't see any of the advantages of mod_webapp. I've never seen a design doc for webapp, but my understanding is that one of its big advantages is that it will directly read the web.xml (and server.xml) files, which will greatly ease the configuration process. Could you possibly summarize some of its other features? The reason I ask is that I think the mod_jk C code (the various modules which plug into the web servers), is actually extremely well-written and flexible. It's totally undocumented, but, if necessary, I'd be willing to remedy that (I don't mind writing documentation). One of the best things about that C code is that it allows many different web servers to talk to many different protocols in a very clean way. So I wonder if it would be possible to make it to also talk whatever protocol you're developing as part of mod_webapp. This would mean basically merging mod_webapp into mod_jk (or merging mod_jk into mod_webapp, depending on your perspective ;-). What do you think of this course of action? I'm hoping that you and I can align our efforts so that we can take as much advantage of each other's work as possible. -Dan -- Dan Milstein // [EMAIL PROTECTED]
cvs commit: jakarta-tomcat/src/share/org/apache/jasper/compiler JspParseEventListener.java
pierred 00/12/21 15:25:28
Modified:src/share/org/apache/jasper/compiler Tag: tomcat_32
JspParseEventListener.java
Log:
Check for null value before invoking method.
From email sent by Brian Bucknam:
It's a long story, but I'm working on a project where Jasper 3.x is embedded
inside a servlet, which can then be deployed to the container of our
customer's choice. The servlet uses JSP files as templates, which is where
Jasper comes in.
In this type of environment, sometimes thing can go really wrong, and the
compiled JSP might, in some cases, fail to get a JspFactory, PageContext, or
JspWriter.
If any of _jspxFactory, pageContext, or out fail to be created, the catch{}
and finally{} clauses just throw NPE's.
Submitted by: "Bucknam, Brian" [EMAIL PROTECTED]
Revision ChangesPath
No revision
No revision
1.17.2.2 +7 -7
jakarta-tomcat/src/share/org/apache/jasper/compiler/JspParseEventListener.java
Index: JspParseEventListener.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/jasper/compiler/JspParseEventListener.java,v
retrieving revision 1.17.2.1
retrieving revision 1.17.2.2
diff -u -r1.17.2.1 -r1.17.2.2
--- JspParseEventListener.java2000/07/03 09:43:21 1.17.2.1
+++ JspParseEventListener.java2000/12/21 23:25:27 1.17.2.2
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat/src/share/org/apache/jasper/compiler/JspParseEventListener.java,v
1.17.2.1 2000/07/03 09:43:21 bergsten Exp $
- * $Revision: 1.17.2.1 $
- * $Date: 2000/07/03 09:43:21 $
+ * $Header:
/home/cvs/jakarta-tomcat/src/share/org/apache/jasper/compiler/JspParseEventListener.java,v
1.17.2.2 2000/12/21 23:25:27 pierred Exp $
+ * $Revision: 1.17.2.2 $
+ * $Date: 2000/12/21 23:25:27 $
*
*
*
@@ -348,18 +348,18 @@
//writer.println("} catch (Throwable t) {");
writer.println("} catch (Exception ex) {");
writer.pushIndent();
-writer.println("if (out.getBufferSize() != 0)");
+writer.println("if (out != null out.getBufferSize() != 0)");
writer.pushIndent();
writer.println("out.clearBuffer();");
writer.popIndent();
- writer.println("pageContext.handlePageException(ex);");
+ writer.println("if (pageContext != null)
pageContext.handlePageException(ex);");
writer.popIndent();
writer.println("} finally {");
writer.pushIndent();
/* Do stuff here for finally actions... */
//writer.println("out.close();");
- writer.println("out.flush();");
- writer.println("_jspxFactory.releasePageContext(pageContext);");
+ writer.println("if (out != null) out.flush();");
+ writer.println("if (_jspxFactory != null)
_jspxFactory.releasePageContext(pageContext);");
writer.popIndent();
writer.println("}");
// Close the service method:
Bug #55: Default for included files is 8859_1, with no option to set otherwise
Trying to close a few Jasper bugs before the holiday break.
I'd appreciate at least another pair of eyes to review what I believe
should be done on that one... -- Pierre
-
Bug #55
-
Synopsis:
Default for included files is 8859_1, with no option to set otherwise.
Report Description:
The default for reading an included file is ISO_8859_1. We can,
of course, set pageConent to read UTF-8 (which is what we need it
to be to support international
code). Unfortunately, when there are two or more levels of
encoding (or the pageContent type ins't set), the encoding that
the JspReader gets set to a hard-coded
"ISO_8859_1", and doesn't allow this to be set to anything else
via the runtime system properties. In:
org.apache.jasper.compiler.JspReader JspReader.java line
158, encoding ALWAYS defaults to 8859_1, and the file.encoding,
when set from the System properties. This is an easy fix, to set
encoding to: encoding =
System.getPropert("file.encoding","8859_1") ; The result,
typically, is that the file will flake out and convert all of the
non-UTF-8 characters to US-ASCII, @%, etc.
-
I'm not sure I fully understand what's described there,
so here is what I believe should be done.
The "encoding" for a JSP file is currently handled as follows:
1. In Compiler.java, we create a JspReader for the top-level
("including") jsp file using the 8859_1 encoding.
2. Using that JspReader, we check if there is a page directive
with 'contentType' specified. If there is, then
a new JspReader for the page is created with the encoding set to the
"charset" specified in the contentType value of the page
directive; otherwise we stick with the default 8859_1 encoding.
3. When a page is included, JspReader.pushFile() is called,
and the encoding passed as argument appears to always
be null (since no encoding attribute can be specified in
the "include" directive, reading 'encoding' off of the
attributes appears to be a bug in JspParseEventListener).
Because it is null, it always defaults to 8859_1.
If I understand well the intent of the bug report, we'd need the
following modifications:
- In step 2, if contentType is not specified in the "including" page,
set the encoding to be:
encoding = System.getProperty("file.encoding", "8859_1");
This means that the default encoding of all JSP files at a site could
be defined globally using system property "file.encoding".
I don't think this is spec-compliant, and would be reluctant
to make that change.
- In step 3, use the encoding of the "including" page.
This would fix what I believe is a bug in the current implementation.
Comments?
-- Pierre
cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup Bootstrap.java
craigmcc00/12/21 15:47:20
Modified:catalina/src/share/org/apache/catalina/startup
Bootstrap.java
Log:
Modify the bootstrap program to call file.getCanonicalPath() rather than
file.getAbsolutePath() when constructing "file:" URLs to declare as
repositories to URLClassLoader instances. This will cause occurrences of
"/./" and "/../" to be normalized out of the URLs, which apparently causes
problems on some platforms -- although I haven't been able to duplicate it
with my simple tests so far.
There are other cases where this change needs to be applied, which will be
dealt with separately.
Submitted by: Stuart Roebuck [EMAIL PROTECTED]
Revision ChangesPath
1.8 +24 -13
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup/Bootstrap.java
Index: Bootstrap.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup/Bootstrap.java,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- Bootstrap.java2000/12/21 22:27:11 1.7
+++ Bootstrap.java2000/12/21 23:47:20 1.8
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup/Bootstrap.java,v
1.7 2000/12/21 22:27:11 craigmcc Exp $
- * $Revision: 1.7 $
- * $Date: 2000/12/21 22:27:11 $
+ * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup/Bootstrap.java,v
1.8 2000/12/21 23:47:20 craigmcc Exp $
+ * $Revision: 1.8 $
+ * $Date: 2000/12/21 23:47:20 $
*
*
*
@@ -66,6 +66,7 @@
import java.io.File;
+import java.io.IOException;
import java.lang.reflect.Method;
import java.net.MalformedURLException;
import java.net.URL;
@@ -84,7 +85,7 @@
* class path and therefore not visible to application level classes.
*
* @author Craig R. McClanahan
- * @version $Revision: 1.7 $ $Date: 2000/12/21 22:27:11 $
+ * @version $Revision: 1.8 $ $Date: 2000/12/21 23:47:20 $
*/
public final class Bootstrap {
@@ -109,6 +110,12 @@
*/
public static void main(String args[]) {
+// Set the debug flag appropriately
+for (int i = 0; i args.length; i++) {
+if ("-debug".equals(args[i]))
+debug = 1;
+}
+
// Construct the class loaders we will need
ClassLoader systemLoader = createSystemLoader();
ClassLoader catalinaLoader = createCatalinaLoader(systemLoader);
@@ -183,18 +190,19 @@
String filenames[] = directory.list();
for (int i = 0; i filenames.length; i++) {
String filename = filenames[i].toLowerCase();
- if ((!filename.endsWith(".jar")) ||
+ if ((!filename.endsWith(".jar")) ||
(filename.indexOf("bootstrap.jar") != -1))
continue;
File file = new File(directory, filenames[i]);
try {
-URL url = new URL("file", null, file.getAbsolutePath());
+URL url = new URL("file", null, file.getCanonicalPath());
if (debug = 1)
log(" Adding " + url.toString());
list.add(url.toString());
-} catch (MalformedURLException e) {
+} catch (IOException e) {
System.out.println("Cannot create URL for " +
filenames[i]);
+e.printStackTrace(System.out);
System.exit(1);
}
}
@@ -226,13 +234,14 @@
classes.isDirectory()) {
try {
URL url = new URL("file", null,
- classes.getAbsolutePath() + "/");
+ classes.getCanonicalPath() + "/");
if (debug = 1)
log(" Adding " + url.toString());
list.add(url.toString());
-} catch (MalformedURLException e) {
+} catch (IOException e) {
System.out.println("Cannot create URL for " +
classes.getAbsolutePath());
+e.printStackTrace(System.out);
System.exit(1);
}
}
@@ -251,13 +260,14 @@
continue;
File file = new File(directory, filenames[i]);
try {
-URL url = new URL("file", null, file.getAbsolutePath());
+URL url = new URL("file", null, file.getCanonicalPath());
if (debug = 1)
log(" Adding " + url.toString());
list.add(url.toString());
-} catch (MalformedURLException e) {
+
cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/loader FileClassLoader.java
craigmcc00/12/21 16:34:37 Removed: catalina/src/share/org/apache/catalina/loader FileClassLoader.java Log: FileClassLoader has been obsolete for a while -- remove it to avoid any potential confusion.
cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup ContextConfig.java HostConfig.java
craigmcc00/12/21 16:37:52
Modified:catalina/src/share/org/apache/catalina/loader
StandardLoader.java
catalina/src/share/org/apache/catalina/startup
ContextConfig.java HostConfig.java
Log:
Second (and last) round of changes from File.getAbsolutePath() to
File.getCanonicalPath(). With these changes, the following assertions can
be made:
* The URLClassLoader for a web application will never be handed a "file:"
URL that is not normalized.
* The document root directory for a web application will always be
normalized.
* The URL returned by ServletContext.getResource() will always be
normalized.
This should clean up the cases where URLClassLoader on some platforms does
not deal nicely with unnormalized repositories, and causes classes (or
resources) to mysteriously not load, or not load from the correct place.
Submitted by: Stuart Roebuck [EMAIL PROTECTED]
Revision ChangesPath
1.13 +12 -9
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/loader/StandardLoader.java
Index: StandardLoader.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/loader/StandardLoader.java,v
retrieving revision 1.12
retrieving revision 1.13
diff -u -r1.12 -r1.13
--- StandardLoader.java 2000/12/14 22:32:16 1.12
+++ StandardLoader.java 2000/12/22 00:37:50 1.13
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/loader/StandardLoader.java,v
1.12 2000/12/14 22:32:16 craigmcc Exp $
- * $Revision: 1.12 $
- * $Date: 2000/12/14 22:32:16 $
+ * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/loader/StandardLoader.java,v
1.13 2000/12/22 00:37:50 craigmcc Exp $
+ * $Revision: 1.13 $
+ * $Date: 2000/12/22 00:37:50 $
*
*
*
@@ -101,7 +101,7 @@
* is not present, the system class loader will be used instead.
*
* @author Craig R. McClanahan
- * @version $Revision: 1.12 $ $Date: 2000/12/14 22:32:16 $
+ * @version $Revision: 1.13 $ $Date: 2000/12/22 00:37:50 $
*/
public final class StandardLoader
@@ -191,7 +191,6 @@
* codeReloader/code interface.
*/
private String loaderClass =
-// "org.apache.catalina.loader.FileClassLoader";
"org.apache.catalina.loader.StandardClassLoader";
@@ -875,10 +874,14 @@
if (!filenames[i].endsWith(".jar"))
continue;
File jarFile = new File(libFile, filenames[i]);
- if (debug 0)
- log(" Adding '" + "file: " +
-jarFile.getAbsolutePath() + "'");
-addRepository("file:" + jarFile.getAbsolutePath());
+try {
+if (debug 0)
+log(" Adding '" + "file: " +
+jarFile.getCanonicalPath() + "'");
+addRepository("file:" + jarFile.getCanonicalPath());
+} catch (IOException e) {
+log(jarFile.getAbsolutePath(), e);
+}
}
}
}
1.35 +18 -10
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup/ContextConfig.java
Index: ContextConfig.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup/ContextConfig.java,v
retrieving revision 1.34
retrieving revision 1.35
diff -u -r1.34 -r1.35
--- ContextConfig.java2000/12/01 19:25:31 1.34
+++ ContextConfig.java2000/12/22 00:37:52 1.35
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup/ContextConfig.java,v
1.34 2000/12/01 19:25:31 craigmcc Exp $
- * $Revision: 1.34 $
- * $Date: 2000/12/01 19:25:31 $
+ * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup/ContextConfig.java,v
1.35 2000/12/22 00:37:52 craigmcc Exp $
+ * $Revision: 1.35 $
+ * $Date: 2000/12/22 00:37:52 $
*
*
*
@@ -118,7 +118,7 @@
* of that Context, and the associated defined servlets.
*
* @author Craig R. McClanahan
- * @version $Revision: 1.34 $ $Date: 2000/12/01 19:25:31 $
+ * @version $Revision: 1.35 $ $Date: 2000/12/22 00:37:52 $
*/
public final class ContextConfig
@@ -678,10 +678,13 @@
File.separator + Constants.DefaultWebXml);
FileInputStream stream = null;
try {
-
Re: Bug #55: Default for included files is 8859_1, with no option to set otherwise
Pierre Delisle wrote:
Trying to close a few Jasper bugs before the holiday break.
I'd appreciate at least another pair of eyes to review what I believe
should be done on that one... -- Pierre
-
Bug #55
-
Synopsis:
Default for included files is 8859_1, with no option to set otherwise.
Report Description:
The default for reading an included file is ISO_8859_1. We can,
of course, set pageConent to read UTF-8 (which is what we need it
to be to support international
code). Unfortunately, when there are two or more levels of
encoding (or the pageContent type ins't set), the encoding that
the JspReader gets set to a hard-coded
"ISO_8859_1", and doesn't allow this to be set to anything else
via the runtime system properties. In:
org.apache.jasper.compiler.JspReader JspReader.java line
158, encoding ALWAYS defaults to 8859_1, and the file.encoding,
when set from the System properties. This is an easy fix, to set
encoding to: encoding =
System.getPropert("file.encoding","8859_1") ; The result,
typically, is that the file will flake out and convert all of the
non-UTF-8 characters to US-ASCII, @%, etc.
-
I'm not sure I fully understand what's described there,
so here is what I believe should be done.
The "encoding" for a JSP file is currently handled as follows:
1. In Compiler.java, we create a JspReader for the top-level
("including") jsp file using the 8859_1 encoding.
2. Using that JspReader, we check if there is a page directive
with 'contentType' specified. If there is, then
a new JspReader for the page is created with the encoding set to the
"charset" specified in the contentType value of the page
directive; otherwise we stick with the default 8859_1 encoding.
3. When a page is included, JspReader.pushFile() is called,
and the encoding passed as argument appears to always
be null (since no encoding attribute can be specified in
the "include" directive, reading 'encoding' off of the
attributes appears to be a bug in JspParseEventListener).
Because it is null, it always defaults to 8859_1.
If I understand well the intent of the bug report, we'd need the
following modifications:
- In step 2, if contentType is not specified in the "including" page,
set the encoding to be:
encoding = System.getProperty("file.encoding", "8859_1");
This means that the default encoding of all JSP files at a site could
be defined globally using system property "file.encoding".
I don't think this is spec-compliant, and would be reluctant
to make that change.
I agree that using "file.encoding" as the ultimate default is not
spec compliant. I suggest you stick to the current behavior, with
"8859_1" if contentType doesn't specify a charset.
- In step 3, use the encoding of the "including" page.
Sounds right to me.
This would fix what I believe is a bug in the current implementation.
Comments?
What about the javac encoding? I believe it's currently hardcoded
as "UTF8" (in Compiler at least). I'm not sure what it should be
in case different included pages specify different charsets ...
Hans
--
Hans Bergsten [EMAIL PROTECTED]
Gefion Software http://www.gefionsoftware.com
Author of JavaServer Pages (O'Reilly), http://TheJSPBook.com
Re: Bug #55: Default for included files is 8859_1, with no option to set otherwise
Hans, What about the javac encoding? I believe it's currently hardcoded as "UTF8" (in Compiler at least). I'm not sure what it should be in case different included pages specify different charsets ... If you refer to bug report #269, I have a fix coming in the next few minutes. [testing it right now]. It will do as you suggested in the bug report. If not, please enlighten me. -- Pierre
RE: help EJB
try www.jboss.org good luck jatin -Original Message-From: Boby Micheal [mailto:[EMAIL PROTECTED]]Sent: Thursday, December 21, 2000 1:12 AMTo: [EMAIL PROTECTED]Subject: help EJB We are soft ware developers(Calrion systems (P)Ltd. , Cochin ,Kerala, India).Now we are developing application in EJB under weblogic server. We required to deploy the application (what we developed in EJB under weblogic server)in Tomcat server. Please give me a step by step Instructions for the deployment of EJB application in Tomcat server 1.Will tomcat server support EJB? 2. Is it required any additional support program, to support EJB in Tomcat,? Boby Michael
cvs commit: jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/resources messages.properties
pierred 00/12/21 17:27:39
Modified:jasper/src/share/org/apache/jasper
EmbededServletOptions.java JspC.java Options.java
jasper/src/share/org/apache/jasper/compiler Compiler.java
jasper/src/share/org/apache/jasper/resources
messages.properties
Log:
Bug fix: bug report #269 -- java.io.UnsupportedEncodingException when processing JSP
From the bug report:
"A "java.io.UnsupportedEncodingException: UTF8" is thrown when generating
the servlet for a JSP file when the Kaffe VM is used. The "UTF8" encoding
name is hardcoded in the Compiler class as the encoding for the generated
servlet source code file. I believe the reason for using "UTF8" as opposed
to "UTF-8" (note the dash) is that this is the only name supported in
JDK 1.1. I suggest adding an init parameter to JspServlet for setting
the encoding name when "UTF8" doesn't work."
Given that there are several possible representations of Unicode data
(UTF-8, UTF-16, UTF-32), and given that the supported encodings vary
between different implementations of the Java platform,
the best way to tackle this is probably as suggested by Hans.
Added new init parameter "javaEncoding" for JspServlet.
Default value specified in web.xml is "UTF-8".
Submitted by: Hans Bergsten ( [EMAIL PROTECTED] )
Revision ChangesPath
1.5 +15 -3
jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/EmbededServletOptions.java
Index: EmbededServletOptions.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/EmbededServletOptions.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- EmbededServletOptions.java2000/11/06 20:52:18 1.4
+++ EmbededServletOptions.java2000/12/22 01:27:37 1.5
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/EmbededServletOptions.java,v
1.4 2000/11/06 20:52:18 pierred Exp $
- * $Revision: 1.4 $
- * $Date: 2000/11/06 20:52:18 $
+ * $Header:
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/EmbededServletOptions.java,v
1.5 2000/12/22 01:27:37 pierred Exp $
+ * $Revision: 1.5 $
+ * $Date: 2000/12/22 01:27:37 $
*
*
*
@@ -144,6 +144,12 @@
private TldLocationsCache tldLocationsCache = null;
/**
+ * Java platform encoding to generate the JSP
+ * page servlet.
+ */
+private String javaEncoding;
+
+/**
* Are we keeping generated code around?
*/
public boolean getKeepGenerated() {
@@ -218,6 +224,10 @@
return tldLocationsCache;
}
+public String getJavaEncoding() {
+ return javaEncoding;
+}
+
/**
* Create an EmbededServletOptions object using data available from
* ServletConfig and ServletContext.
@@ -320,6 +330,8 @@
Logger.FATAL);
}
}
+
+this.javaEncoding = config.getInitParameter("javaEncoding");
// Setup the global Tag Libraries location cache for this
// web-application.
1.7 +7 -3 jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/JspC.java
Index: JspC.java
===
RCS file: /home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/JspC.java,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- JspC.java 2000/11/06 20:52:19 1.6
+++ JspC.java 2000/12/22 01:27:37 1.7
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/JspC.java,v 1.6
2000/11/06 20:52:19 pierred Exp $
- * $Revision: 1.6 $
- * $Date: 2000/11/06 20:52:19 $
+ * $Header:
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/JspC.java,v 1.7
2000/12/22 01:27:37 pierred Exp $
+ * $Revision: 1.7 $
+ * $Date: 2000/12/22 01:27:37 $
*
*
*
@@ -210,6 +210,10 @@
public TldLocationsCache getTldLocationsCache() {
return tldLocationsCache;
+}
+
+public String getJavaEncoding() {
+ return "UTF-8";
}
public String getClassPath() {
1.5 +9 -3
jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/Options.java
Index: Options.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/Options.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- Options.java 2000/11/06 20:52:20 1.4
+++ Options.java 2000/12/22
cvs commit: jakarta-tomcat-4.0/catalina/src/conf web.xml
pierred 00/12/21 17:31:03 Modified:catalina/src/conf web.xml Log: New JspServlet init parameter for alternate java encoding used when generating Jsp pages servlet source code. The default java encoding used is UTF8. This alternate is set by default to UTF-8. Revision ChangesPath 1.11 +5 -0 jakarta-tomcat-4.0/catalina/src/conf/web.xml Index: web.xml === RCS file: /home/cvs/jakarta-tomcat-4.0/catalina/src/conf/web.xml,v retrieving revision 1.10 retrieving revision 1.11 diff -u -r1.10 -r1.11 --- web.xml 2000/10/31 22:54:07 1.10 +++ web.xml 2000/12/22 01:31:03 1.11 @@ -46,6 +46,11 @@ /init-param -- init-param + !-- An alternate java encoding -- + param-namejavaEncoding/param-name + param-valueUTF-8/param-value +/init-param +init-param !-- Levels: FATAL ERROR WARNING INFORMATION DEBUG -- param-namelogVerbosityLevel/param-name param-valueWARNING/param-value
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
cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session ManagerBase.java StandardManager.java
craigmcc00/12/21 17:54:34
Modified:catalina/src/share/org/apache/catalina/session
ManagerBase.java StandardManager.java
Log:
Cause the random number to be initialized when a webapp first starts,
rather than waiting for the first call to request.getSession().
Actually use the calculated seed value to initialize the random number
generator, rather than just calculating it :-(. On at least Linux and
Win98, this totally eliminates the multi-second seeding delay --
apparently, the default seeding algorithm is the one that is
computationally expensive.
Revision ChangesPath
1.3 +29 -19
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session/ManagerBase.java
Index: ManagerBase.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session/ManagerBase.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- ManagerBase.java 2000/10/13 23:33:26 1.2
+++ ManagerBase.java 2000/12/22 01:54:33 1.3
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session/ManagerBase.java,v
1.2 2000/10/13 23:33:26 craigmcc Exp $
- * $Revision: 1.2 $
- * $Date: 2000/10/13 23:33:26 $
+ * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session/ManagerBase.java,v
1.3 2000/12/22 01:54:33 craigmcc Exp $
+ * $Revision: 1.3 $
+ * $Date: 2000/12/22 01:54:33 $
*
*
*
@@ -86,7 +86,7 @@
* be subclassed to create more sophisticated Manager implementations.
*
* @author Craig R. McClanahan
- * @version $Revision: 1.2 $ $Date: 2000/10/13 23:33:26 $
+ * @version $Revision: 1.3 $ $Date: 2000/12/22 01:54:33 $
*/
public abstract class ManagerBase implements Manager {
@@ -413,21 +413,31 @@
public synchronized Random getRandom() {
if (this.random == null) {
- log(sm.getString("managerBase.seeding", randomClass));
- try {
- Class clazz = Class.forName(randomClass);
- this.random = (Random) clazz.newInstance();
- long seed = System.currentTimeMillis();
- char entropy[] = getEntropy().toCharArray();
- for (int i = 0; i entropy.length; i++) {
- long update = ((byte) entropy[i]) ((i % 8) * 8);
- seed ^= update;
- }
- } catch (Exception e) {
- log(sm.getString("managerBase.random", randomClass), e);
- this.random = new java.util.Random();
- }
- log(sm.getString("managerBase.complete", randomClass));
+synchronized (this) {
+if (this.random == null) {
+// Calculate the new random number generator seed
+log(sm.getString("managerBase.seeding", randomClass));
+long seed = System.currentTimeMillis();
+char entropy[] = getEntropy().toCharArray();
+for (int i = 0; i entropy.length; i++) {
+long update = ((byte) entropy[i]) ((i % 8) * 8);
+seed ^= update;
+}
+try {
+// Construct and seed a new random number generator
+Class clazz = Class.forName(randomClass);
+this.random = (Random) clazz.newInstance();
+this.random.setSeed(seed);
+} catch (Exception e) {
+// Fall back to the simple case
+log(sm.getString("managerBase.random", randomClass),
+e);
+this.random = new java.util.Random();
+this.random.setSeed(seed);
+}
+log(sm.getString("managerBase.complete", randomClass));
+}
+}
}
return (this.random);
1.5 +11 -4
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session/StandardManager.java
Index: StandardManager.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session/StandardManager.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- StandardManager.java 2000/10/14 21:43:54 1.4
+++ StandardManager.java 2000/12/22 01:54:33 1.5
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session/StandardManager.java,v
1.4 2000/10/14 21:43:54 craigmcc Exp $
- *
Re: Bug #55: Default for included files is 8859_1, with no option to set otherwise
Hans Bergsten wrote: ... So, the only possible remaining thing I can think of is to make sure the encoding specified by jspEncoding is also used as the "-encoding" argument to the javac command. It is. -- Pierre
back port to 3.2 -- JspInterceptor
Tried to back port the last fix I made to Jasper in tomcat 4.0 to tomcat 3.2 (the fix related to bug report #269 -- java encoding). Was almost there until I realized there is a new class "JspInterceptor" in tomcat 3.2 that is impacted by that fix. Unfortunately, I'm not too knowledgeable about this new class and am afraid I might miss something. So, if some kind sould wants to do the port, all the details are in my last commit. Otherwise, I'd need someone to explain to me the relationship between the Compiler and JspInterceptor classes. [Sorry, too tired and getting lazy...] -- Pierre
RE: Bug #55: Default for included files is 8859_1, with no option to set otherwise
Pierre Delisle is wondering:
-
Bug #55
-
Synopsis:
Default for included files is 8859_1, with no option to
set otherwise.
[SNIP]
I'm not sure I fully understand what's described there,
so here is what I believe should be done.
The "encoding" for a JSP file is currently handled as follows:
1. In Compiler.java, we create a JspReader for the top-level
("including") jsp file using the 8859_1 encoding.
2. Using that JspReader, we check if there is a page directive
with 'contentType' specified. If there is, then
a new JspReader for the page is created with the encoding
set to the
"charset" specified in the contentType value of the page
directive; otherwise we stick with the default 8859_1 encoding.
3. When a page is included, JspReader.pushFile() is called,
and the encoding passed as argument appears to always
be null (since no encoding attribute can be specified in
the "include" directive, reading 'encoding' off of the
attributes appears to be a bug in JspParseEventListener).
Because it is null, it always defaults to 8859_1.
If I understand well the intent of the bug report, we'd need the
following modifications:
- In step 2, if contentType is not specified in the "including" page,
set the encoding to be:
encoding = System.getProperty("file.encoding", "8859_1");
This means that the default encoding of all JSP files at a
site could
be defined globally using system property "file.encoding".
I don't think this is spec-compliant, and would be reluctant
to make that change.
- In step 3, use the encoding of the "including" page.
This would fix what I believe is a bug in the current
implementation.
Comments?
Maybe I'm not reading carefully enough (and I haven't had time to trace the
code) but I don't understand what you mean in your "modifications".
The correct behavior seems to me that when a file is included, a 'fake'
JspReader should be created to scan the file for a @page directive with a
contentType, then create the 'real' JspReader using either the @page
directive if it was found, or the encoding of the including file as a
default.
You may be already saying what I just said, and I hope you are :-) Hans'
replies have confused me(!), because they don't really seem to apply to this
bug.
Hope this helps,
Brian
-
Brian Bucknam
WebGain, Inc.
[EMAIL PROTECTED]
Re: Bug #55: Default for included files is 8859_1, with no optionto set otherwise
Maybe I'm not reading carefully enough (and I haven't had time to trace the code) but I don't understand what you mean in your "modifications". The correct behavior seems to me that when a file is included, a 'fake' JspReader should be created to scan the file for a @page directive with a contentType, then create the 'real' JspReader using either the @page directive if it was found, or the encoding of the including file as a default. You may be already saying what I just said, and I hope you are :-) Yes, I am saying what you just said. -- Pierre
Re: Bug Report #649
Tomoaki From: Tomoaki Okitsu [EMAIL PROTECTED] Subject: Bug Report #649 Date: Fri, 22 Dec 2000 10:32:32 +0900 Message-ID: [EMAIL PROTECTED] http://tomcat.3.2.1/examples/jsp/num/numguess.jsp%20 I test this url. But I get "404 Not Found" and don't see a JSP source code. This bug may be system dependent. Would you describe your OS and its release? Anyway, this bug's cause is the almost same as BugRat Report #513. If a filename has trailers which is constructed by space characters (CR, LF, SPACE etc.), Tomcat misinterprets its MIME-type and return its source code in text/plain format. Kazuhiro Kazama ([EMAIL PROTECTED]) NTT Network Innovation Laboratories
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
