Friendster
Funny...I got a JSP stack trace which revealed Friendster uses Catalina. Talk about a high load that is probably melting their JVM's...what a cool concept...too bad they used that JSP crap...=) -jon -- BU** SH** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JDK 1.4 - again
on 2003/2/21 3:40 PM, Steve Burrus [EMAIL PROTECTED] wrote: Gentlemen, as I really do appreciate all of the discussion about just how fast Resin and the others are, I was MAINLY asking about just what it is!!! Is it also a web container/application server like my Tomcat is? And in yer reply to me, would you also tell me how it's set up? Wow! When did hell freeze over? =) -jon -- StudioZ.tv /\ Bar/Nightclub/Entertainment 314 11th Street Folsom /\ San Francisco http://studioz.tv/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Interesting
I wonder if one could use these techniques to hack a servlet engine somehow and get from one context to another (assuming you had access to run servlets in it...ie: shared hosting)... http://www.javaspecialists.co.za/archive/Issue014.html -jon -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Duplicate session IDs are *common*
on 2003/1/9 10:28 PM, Remy Maucherat [EMAIL PROTECTED] wrote: I can't reproduce an id collision so far. Remy I'm sure you aren't running the same level of concurrency that say a company like Maxis is running. Duplicate the environment and the problems become clear. -jon -- StudioZ.tv /\ Bar/Nightclub/Entertainment 314 11th Street @ Folsom /\ San Francisco http://studioz.tv/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PATCH] forward instead of redirect for welcome files
on 2003/1/3 4:03 PM, Matt Parker [EMAIL PROTECTED] wrote: I'd like to suggest that catalina perform a forward, rather than a redirect, for requests that end with '/'. With a redirect, special configuration is necessary for proxy servers to work correctly. Also, a forward doesn't require an additional round trip to the client--a redirect must get back to the client and the client then issues a new request. I've tested this under Linux. Thanks! Matt That goes against the behavior of most HTTP servers, including Apache HTTPd. -jon -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Duplicate session IDs?
on 2002/12/24 5:52 AM, Tim Funk [EMAIL PROTECTED] wrote: I hope you were joking about the monotonic increase of sessionIds. If that were done - it would be trivial to steal another's sessionId by guessing. How is that? laskdfowifjwo2i3jofij2oi3jofwjieogih934htwo4i1 io2oiwejofiwjoijr9238jr9iejofij2oi3jro23ij2i32 Aslkdjfalskdjflaksjdflkasjdflkjlsdkjflaskjdfl3 lakdjflkasjdflkjwoeirjowiejo2ij4o3ij4o2i4o3jo4 flaksjdflksajdflkjsdlfkjsdlkfalsdjflasdkflksd5 laksdfjlkasjdflaskjdflksjdfowiejreowiefjowiee6 The only problem with it is that the session id would grow in length as more digits are added. I don't see how adding a number would make things more easily to steal (as long as the first part is unique random garbage), but maybe I'm missing something. It would be best to do something like this: SHA1(laskdfowifjwo2i3jofij2oi3jofwjieogih934htwo4i1) SHA1(io2oiwejofiwjoijr9238jr9iejofij2oi3jro23ij2i32) SHA1(Aslkdjfalskdjflaksjdflkasjdflkjlsdkjflaskjdfl3) SHA1(lakdjflkasjdflkjwoeirjowiejo2ij4o3ij4o2i4o3jo4) SHA1(flaksjdflksajdflkjsdlfkjsdlkfalsdjflasdkflksd5) ... SHA1(laksdfjlkasjdflaskjdflksjdfowiejreowiefjowiee600) So that you always have a uniform length. Just trying to learn... -jon -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] minimal JSR 154 only distribution
on 2002/12/11 1:36 PM, Amy Roh [EMAIL PROTECTED] wrote: I vote for one distribution with options to disable whatever you don't want. Simple yet everyone gets only what they want. Amy The vote was: Create a separate minimal JSR 154 only distribution of Tomcat 4.x: +1 [] 0 [] -1 [] -jon -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] minimal JSR 154 only distribution
on 2002/12/11 5:06 PM, Glenn Nielsen [EMAIL PROTECTED] wrote: Looking at the original vote I realize that what you ask can't be done. Tomcat 4 is the RI of Servlet 2.3, JSR 154 is for Servlet 2.4. So it isn't possible to create a JSR 154 only dist of Tomcat 4. Glenn Very good point. I withdrawal my vote. A new vote will need to be made for Tomcat 5. I will re-submit when I can also submit a patch for it. =) As soon as I'm over a Scarab deadline (Dec 20th), I'm going to work on this and it is going to turn into another similar Anakia-style deal. If you remember correctly, people -1'd Anakia all over the place until I went and actually built the website using it. Now, to this day, Anakia is still used for the Jakarta site (as well as the main www.apache.org site). So, for something that people said sucks so badly and is such a terrible idea, it has worked very well for quite a while now. =) The same will be true for my minimal distribution idea. -jon -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] minimal JSR 154 only distribution
on 2002/12/10 12:49 AM, Henri Gomez [EMAIL PROTECTED] wrote: - Who will be the release managers for the 'alternative distributions', may be Jon is candidate ? I already volunteered to manage the distribution that I propose. I have been doing distributions of servlet containers since you guys were in diapers. -jon -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] minimal JSR 154 only distribution
on 2002/12/10 12:53 AM, Henri Gomez [EMAIL PROTECTED] wrote: The idea being to provide a minimal tomcat binary and many external modules which will be linked at runtime if present, Apache 2.0 does it that way, why could we do the same. You are repeating my ideas that I have already said on the list. -jon -- StudioZ.tv /\ Bar/Nightclub/Entertainment 314 11th Street @ Folsom /\ San Francisco http://studioz.tv/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Minimal or Modular it's up to you
on 2002/12/10 1:19 AM, Henri Gomez [EMAIL PROTECTED] wrote: What Jon and Pier want is a minimal distribution of Tomcat 5. No. What I want is a distribution of a JSR 154 container with nothing more than the RI of JSR 154. Period. -jon -- StudioZ.tv /\ Bar/Nightclub/Entertainment 314 11th Street @ Folsom /\ San Francisco http://studioz.tv/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] minimal JSR 154 only distribution
on 2002/12/10 1:00 AM, Remy Maucherat [EMAIL PROTECTED] wrote: All I'm seeing is that I shouldn't pay attention to your posts (I should have learnt that a while ago, I guess) ;-) Is that good enough for you ? As Pier says: What-EVER! Sorry, no. You should try to give users as few choices as possible, if you're targetting your software at a broad audience (looking at the download stats, Tomcat has that kind of audience). You never read Joel on software, I suppose ... On the other side of the scale, advanced users who know what they want should be able to tweak the software to the death (that's my opinion; Joel doesn't concieve software for advanced users, appatrently). Tomcat allows that. However, the golden rule is that normal people shouldn't have to care (of course, it's far from perfect, and Tomcat is still way to hard to use for the average Joe, but that's another story, and I believe we're working on it). You admit Tomcat is to hard to use. The reason it is to hard to use is because it is bundled with a whole bunch of crap no one needs. I want to get rid of the crap and just let people download something simple. -jon -- StudioZ.tv /\ Bar/Nightclub/Entertainment 314 11th Street @ Folsom /\ San Francisco http://studioz.tv/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Minimal or Modular it's up to you
on 2002/12/10 1:46 AM, Henri Gomez [EMAIL PROTECTED] wrote: Ok, so just take the tomcat core and don't install/activate the jasper module. Exactly. -jon -- StudioZ.tv /\ Bar/Nightclub/Entertainment 314 11th Street @ Folsom /\ San Francisco http://studioz.tv/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] minimal JSR 154 only distribution
on 2002/12/10 2:36 AM, Henri Gomez [EMAIL PROTECTED] wrote: Yes but add the ability to activate/include modules, which is the Costin idea ;) Nope...Read my message with the ascii chart in it... -jon -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] minimal JSR 154 only distribution
on 2002/12/10 7:30 AM, Costin Manolache [EMAIL PROTECTED] wrote: Yes - Jon will not be happy ( as far as I know Jon ) if jasper.jar is anywhere in the distribution, even if it is not used. If Jasper is in there, then it isn't a (repeat) 'minimal JSR 154 only distribution.' -jon -- StudioZ.tv /\ Bar/Nightclub/Entertainment 314 11th Street @ Folsom /\ San Francisco http://studioz.tv/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
FW: [VOTE] minimal JSR 154 only distribution
I'm going to repost this message once again because it seems Remy and Costin didn't bother reading it the first time and are now essentially agreeing to what I suggested below. What-EVER! -jon -- Forwarded Message From: Jon Scott Stevens [EMAIL PROTECTED] Reply-To: Tomcat Developers List [EMAIL PROTECTED] Date: Mon, 09 Dec 2002 01:16:20 -0800 To: tomcat-dev [EMAIL PROTECTED] Subject: Re: [VOTE] minimal JSR 154 only distribution What I would love to see is a tree of downloads where each one gains more and more features (it is additive). Such as: JSR-154 Implementation / \ Jasper Velocity / \ \ Admin Tool (JMX) Java Server Feces Scarab That way, you only need to download what you need. Bundles are easily created by simply picking off the branch of the tree that you want. If you want the Tomcat distribution with web based administration abilities, then you grab it at the Admin Tool level and so on. We can even build an ant based system which is able to help us manage the selection of components to include in the distribution. This would be similar to the way that we currently have jar repositories and dependencies, but on an application level. Click here to install Jasper, Struts, etc. Not only does this provide our users the ability to simply get what they need (and add it after the fact if they don't have it), it helps us focus on providing a pluggable system which is separate from the other systems (ie: clean dependencies). I personally think that this is a much cleaner way of providing distributions because it does not require people to learn or deal with things they do not care about. Options are a good thing. Let's not limit ourselves. One last point, we should be able to experiment around here. The negative votes have been based on biases about what I think about Jasper and my opinions. They are not based on the idea that experimentation is a good thing and I think that is just plain wrong and very closed minded. Who are you to decide what our users may or may not like? In the end, if things don't work out, then fine at least we learned something and we can move on to the next thing. What do we really have to loose here? -jon -- StudioZ.tv /\ Bar/Nightclub/Entertainment 314 11th Street @ Folsom /\ San Francisco http://studioz.tv/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] SPAM: Start SpamAssassin results SPAM: -109.30 hits, 5 required; SPAM: * -0.8 -- Found a In-Reply-To header SPAM: * -0.3 -- User-Agent header indicates a non-spam MUA (Entourage) SPAM: * 0.3 -- BODY: Asks you to click below SPAM: * -0.3 -- Long signature present (empty lines) SPAM: * -100.0 -- From: address is in the user's white-list SPAM: * -6.0 -- User is listed in 'whitelist_to' SPAM: * -0.2 -- Email came from some known mailing list software SPAM: * -2.0 -- AWL: Auto-whitelist adjustment SPAM: SPAM: End of SpamAssassin results -- End of Forwarded Message -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] minimal JSR 154 only distribution
on 2002/12/10 2:52 PM, Costin Manolache [EMAIL PROTECTED] wrote: What Remy and Costin are agreeing on is one tomcat release that includes multiple profiles - so people can run jsr154 or minimal or default or all. (repeat) Which is what I already suggested. I don't know why you have the impression that I have to bother reading your messages. Costin Because you respond to them. Geeez Costin. -jon -- StudioZ.tv /\ Bar/Nightclub/Entertainment 314 11th Street @ Folsom /\ San Francisco http://studioz.tv/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] minimal JSR 154 only distribution
on 2002/12/10 3:23 PM, Glenn Nielsen [EMAIL PROTECTED] wrote: Then we only have one download (perhaps large) but with a variety of different installs. Right now, I have to specially distribute Tomcat for Scarab. Instead, I want one small download that I can point people at and tell them to copy their scarab.war into. It should be a download which only contains code and data that Scarab requires (which is a minimal JSR 154 container). -jon -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] minimal JSR 154 only distribution
on 2002/12/10 3:15 PM, Costin Manolache [EMAIL PROTECTED] wrote: Yes - your admin tool argument doesn't make sense. You can easily precompile the admintool ( and we should do it anyway ) and run it in the JSR154-only container - if you want to. I thought that you need Jasper in order to run JSP's (compiled or not). -jon -- StudioZ.tv /\ Bar/Nightclub/Entertainment 314 11th Street @ Folsom /\ San Francisco http://studioz.tv/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] minimal JSR 154 only distribution
Yes - your admin tool argument doesn't make sense. You can easily precompile the admintool ( and we should do it anyway ) and run it in the JSR154-only container - if you want to. I thought that you need Jasper in order to run JSP's (compiled or not). Yes, you need them since even if the classes are compiled, they are still having reference to org.apache.jasper.* -- Jeanfrancois Then I wonder what the heck Costin thinks he is talking about. But then again, I have been wondering that for years now. =) -jon -- StudioZ.tv /\ Bar/Nightclub/Entertainment 314 11th Street @ Folsom /\ San Francisco http://studioz.tv/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] minimal JSR 154 only distribution
on 2002/12/10 4:23 PM, Glenn Nielsen [EMAIL PROTECTED] wrote: Right. You need a distribution tailored for your use. Others may have slightly different dists they need. Where does it stop? Would we end up with 2-3 dozen different distributions? Tomcat can be used in so many different ways that it can be very difficult for those devs who vote to decide on how many dists there should be and what they should contain. The line is very clear where it stops: A JSR 154 only container and a JSR 154 + JSR 152 container. That is why I'm not asking for any 'external' stuff to be included in the Tomcat distribution. I don't want to blur the lines. -jon -- StudioZ.tv /\ Bar/Nightclub/Entertainment 314 11th Street @ Folsom /\ San Francisco http://studioz.tv/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] minimal JSR 154 only distribution
on 2002/12/10 4:59 PM, Costin Manolache [EMAIL PROTECTED] wrote: Yes - your admin tool argument doesn't make sense. You can easily precompile the admintool ( and we should do it anyway ) and run it in the JSR154-only container - if you want to. I thought that you need Jasper in order to run JSP's (compiled or not). Yes, you need them since even if the classes are compiled, they are still having reference to org.apache.jasper.* No, you don't. You can just copy jasper-runtime.jar in WEB-INF/lib and you're done. At least that used to work in 3.3 - I don't see any reason it'll not work ( except maybe some bugs ). Costin Huh? jar -xvf jasper-runtime.jar created: META-INF/ extracted: META-INF/MANIFEST.MF created: org/ created: org/apache/ created: org/apache/jasper/ created: org/apache/jasper/logging/ created: org/apache/jasper/util/ created: org/apache/jasper/runtime/ created: org/apache/jasper/resources/ ... -jon -- StudioZ.tv /\ Bar/Nightclub/Entertainment 314 11th Street @ Folsom /\ San Francisco http://studioz.tv/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] minimal JSR 154 only distribution
What I would love to see is a tree of downloads where each one gains more and more features (it is additive). Such as: JSR-154 Implementation / \ Jasper Velocity / \ \ Admin Tool (JMX) Java Server Feces Scarab That way, you only need to download what you need. Bundles are easily created by simply picking off the branch of the tree that you want. If you want the Tomcat distribution with web based administration abilities, then you grab it at the Admin Tool level and so on. We can even build an ant based system which is able to help us manage the selection of components to include in the distribution. This would be similar to the way that we currently have jar repositories and dependencies, but on an application level. Click here to install Jasper, Struts, etc. Not only does this provide our users the ability to simply get what they need (and add it after the fact if they don't have it), it helps us focus on providing a pluggable system which is separate from the other systems (ie: clean dependencies). I personally think that this is a much cleaner way of providing distributions because it does not require people to learn or deal with things they do not care about. Options are a good thing. Let's not limit ourselves. One last point, we should be able to experiment around here. The negative votes have been based on biases about what I think about Jasper and my opinions. They are not based on the idea that experimentation is a good thing and I think that is just plain wrong and very closed minded. Who are you to decide what our users may or may not like? In the end, if things don't work out, then fine at least we learned something and we can move on to the next thing. What do we really have to loose here? -jon -- StudioZ.tv /\ Bar/Nightclub/Entertainment 314 11th Street @ Folsom /\ San Francisco http://studioz.tv/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] Minimal tomcat ( JSR154 + JSR152 )
on 2002/12/9 7:16 AM, Costin Manolache [EMAIL PROTECTED] wrote: Votes: [ ] +1 I like the idea, I might help [ ] -1 I don't like the idea, I won't help. +0 I don't have time to help, but I like the idea. -jon -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] minimal JSR 154 only distribution
on 2002/12/9 7:27 AM, Remy Maucherat [EMAIL PROTECTED] wrote: I'd really like to avoid the proliferation of too many distributions. I don't agree with that. There is nothing wrong with giving users choices. -jon -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] minimal JSR 154 only distribution
on 2002/12/9 7:32 AM, Henri Gomez [EMAIL PROTECTED] wrote: What about using a minimal tomcat core with plugged modules to give access to jsp/jmx ? Will make both Costin, and Jon happy and let us have only one distribution with clear indication in server.xml on how to activate/desactive such module. That does not make me happy. You are missing my point. Read the subject line of this message. -jon -- StudioZ.tv /\ Bar/Nightclub/Entertainment 314 11th Street @ Folsom /\ San Francisco http://studioz.tv/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] minimal JSR 154 only distribution
on 2002/12/9 7:51 AM, Costin Manolache [EMAIL PROTECTED] wrote: No Jon - my vote wasn't based on your biasses about jasper, but on the biasses of many members of the tomcat community. So, you speak for these people? I don't think so. 5.0 was supposed to be the release we make togheter, as a united community based on consensus. My proposal has nothing to do with that. There is one jakarta project where experimentation without consensus was the operating mode - and I certainly don't like the result. You may remember about the division of the tomcat community on 3.3/4.0 - and I don't think 69K of code ( jasper runtime ) would justify another division. I find it really funny that you are now forced to work on 4.x. Consensus. What consensus? This has nothing to do with which container to use. It has everything to do with giving people options. -jon -- StudioZ.tv /\ Bar/Nightclub/Entertainment 314 11th Street @ Folsom /\ San Francisco http://studioz.tv/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] minimal JSR 154 only distribution
on 2002/12/9 8:21 AM, Remy Maucherat [EMAIL PROTECTED] wrote: People cannot agree on everything. Here, we're talking about relatively minor topics. This issue won't end up in a division of the community, but rather in one additional binary distribution based on the same codebase. I can live with that (well, as long as I'm not the one building them all ;-) ). If the lack of consensus spreads to more serious topics (like a 4.2.x branch), then I would agree it could be worrying. Remy Finally, Remy is starting to see the light. -jon -- StudioZ.tv /\ Bar/Nightclub/Entertainment 314 11th Street @ Folsom /\ San Francisco http://studioz.tv/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] minimal JSR 154 only distribution
on 2002/12/9 9:14 AM, Jeanfrancois Arcand [EMAIL PROTECTED] wrote: I personally think that this is a much cleaner way of providing distributions because it does not require people to learn or deal with things they do not care about. Options are a good thing. Let's not limit ourselves. Youy don't need to learn JSP/Admin Tool if you don't use it. The actual Tomcat installation doesn't require you to learn the Admin Tool or JSP Read what I wrote again. I said Learn or deal with and I made no specific point about the JSP/Admin Tool. I'm with this group since August, and did not see any post from you since last week. So my vote is certainly not based on your biaises :-). You vote is based on a lack of history and a view of the larger picture. Simplicity. But since we don't have any statistic about the user (what we want, what he use when he download Tomcat), it is hard to prove he doesn't use JSP/Admin Tool/JMX, and hard to prove he doesn't use it. Exactly my point. -jon -- StudioZ.tv /\ Bar/Nightclub/Entertainment 314 11th Street @ Folsom /\ San Francisco http://studioz.tv/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] Minimal tomcat ( JSR154 + JSR152 )
on 2002/12/9 9:37 AM, Costin Manolache [EMAIL PROTECTED] wrote: I don't see why a vote on Jon's proposal would affect my proposal ( or any future vote ). I agree. -jon -- StudioZ.tv /\ Bar/Nightclub/Entertainment 314 11th Street @ Folsom /\ San Francisco http://studioz.tv/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] Minimal tomcat ( JSR154 + JSR152 )
on 2002/12/9 9:37 AM, Costin Manolache [EMAIL PROTECTED] wrote: Then make a proposal that maximum 2 tomcat binary distribution should be allowed. I will -1 this vote. -jon -- StudioZ.tv /\ Bar/Nightclub/Entertainment 314 11th Street @ Folsom /\ San Francisco http://studioz.tv/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] Minimal tomcat ( JSR154 + JSR152 )
on 2002/12/9 3:58 PM, Costin Manolache [EMAIL PROTECTED] wrote: It's hard to find something that doesn't exist. ? I hate the practice of using old postings as arguments in most cases - it's normal for people to change their minds. There is a difference between changing your mind and making up the rules as you go along. But in this case you keep making false statements, and not only here. It should be quite easy to look for a [VOTE] or [PROPOSAL] that you made and was voted on tomcat-dev. Then find it. -jon -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] minimal JSR 154 only distribution
on 2002/12/8 7:59 PM, Jeanfrancois Arcand [EMAIL PROTECTED] wrote: (1) Jasper is very a very small jar file. That isn't the question. (2) The Admin Tool should go with the minimal distribution of Tomcat. We decided to include JMX in Tomcat distribution...what's the point having JMX and not the Admin Tool? Maybe JSP is not required by all Tomcat users, but I'm sure a lot of them like to have the Admin Tool . I have never used the Admin Tool. Ever. I don't even know how to use it or what it does. I don't need it and I don't want it. Since I was talking about a JSR 154 ONLY implementation of a Servlet Container (see subject line of this message) and there is absolutely no requirement in JSR 154 to provide the Admin Tool, I don't see how your argument is valid for what I'm proposing. =) -jon -- StudioZ.tv /\ Bar/Nightclub/Entertainment 314 11th Street @ Folsom /\ San Francisco http://studioz.tv/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] minimal JSR 154 only distribution
on 2002/12/8 11:32 PM, Costin Manolache [EMAIL PROTECTED] wrote: I hope that more tomcat committers will send at least a +0 or -0, and even better +1 or -1. There is no need to get into too much debate - just yes and no would help. I agree. Especially since what Jeanfrancois was debating as his -1 reason had nothing to do with what the vote was about. =) -jon -- StudioZ.tv /\ Bar/Nightclub/Entertainment 314 11th Street @ Folsom /\ San Francisco http://studioz.tv/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] minimal JSR 154 only distribution
on 2002/12/7 7:08 AM, Remy Maucherat [EMAIL PROTECTED] wrote: - I think this distribution doesn't have much interest (Jasper is rather small + the vast majority of users want the feature) I don't agree with that, and you have no conclusive proof of that. - As the release manager, I feel lazy, and would like to minimize the possibilities of screwing up a distribution I'm +1 which means that I'm willing to help. I have already posted the ant build for it. - Some Tomcat features depend on Jasper (like the admin webapp) It is a minimal distribution. - If we follow Costin's ideas on bundling, full-tomcat will bundle lots of projects; we can also bundle Velocity here (probably on the condition that it moves to commons-logging, to harmonize dependencies) I never mentioned Velocity and I don't care about bundles of software. I WANT A MINIMAL DISTRIBUTION OF JUST JSR 154. - Users are used to the idea of having JSP support bundled, so this could further increase support issues (even if you put no JSP in bold, I think people will report that their JSP doesn't work) Apache JServ never included JSP and was the first major open source servlet engine. In fact, at the time, JServ couldn't even properly run JSP's. Personally, I think this is a yes or no vote, so I don't think either choice needs a justification. Doesn't really matter what you personally think. The voting rules are clearly defined by the Jakarta charter. -jon -- StudioZ.tv /\ Bar/Nightclub/Entertainment 314 11th Street @ Folsom /\ San Francisco http://studioz.tv/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] minimal JSR 154 only distribution
on 2002/12/7 9:37 AM, Glenn Nielsen [EMAIL PROTECTED] wrote: I will consider voting +1 if any of the other tomcat devs who want this will volunteer to be the release manager for the servlet only distribution. I would find this handy when using Tomcat as a SOAP server where JSP is not needed. Glenn I will volunteer to be the release manager. -jon -- StudioZ.tv /\ Bar/Nightclub/Entertainment 314 11th Street @ Folsom /\ San Francisco http://studioz.tv/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] minimal JSR 154 only distribution
on 2002/12/7 10:45 AM, Jason Hunter [EMAIL PROTECTED] wrote: It seems Jon is more interested in a release without jsp then in a release that includes velocity. Too bad. I think that's to Jon's credit. It shows the goal isn't to put Velocity and JSP on even footing, but just to provide what users want, which is often a more secure server without JSP. -jh- I always love how Jason just gets it. =) Although, security is one point, I simply just don't want JSP in my JSR 154 container. -jon -- StudioZ.tv /\ Bar/Nightclub/Entertainment 314 11th Street @ Folsom /\ San Francisco http://studioz.tv/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] minimal JSR 154 only distribution
on 2002/12/7 4:25 PM, Pier Fumagalli [EMAIL PROTECTED] wrote: Jon, I'm very sorry mate, you're 4 months too late :-( I lost my fight about this very same topic back then... Pier Maybe to late for your opinion, but honestly, I haven't been that impressed with Jetty. I saw very little if any speed increase with Jetty and Scarab and I actually consider Jetty's distribution to be packed with more crud than Tomcat's...but maybe I'm just biased by Tomcat. At this point, I don't think that with JSR 154 and JSR 152 being separate, there is much that anyone here can say negative about distributing JSR 154 only engine. Clearly there is a demand. Clearly it is a good thing to have options. -jon -- StudioZ.tv /\ Bar/Nightclub/Entertainment 314 11th Street @ Folsom /\ San Francisco http://studioz.tv/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: minimal
on 2002/12/6 7:19 AM, Costin Manolache [EMAIL PROTECTED] wrote: Shapira, Yoav wrote: Hi, - jasper ( at least jasper runtime - but probably the whole thing ). Now that we have JSR 154 and JSR 153, can't we make a distribution of Tomcat that does not include Jasper? That would rock. =) Big time +1 on that. I don't use Jasper/JSP pages at all, and while it's not a big hindrance to carry around, I always prefer smaller / lighter / simpler when possible. That won't happen. If you don't use/like - it may be a reason to vote or ask to include whatever you use. At least I refuse to accept I don't like it so nobody should use it. Costin What people are saying is that they would like A distribution of Tomcat without Jasper. We are not saying all distributions of Tomcat should not include Jasper, only A distribution. It has nothing to do with I don't like it so nobody should use it. It simply has to do with the fact that Jasper is no longer a requirement of JSR 154 and therefore there is a demand that people have a servlet container which only offers what is in JSR 154. I want a reference implementation distribution of JSR 154 and only JSR 154. -jon -- StudioZ.tv /\ Bar/Nightclub/Entertainment 314 11th Street @ Folsom /\ San Francisco http://studioz.tv/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[VOTE] minimal JSR 154 only distribution
Create a separate minimal JSR 154 only distribution of Tomcat 4.x: +1 [] 0 [] -1 [] -jon -- StudioZ.tv /\ Bar/Nightclub/Entertainment 314 11th Street @ Folsom /\ San Francisco http://studioz.tv/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Ant build target to create minimal Tomcat without JSP
The target below is used by Scarab's build file to upgrade our distribution
of Tomcat based off a standard binary distribution of Tomcat 4.1.x. Note
that I put the xercesImpl.jar into server/lib because of backwards
compatibility issues with Xerces. Why this isn't done by default is beyond
me. It would save people a lot of headaches.
With little modification, this can be used as the basis to create a minimal
Tomcat distribution.
The only issue remaining is that one needs to come up with a web.xml that
has all the Jasper and other crap removed...
http://scarab.tigris.org/source/browse/scarab/src/tomcat-4.1/conf/web.xml?re
v=1.1content-type=text/x-cvsweb-markup
target name=upgrade-tomcat-4-1-bin
echo
Upgrading Tomcat 4.1 from: ${tomcat.binary.dir}
/echo
copy todir=${tomcat.dist.dir}/bin filtering=no
fileset dir=${tomcat.binary.dir}/bin/
/copy
copy todir=${tomcat.dist.dir}/common/endorsed filtering=no
fileset dir=${tomcat.binary.dir}/common/endorsed
include name=**/xmlParserAPIs.jar/
/fileset
/copy
copy todir=${tomcat.dist.dir}/server/lib filtering=no
fileset dir=${tomcat.binary.dir}/common/endorsed
include name=**/xercesImpl.jar/
/fileset
/copy
copy todir=${tomcat.dist.dir}/common/lib filtering=no
fileset dir=${tomcat.binary.dir}/common/lib
include name=**/commons-collections.jar/
include name=**/naming-common.jar/
include name=**/naming-resources.jar/
include name=**/servlet.jar/
/fileset
/copy
copy todir=${tomcat.dist.dir}/server/lib filtering=no
fileset dir=${tomcat.binary.dir}/server/lib
include name=**/catalina.jar/
include name=**/commons-beanutils.jar/
include name=**/commons-digester.jar/
include name=**/commons-digester.jar/
include name=**/servlets-common.jar/
include name=**/servlets-default.jar/
include name=**/servlets-invoker.jar/
include name=**/tomcat-coyote.jar/
include name=**/tomcat-http11.jar/
include name=**/tomcat-util.jar/
/fileset
/copy
/target
-jon
--
StudioZ.tv /\ Bar/Nightclub/Entertainment
314 11th Street @ Folsom /\ San Francisco
http://studioz.tv/
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: minimal
on 2002/12/5 10:34 AM, Costin Manolache [EMAIL PROTECTED] wrote: And components to be included in minimal: - catalina - coyote - tomcat-util - http11/jk2 - all valves/etc that are required for tomcat to operate. - naming I'm 100% +1 on a minimal distribution of Tomcat 4 that only includes enough crud to allow normal servlets to run. I have one with Scarab and it was a PITA to create because I basically had to trial and error which .jar files needed to be included (and where). Take a look at Scarab's distribution of Tomcat. http://scarab.tigris.org/source/browse/scarab/src/tomcat-4.1/ -jon -- StudioZ.tv /\ Bar/Nightclub/Entertainment 314 11th Street @ Folsom /\ San Francisco http://studioz.tv/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: minimal
on 2002/12/5 11:51 AM, Costin Manolache [EMAIL PROTECTED] wrote: - jasper ( at least jasper runtime - but probably the whole thing ). Now that we have JSR 154 and JSR 153, can't we make a distribution of Tomcat that does not include Jasper? That would rock. =) -jon -- StudioZ.tv /\ Bar/Nightclub/Entertainment 314 11th Street @ Folsom /\ San Francisco http://studioz.tv/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Strange Tomcat 4.1.x release versions
The last official final release was Tomcat 4.1.12 We now have a Tomcat 4.1.16 beta. What is up with this weird release numbering? What happened to Tomcat 4.1.13? Maybe Remy got infected by Sun's marketing. I'm still curious how Sun is going to deal with releasing Java 2.0 and the confusion that is going to create with Java2. What a brain dead idea that one was. I'm also not seeing a vote taking on the list about whether or not to do a release...or at least some sort of advance warning. I just love how this place turns into a free for all. Not. -jon -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Strange Tomcat 4.1.x release versions
on 2002/12/3 11:51 AM, Craig R. McClanahan [EMAIL PROTECTED] wrote: http://nagoya.apache.org/eyebrowse/ReadMsg?[EMAIL PROTECTED]. orgmsgNo=52475 Someone obviously hasn't been keeping up on TOMCAT-DEV mail :-). See the discussions and vote that took place in April 2003, where the Tomcat developers agreed to adopt the version numbering approach that Apache 2.0 (and several other projects) use. A good starting point: http://nagoya.apache.org/eyebrowse/ReadMsg?[EMAIL PROTECTED]. orgmsgNo=39859 Ok, I understand the version number part now. I actually read those discussions but forgot about them. Full brain. But are you also saying that the HTTPd project doesn't announce on the list in advance when a new release is going to happen? -jon -- StudioZ.tv /\ Bar/Nightclub/Entertainment 314 11th Street @ Folsom /\ San Francisco http://studioz.tv/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Strange Tomcat 4.1.x release versions
on 2002/12/3 11:57 AM, Costin Manolache [EMAIL PROTECTED] wrote: It was voted on the list, Remy sent the proposal last week. Ok, I guess I missed that email. Sorry. -jon -- StudioZ.tv /\ Bar/Nightclub/Entertainment 314 11th Street @ Folsom /\ San Francisco http://studioz.tv/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Javac memory leak
on 2002/11/20 7:34 AM, John Trollinger [EMAIL PROTECTED] wrote: We have 2, one is webdav and the other is our actual application. We use a lot of custom tags and a lot of both types of includes (when I say a lot we have jsp pages that include over 500 other jsp pages, and no, this is not my design :) ) Yea, most people blame bad JSP design on others. I blame it on Sun. =) -jon -- StudioZ.tv /\ Bar/Nightclub/Entertainment 314 11th Street @ Folsom /\ San Francisco http://studioz.tv/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit:jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/coreContainerBase.java
on 2002/11/5 1:31 PM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
protected void log(String message) {
-Logger logger = getLogger();
-if (logger != null)
-logger.log(logName() + : + message);
-else
-System.out.println(logName() + : + message);
-
+// Logger logger = getLogger();
+// if (logger != null)
+// logger.log(logName() + : + message);
+// else
+log.info(message);
}
What the heck is that? There are now two methods with the same name for
logging and one goes to info and the other goes to error based on the method
signature? Where is the logic in that?
And god forbid...maybe try formatting your code properly? The spaces are off
and you put the static log at the bottom of the file???
http://java.sun.com/docs/codeconv/html/CodeConventions.doc2.html#1852
-jon
--
To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: 4.0.7 release?
on 2002/10/24 9:23 PM, Glenn Nielsen [EMAIL PROTECTED] wrote: I am running scarab B13 using Tomcat 4.1.x, JDK 1.3.1, and the SecurityManager. I would have to go back and look at my config to see how I am doing it. Once again, we are just testing scarab and working through how we want to configure modules, attributes, etc. for our needs. Wemay not have tried whatever feature causes the problem. Do you have an example of how to trigger it? It is a startup error. Did you have to do anything special to re-order the Xerces in your classpath? -jon -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: 4.0.7 release?
on 2002/10/25 3:40 PM, Glenn Nielsen [EMAIL PROTECTED] wrote: I just checked. I removed xerces related apis from common/endorsed and put them in server/lib. That removed them from the jar's visible to the scarab webapp. But left them available for the container to use. This is using JDK 1.3.1. Regards, Glenn Great! That was the part I couldn't figure out. Scarab now defaults to use Tomcat 4.1.12 (I also worked around the bug I reported that was fixed) and I withdraw my request to do a release of 4.0.7. The only sad thing to report is that at first glance Tomcat 4.1.12 doesn't seem any faster than Tomcat 4.0.6. -jon -- StudioZ.tv /\ Bar/Nightclub/Entertainment 314 11th Street @ Folsom /\ San Francisco http://studioz.tv/ -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: 4.0.7 release?
on 2002/10/24 1:12 AM, Henri Gomez [EMAIL PROTECTED] wrote: Do you plan to make scarab works with 4.1.x ? Read: http://scarab.tigris.org/faq.html Blame the Xerces team for breaking backwards compatibility. Bah. -jon -- StudioZ.tv /\ Bar/Nightclub/Entertainment 314 11th Street @ Folsom /\ San Francisco http://studioz.tv/ -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: 4.0.7 release?
Scarab only works in Tomcat 4.1.x if you use JDK 1.4.x. It does not work with JDK 1.3.x If you can get Scarab to work with Tomcat 4.1.x on JDK 1.3.x, let me know how you got it to work and I will immediately switch Scarab to use Tomcat 4.1.x. Otherwise, I would appreciate it if someone would please do a release of Tomcat 4.0.7 with the latest Coyote as soon as possible. Scarab won't be updated to use Xerces 2.x until SourceCast uses Xerces 2.x and I'm not sure when that will happen. Yes, I know that Scarab is open source and shouldn't have such a requirement, but the fact of the matter is that CollabNet is paying for 99% of Scarab's development and my paycheck, so I do as they say. =) I'm starting to sound like Pier. =) -jon on 2002/10/24 2:06 AM, Glenn Nielsen [EMAIL PROTECTED] wrote: I have scarab running in Tomcat 4.1.12. Though I can't say that we have tried all the features of scarab like XML import/export. Glenn Henri Gomez wrote: Jon Scott Stevens wrote: Can I get a 4.0.7 release? It has an important configuration bug fix that I need for Scarab. Hi Jon, I tried to use Scarab with 4.1.12 but it didn't works. Do you plan to make scarab works with 4.1.x ? -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: 4.0.7 release?
on 2002/10/23 1:11 AM, Remy Maucherat [EMAIL PROTECTED] wrote: Jon Scott Stevens wrote: Can I get a 4.0.7 release? It has an important configuration bug fix that I need for Scarab. There has been zero changes to the 4.0.x branch since 4.0.6 got released. Remy Ok, I guess it went into HEAD. I didn't realize that 4.0.x was on the branch now. A fix was done with regards to proxyName/proxyPort configuration in the HEAD branch (based on a bug I reported) and I would love to see it make it into 4.0.x since Scarab still uses that because of XML parser issues when using JDK 1.3.x. So, if I backport the single fix, will you do a release? =) -jon -- StudioZ.tv /\ Bar/Nightclub/Entertainment 314 11th Street @ Folsom /\ San Francisco http://studioz.tv/ -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
4.0.7 release?
Can I get a 4.0.7 release? It has an important configuration bug fix that I need for Scarab. -jon -- StudioZ.tv /\ Bar/Nightclub/Entertainment 314 11th Street Folsom /\ San Francisco http://studioz.tv/ -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: cvs commit:jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11Constants.java Http11Processor.java InternalOutputBuffer.java
on 2002/10/10 6:14 AM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
+}
+
+
+/**
+ * Specialized utility method: find a sequence of lower case bytes inside
+ * a ByteChunk.
+ */
+protected int findBytes(ByteChunk bc, byte[] b) {
+
+byte first = b[0];
+byte[] buff = bc.getBuffer();
+int start = bc.getStart();
+int end = bc.getEnd();
+
+// Look for first char
+int srcEnd = b.length;
+
+for (int i = start; i = (end - srcEnd); i++) {
+if (buff[i] != first) continue;
+// found first char, now look for a match
+int myPos = i+1;
+for (int srcPos = 1; srcPos srcEnd; ) {
+if (buff[myPos++] != Ascii.toLower(b[srcPos++]))
+break;
+if (srcPos == srcEnd) return i - start; // found it
+}
+}
+return -1;
+
Tabs.
-jon
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
ProxyName problem
Hey all, For Scarab (using Tomcat 4.0.6), I want to be able to do something like this (server.xml): Connector className=org.apache.coyote.tomcat4.CoyoteConnector port=@TOMCAT_HTTP_PORT@ minProcessors=5 maxProcessors=75 enableLookups=true redirectPort=8443 acceptCount=10 debug=0 connectionTimeout=6 proxyName=@TOMCAT_PROXY_NAME@ proxyPort=@TOMCAT_PROXY_PORT@/ Where Ant would then replace proxyName/proxyPort with a value *IF DEFINED*. If it isn't defined, then it would replace it with . Now, this *almost* works in that if proxyPort=, then the default port is used. BUT, if proxyName=, then request.getServerName() returns , which is clearly bad. Instead, if it is , I would rather have it return the default that the Host: header is set to (or worst case, use InetAddress.getLocalHost().getHostName();). Comments? -jon -- StudioZ.tv /\ Bar/Nightclub/Entertainment 314 11th Street @ Folsom /\ San Francisco http://studioz.tv/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: jk2 and daemon ( was Re: commons-daemon release ?)
on 2002/10/10 6:50 PM, Pier Fumagalli [EMAIL PROTECTED] wrote: I can tell you that our main Java instance for VNUNET.COM takes approximately 4 to 5 minutes to start... OUCH. -jon -- StudioZ.tv /\ Bar/Nightclub/Entertainment 314 11th Street @ Folsom /\ San Francisco http://studioz.tv/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit:jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat4CoyoteConnector.java
on 2002/10/10 7:33 PM, [EMAIL PROTECTED] [EMAIL PROTECTED]
wrote:
+if(! .equals(proxyName)) {
I usually do:
if (proxyName != null proxyName.length() 0)
Looking at the source code to String.java, that is a far more efficient way
to do things (would be nice if that code was at the top of String.equals(),
but it isn't). You can probably take out the null check, if you know the
string won't be null, but that is only a minor optimization.
-jon
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Servlet API 2.2 2.3
on 2002/9/25 9:16 AM, Adrian Almenar [EMAIL PROTECTED] wrote: Ok, but can you put a release on the servlet api ?? if i only want the servlet api, i need to download all tomcat tar.gz. how can i download a servlet 2.2, 2.3 api source without being a nightly. Either grab it from CVS or try this one: http://java.sun.com/products/servlet/download.html -jon -- StudioZ.tv /\ Bar/Nightclub/Entertainment 314 11th Street @ Folsom /\ San Francisco http://studioz.tv/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [SECURITY] Apache Tomcat 4.x JSP source disclosurevulnerability
on 2002/9/25 6:27 AM, Costin Manolache [EMAIL PROTECTED] wrote: Well, this is not a very good policy IMO. Self-contained applications are a good thing ( IMO ). Then store your templates in the WEB-INF directory. That is what we do with Scarab, which is 100% self contained. And of course, JSPs don't have to be stored in the webroot either - and in general shouldn't be there except for development. It's better (IMO) to just precompile and include only the generated servlets - at least for a category of webapps. Correct, but what is *encouraged* by default is to store them in the webroot. Maybe you guys should fix that. jakarta-tomcat-4.0.5/webapps/examples/jsp -jon -- StudioZ.tv /\ Bar/Nightclub/Entertainment 314 11th Street @ Folsom /\ San Francisco http://studioz.tv/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [SECURITY] Apache Tomcat 4.x JSP source disclosurevulnerability
on 2002/9/24 4:59 AM, Remy Maucherat [EMAIL PROTECTED] wrote: A security vulnerability has been confirmed to exist in all Apache Tomcat 4.x releases (including Tomcat 4.0.4 and Tomcat 4.1.10), which allows to use a specially crafted URL to return the unprocessed source of a JSP page, or, under special circumstances, a static resource which would otherwise have been protected by security constraint, without the need for being properly authenticated. Once again...JSP sucks and Velocity is the right way to go...you will never have to worry about your container spilling your beans (pun intended). Given that Tomcat gets around 100k+ downloads/week...imagine how many servers now need to be updated and how much money and time that will cost to do so? http://jakarta.apache.org/velocity/ Wake up people. Velocity is faster and more secure than JSP will ever be. -jon -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [SECURITY] Apache Tomcat 4.x JSP source disclosurevulnerability
on 2002/9/24 5:15 PM, Steve Downey [EMAIL PROTECTED] wrote: http://localhost:8080/velexample/servlet/org.apache.catalina.servlets.DefaultS ervlet/sample.vm Unlike JSP, we don't store (or encourage people to store) .vm files in the webroot. They can be anywhere on the fileystem and with custom resource loaders could even be stored in a database on another machine somewhere. -jon -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Jasper 2 Question
on 2002/9/19 8:06 AM, Lenny Karpel [EMAIL PROTECTED] wrote: sorry .. I don't understand your response ! are you saying that we shouldn't use jsp ? I have been saying that for years now! http://jakarta.apache.org/velocity/ymtd/ymtd.html =) -jon -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: 4.1.10 tarball is borked.
on 2002/9/18 3:35 PM, Ian Darwin [EMAIL PROTECTED] wrote: Well I guess it must be, it's on gnu.org. http://www.gnu.org/manual/tar/html_node/tar_toc.html -jon -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: 4.1.10 tarball is borked.
on 2002/9/17 7:01 AM, Ian Darwin [EMAIL PROTECTED] wrote: Er, you mean perhaps that BSD tar doesn't yet support the non-standard GNU extensions? Like being able to support simple things like directory paths longer than 255 characters? If it isn't a standard, it should be! =) -jon -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: 4.1.10 tarball is borked.
on 2002/9/17 7:01 AM, Ian Darwin [EMAIL PROTECTED] wrote: Er, you mean perhaps that BSD tar doesn't yet support the non-standard GNU extensions? Interesting history on the issue... http://www.gnu.org/manual/tar/html_node/tar_117.html#SEC112 Most OSS projects that I see these days 'standardize' on GNU tar. @see MySQL.com @see default implementation of Ant's tar -jon -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PROPOSAL] Split the repo's
on 7/17/02 11:35 PM, Patrick Luby [EMAIL PROTECTED] wrote: All, Patrick Luby wrote: I tend to agree with Jon on this issue. When I voted for a java-servletapi-5 repository, I made the - I think reasonable - assumption that the java-servletapi-5 repository would only contain the JSR-154 code. After all, the java-servletapi-4 repository has, for as long as I can remember, only contained javax.servlet.* classes. Oops. The javax.servlet.jsp.* packages have been in jakarta-servlet-4 for a long time. In any case, I tried seeing if this issue could be solved by merely moving the javax.servlet.jsp.* packages over to the jakarta-tomcat-jasper repository. Unfortunately, that breaks the jakarta-taglibs code that jakarta-tomcat-jasper depend on. I suspect that there are other projects that may expect the javax.servlet.jsp.* package to be in servlet.jar as well. :( So, even though I don't like the current structure and I think it would be cleaner to have the javax.servlet.jsp.* packages separated from the javax.servlet.* packages, separating them may cause a lot of pain for others who have come to depend on the current structure. I feel that I should take this into my vote and, hence, I am changing my vote to: [X] I don't want the API's split into separate repo's [ ] I don't care [ ] I want the API's split into separate repo's. Patrick I NEVER SAID ANYTHING ABOUT CHANGING THE PACKAGE STRUCTURE OF THE JAR FILE. -jon -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PROPOSAL] Split the repo's
on 7/18/02 7:16 AM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: I'm pretty sure Jon is not proposing this for the benefit of tomcat or tomcat users, but out of his hate for JSPs. From my POV, splitting JSP out of Tomcat would benefit Tomcat and Tomcat users. -jon -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PROPOSAL] Split the repo's
on 7/18/02 7:16 AM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: But that's not the reason I'm voting against - we already have too many CVS trees and this is bad organization, it could be well placed in a single CVS in separate directories. Having a separate CVS for a dozen of files instead of just a separate directory is a bad solution. I'm cool with that modification to the proposal. Separate directory tree's in the same repo is fine with me as long as the building of the Servlet API does not require the other directory tree to exist. ie: The Servlet API should not depend on the JSP API. -jon -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PROPOSAL] Split the repo's
on 7/18/02 4:07 PM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Ok, what about using the original jakarta-servletapi repository and creating a subdir for each JSR ? I think it should be renamed... Or a new jakarta-apis directory and creating one subdir for each JSR ? Sounds good. Maybe even a directory structure like: jakarta-apis/jsr154/src/java jakarta-apis/jsr152/src/java Eventually this can be used for other JSRs where open source implementations are permited - similar with what xml-apis is doing with DOM,SAX,JAXP. +1 -jon -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PROPOSAL] Split the repo's
on 7/18/02 5:13 PM, Craig R. McClanahan [EMAIL PROTECTED] wrote: * Who gets commit access? This goes beyond Tomcat's committers once other APIs start getting added. Craig That is why I suggested separate repo's. -jon -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Missed vote
on 7/17/02 1:30 PM, Kin-Man Chung [EMAIL PROTECTED] wrote: I am sympathetic to Jon's view on separating servlet and JSP API and repositories. One result of the separation would make it likely that package names for JSP 2.0 API may change. JSP2.0 is now in public review, so it may be important to raise this issue before the door is closed. Until the JSP 2.0 spec is changed, it make less sense for us to have two separate repos. (It just make more sense to put javax.servlet.jsp.tagext.TagInfo with javax.servlet classes). They can be in separate repo's with the same package name. If Sun wants to distribute a combined .jar file from their website, then that is fine. But when the software lives on the Jakarta site, it should be in separate repo's. As a committer on both Tomcat and Servlet API, co-founder of Jakarta, as well as a member of the ASF and JSR 053/154, here is my -1 based on the reasons I have already stated (and which 2 other people agreed with me on). Please put the files in separate cvs repo's. -jon -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Missed vote
on 7/17/02 2:47 PM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: so I'm -1 on spliting them up unless the JSR expert groups decide so. As Craig mentioned on the JSR 154 list, this isn't a JSR decision and I wasn't talking about splitting the jar's up...Sun can distribute whatever they want...I'm talking about splitting the repo's up. If you want to make the build system produce a single .jar file from the two repo's then that is fine. We are also talking about the next version of the Servlet API (5.0) which is based on the work of JSR 154...not JSR 053. JSR 154 is specific to the Servlet API and is not working on JSP. So, it no longer makes sense to have the two together for the next revision of the Servlet API. 2 API's, 2 JSR's, 2 CVS repo's. We are at a -1 stalemate. Should we involve the Jakarta PMC now? -jon -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Missed vote
on 7/17/02 3:50 PM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: As I said, xml.apache.org is packaging 3 APIs from 3 different and unrelated sources in a single repo and jar ( DOM, SAX, JAXP ), and that was discussed and aproved by both xalan and xerces communities. Those 3 api's are copies of the originals placed into a single repo. Again, that is different than two different API's original source code stored in the same repo. I don't care too much about 2 repositories, but I do care about a single jar. And I don't like seeing the voting system abused. As I said, I don't care about the single .jar. The primary issue here is the use of the same repo for both of the next generation Servlet and JSP api's. -jon -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[PROPOSAL] Split the repo's
After JSR053 was formed and dependencies were added to the Servlet API from the JSP API, it became clear that this was a bad thing. It was ok to have the JSP API rely on the Servlet API, but not the other way around. The reason for this is because many people choose to use the Servlet API without wanting anything to do with JSP. As part of this realization, the next versions of JSP and the Servlet API were defined as separate JSR's in the JCP. http://jcp.org/jsr/detail/152.jsp http://jcp.org/jsr/detail/154.jsp A vote was cast on the tomcat-dev list that suggested a proposal for Tomcat 5.0. It was unclear to myself and others that this also included combining the CVS repositories for the Servlet API and the JSP API and disrespecting the fact that there are two separate JSR's. Therefore, I'm asking for another vote to split the CVS repositories to represent the split JSR's and adapt the build system of the JSP repository to have a dependency on the Servlet repository, but not the other way around. It is ok to also have the JSP build system generate a single .jar file with both the Servlet api and JSP api included. [ ] I don't want the API's split into separate repo's [ ] I don't care [ ] I want the API's split into separate repo's. -jon -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Missed vote
Arg. I missed the vote where the Servlet API and JSP classes were going to be stored in the same repo. Is there any way that I can -1 that after the fact? Several of us have worked hard over the years to completely separate the Servlet API from the JSP API for various valid reasons (including the fact that some of us don't like JSP). This fight came to an end when Sun decided to create separation of the two API's by having separate JSR's. Now, it seems that we are moving backwards again by having the two API's stored in the same repo and now that I found out that that has happened, I would love to try to stop it from going any further. What can we do here? -jon -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Missed vote
on 7/16/02 1:14 PM, Craig R. McClanahan [EMAIL PROTECTED] wrote: What's so painful about a ten-line build.xml target that creates a separate JAR file with just the javax.servlet and javax.servlet.http API classes, if that's what you need? Sharing a CVS repository has little or nothing to do with how many distributable outputs you create. On the other hand, having both servlet and JSP APIs in a single JAR file is quite useful to a very large number of existing Tomcat (and other container) users, so it should be available also. Craig I used to say the same thing about Turbine and Torque. You could use Torque without using any of the Turbine code...yet people refused to use Torque because it was packaged in the same jar file as Turbine. I also think that keeping two different API's in the same .jar file is a terrible idea. Think about all the issues we have/had with the XML api's. The Servlet API is also on a different release cycle than the JSP API. Also, having things in the same repo makes it to easy to create dependencies between the two API's...that is why the JSR's were split as well. As Pier said, 2 API's, 2 JSR's, 2 CVS repo's. Consider this my strong -1. -jon -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Prove me wrong - take this quiz
on 5/9/02 6:20 PM, Pier Fumagalli [EMAIL PROTECTED] wrote: 1) Make sure my employer is happy not running alpha software in production 2) Feed and pet the cat 3) Find girlfriend (yeah, right) 4) Tease Jon 5) Make mod_webapp happy 6) try out tomcat 4.1 Woo hoo! I'm up to #4! :-) -jon -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [Coyote] Coyote 1.0b9 release notice
on 5/10/02 3:57 PM, Remy Maucherat [EMAIL PROTECTED] wrote: I plan to release Coyote 1.0b9 at the same time as Tomcat 4.0.4 Beta 3 (enough delays, I'm doing it later this afternoon, hopefully). The idea is to have TC 4.0.4b3 be a last beta before final, and Coyote 1.0 would also be released at the same time. I don't know how much this is compatible with whatever work still needs to be done in JK2. If it's not, then Coyote 1.0 will be released later (but obviously, it needs to be before a 4.1.x Stable release). Remy My only semi-major complaint about Coyote (and I told Remy about this in person) is that the container now returns 503 errors until the servlet is started. Before, it would block (not quickly return a 503) until the servlet is finished starting. Remy said it was a result of the new threading that Costin put into things. That said, when the classloader is dumped and reloaded as a result of a resource change, the container (properly) blocks until the servlet is reloaded. Now, why reloading behavior is different than startup behavior, I don't know. -jon -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [Coyote] Coyote 1.0b9 release notice
on 5/10/02 4:42 PM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Well, it is a result of the new threading in the sense that now it is possible to not block. If you want to bock there - it is quite easy to code this :-) I think returning 503 is a correct behavior too - it means 'resource temporary unavailable, try later' - which is exactly the case. Apache should return the same result if it can't connect to tomcat. Costin Even if it is correct behavior in a technical sense, it isn't from a user sense since users don't care or know what a 503 is. Why not just block until the resource is available? I personally consider this a bug since this is changed behavior from every single previous release of Tomcat. So, could you please code it up if it is easy? -jon -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit:jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/runtimePageContextImpl.java
on 5/6/02 4:32 PM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
+Throwable rootCause = ((JspException)t).getRootCause();
+if (rootCause != null) {
+throw new ServletException(t.getMessage(), rootCause);
+} else {
+throw new ServletException(t);
+}
The last } has a tab in front of it.
-jon
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[PATCH] mbean patch
Removes redundant code Minor JLS formatting. -jon mbean.patch Description: Binary data -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit:jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/mbeansMBeanFactory.java
on 5/2/02 5:27 PM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
+if (pathStr.equals(/)) {
Should be '/'
?
-jon
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit:jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/mbeansMBeanFactory.java
on 5/2/02 5:27 PM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
+String pathStr = pname.getKeyProperty(path);
+if (pathStr.equals(/)) {
+pathStr = ;
+}
Also, this seems to repeat code over and over and over...why not make a
simple method?
-jon
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit:jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/coreStandardContext.java
on 4/30/02 2:13 PM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: +if (!started) +throw new IllegalStateException +(sm.getString(containerBase.notStarted, logName())); It drives me nuts that you guys don't even follow the Sun coding spec's. http://java.sun.com/docs/codeconv/html/CodeConventions.doc6.html#449 -jon -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Using InstallAnywhere for Tomcat installer
on 4/23/02 2:33 PM, Remy Maucherat [EMAIL PROTECTED] wrote: To get around this, Zero G has offered to donate a license of InstallAnywhere to Tomcat, as well as installer code. I have a strong -1 on this unless the licese is granted to ALL Jakarta projects. It isn't fair to judge one project under Jakarta more worthy of this license over other projects. -jon -- Nixon: At least with liquor, I don't lose motivation. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/webapp INSTALL.txtREADME.txt
on 3/21/02 5:49 AM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: +NO, IT DOES NOT RUN WITH WINDOWS (your images don't appear and the +whole thing hangs?) AND SINCE I DON'T USE NEITHER POSSESS A MICROSOFT +WINDOWS BASED MACHINE, THERE ARE NO CURRENT PLANS ON MAKING IT WORK +OVER THERE (from my side). DON'T USE NEITHER? Bad bad bad english. If you write it in Italian it will be easier to read. :-) -jon -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: HTML form: multipart/form-data
on 3/11/02 10:08 PM, Bojan Smojver [EMAIL PROTECTED] wrote: I was looking for a class capable of parsing the above, but I couldn't find one in Jakarta source tree (in the meantime I whacked a dodgy one together, so my immediate problem is solved). Can someone point me to the 'proper' one in in Jakarta sources? Bojan The code you need is in here (MultipartStream.java): http://cvs.apache.org/viewcvs.cgi/jakarta-turbine-fulcrum/src/services/java /org/apache/fulcrum/upload/ p.s. Unlike Struts, it can be separated out. p.s. Don't use JavaMail for it, because JavaMail tends to have a lot of overhead. p.s. Once again, Turbine rules. :-) -jon -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: In memory session replication, reminder
on 3/12/02 1:08 AM, GOMEZ Henri [EMAIL PROTECTED] wrote: We speak about spread some times ago but the licence wasn't Apache at this time, and yes it's another good Broadcast system. Good point it support native and java. Spread has a BSD license now. Thanks to many ASF members speaking to the spread developers and convincing them to switch. -jon -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PROPOSAL] Proposed integration of Coyote in 4.0-HEAD
on 3/12/02 6:30 PM, Remy Maucherat [EMAIL PROTECTED] wrote: A) URI decoding refactoring. To avoid doing some URI decoding in many places in the pipeline, a decodedURI field (with associated getter/setter) should be added in the HttpRequest interface, and used in the Catalina pipeline. This also has the advantage to guarantee that no double URI decoding occurs (which can lead to URI-based security attacks). ballot [ ] +1 [ ] +0 [ ] -1: /ballot Q: How can you modify the Servlet API interfaces? -jon -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [4.0.2] [VOTE] Final release
on 2/8/02 10:32 AM, Remy Maucherat [EMAIL PROTECTED] wrote: ballot [ ] +1 - I support this release and I will help [X] +0 - I support this release [ ] -0 - I do not support this release, because: -jon -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit:jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/coreStandardServer.java
Thanks guys for making the changes...I'm sorry I didn't come up with a perfect patch that would be easily applied, I just didn't want to step on toes or do something wrong as a result of my lack of familiarity of the entire code base. thanks, -jon on 1/31/02 1:13 PM, Craig R. McClanahan [EMAIL PROTECTED] wrote: On Thu, 31 Jan 2002, Remy Maucherat wrote: Date: Thu, 31 Jan 2002 13:06:35 -0800 From: Remy Maucherat [EMAIL PROTECTED] Reply-To: Tomcat Developers List [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Subject: Re: cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core StandardServer.java PR: Bugzilla #6130 Submitted by: Jon Stevens [EMAIL PROTECTED] +1 for the change. Does that mean ok for 4.0.2 as well? Nope, but +1 too. I don't see what anything it could break. OK, will do it in a sec. Remy Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit:jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/coreStandardServer.java
on 1/31/02 12:56 PM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
craigmcc02/01/31 12:56:03
Modified:catalina/src/share/org/apache/catalina/connector/http
HttpConnector.java
catalina/src/share/org/apache/catalina/core
StandardServer.java
Log:
Enhance the exception message produced when creating a server socket
fails (typically due to an Address in use situation) to include the
port number of the failed open.
Enhancements to the proposed patch include:
* If the socket is only for a particular IP address, report that also.
* Add a similar enhancement to the message for the shutdown port opening
(although you will normally encounter an error on the connector before
running in to this one).
PR: Bugzilla #6130
Submitted by:Jon Stevens [EMAIL PROTECTED]
Revision ChangesPath
1.30 +16 -6
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/http/HttpC
onnector.java
Index: HttpConnector.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/
http/HttpConnector.java,v
retrieving revision 1.29
retrieving revision 1.30
diff -u -r1.29 -r1.30
--- HttpConnector.java20 Dec 2001 21:25:23 -1.29
+++ HttpConnector.java31 Jan 2002 20:56:03 -1.30
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/
http/HttpConnector.java,v 1.29 2001/12/20 21:25:23 remm Exp $
- * $Revision: 1.29 $
- * $Date: 2001/12/20 21:25:23 $
+ * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/
http/HttpConnector.java,v 1.30 2002/01/31 20:56:03 craigmcc Exp $
+ * $Revision: 1.30 $
+ * $Date: 2002/01/31 20:56:03 $
*
*
*
@@ -66,6 +66,7 @@
import java.io.IOException;
+import java.net.BindException;
import java.net.InetAddress;
import java.net.ServerSocket;
import java.net.Socket;
@@ -102,7 +103,7 @@
*
* @author Craig R. McClanahan
* @author Remy Maucherat
- * @version $Revision: 1.29 $ $Date: 2001/12/20 21:25:23 $
+ * @version $Revision: 1.30 $ $Date: 2002/01/31 20:56:03 $
*/
@@ -972,14 +973,23 @@
// If no address is specified, open a connection on all addresses
if (address == null) {
log(sm.getString(httpConnector.allAddresses));
-return (factory.createSocket(port, acceptCount));
+try {
+return (factory.createSocket(port, acceptCount));
+} catch (BindException be) {
+throw new BindException(be.getMessage() + : + port);
+}
}
// Open a server socket on the specified address
try {
InetAddress is = InetAddress.getByName(address);
log(sm.getString(httpConnector.anAddress, address));
-return (factory.createSocket(port, acceptCount, is));
+try {
+return (factory.createSocket(port, acceptCount, is));
+} catch (BindException be) {
+throw new BindException(be.getMessage() + : + address +
+: + port);
+}
} catch (Exception e) {
log(sm.getString(httpConnector.noAddress, address));
return (factory.createSocket(port, acceptCount));
Hey Craig, there is another factory.createSocket that gets created in the
catch clause right above...seems that that should be in a
try/catch(BindException) as well, doesn't it?
That is why I originally wrapped so much of the code in a single
try/catch...
-jon
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[PATCH] Improving BindException error reporting
Someone on the Scarab list just reported a problem with getting a BindException. It would be easier to debug the problem for the user if the exception that they sent me showed the port number that the server was trying to bind to at the time of the exception. That way, I can tell if it was the shutdown port or the running port. This is a little patch that should improve BindException error reporting. It is against the 4.0.x branch. I'm not sure that I did it 100% right so I'm submitting here in the hopes that someone (Craig? Remy?) will either approve it or fix it and apply it. When you see it, I think that you will get what I'm trying to do. Also, I'm not sure if this patch covers the shutdown port #...if it doesn't that would be another good place to apply it to as well. Thanks, -jon catalina.patch Description: Binary data -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Alternate JMX implementation
on 1/17/02 12:14 PM, Remy Maucherat [EMAIL PROTECTED] wrote: Hi, Tomcat 4 HEAD can now be built and run using an alternate JMX implementation (with a much more open-source friendly license :)): OpenJMX (www.open-jmx.org). Note: OpenJMX 1.0b1 will not work with Tomcat, but a build from OpenJMX CVS will Note 2: The main JMX variable in build.properties has been renamed from jmxri.jar to jmx.jar Remy Awesome! -jon -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
FW: KPMG-2002003: Bea Weblogic DOS-device Denial of Service
I'm curious how Tomcat deals with this issue. Oh yea. Yet another reason why JSP sucks. :-) -jon -- Forwarded Message From: Peter Gründl [EMAIL PROTECTED] Date: Tue, 8 Jan 2002 16:33:26 +0100 To: [EMAIL PROTECTED] Subject: KPMG-2002003: Bea Weblogic DOS-device Denial of Service -=Bea Weblogic DOS-device Denial of Service=- courtesy of KMPG Denmark BUG-ID: 2002003 Released: 8th Jan 2002 Problem: A flaw in the way the Bea Weblogic server handles specific requests containing DOS-devices can cause a Denial of Service situation, where web requests are no longer being serviced. Vulnerable: === - Bea Weblogic Server 6.1 Service Pack 1 for Windows NT/2000 - Older releases and other pure java application servers could be vulnerable, but haven't been tested. Details: When the Weblogic server receives a .jsp request, it invokes an external compiler to deal with the .jsp ressource requested. The server can be fooled into thinking you are requesting a valid .jsp ressource by simply requesting a DOS-device (such as eg. aux) and appending the .jsp extension to it (aux.jsp). The external compiler is then invoked and due to the nature of the DOS-devices, this working thread never finishes. The server can handle about a 10-11 working threads, so when this number of active threads has been reached, the server will no longer service any requests. Since both HTTP and HTTPS are handled by the same module, both are crippled if one is attacked. Vendor URL: === You can visit the vendors webpage here: http://www.beasys.com Vendor response: The vendor was contacted on the 6th of November, 2001. On the 15th of November the vendor confirms that they have reproduced the issue on Windows 2000 and Windows NT. The issue is assigned the bug id: CR062542 by the vendor. On the 3rd of January, 2002 the vendor confirmed the release of the new service pack and that it included the patch for this issue. Corrective action: == Upgrade to Service Pack 2, which can be downloaded here: http://commerce.beasys.com Author: Peter Gründl ([EMAIL PROTECTED]) KPMG is not responsible for the misuse of the information we provide through our security advisories. These advisories are a service to the professional security community. In no event shall KPMG be lia- ble for any consequences whatsoever arising out of or in connection with the use or spread of this information. -- End of Forwarded Message -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
