Re: Tomcat 3.3 / 4.0 confusion, rant and plan...
Liam Magee [EMAIL PROTECTED] wrote: I have been a long-time silent listener on this list, and use Tomcat 3.1 in a production environment. I have been greatly appreciative of the hard work gone into the software to date, and respect that its development is on a volunteer basis. But I fully concur with the sentiments of this posting - for the past couple of months it's been completely unclear as what the development path and release schedule for Tomcat looks like (3.2?, 3.3?, 4.0?). I would like to continue to use Tomcat, and eventually have time to get more involved in its development, but the lack of any obvious plan and schedule leaves companies like ours considering whether we need to fall back to commercial offerings to get any kind of reliability or accountability for the direction of releases. Again, I respect that the basis of this project is volunteer-driven, but it is possible to get a balance between the democratic impulses of OSS and a more rigorous project management approach to 'deliverables'? Let me wear my "foundation member" hat for a while, try to make a point of the current situation, and explain something that is obvious for long-time developers, but might not be so clear for newcomers. First of all let's clear up a long time issue (I reply to webmaster@jakarta too, and this question keeps popping up) What is Tomcat? Tomcat, the Jakarta Apache flagship product, is (as the web site states) the Reference Implementation for the Java Servlet and JavaServer Pages Technologies. Let's try to explain this a little bit: Tomcat is NOT a servlet engine and it is NOT a JSP engine/compiler; Tomcat is the union of those two separate technologies. Some confusion have arised in the past because in the 3.x tree Tomcat is the name of BOTH the servlet engine AND of the full distribution. But, recognized this problem, in the new 4.x tree we changed things to make better understand this distiction: "Catalina" is the servlet engine, "Jasper" is the JSP engine/compiler and "Tomcat" is the union of those two. What does this mean? This means that, at the end, you will be able to download Catalina (if you need only servlets), Jasper (if you want to use JSPs on ANY servlet engine, even on Allaire's JRun hopefully), or Tomcat (if you want to use the full distribution from Apache). Why all this confusion? Why do we need Tomcat? Can't we just have "Catalina" and "Jasper"? No, we can't... Because Tomcat (the full product) is the reference implementation of the Java Community Process' JSR-53, so, one JSR, one specification, one name, one distribution... (Ok, I have to save this one for all the webmaster@jakarta emails). Now, to explain a little bit how we are organized, let me say that we're far from the time when we were a bunch of kids playing at Java.Apache.ORG with JServ. Now we are part of the Apache Software Foundation, and because of that, we have to obey to some rules. Most of our self-imposed regulations were derived by the invaluable experience gathered by the HTTPD project (the web-server) and that was absorbed by all other branches of the foundation by osmosis. We have a voting process, a vetoing process, a list of people who have the right, and the due (I would like to underline this!) to vote on issues. This all is clearly described in our "Guidelines" page, please READ it, because that's the LAW in this community. Once an issue is found (a new release, a new codebase, anything that needs a general agreement), all the committers (people with access to the CVS) are asked for a vote. And when a decision is took, it's a responsibility of those voting committers to maintain what was promised. (Yes, if you're a committer, you have responsibilities in front of the community... Again, we're far from the old JServ days). Now, to sum up what happened in the last few months: Some of us (in particular Craig, me, Jon, Remy and others) weren't feeling comfortable with the Tomcat 3.x (Servlet Engine) codebase. Craig, the main author of what would have become JServ 2.0, asked the permission to create a new propositive servlet engine, we voted, and the "Catalina" proposal was created. When Servlet 2.3 and JSP 1.2 came along, this community was asked to vote again, on what codebase would have been used for this new reference implementation: we had to choose between Tomcat 3.x (Servlet Engine) and Catalina, and we decided to adopt Catalina as our next-generation servlet engine. In those last few days, I've seen emails going around with a "Tomcat 3.3" label stamped upon them, and that's when I started to wonder, and get confused. This community didn't vote for a Tomcat 3.3 release, nor we were asked what we were thinking about such a thing. Puzzled, I started asking around, and, aparently, what was clear in the past (Tomcat 3.2 release and then Tomcat 4.0) was all screwed up. For what concerns me, Tomcat 3.3 doesn't exist as an Apache Project. It was not voted upon, and it is in direct
Re: Tomcat 3.3 / 4.0 confusion, rant and plan...
Luke Holden [EMAIL PROTECTED] wrote: What is the status of the Tomcat 4.0 web connector for apache (if any)? ARRGGH :) :) :) :) You know how to make me suffer... A beta will be available soon Pier - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 3.3 / 4.0 confusion, rant and plan...
"Pier P. Fumagalli" wrote: What is the status of the Tomcat 4.0 web connector for apache (if any)? ARRGGH :) :) :) :) You know how to make me suffer... A beta will be available soon hahahaha :) Well is there any way I can help? Although slightly new to java Ive been programming for a number of years. (I mainly program in c/c++ and php).. however I have recently cought onto the java language and I really enjoy it. I would love to help in any way I can :) -- Luke - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Doh!
Whew! Pier's text below, or something like it, would be good to have in the (Tomcat-4.0?) user's guide. [I know the distinctions made below were made in emails (and docs I didn't read :-)) by Craig, but being vastly ignorant of servlets and JSPs, it all ran together in my mind over time.] Those who want to capitalize on OSS as users, might find paragraph 3 especially important, since it indicates the significance of the names for use as well as for development activity. Roy -- Roy Wilson E-mail: [EMAIL PROTECTED] Let's try to explain this a little bit: Tomcat is NOT a servlet engine and it is NOT a JSP engine/compiler; Tomcat is the union of those two separate technologies. Some confusion have arised in the past because in the 3.x tree Tomcat is the name of BOTH the servlet engine AND of the full distribution. But, recognized this problem, in the new 4.x tree we changed things to make better understand this distiction: "Catalina" is the servlet engine, "Jasper" is the JSP engine/compiler and "Tomcat" is the union of those two. What does this mean? This means that, at the end, you will be able to download Catalina (if you need only servlets), Jasper (if you want to use JSPs on ANY servlet engine, even on Allaire's JRun hopefully), or Tomcat (if you want to use the full distribution from Apache). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 3.3 / 4.0 confusion, rant and plan...
"Pier P. Fumagalli" wrote: So, I'm proposing this plan, and please vote on 2 and 4 (1 and 3 were already voted upon with a bunch of +1s)... 1) Release Tomcat 3.2 final (soon, please!) +1 2) Create a new proposal tree alongside with Catalina (new name to avoid confusion, please) +0 3) Release Tomcat 4.0 (with Catalina, as we all decided) +1 4) Decide wether Tomcat 5.0 will be Catalina based or "whatever" new proposal comes along. -1, way too early to consider this Get the Tomcat 4.0 Apache mod_warp connector committed. +1, ;-) -- Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Tomcat 3.3 / 4.0 confusion, rant and plan...
For what concerns me, Tomcat 3.3 doesn't exist as an Apache Project. It was not voted upon, and it is in direct contrast with what this community decided.rg I'm probably wrong, but I don't remember a vote that said Tomcat 3.2 was a new development over Tomcat 3.1. I thought it was clear that Tomcat 3.1 was an "unfinished" work and Tomcat 3.2 was necessary step down the road to finishing Tomcat's mission to provide an RI for the servlet 2.2/JSP 1.1 specs. In my opinion, Tomcat 3.2 doesn't finish the job. It has enough bugs and out of spec issues that it can't claim to be a "finished" RI. rantAnd it certainly wasn't left in a releasable state when work on it was for the most part abandoned by most everybody back in early summer./rant:-) So for the near term, I plan to put my efforts to "finishing" the Servlet 2.2/JSP 1.1 RI. At this point, my preference is to put that effort into Tomcat 3.3 as opposed to continuing to fix Tomcat 3.2. Though, if there is to be only a Tomcat 3.2 release and no Tomcat 3.3, I would prefer to not release the current Tomcat 3.2 and treat the MAIN branch as Tomcat 3.2.;-) I think Jakarta should provide a "quality" RI for the Servlet 2.2/JSP 1.1 specs, and in the future a "quality" RI for the Servlet 2.3/JSP 1.2 specs. IMHO, to release what we have now as the RI for 2.2/1.1 and say this is as good as the RI gets, would reflect badly on Jakarta. I admit to being selfish in this opinion. It is SAS Institute's intention to use Tomcat with our Java IDE. SAS has enough customers that do not jump on cutting edge technology, that 2.2/1.1 will be in use for a long while. We have a need for a solid Tomcat 3.x implementation, both as the RI and as a "well behaved" web server. This is where I will put my Tomcat 3.x efforts before moving on to Tomcat 4.0. Others are welcome to put their effort where it most interests them. Cheers, Larry Isaacs - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Tomcat 3.3 / 4.0 confusion, rant and plan...
Sorry again, but this time I have to vote -1 on a "new" Tomcat 3.3, expecially before 3.2 final is out of the door. The NEXT major release is going to be Tomcat 4.0, based on Catalina, as we all agreed on months ago. The impression I got from reading the dev list was that 4.x was where everyone was going to be focussing, one 3.x was in a rockin' good state. Isn't that what happened to JServ? I thought the JServ page said something like, "JServ is only bug fixes from now on - go get Tomcat" ? I can't find where I read that now, so maybe I didn't, but I sure thought I did ;) Also, whatever the result of this discussion, we should most definitely have Pier's stuff on the main page (jakarta home and Tomcat home). From an, "I've never seen Tomcat before" being faced with two downloads, which one would you grab, seeing 3.1, 3.2b6 and 4.0M4 available? Maybe 3.2b6 if you're familiar with the software development process. It can confuse people who want to contribute as well. Who is the webmaster for jakarta? The project is very much alive and kicking, but there hasn't been a news update since July! I wouldn't say there there's no news considering the PHP home page ducking =) has updates when new betas are released. Maybe the main page should be a combined news/description page like the Java-Apache home. The list of products on the right with a description and release number? That's hella cool! - r - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Tomcat 3.3 / 4.0 confusion, rant and plan...
"I've never seen Tomcat before" being faced with two downloads, which one would you grab, seeing 3.1, 3.2b6 and 4.0M4 available? "being faced with two downloads, which of these three would you grab?" I think next time I won't get up at 6 am =) I think Jakarta should provide a "quality" RI for the Servlet 2.2/JSP 1.1 specs, and in the future a "quality" RI for the Servlet 2.3/JSP 1.2 specs. IMHO, to release what we have now as the RI for 2.2/1.1 and say this is as good as the RI gets, would reflect badly on Jakarta. FWIW I'm in total agreement here. I think the major functionality that was planned should be implemented, all the known killer bugs fixed up, etc. As a long-time (since early summer =) advocate of Tomcat, I would have a tough time explaining to people, "Well, 3.x is sort of this unfinished thing that they weren't happy with, so they started 4.x". To me, that DOES give the impression that the Tomcat project is indeed what Pier said exactly it is NOT: kids playing around in the org tree. - r - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
BugRat Report #342 has been filed.
Bug report #342 has just been filed. You can view the report at the following URL: http://znutar.cortexity.com:/BugRatViewer/ShowReport/342 REPORT #342 Details. Project: Catalina Category: Feature Requests SubCategory: Enhancement Class: suggest State: received Priority: low Severity: non-critical Confidence: public Environment: Release: Apache Tomcat/4.0-dev JVM Release: java version "1.3.0rc1" Operating System: Linux OS Release: RedHat 7.0 Platform: I386 Synopsis: include $JAVA_HOME/bin when call java or jdb on catalina.sh Description: Including $JAVA_HOME/bin allows to run catalina.sh without setting up the path to run java. you make sure that when you setup JAVA_HOME catalina will pick this up and call the correct java version. Juan Title: BugRat Report # 342 BugRat Report # 342 Project: Catalina Release: Apache Tomcat/4.0-dev Category: Feature Requests SubCategory: Enhancement Class: suggest State: received Priority: low Severity: non-critical Confidence: public Submitter: Juan Jose Pablos ([EMAIL PROTECTED]) Date Submitted: Nov 4 2000, 08:58:50 CST Responsible: Z_Tomcat Alias ([EMAIL PROTECTED]) Synopsis: include $JAVA_HOME/bin when call java or jdb on catalina.sh Environment: (jvm, os, osrel, platform) java version "1.3.0rc1", Linux, RedHat 7.0, I386 Additional Environment Description: there is no a path to locate the java binaries on the enviroment Report Description: Including $JAVA_HOME/bin allows to run catalina.sh without setting up the path to run java. you make sure that when you setup JAVA_HOME catalina will pick this up and call the correct java version. Juan How To Reproduce: null Workaround: null View this report online... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Documentation Progress
Hi all, me again =) The last time we spoke about this, beta 6 was about to be built. Mike Bremford made some schmokin' changes to the mod_jk HOWTO, both of us to the Apache HOWTO and the index page (User's Guide updates were in-progress). There was some confusion w/the tree between Alex and Larry, and I think (???) that was sorted out. The confusion is really why I stopped working on the docs, because I had no clue what was going on and didn't really want to get involved with school starting and whatnot. Now that it's been about a month from that, and 3.2 still isn't released, would anyone mind matching 3.2's branch up with the MAIN branch (docs only of course) so there can be a single set of docs and I can get back to work? Apologies in advance for my horrible CVS-speak, I'll learn it one of these days =) It would mean that the online docs would refer to things not yet working in 3.1, but they already do, and people shouldn't be using it anyways shrug Also, once this is done, is there some way to do this? /tomcat/docs/ -- Tomcat CVS /docs So the latest docs are always online? Maybe this is what's being done already? I don't think the community is helped by having new, relevant documentation buried at the bottom of some tree. Also, having me write some, then send to Larry who has to back-edit them to fit into the 3.2 tree probably isn't the best idea since there's a duplication of work and I'm sure Larry and everyone else, prefer that he cut Java ;) To add to this mess, I'm not sure what to do w.r.t. Catalina! Goal: to help the jakarta-tomcat project as much as I can with docs (for now!). How do I do that? - r - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 3.3 / 4.0 confusion, rant and plan...
Sorry Pier, but I don't think I'm doing anything wrong. I worked ( pretty hard ) on the last year or so on tomcat. I worked ( pretty hard ) convincing other people to contribute. Tomcat 3.1 is better that tomcat 3.0 ( or the old JWSDK ). Tomcat 3.2 ( as it was few months ago ) is better than tomcat3.1. It's not perfect - but it's better. There are fundamental problems ( that are present in other containers as well, even worse !), and 3.3 is going to fix them. I don't care how it'll be called, or where it'll stay ( an Apache Fundation member asked me to go to SourceForge and stop using the name "tomcat" - and Pier is asking me to make it a "revolution" and change the name to something else, as Tomcat is no longer correct ). The fundamental problems are: - can't support charset detection ( i.e. the encoding of the URI ) - there is a limit on performance because of excessive use of Strings - the code still need improvements in the modular structure. I have no idea why tomcat 3.2 hasn't been released - it's not my decision. As far as I'm concerned 3.2 is over ( for me ) - it's a step forward, but (as 3.1 ) it isn't perfect. I don't know any "critical" bug in 3.2 that wasn't in 3.1 also. Regarding the "confusion" of using "tomcat" ( i.e. 2 different codebases with the same name ) - well, I don't quite understand how it is my fault, but I'm going to work on the current ( "evolutionary" ) codebase, whatever you decide to call it. If mighty Apache Members or PMC decide to ban this project, or to change it's name - so be it. You can also revoke my account on locus - feel free to do it, it seems my presence there is less and less wanted. As long as my account still works ( and I'm still a commiter ), I'll continue to work as before - if the code I commit is buggy, please -1 it. I don't think I need a vote to add new features to tomcat 3.3 ( that are present in catalina ) - after all none of that was "proposed" or "voted" on the other codebase. Regarding the implementation of Servlet2.3 and JSP1.2 - I'm curious to see how will you "spin" this, but I think it's important to support the latest specs, and tomcat3 was designed with "facades" from beginning - ask Duncan why. To conclude ( I hope my last mail on this topic ) - I think tomcat3 is very good container, has a very good desing, and I don't think Apache "politics" and Apache hierarchies can stop good code for beeing developed. Costin P.S. I am not allowed to say anything about tomcat 4.0 or catalina, but I do hope that open source magic will work and people will compare the 2 architectures and decide what works better. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Tomcat 3.3 / 4.0 confusion, rant and plan...
time explaining to people, "Well, 3.x is sort of this unfinished thing that they weren't happy with, so they started 4.x". To me, that DOES give the 3.x and 4.x are 2 different servlet containers, with very different design. The only confusing thing is the fact that the same name is used for both, and the number looks like 4 is a continuation of 3. Which one is better should be based on code reading and real-world testing, not on the number that is stick on it. ( BTW, the feature set is very different, the core design is different and of course the performance is different too ) Again, I don't remember when Apache decided to throw away a particular design and codebase and the reasons behind it, but if Members decide so I don't think I can do too much about it. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Tomcat 4.0 Milestone 4 Kudos
Excuse the enthusiasm, but ... I just looked at the docs for about 2 minutes, started up TC4.0, and started looking. It's great! I'm impressed that I can actually DO something right out of the box: it's a great encouragement to learn more. Meanwhile, back at the ranch, ab load testing begins ... Roy -- Roy Wilson E-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-4.0/catalina/src/bin catalina.sh
craigmcc00/11/04 08:08:55
Modified:catalina/src/bin catalina.sh
Log:
Use "$JAVA_HOME/bin/java" instead of "java" to execute the JVM, to ensure
that the correct runtime (based on the setting of JAVA_HOME) is selected,
no matter what is on the user's path. This functionality already exists
in the Windows version of the startup script.
PR: BugRat Bug Reports #341, 342
Submitted by: Juan Jose Pablos ([EMAIL PROTECTED])
Revision ChangesPath
1.9 +7 -7 jakarta-tomcat-4.0/catalina/src/bin/catalina.sh
Index: catalina.sh
===
RCS file: /home/cvs/jakarta-tomcat-4.0/catalina/src/bin/catalina.sh,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- catalina.sh 2000/11/02 06:14:08 1.8
+++ catalina.sh 2000/11/04 16:08:54 1.9
@@ -12,7 +12,7 @@
#
# JAVA_HOME Must point at your Java Development Kit installation.
#
-# $Id: catalina.sh,v 1.8 2000/11/02 06:14:08 remm Exp $
+# $Id: catalina.sh,v 1.9 2000/11/04 16:08:54 craigmcc Exp $
# -
@@ -71,7 +71,7 @@
CP=$i:${CP}
done
echo Embedded Classpath: $CP
- java $CATALINA_OPTS -classpath $CP \
+ $JAVA_HOME/bin/java $CATALINA_OPTS -classpath $CP \
-Dcatalina.home=$CATALINA_HOME \
org.apache.catalina.startup.Embedded "$@"
@@ -86,13 +86,13 @@
if [ "$1" = "-security" ] ; then
echo Using Security Manager
shift
-java $CATALINA_OPTS -classpath $CP \
+$JAVA_HOME/bin/java $CATALINA_OPTS -classpath $CP \
-Djava.security.manager \
-Djava.security.policy==$CATALINA_HOME/conf/catalina.policy \
-Dcatalina.home=$CATALINA_HOME \
org.apache.catalina.startup.Bootstrap "$@" start
else
-java $CATALINA_OPTS -classpath $CP \
+$JAVA_HOME/bin/java $CATALINA_OPTS -classpath $CP \
-Dcatalina.home=$CATALINA_HOME \
org.apache.catalina.startup.Bootstrap "$@" start
fi
@@ -104,14 +104,14 @@
if [ "$1" = "-security" ] ; then
echo Using Security Manager
shift
-java $CATALINA_OPTS -classpath $CP \
+$JAVA_HOME/bin/java $CATALINA_OPTS -classpath $CP \
-Djava.security.manager \
-Djava.security.policy==$CATALINA_HOME/conf/catalina.policy \
-Dcatalina.home=$CATALINA_HOME \
org.apache.catalina.startup.Bootstrap "$@" start \
$CATALINA_HOME/logs/catalina.out 21
else
-java $CATALINA_OPTS -classpath $CP \
+$JAVA_HOME/bin/java $CATALINA_OPTS -classpath $CP \
-Dcatalina.home=$CATALINA_HOME \
org.apache.catalina.startup.Bootstrap "$@" start \
$CATALINA_HOME/logs/catalina.out 21
@@ -120,7 +120,7 @@
elif [ "$1" = "stop" ] ; then
shift
- java $CATALINA_OPTS -classpath $CP \
+ $JAVA_HOME/bin/java $CATALINA_OPTS -classpath $CP \
-Dcatalina.home=$CATALINA_HOME \
org.apache.catalina.startup.Bootstrap "$@" stop
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-4.0/catalina/src/bin catalina.sh
craigmcc00/11/04 08:09:34 Modified:catalina/src/bin catalina.sh Log: Oops ... forgot the "jdb" calls for the debug option. Revision ChangesPath 1.10 +3 -3 jakarta-tomcat-4.0/catalina/src/bin/catalina.sh Index: catalina.sh === RCS file: /home/cvs/jakarta-tomcat-4.0/catalina/src/bin/catalina.sh,v retrieving revision 1.9 retrieving revision 1.10 diff -u -r1.9 -r1.10 --- catalina.sh 2000/11/04 16:08:54 1.9 +++ catalina.sh 2000/11/04 16:09:33 1.10 @@ -12,7 +12,7 @@ # # JAVA_HOME Must point at your Java Development Kit installation. # -# $Id: catalina.sh,v 1.9 2000/11/04 16:08:54 craigmcc Exp $ +# $Id: catalina.sh,v 1.10 2000/11/04 16:09:33 craigmcc Exp $ # - @@ -50,13 +50,13 @@ pushd $CATALINA_HOME if [ "$1" = "-security" ] ; then shift -jdb \ +$JAVA_HOME/bin/jdb \ $CATALINA_OPTS \ -sourcepath ../../jakarta-tomcat-4.0/catalina/src/share \ -classpath $CP -Dcatalina.home=$CATALINA_HOME \ org.apache.catalina.startup.Bootstrap "$@" start else -jdb \ +$JAVA_HOME/bin/jdb \ $CATALINA_OPTS \ -sourcepath ../../jakarta-tomcat-4.0/catalina/src/share \ -classpath $CP -Dcatalina.home=$CATALINA_HOME \ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
BugRat Report #280 was closed (apparently by: Ignacio Ortega)
Report #280 was closed by Person #0 Synopsis: Trailing slash in init parameter value seems to disappear (logged in as: Ignacio Ortega) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
BugRat Report #244 was linked to Bug #27(apparently by:Ignacio Ortega)
BugRat Report #244 was linked to Bug #27 (logged in as:Ignacio Ortega) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Tomcat 3.3 / 4.0 confusion, rant and plan...
So what are our goals, anyhow ? I think we should concentrate on the following goals (in this order): 1) Provide a quality RI of Servlet 2.2/JSP 1.1. This is something that Tomcat 3.0 claimed to be, but until now we are still not quite sure ! 2) Provide a production quality implementation of Servlet 2.2/JSP 1.1, so the users don't have to ask "JServ ot Tomcat ?". 3) Provide support for future versions of the specifications, as both RI and production quality environment. Now, how do individual versions of Tomcat meet these goals ? Tomcat 3.1 meets neither, IMHO. Tomcat 3.2 does not meet 3), and it meets 1) much better than 3.1, enen though not perfectly. Are we happy with this ? Can we release 3.2 as it is now, or do we want to be 100% sure that we have 1) or even 2) ? Tomcat 4.x meets all, but it's not going to happen for a while. From this I think that clearly there is need for further development in the 3.x codebase, until we fully meet 1) and 2). Namely, we should release 3.2 ASAP. I consider it a big mistake that we (including myself) stopped development of 3.2 and didn't finish it yet. And I wouldn't want us to make the same mistake for 3.3: we don't necessarily need more features and new specification support in 3.3, particularly if that's going to delay the delivery of goal 2) (which should also happen ASAP). So 3.3 makes sense, but without support for the new specs, webdav etc. If we never finish what we started, then (as Rob said) we are a bunch of kids playing around in the org tree. My 2 Kc. Petr - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Fix for Tomcat 3.2 TcpConnector.receive() Problem
I am running Tomcat 3.2 with Apache 1.3.12 under Windows NT 4.0/Service
Pack 5 using the JRE 1.2.2 w/o Hotspot. I was getting the message
"Incomplete read, deal with it" when sending servlet requests ~1.5KB.
In short, I dealt with it by continuing to read until the full request has
been read from the socket InputStream.
I apologize for not properly posting this patch. I am under time
constraints and do not have time to "learn" the appropriate method.
class: org.apache.tomcat.service.connector.TcpConnector
method: public int receive(MsgBuffer msg)
-- NEW ---
// XXX check if enough space - it's assert()-ed !!!
// Can we have only one read ( with unblocking, it can read all at once -
but maybe more ) ?
//??? len-=4; // header
int offset = 4 ;
int remainingLength = len ;
do {
rd=in.read( b, offset, remainingLength );
offset += rd ;
remainingLength -= rd ;
}
while (remainingLength 0) ;
-- OLD ---
// XXX check if enough space - it's assert()-ed !!!
// Can we have only one read ( with unblocking, it can read all at once -
but maybe more ) ?
//??? len-=4; // header
rd=in.read( b, 4, len );
if( rd != len ) {
System.out.println( "Incomplete read, deal with it " + len + " " +
rd);
// ??? log
}
--
Mark Pollard
PanGo Networks, Inc.
http://www.pangonetworks.com
smime.p7s
RE: Tomcat 3.3 / 4.0 confusion, rant and plan...
I'd like to speak up about this briefly. Catalina/Tomcat-4.0 may be the future which is fine, but Tomcat is now being used in production settings. We've been testing the 3.2b* releases and the performance is better than 3.1 which is important for us. The performance of 3.3 is supposed to be better still. Catalina may have the perfect design, but I can't say anything about that because I haven't gotten time to look at the code. From previous emails though, it sounds like the supporting code such as Apache httpd connectors may not be ready yet, let alone tested. Mod_jk wasn't perfect at the last time that I tested it, but it was functional. What am I saying? Tomcat 3.x may not be perfect yet, but it has the supporting software in place and working. Catalina may have the perfect embedded http server, but that is of no interest to us. We need the speed and flexibility of the Apache httpd. What I'm asking is will Catalina be ready for production usage any time soon? Has it been tuned for speed yet? As for 3.3, I see it as a finish of what 3.2 started. We don't need Servlet 2.3 yet, so that isn't important to us. What we need is stability and performance. Once 3.2 is in production use, people will find bugs and problems. Thats the nature of software. I think that should be the real place of 3.3. Take what has been done as far as performance, and the fixes for bugs and spec compliance issues from 3.2 and put them in 3.3 and release that. I think that perhaps the choice between the 3.x architecture and the Catalina proposal may have been a little premature. Catalina doesn't have the supporting features yet that the 3.x series has. We can't do a head-to-head comparison between the two because Catalina doesn't have the connectors in place yet. I would like to thank Costin and everybody involved in the 3.x series. They took a non-optimal code base and turned it into something suitable for production use. They got it up and running soon enough that it has been able to get traction in the industry and let us develop applications based off the newer specifications. They made the way for Tomcat 4.0, whatever code that may be. I don't think that code that works now should be thrown away until the code that is intended to replace it is ready to replace it. Paul Frieden On Sat, 4 Nov 2000 [EMAIL PROTECTED] wrote: time explaining to people, "Well, 3.x is sort of this unfinished thing that they weren't happy with, so they started 4.x". To me, that DOES give the 3.x and 4.x are 2 different servlet containers, with very different design. The only confusing thing is the fact that the same name is used for both, and the number looks like 4 is a continuation of 3. Which one is better should be based on code reading and real-world testing, not on the number that is stick on it. ( BTW, the feature set is very different, the core design is different and of course the performance is different too ) Again, I don't remember when Apache decided to throw away a particular design and codebase and the reasons behind it, but if Members decide so I don't think I can do too much about it. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Tomcat 3.3 / 4.0 confusion, rant and plan...
Everyone, I see no reason why Tomcat 3.x and 4.x have to be mutually exclusive. As far as I can tell, Tomcat 3.x is Servlet 2.2, and Tomcat 4.x is Servlet 2.3. It's as simple as that. Yes, the vote did happen. You now have Tomcat 4.x, and that is what I am using, and it is awesome! Craig, you rock! But, if there are spec compliance issues WRT Tomcat 3 and Servlet 2.2, then I believe development on the 3.x tree MUST continue, until Tomcat 3.x truly IS the RI of Servlet 2.2. Anything else would not make sense. The numbering (3.2, 3.3) does not matter. If you look at the httpd part of the ASF, they have been working on 1.3.x, as well as 2.x. What they did is they chose to only maintain the 1.3.x tree if Apache was not compliant with something in the HTTP spec itself, or bug fixes. They voted as a group to do any and all new feature development in the 2.x tree, and that is what they are doing. Since the 2.x tree creation, they have released 1.3.13, 1.3.14, and they are working on 1.3.15. Development has stopped, but bug fixing continues. 90% of the httpd work that goes on is in the 2.x tree, but the 1.3.x tree is alive, and will be for quite awhile. AFAIK, you guys voted to make Catalina the engine of choice for Tomcat in its Servlet 2.3 implementation, and you are doing that. I would say that the majority of development should eventually be on Catalina, but if Tomcat 3.x has spec issues, those should be fixed, unless you have also voted that Catalina is the RI for Servlet 2.2 as well. FWIW, the httpd people are EXTREMELY against any new features in the 1.3.x tree, but they do not stop new releases for bug fixes or spec-compliance issues. I think that should be the same type of thing here. Just my non-voting $.02. Scott Sanders - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 3.3 / 4.0 confusion, rant and plan...
On Fri, 3 Nov 2000, Pier P. Fumagalli wrote: Sorry for starting what it might end up as a long flamewar, but reading almost 500 emails on the list I ended up a little confused... Also, in a bunch of side discussions, but related always to the same topic, I feel there's something wrong going around here... Question: WHAT THE HACK IS TOMCAT 3.3 ??? I'm not disagreeing with you Pier, but I will say I believe that there are 2 possible ways to interpret the current situation, and I do not think I'm the only one who thinks this. 1) The fact that there are smart software developers out there contributing to Tomcat 3.x codebase and not necessarily contributing to the 4.0 codebase is a failure of the Jakarta Apache community to obtain sufficient buy-in from those people. The division of resources in this situation is what should be avoided at all cost, because this is the one major limitation OSS has: division of finite resources within a community because of forking. I would assume one of ASF goals is to prevent this. 2) Or alternatively, anything beyond Tomcat 3.1 refects that Tomcat 3.1 is a "rolling beta", which means the "code-train" is in such bad shape that the developers are throwing track in front of it as it moves forward. Not a good thing. Or maybe we have a combination between the two. At any rate, ASF should rule clearly whether to let the code-train of 3.x roll off the track, whether to let it continue to roll on track but away from it's auspices, or to support the two code bases as is. By doing nothing ASF implicitly supports the latter, which is counterintuive to ASF's entire raison d'etre. my $0.02 -Nick - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 3.3 / 4.0 confusion, rant and plan...
"Pier P. Fumagalli" wrote: Sorry for starting what it might end up as a long flamewar, but reading almost 500 emails on the list I ended up a little confused... Also, in a bunch of side discussions, but related always to the same topic, I feel there's something wrong going around here... Thanks Pier for bringing this issue to a vote. Based on the other replies to this mail, it seems to me like the majority wants Tomcat 3.x to be the RI for Servlet 2.2/JSP 1.1, with production quality of course, and Tomcat 4.x the RI for Servlet 2.3/JSP 1.2. That's what makes most sense to me. The devil may be in the details, but I hope we can make it so. [...] So, I'm proposing this plan, and please vote on 2 and 4 (1 and 3 were already voted upon with a bunch of +1s)... 1) Release Tomcat 3.2 final (soon, please!) +1000. Sam promised a release candidate a couple of weeks back, but it didn't happen (I'm sure for a good reason). If Sam doesn't have the time to do this now, maybe someone else who's familiar with the release procedures can step up to the task? When the release candidate is available, we should make sure it's tested quickly (I promise to do so with a number of JSP applications I have handy). Only serious regression bugs should be allowed to force another candidate cycle. For the future, I suggest we document the release procedures and put them in CVS so it's easier for someone to help out with this if the appointed release manager can't do it for any reason. 2) Create a new proposal tree alongside with Catalina (new name to avoid confusion, please) -1, two code bases is more than enough ;-) If we can agree that Tomcat 3.x is the RI for Servlet 2.2/JSP 1.1 *only*, it makes sense for this code base to continue for bug fixes and improvements that are in support of these spec versions. I would have preferred to call these releases 3.2.1, 3.2.2 etc. instead of 3.3, but it's not all that important. Costin, Larry and others have put a lot of effort into 3.3, and even though I have not tested it yet myself, based on comments from others it's much better than 3.2 so lets take advantage of all that hard work and make sure it's released as the next 2.2/1.1 RI instead of hiding it in a new proposal branch. 3) Release Tomcat 4.0 (with Catalina, as we all decided) +1, but this will take some time since the new specs will not be final until next year, likely Q2. 4) Decide wether Tomcat 5.0 will be Catalina based or "whatever" new proposal comes along. -1, let's focus on 3.x and 4.x for now. Hans -- Hans Bergsten [EMAIL PROTECTED] Gefion Software http://www.gefionsoftware.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 3.3 / 4.0 confusion, rant and plan...
"Craig R. McClanahan" wrote: [...] Therefore, I'm going to spend the weekend integrating all the bug reports and fixes I can find into 3.2 -- please check the CVS commit reports and remind me of any that I miss. In particular, I would like people to check out the changes to MOD_JSERV and MOD_JK ... I don't have great facilities to test these exhaustively, so I'm going to be taking the word of some of the patch poster. Maybe we can get a release candidate available by midweek? Are you saying what I hope you're saying, that you're stepping in as release manager for 3.2 to make sure it gets released quickly? If so, thousands of thanks! Hans -- Hans Bergsten [EMAIL PROTECTED] Gefion Software http://www.gefionsoftware.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 3.3 / 4.0 confusion, rant and plan...
Hans Bergsten wrote: "Craig R. McClanahan" wrote: [...] Therefore, I'm going to spend the weekend integrating all the bug reports and fixes I can find into 3.2 -- please check the CVS commit reports and remind me of any that I miss. In particular, I would like people to check out the changes to MOD_JSERV and MOD_JK ... I don't have great facilities to test these exhaustively, so I'm going to be taking the word of some of the patch poster. Maybe we can get a release candidate available by midweek? Are you saying what I hope you're saying, that you're stepping in as release manager for 3.2 to make sure it gets released quickly? I don't care who does the actual release (I will if Sam can't and everyone else is OK with that), but I want to stop having to say "I dunno" when people ask about 3.2. If so, thousands of thanks! Hans -- Hans Bergsten [EMAIL PROTECTED] Gefion Software http://www.gefionsoftware.com Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/service/connector TcpConnector.java
craigmcc00/11/04 12:08:08
Modified:src/share/org/apache/tomcat/service/connector Tag: tomcat_32
TcpConnector.java
Log:
When receiving messages from the input stream, fully read the header and
the message before returning.
Revision ChangesPath
No revision
No revision
1.2.2.1 +52 -22
jakarta-tomcat/src/share/org/apache/tomcat/service/connector/TcpConnector.java
Index: TcpConnector.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/service/connector/TcpConnector.java,v
retrieving revision 1.2
retrieving revision 1.2.2.1
diff -u -r1.2 -r1.2.2.1
--- TcpConnector.java 2000/06/12 09:45:22 1.2
+++ TcpConnector.java 2000/11/04 20:08:07 1.2.2.1
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/service/connector/TcpConnector.java,v
1.2 2000/06/12 09:45:22 shachor Exp $
- * $Revision: 1.2 $
- * $Date: 2000/06/12 09:45:22 $
+ * $Header:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/service/connector/TcpConnector.java,v
1.2.2.1 2000/11/04 20:08:07 craigmcc Exp $
+ * $Revision: 1.2.2.1 $
+ * $Date: 2000/11/04 20:08:07 $
*
*
*
@@ -103,31 +103,61 @@
return msg;
}
+
+/**
+ * Read the next message from the input stream, and return the
+ * message length that was actually read (not counting the header).
+ *
+ * @param msg Message buffer into which we should read
+ *
+ * @exception IOException if an input/output error occurs
+ */
public int receive(MsgBuffer msg) throws IOException {
- // Read Packet
+ // Acquire our byte buffer
byte b[]=msg.getBuff();
-
- int rd=in.read( b, 0, H_SIZE );
- if( rd=0 ) {
- // System.out.println("Rd header returned: " + rd );
- return rd;
- }
- int len=msg.checkIn();
+// Read the entire header
+if (receiveFully(b, 0, H_SIZE) H_SIZE)
+return (-1);// End of file indication
- // XXX check if enough space - it's assert()-ed !!!
- // Can we have only one read ( with unblocking, it can read all at once - but
maybe more ) ?
- //??? len-=4; // header
-
- rd=in.read( b, 4, len );
- if( rd != len ) {
- System.out.println( "Incomplete read, deal with it " + len + " " + rd);
- }
- // msg.dump( "Incoming");
- return rd;
- //System.out.println( "Incoming Packet len=" + len);
+// Read the entire message
+ int len = msg.checkIn();
+int read = receiveFully(b, H_SIZE, len);
+return (read);
+
+}
+
+
+/**
+ * Read the specified number of bytes into the specified buffer,
+ * continuing to read until the required number of bytes has been
+ * encountered or end-of-file is reached. Return the number of
+ * bytes actually read (which will be less than the specified length
+ * strongonly/strong if EOF was reached.
+ *
+ * @param buff Byte array into which reading takes place
+ * @param off Initial offset at which read bytes are placed
+ * @param len Number of bytes to be read
+ *
+ * @exception IOException if an input/output error occurs
+ */
+private int receiveFully(byte buff[], int off, int len)
+throws IOException {
+
+int count = 0;
+while (len 0) {
+int read = in.read(buff, off, len);
+if (read 0) // End of file indication
+break;
+count += read;
+off += read;
+len -= read;
+}
+return (count);
+
}
+
public void send( MsgBuffer msg ) throws IOException {
msg.end();
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Fix for Tomcat 3.2 TcpConnector.receive() Problem
Mark,
I just checked in a slight generalization of this change (the read of the four-byte
header could fail in the same way. I forgot to give you credit in the CVS commit
:-(, but thaks for the bug report. Please test this (with your large servlet
requests) when you can.
Craig
Mark Pollard wrote:
I am running Tomcat 3.2 with Apache 1.3.12 under Windows NT 4.0/Service
Pack 5 using the JRE 1.2.2 w/o Hotspot. I was getting the message
"Incomplete read, deal with it" when sending servlet requests ~1.5KB.
In short, I dealt with it by continuing to read until the full request has
been read from the socket InputStream.
I apologize for not properly posting this patch. I am under time
constraints and do not have time to "learn" the appropriate method.
class: org.apache.tomcat.service.connector.TcpConnector
method: public int receive(MsgBuffer msg)
-- NEW ---
// XXX check if enough space - it's assert()-ed !!!
// Can we have only one read ( with unblocking, it can read all at once -
but maybe more ) ?
//??? len-=4; // header
int offset = 4 ;
int remainingLength = len ;
do {
rd=in.read( b, offset, remainingLength );
offset += rd ;
remainingLength -= rd ;
}
while (remainingLength 0) ;
-- OLD ---
// XXX check if enough space - it's assert()-ed !!!
// Can we have only one read ( with unblocking, it can read all at once -
but maybe more ) ?
//??? len-=4; // header
rd=in.read( b, 4, len );
if( rd != len ) {
System.out.println( "Incomplete read, deal with it " + len + " " +
rd);
// ??? log
}
--
Mark Pollard
PanGo Networks, Inc.
http://www.pangonetworks.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/core ContextManager.java
craigmcc00/11/04 12:28:48
Modified:src/share/org/apache/tomcat/core Tag: tomcat_32
ContextManager.java
Log:
When configuring a ContextManager, allow the "work" and "home" attributes
to be specified (or defaulted) in any order.
Reported by: Mark Lewis [EMAIL PROTECTED], TOMCAT-DEV, 01 Nov 2000
Revision ChangesPath
No revision
No revision
1.100.2.13 +26 -14
jakarta-tomcat/src/share/org/apache/tomcat/core/ContextManager.java
Index: ContextManager.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/core/ContextManager.java,v
retrieving revision 1.100.2.12
retrieving revision 1.100.2.13
diff -u -r1.100.2.12 -r1.100.2.13
--- ContextManager.java 2000/10/23 16:55:48 1.100.2.12
+++ ContextManager.java 2000/11/04 20:28:47 1.100.2.13
@@ -153,8 +153,13 @@
/** Private workspace for this server
*/
-String workDir;
+String workDir = null; // Initialized the first time we get it
+/** Configured workspace directory name (not absolutized yet)
+ */
+String workDirProperty = null;
+
+
/** The base directory where this instance runs.
* It can be different from the install directory to
* allow one install per system and multiple users
@@ -196,7 +201,7 @@
*/
public void setHome(String home) {
this.home=FileUtil.getCanonicalPath( home );
- logInt( "Setting home to " + this.home );
+ if (debug0) logInt( "Setting home to " + this.home );
}
/**
@@ -286,24 +291,31 @@
* WorkDir property - where all working files will be created
*/
public void setWorkDir( String wd ) {
- if(debug0) logInt("set work dir " + wd);
- // make it absolute
- File f=new File( wd );
- if( ! f.isAbsolute() ) {
- File wdF=getAbsolute( f );
- wd= wdF.getAbsolutePath();
- }
-
- this.workDir=wd;
+ if (debug0) logInt("set work dir " + wd);
+this.workDirProperty = wd; // Store only the string for now
}
/**
* WorkDir property - where all working files will be created
*/
public String getWorkDir() {
- if( workDir==null)
- workDir=getHome() + File.separator + DEFAULT_WORK_DIR;
- return workDir;
+
+// The first time this is called, calculate the right value
+if (this.workDir == null) {
+File f = null;
+if (this.workDirProperty == null)
+f = new File(DEFAULT_WORK_DIR);
+else
+f = new File(this.workDirProperty);
+if (!f.isAbsolute())
+f = getAbsolute(f);
+this.workDir = f.getAbsolutePath();
+if (debug0) logInt("calc work dir " + this.workDir);
+}
+
+// Return the calculated work directory value
+return (this.workDir);
+
}
/**
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat/src/doc in-process-howto.html
craigmcc00/11/04 12:37:47 Modified:src/doc Tag: tomcat_32 in-process-howto.html Log: Add a CVS identifier to the in-process-howto.html page (primarily to see which version is actually reflected on the web site). Revision ChangesPath No revision No revision 1.1.2.2 +5 -0 jakarta-tomcat/src/doc/in-process-howto.html Index: in-process-howto.html === RCS file: /home/cvs/jakarta-tomcat/src/doc/in-process-howto.html,v retrieving revision 1.1.2.1 retrieving revision 1.1.2.2 diff -u -r1.1.2.1 -r1.1.2.2 --- in-process-howto.html 2000/10/16 02:20:08 1.1.2.1 +++ in-process-howto.html 2000/11/04 20:37:46 1.1.2.2 @@ -258,5 +258,10 @@ pPlease send feedback, bug report or any additional information to tt[EMAIL PROTECTED]/tt. /p + +div align="center"font size="-1"pre +$Id: in-process-howto.html,v 1.1.2.2 2000/11/04 20:37:46 craigmcc Exp $ +/pre/font/div + /body /html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
FYI: Tomcat Docs on the Jakarta Web Site
I've updated the Tomcat documentation pages on the Jakarta web site to pull the "tomcat_32" branch, so that we can see the docs that will be included in a 3.2 release (and have the opportunity to fix them). Please help this process by reviewing the only doc pages at: http://jakarta.apache.org/tomcat/jakarta-tomcat/src/doc/index.html and make sure they are up to date. In particular, any relevant updates that have been checked in on the main branch should be also checked in on the "tomcat_32" branch. If you've made an update to the docs and want to see them reflected on the web site, log on to locus and do the following: cd /www/jakarta.apache.org/tomcat/jakarta-tomcat cvs update -dP Craig McClanahan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Tomcat 3.2 Issue] Security Constraints on RequestDispatcher Calls
While researching the isues related to BugRat Bug Report #213
("RequestDispatcher does not propogate errors"), I became aware that, in
the implementation of RequestDispatcher.forward() and
RequestDispatcher.include(),
(org.apache.tomcat.facade.RequestDispatcherImpl) the method
ContextManager.processRequest() is called to perform the mapping of the
forwarded or included request to the appropriate servlet.
This kind of function re-use makes sense -- however, it has a disturbing
implication in this case. The implementation of processRequest() calls
the contextMap() and requestMap() methods of all configured request
interceptors. This means (among other things) that security
constraints, if you are using container managed security, will be called
on the original request *and* on the forwarded-to or included servlet.
This behavior wasn't really specfied in servlet 2.2, but it was
clarified in 2.3 -- security constraints are only to be applied on the
original request URI, not when doing request dispatcher stuff.
Because it was unspecified in 2.2, I recommend we just note this as an
issue in the Tomcat 3.2 release notes -- unless someone wants to dig in
and do the intricate special casing necessary to make this work the way
that 2.3 would require. Any thoughts?
Craig McClanahan
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat/src/doc readme
craigmcc00/11/04 13:07:28 Modified:src/doc Tag: tomcat_32 readme Log: Add a note about the fact that Tomcat 3.2 applies security constraints on request dispatcher forwards and includes. Revision ChangesPath No revision No revision 1.8.2.4 +16 -1 jakarta-tomcat/src/doc/readme Index: readme === RCS file: /home/cvs/jakarta-tomcat/src/doc/readme,v retrieving revision 1.8.2.3 retrieving revision 1.8.2.4 diff -u -r1.8.2.3 -r1.8.2.4 --- readme2000/10/13 02:52:31 1.8.2.3 +++ readme2000/11/04 21:07:26 1.8.2.4 @@ -1,4 +1,4 @@ -$Id: readme,v 1.8.2.3 2000/10/13 02:52:31 larryi Exp $ +$Id: readme,v 1.8.2.4 2000/11/04 21:07:26 craigmcc Exp $ Release Notes for: == @@ -280,3 +280,18 @@ URL. If that static page contains relative links to resources served by Tomcat, then invoking those links would carry the mismatched case to Tomcat where it cause the resource not to be found. + +6.8 Container Managed Security Constraints + +Due to the way that Tomcat 3.2 is implemented, container managed security +constraints are imposed both on the original request URI *and* on subrequests +initiated to handle RequestDispatcher.forward() or RequestDispatcher.include() +calls. Whether or not this should actually be done was not defined in the +Servlet 2.2 Specification, but has been clarified in 2.3 -- security +constraints should only be applied on the original request URI. + +For future compatibility, you should be aware of this issue as you design your +security constraint architecture, to avoid portability problems if you ever +migrate to a different Servlet 2.2 container (which might implement this +differently), or to a Servlet 2.3 container at a later date. + - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 3.3 / 4.0 confusion, rant and plan...
I believe development on the 3.x tree MUST continue, until Tomcat 3.x truly IS the RI of Servlet 2.2. Anything else would not make sense. The numbering (3.2, 3.3) does not matter. You will find that the 3.3 tree is pretty nearly as big an architectural change (from 3.2) as is 4.0 (rather than just being maintenance / bug fixes like the Apache 1.3 / 2.0 example) ... but it's still academic because no one seems to want to finish what they started. If that is the case (ANY architectural changes), I agree with you, Craig. That is IMHO a 'bad idea'. Tomcat 3.x should really just be fixing enough of the code to conform to the spec. Scott Sanders - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/naming/java package.html
remm00/11/04 14:27:09
Modified:catalina/src/share/org/apache/naming/factory
TyrexDataSourceFactory.java
TyrexTransactionFactory.java
Added: catalina/src/share/org/apache/naming package.html
catalina/src/share/org/apache/naming/factory package.html
catalina/src/share/org/apache/naming/java package.html
Log:
- Added some JavaDoc documentation about configuring the Tyrex factories,
as well as links to the Tyrex website.
- Added some package.html files.
Revision ChangesPath
1.1
jakarta-tomcat-4.0/catalina/src/share/org/apache/naming/package.html
Index: package.html
===
body
pThis package contains a memory based naming service provider./p
p/p
/body
1.2 +40 -4
jakarta-tomcat-4.0/catalina/src/share/org/apache/naming/factory/TyrexDataSourceFactory.java
Index: TyrexDataSourceFactory.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/naming/factory/TyrexDataSourceFactory.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- TyrexDataSourceFactory.java 2000/11/04 06:46:09 1.1
+++ TyrexDataSourceFactory.java 2000/11/04 22:27:06 1.2
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/naming/factory/TyrexDataSourceFactory.java,v
1.1 2000/11/04 06:46:09 remm Exp $
- * $Revision: 1.1 $
- * $Date: 2000/11/04 06:46:09 $
+ * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/naming/factory/TyrexDataSourceFactory.java,v
1.2 2000/11/04 22:27:06 remm Exp $
+ * $Revision: 1.2 $
+ * $Date: 2000/11/04 22:27:06 $
*
*
*
@@ -76,10 +76,31 @@
import tyrex.jdbc.xa.EnabledDataSource;
/**
- * Object factory for Tyrex DataSources.
+ * Object factory for Tyrex DataSources.br
+ * Tyrex is an open-source transaction manager, developed by Assaf Arkin and
+ * exolab.org. See the a href="http://tyrex.exolab.org/"Tyrex homepage/a
+ * for more details about Tyrex and downloads.
+ * p
+ * This factory can produced either ServerDataSource objects (with integrated
+ * connection pooling) or EnabledDataSource objects. If the requested type is
+ * "tyrex.jdbc.ServerDataSource", a ServerDataSource will be instantiated.
+ * Be aware that some specific runtime permissions have to be set to be able
+ * to generate a ServerDataSource object (see the Tyrex documentation at the
+ * Tyrex website for more information).
+ * p
+ * Definition of the following additional properties is recommended :
+ * ul
+ * lidriverName : Name of the JDBC driver to use ( = connection URL)/li
+ * lidriverClassName : Class name of the JDBC driver/li
+ * liuser : User name. Can also be specified later when the Connection
+ * is retrieved./li
+ * lipassword : Password. Can also be specified later when the Connection
+ * is retrieved./li
+ * liloginTimeout : Optional. Login timeout./li
+ * /ul
*
* @author Remy Maucherat
- * @version $Revision: 1.1 $ $Date: 2000/11/04 06:46:09 $
+ * @version $Revision: 1.2 $ $Date: 2000/11/04 22:27:06 $
*/
public class TyrexDataSourceFactory
@@ -104,7 +125,14 @@
public static final String DRIVER_NAME = "driverName";
public static final String DRIVER_CLASS_NAME = "driverClassName";
+// Default values
+public static final String DEFAULT_DRIVER_NAME = "jdbc:HypersonicSQL:.";
+public static final String DEFAULT_DRIVER_CLASS_NAME =
+"org.hsql.jdbcDriver";
+public static final String DEFAULT_USER = "sa";
+public static final String DEFAULT_PASSWORD = "";
+
// - Instance Variables
@@ -150,20 +178,28 @@
currentRefAddr = ref.get(USER);
if (currentRefAddr != null) {
ds.setUser(currentRefAddr.getContent().toString());
+} else {
+ds.setUser(DEFAULT_USER);
}
currentRefAddr = ref.get(PASSWORD);
if (currentRefAddr != null) {
ds.setPassword(currentRefAddr.getContent().toString());
+} else {
+ds.setPassword(DEFAULT_PASSWORD);
}
currentRefAddr = ref.get(DRIVER_NAME);
if (currentRefAddr != null) {
ds.setDriverName
(currentRefAddr.getContent().toString());
+} else {
+
RE: Tomcat 3.3 / 4.0 confusion, rant and plan...
Some non-committer 2c here from me. Both of these things... From Nick: 1) The fact that there are smart software developers out there contributing to Tomcat 3.x codebase and not necessarily contributing to the 4.0 codebase is a failure of the Jakarta Apache community to obtain sufficient buy-in from those people. The division of resources in this situation is what should be avoided at all cost, because this is the one major limitation OSS has: division of finite resources within a community because of forking. I would assume one of ASF goals is to prevent this. and from Scott: If that is the case (ANY architectural changes), I agree with you, Craig. That is IMHO a 'bad idea'. Tomcat 3.x should really just be fixing enough of the code to conform to the spec. I agree with, and it sounds like a vote is in order. Besides, I feel better when everyone plays together =) But irrespective of the outcome, and I think Craig agrees or else he wouldn't be doing what he's doing right now; Tomcat 3.2 should be out-the-door asap. - r - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat/src/native/nt_service jk_nt_service.c
craigmcc00/11/04 14:48:43
Modified:src/native/nt_service Tag: tomcat_32 jk_nt_service.c
Log:
Patch the NT Service tool to fix bugs when shutting down Tomcat via the
AJP12 protocol, which causes Tomcat to be shutdown with extreme prejudice
instead of waiting for it to shut down via the ajp12 shutdown message.
NOTE: I HAVE NO MECHANISM FOR TESTING THIS PATCH - PLEASE CHECK IT OUT
Submitted by: Brett Bergquist [EMAIL PROTECTED],
on TOMCAT-DEV, 31-Oct-2000
Revision ChangesPath
No revision
No revision
1.3.2.1 +3 -3 jakarta-tomcat/src/native/nt_service/Attic/jk_nt_service.c
Index: jk_nt_service.c
===
RCS file: /home/cvs/jakarta-tomcat/src/native/nt_service/Attic/jk_nt_service.c,v
retrieving revision 1.3
retrieving revision 1.3.2.1
diff -u -r1.3 -r1.3.2.1
--- jk_nt_service.c 2000/06/12 09:48:59 1.3
+++ jk_nt_service.c 2000/11/04 22:48:42 1.3.2.1
@@ -56,7 +56,7 @@
/***
* Description: NT System service for Jakarta/Tomcat *
* Author: Gal Shachor [EMAIL PROTECTED] *
- * Version: $Revision: 1.3 $ *
+ * Version: $Revision: 1.3.2.1 $ *
***/
#include "jk_global.h"
@@ -670,13 +670,13 @@
}
} else {
char b[] = {(char)254, (char)15};
-int rc = send(sd, b, 2, 0);
+rc = send(sd, b, 2, 0);
if(2 == rc) {
rc = JK_TRUE;
}
}
jk_close_socket(sd);
-if(2 == rc) {
+if(JK_TRUE == rc) {
if(WAIT_OBJECT_0 == WaitForSingleObject(hTomcat, 30*1000)) {
return;
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Tomcat 3.3 / 4.0 confusion, rant and plan...
Everyone wants a TC3.2 -- I believe the only major concerns over the past couple weeks have been expressed in this snippet from a week ago: - snip - It seemed that the last outstanding issue was the compilation under JDK 1.1, but that should be fixed now. So is there still something that needs to be fixed ? I would really appreciate if the release could happen within the next few days. Thanks Petr session/cookie and other patches (date spinlock and one more i think) have not been integrated...can someone dump em in and release b7 or final ? -Ys- [EMAIL PROTECTED] - snip - We should make sure anything major such as this has been integrated. Let us debate the necessity of 3.3 (or at least something to fix 3.2 bugs) after 3.2 Final is released. But I believe there is a definite demand for something to replace JServ in *production* environments *right now*, and that requires active bug-fixing development. That probably also points to Tomcat 3.2.x or 3.3, 3.x... Thanks, Michael Percy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
missing jasper in tomcat cvs tree
Hi, Just did an checkout of jakarta-tomcat. The build is not succeeding and stops with the error: srcdir "blabla/jakarta-tomcat/src/jasper3" does not exist! what`s the problem? Juergen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 3.3 / 4.0 confusion, rant and plan...
That's a very interesting discussion, I certainly learned a lot from it. So, tomcat3.3 is confusing and shouldn't be called tomcat because catalina is tomcat. And while tomcat3.2 was ok, and nobody complained that the performance increased several times and a lot of features were added, for tomcat3.3 it's no longer permitted to add features, but only bug fixes ? I don't get it - so servlet2.3 is "reserved" for catalina, and no other container is allowed to implement it? Or at least not tomcat ? While it was ok for catalina to implement 2.2 ? And while it was ok to add features for 3.2, I can't do that for 3.3? Regardless if those features are useful or not, or if _USERS_ will benefit from that, and more importantly - I'm not asking for features but willing to implement them myself ? So if I'll implement a servlet2.3 facade for tomcat3.3 - I'll not be able to release it or check it in ? Can I still use my own home page or a public web site ? Regarding the 3.2 - there is no critical bug in 3.2 AFAIK, or at least watchdog passes and 3.2 doesn't seem to crash or behave worse than 3.1. After I finish with the big changes ( required to support charsets and performance ) I'll start fixing the remaining bugs. So far it seems everyone is certain about how bad 3.3 is and how good 4.0 is, and you may be right - but I do hope that you spent the required time to understand both. To be honest, starting a revolution seems the best thing for me - the precedent is already set, I'll no longer have to follow the "JDK1.1 compatible" rule, no need to support or worry about backward compatibility, and all the freedom I need. I can also follow Craig's request and move it outside of Apache. That would mean I ( as a developer spending free hours on the project ) will be able to write code without worry about the politics and ASF members and PMCs and all the upper management. I'll think about all this, but one thing is certain - I'm very disappointed with what happens here. Costing - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Tomcat 3.3 / 4.0 confusion, rant and plan...
Costin is an avid developer devoted to this project and technology, and you are fools to lose him and fork the project. I think it is possible that many contributors (present and potential future) will follow him. He is one of the few major contributors not employed by Sun. I don't see why there cannot be a compromise in this matter to avoid project forking... what, truly, are the alternatives? Nothing good. And what is the real agenda here, anyway... Mike - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Strange behavior with context mapping and load-on-startup
David Soroko wrote: I am observing the following behavior which I do not understand (Tomcat 3.1 and 3.2b6) The setup: The appdev Hello sample servlet to which the method init (ServletConfig config) has been added. It just prints a line of text. To the servlet's web.xml the load-on-startup1/load-on-startup element has been added To the server.xml the Context element has been added: Context path="" docBase="webapps/myapp" debug="0" /Context What I see, is that when Tomcat starts the init() method is being invoked twice. Is this a correct behavior or is there something illegal about path="" ? David, Try as I might, I could not reproduce this with Tomcat 3.2 -- it always seems to call my init() method once and only once like it is supposed to. The only thing I can think of that might trigger what you are seeing is if you edited the file $TOMCAT_HOME/conf/web.xml instead of the web.xml inside your web application -- that would cause the servlet to get loaded once per web application (at least under 3.1). If this is not what you did, could you please zip up a copy of the web application directory you are using, so that I can reproduce exactly what you are seeing? David Soroko Manna Inc. Craig McClanahan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Strange behavior with context mapping and load-on-startup
"Craig R. McClanahan" wrote: David Soroko wrote: I am observing the following behavior which I do not understand (Tomcat 3.1 and 3.2b6) The setup: The appdev Hello sample servlet to which the method init (ServletConfig config) has been added. It just prints a line of text. To the servlet's web.xml the load-on-startup1/load-on-startup element has been added To the server.xml the Context element has been added: Context path="" docBase="webapps/myapp" debug="0" /Context What I see, is that when Tomcat starts the init() method is being invoked twice. Is this a correct behavior or is there something illegal about path="" ? David, Try as I might, I could not reproduce this with Tomcat 3.2 -- it always seems to call my init() method once and only once like it is supposed to. The only thing I can think of that might trigger what you are seeing is if you edited the file $TOMCAT_HOME/conf/web.xml instead of the web.xml inside your web application -- that would cause the servlet to get loaded once per web application (at least under 3.1). If this is not what you did, could you please zip up a copy of the web application directory you are using, so that I can reproduce exactly what you are seeing? Once upon a time this happened when an application was defined by a Context element and stored in the default webapps directory. Tomcat created one context for the Context declaration and one for the the WAR (or expanded WAR) it found in the webapps directory. I haven't tested if this is the case still, but it might be. If so, I suggest you leave it as it is in 3.2. The simple work-around is to store applications defined by Context elements somewhere else than in webapps. Hans -- Hans Bergsten [EMAIL PROTECTED] Gefion Software http://www.gefionsoftware.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Strange behavior with context mapping and load-on-startup
Hans Bergsten wrote: Once upon a time this happened when an application was defined by a Context element and stored in the default webapps directory. Tomcat created one context for the Context declaration and one for the the WAR (or expanded WAR) it found in the webapps directory. Well, that's not it either ... it either doesn't fail in 3.2 or it has been fixed already. Oh well, much bigger fish yet to fry ... I'm working chronologically backwards and am only back to last Monday's reports on TOMCAT-DEV :-( Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat/src/native/jk jk_ajp13.c
craigmcc00/11/04 15:48:12
Modified:src/native/jk Tag: tomcat_32 jk_ajp13.c
Log:
Fix a bug in "jk_ajp13.c" that caused the "Authorization" header to be
incorrectly transmitted to Tomcat as an "Accept-Language" header.
I DO NOT HAVE REASONABLE FACILITIES TO TEST THIS PATCH - PLEASE TRY IT OUT.
Submitted by: Sergejs Suskovs [EMAIL PROTECTED]
Revision ChangesPath
No revision
No revision
1.5.2.2 +2 -2 jakarta-tomcat/src/native/jk/Attic/jk_ajp13.c
Index: jk_ajp13.c
===
RCS file: /home/cvs/jakarta-tomcat/src/native/jk/Attic/jk_ajp13.c,v
retrieving revision 1.5.2.1
retrieving revision 1.5.2.2
diff -u -r1.5.2.1 -r1.5.2.2
--- jk_ajp13.c2000/09/13 23:06:25 1.5.2.1
+++ jk_ajp13.c2000/11/04 23:48:11 1.5.2.2
@@ -56,7 +56,7 @@
/***
* Description: Experimental bi-directionl protocol handler. *
* Author: Gal Shachor [EMAIL PROTECTED] *
- * Version: $Revision: 1.5.2.1 $ *
+ * Version: $Revision: 1.5.2.2 $ *
***/
@@ -243,7 +243,7 @@
return JK_FALSE;
}
} else if(!strcmp(header_name, "authorization")) {
-*sc = SC_ACCEPT_LANGUAGE;
+*sc = SC_AUTHORIZATION;
} else {
return JK_FALSE;
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 3.3 / 4.0 confusion, rant and plan...
Michael Percy [EMAIL PROTECTED] wrote: Costin is an avid developer devoted to this project and technology, and you are fools to lose him and fork the project. Costin is a great guy, I have nothing personal against him... I was so happy when he got his green card last week because I consider him as a friend, first. But that doesn't mean that we have different ideas on many topics. [...] He is one of the few major contributors not employed by Sun. Err... Have you ever tried sending emails to [EMAIL PROTECTED] ? Pier - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 3.3 / 4.0 confusion, rant and plan...
The problem of the division of finite resources remains. Costin, would you consider bringing your brains into the 4.0 tree? Is 3.3 that good that it should weigh in _against_ (as a competeing implementation) 4.0? Pier, Craig, have you done all you can to get Costin "on-board" with 4.0? I just feel it a shame that Costin has this obvious empassioned pride of ownership in Tomcat and is sort of getting punished for it. I'm not saying it's malice, but it does seem somewhat insensitive. On Sat, 4 Nov 2000, Pier P. Fumagalli wrote: Michael Percy [EMAIL PROTECTED] wrote: Costin is an avid developer devoted to this project and technology, and you are fools to lose him and fork the project. Costin is a great guy, I have nothing personal against him... I was so happy when he got his green card last week because I consider him as a friend, first. But that doesn't mean that we have different ideas on many topics. [...] He is one of the few major contributors not employed by Sun. Err... Have you ever tried sending emails to [EMAIL PROTECTED] ? Pier - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Nicolaus Bauman Software Engineer Simplexity Systems - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 3.3 / 4.0 confusion, rant and plan...
What about this: - I start a new revolution in tomcat3.2 space ( proposals/something ), and all the implementation of 2.3 and all controversial stuff will go there ( i.e. all new features, like dav, http1.1, resource caching, the new SMTP and POP3 protocols - since any feature will be in fact just an interceptor plus the implementation itself ) - in tomcat3.3 we'll only have bug fixes, no other features. Tomcat3.3 will continue to be servlet2.2/jsp1.1, etc If the "revolution" rules still apply ( and I hope this is the case), there is no "vote" or procedure for revolutions, and any developer is free to work on whatever he likes. My preference is ( as you know ) to continue with the current stable codebase. That will be ( hopefully ) the last time we have this problem - I don't think we'll need any core change after 3.3 ( the code is very small now, and almost all work is delegated to modules - so it's very little that may change ). After that we can follow the 3.3.1, etc - again, only bug fixes. IMHO it's a decent proposal - I'll try to think of a name ( or names ) for the new "module-revolutions" - and everyone should be happy ( with some bad memories, maybe ). That will also allow to take more agressive steps in improving tomcat3 ( since the "revolution" branch will be less visible and the pressure will be lower ). It's cool to be revolutionar ( even if I still believe evolution is the way to go). Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat/src/native/apache/jserv jserv_ajpv12.c
craigmcc00/11/04 16:01:25
Modified:src/native/apache/jserv Tag: tomcat_32 jserv_ajpv12.c
Log:
If ap_bread() returns a negative value (to indicate that an error occurred),
return -1 ourselves instead of trying to call ap_bwrite() with a length of
-1. This was causing a GPF on Windows.
Submitted by: [EMAIL PROTECTED]
Revision ChangesPath
No revision
No revision
1.7.4.1 +3 -0 jakarta-tomcat/src/native/apache/jserv/Attic/jserv_ajpv12.c
Index: jserv_ajpv12.c
===
RCS file: /home/cvs/jakarta-tomcat/src/native/apache/jserv/Attic/jserv_ajpv12.c,v
retrieving revision 1.7
retrieving revision 1.7.4.1
diff -u -r1.7 -r1.7.4.1
--- jserv_ajpv12.c2000/04/04 19:58:19 1.7
+++ jserv_ajpv12.c2000/11/05 00:01:24 1.7.4.1
@@ -57,7 +57,7 @@
* Description: ajpv1.2 protocol, used to call local or remote jserv hosts *
* Author: Pierpaolo Fumagalli [EMAIL PROTECTED] *
* Author: Michal Mosiewicz [EMAIL PROTECTED] *
- * Version: $Revision: 1.7 $ *
+ * Version: $Revision: 1.7.4.1 $ *
*/
#include "jserv.h"
@@ -393,6 +393,9 @@
char buffer[HUGE_STRING_LEN];
int len;
len = (int) ap_bread(buffsocket, buffer, HUGE_STRING_LEN);
+if (len 0) {
+ return -1;
+}
#ifdef HAVE_APFD /* IBM Apache */
if(r-connection-client-pfd-sd = 0) {
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 3.3 / 4.0 confusion, rant and plan...
"Pier P. Fumagalli" wrote: Hans Bergsten [EMAIL PROTECTED] wrote: "Pier P. Fumagalli" wrote: Sorry for starting what it might end up as a long flamewar, but reading almost 500 emails on the list I ended up a little confused... Also, in a bunch of side discussions, but related always to the same topic, I feel there's something wrong going around here... Thanks Pier for bringing this issue to a vote. Based on the other replies to this mail, it seems to me like the majority wants Tomcat 3.x to be the RI for Servlet 2.2/JSP 1.1, with production quality of course, and Tomcat 4.x the RI for Servlet 2.3/JSP 1.2. That's what makes most sense to me. The devil may be in the details, but I hope we can make it so. James might be an "instigator", but I'm for sure _THE_ "troublemaker" :) :) I fully agree with you on that. Let me explain better my position: ;-) I have NOTHING against a Tomcat 3.3 release, if we want to call it 3.3. The thing I am against is having two different releases of "Tomcat" (3.3 and 4.0) having the same features and capabilities... We're in total agreement on this. [...] Servlet 2.0? Apache JServ (Actually, we might end up moving it to Jakarta as an "historic" piece of code when Java.Apache.ORG dies) Servlet 2.1? (fuck, we don't have it, any volunteer?) Servlet 2.2/JSP 1.1? Tomcat 3.x (3.2, 3.3, 3.4, 3.5 and so on, as long as there's people willing to deveop it) Servlet 2.3/JSP 1.2? Tomcat 4.x Servlet NEXT? When they come out, we'll see what we have in our hands and we'll decide This _IS_ clear Right. Hans -- Hans Bergsten [EMAIL PROTECTED] Gefion Software http://www.gefionsoftware.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 3.3 / 4.0 confusion, rant and plan...
[EMAIL PROTECTED] wrote: What about this: - I start a new revolution in tomcat3.2 space ( proposals/something ), and all the implementation of 2.3 and all controversial stuff will go there ( i.e. all new features, like dav, http1.1, resource caching, the new SMTP and POP3 protocols - since any feature will be in fact just an interceptor plus the implementation itself ) Okay, if you feel strongly about not working with the Tomcat 4.x code base. This revolution branch would, however, not change the decision to use the Tomcat 4.x code base for Servlet 2.3/JSP 1.2. The earliest it could be considered would be for the next version of the specs. - in tomcat3.3 we'll only have bug fixes, no other features. Tomcat3.3 will continue to be servlet2.2/jsp1.1, etc Agree. If the "revolution" rules still apply ( and I hope this is the case), there is no "vote" or procedure for revolutions, and any developer is free to work on whatever he likes. My preference is ( as you know ) to continue with the current stable codebase. I've noticed ;-) I'm okay with another revolution branch, as long as we're clear about which spec versions Tomcat 3.x and Tomcat 4.x supports. [...] It's cool to be revolutionar ( even if I still believe evolution is the way to go). Sometimes evolution just doesn't work ;-) Anyway, if this makes everyone happy, I'm all for it. Hans -- Hans Bergsten [EMAIL PROTECTED] Gefion Software http://www.gefionsoftware.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 3.3 / 4.0 confusion, rant and plan...
Pier P. Fumagalli wrote: If you want to go on and make a 3.3, do it, but if you want to implement Servlet 2.3 in that release, you'll get my -1... Whether I personally agree with 3.x design or not, as an ASF member myself, I believe that it is important to protect Costin's right to pursue it. It was not terribly long ago that what became Catalina was controversial. - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 3.3 / 4.0 confusion, rant and plan...
- Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, November 04, 2000 4:27 PM Subject: Re: Tomcat 3.3 / 4.0 confusion, rant and plan... And why not: Servlet2.0 - Tocmat3.3 Servlet2.1 - Tomcat3.3 Servlet2.2 - Tomcat3.3 Servlet2.3 - Tomcat3.3 Servlet.next - Tomcat3.3 I don't agree. Having : Servlet2.0 - TocmatNext Servlet2.1 - TomcatNext Servlet2.2 - TomcatNext Servlet2.3 - TomcatNext Servlet.next - TomcatNext is very fine. I don't think people want anything but bug fixes (and perhaps a few more features) for Tomcat 3.2 and eventually 3.3. And even: "I have old servlet2.2 apps, and some new servlet3.0 apps, and there are some incompatibilities between 3.0 servlet API and 2.2, what can I do ? " - Tomcat3.3 Anyway, I'll be more than happy to remove the 2.3 facade from tomcat2.2 if that it's your concern. But I don't think you can stop me ( or someone else ) from implementing a 3.x Interceptor that plugs in a 2.3 ( or Servlet.Next ) into tomcat. If the rules for "revolution" are still accepted, I'll do that in a /proposal tree, if not - I'll do it on my home page. I think it's the right thing to do, instead of rewriting everything again and again. I think that would be the best. Now, a few points : - The main branch in the jakarta-tomcat tree is broken, and is also a bug mess right now. I think it needs to be fixed so that it complies more with the objectives set for TC3.3. - If it was possible to avoid code duplication for as many components as possible it would be great ;) Fixes / improvements are really hard to merge otherwise. Since I think the main point of disagreement is the servlet engine core, that should be doable. That's the main issue here, and that's what I think it's wrong in your table - the code should be reusable, and supporting multiple facades is not only easy, but it's important for future. Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 3.3 / 4.0 confusion, rant and plan...
- I start a new revolution in tomcat3.2 space ( proposals/something ), and all the implementation of 2.3 and all controversial stuff will go there ( i.e. all new features, like dav, http1.1, resource caching, the new SMTP and POP3 protocols - since any feature will be in fact just an interceptor plus the implementation itself ) Okay, if you feel strongly about not working with the Tomcat 4.x code base. This revolution branch would, however, not change the decision to use the Tomcat 4.x code base for Servlet 2.3/JSP 1.2. The earliest it could be considered would be for the next version of the specs. Well, if it's a revolution it can implement anything - including 2.3. It's not going to be the "RI", of course. Again, support for 2.3 is just an independent module that doesn't have to be included in the default distribution. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
HttpServletResponse.encodeURL is broken for relative URLs
Hi, it appears that HttpServletResponse.encodeURL refuses to add a JSESSIONID to relative URLs for Tomcat 3.1 and 3.2b6. I looked at the code, and it appears that HttpServletResponseFacade.isEncodeable() always returns false on URL strings that are not fully qualified, and this causes encodeURL to always ignore relative URLs. I can't find anything in the javadoc or servlet spec saying that encodeURL is supposed to ignore relative URLs. Since using relative URLs for internal navigation around websites is considered a standard practice, my guess is that encodeURL is supposed work correctly with relative URLs. Am I mistaken in this? This is a bad bug for me; I'm writing Palm VII sites, and Palm web clippings don't support cookies at all, which makes HttpServletResponse.encodeURL important. Thanks! -Colin -- Colin Evans Bitmo, Inc. (http://www.bitmo.com) (415)920.7225 / [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: HttpServletResponse.encodeURL is broken for relative URLs
Colin Evans wrote: Hi, it appears that HttpServletResponse.encodeURL refuses to add a JSESSIONID to relative URLs for Tomcat 3.1 and 3.2b6. I looked at the code, and it appears that HttpServletResponseFacade.isEncodeable() always returns false on URL strings that are not fully qualified, and this causes encodeURL to always ignore relative URLs. I can't find anything in the javadoc or servlet spec saying that encodeURL is supposed to ignore relative URLs. Since using relative URLs for internal navigation around websites is considered a standard practice, my guess is that encodeURL is supposed work correctly with relative URLs. Am I mistaken in this? This is a bad bug for me; I'm writing Palm VII sites, and Palm web clippings don't support cookies at all, which makes HttpServletResponse.encodeURL important. It is not supposed to ignore them -- it is supposed to convert them to absolute and then add the path parameter if: - The host and port of the absolute URL matches the original request - The context path of the absolute URL matches the original request (i.e. the URL points back at this app) I will take a look - but in the past, this has seemed to work correctly. Thanks! -Colin Craig -- Colin Evans Bitmo, Inc. (http://www.bitmo.com) (415)920.7225 / [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: HttpServletResponse.encodeURL is broken for relative URLs
"Craig R. McClanahan" wrote: [...] It is not supposed to ignore them -- it is supposed to convert them to absolute and then add the path parameter if: - The host and port of the absolute URL matches the original request - The context path of the absolute URL matches the original request (i.e. the URL points back at this app) I will take a look - but in the past, this has seemed to work correctly. I just looked at the source used in Beta 6, and it appears to work as it should. That's also my experience from running Beta 6. Hans -- Hans Bergsten [EMAIL PROTECTED] Gefion Software http://www.gefionsoftware.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Why tomcat 3.x makes redirects (302) absolute ?
Excuse my ignorance, Why tomcat 3.x makes redirects (302) absolute ? It leads to problems with NAT ( at router level ) redirects, and reverse proxys, and it can commented without aparent harm Saludos , Ignacio J. Ortega - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Why tomcat 3.x makes redirects (302) absolute ?
Nacho wrote: Excuse my ignorance, Why tomcat 3.x makes redirects (302) absolute ? It leads to problems with NAT ( at router level ) redirects, and reverse proxys, and it can commented without aparent harm See servlet 2.2 specification, section 6.3, first complete paragraph. Making the URL absolute is required. Saludos , Ignacio J. Ortega Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/core Handler.java
public void service(Request req, Response res)
throws IOException, ServletException
{
+ synchronized(this) {
if( ! initialized ) {
try {
init();
@@ -271,6 +272,7 @@
return;
}
}
+ }
This looks significant from a performance perspective. Wouldn't it be
better if an _additional_ if (!initialized) were added prior to the
synchronized?
- Sam Ruby
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Why tomcat 3.x makes redirects (302) absolute ?
Hola Craig: See servlet 2.2 specification, section 6.3, first complete paragraph. Making the URL absolute is required. It's required when it's used trought the convenience methods (sendRedirect sendError) not when the container send itself a redirect... and this was the reasoning behind my question when a webapp served by tomcat standalone it's accesed trought a router with NAT a simple http://host:8080/context fails because the redirect message has the internal IP or name of the machine in the "Location" header, thus the client can not found the original host of the redirect that from the client point it's the router not the internal name or ip, this can be done without making url absolute for tomcat own use, and when it's done trought a sendRedirect made it absolute as the spec says, i'm really wrong ? Craig Saludos , Ignacio J. Ortega - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: I think that it is a bug.
Qian Weichun wrote:
The bug lies here:
I forward a request in my servlet.
After I commit the output, I perform the forwarding.
Tomcat doesn't act conforming to the servlet 2.2 specification,
which specifies that it should throw the IllegalStateException.
Peek the source:
public void doGet(HttpServletRequest request,HttpServletResponse response)
throws IOException,ServletException {
response.setContentType("text/html;charset=gb2312");
PrintWriter out = response.getWriter();
out.println("html");
out.println("head");
out.println("titleForward A Request/title");
out.println("/head");
out.println("body");
out.println("h1Just A Test!/h1");
out.println("/body");
out.println("/html");
out.flush();
request.getRequestDispatcher("/forwarded.jsp").forward(request,response);
}
Qian,
If Tomcat 3.2 were an implementation of the Servlet 2.3 specification, this would
indeed be a spec violation, because the
2.3 spec specifically states that flushing the output stream returned by
response.getOutputStream(), or the PrintWriter
returned by response.getWriter(), will cause the response to be committed.
In a servlet 2.2 environment, however, it is not defined whether or not a flush() call
on the output stream or writer causes
the response to be committed. Therefore, Tomcat's behavior (while perhaps unexpected)
is within the bounds of acceptable
behavior.
If you want to ensure that the response has been committed, no matter what version of
the servlet spec your container
implements, call response.flushBuffer() instead of out.flush().
Craig McClanahan
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PATCH] jk_nt_service shutdown
Luke,
I apologize for not giving you credit for this patch -- it was included (along
with other patches) by someone else. But thanks!!!
Craig McClanahan
"Kirby, Luke" wrote:
Hi!
It would seem that the Jakarta NT Service fails to properly shutdown Tomcat.
Examining the code shows that it does the right thing and sends the ajp1[23]
shutdown message but then happily proceeds to terminate the Tomcat process
before it has a chance to shutdown gracefully. Oops!
The patch to fix it is below. This patch also includes a fix to the .dsp
file, required by the mod_jk reorganisation.
Enjoy!
Luke
Index: jk_nt_service.c
===
RCS file:
/home/cvspublic/jakarta-tomcat/src/native/mod_jk/nt_service/jk_nt_service.c,
v
retrieving revision 1.1
diff -u -r1.1 jk_nt_service.c
--- jk_nt_service.c 2000/08/26 02:03:53 1.1
+++ jk_nt_service.c 2000/10/25 04:19:10
@@ -639,9 +639,10 @@
static void stop_tomcat(short port,
const char *protocol,
HANDLE hTomcat)
-{
+{
+
struct sockaddr_in in;
-
+
if(jk_resolve("localhost", port, in)) {
int sd = jk_open_socket(in, JK_TRUE, NULL);
if(sd 0) {
@@ -659,7 +660,7 @@
rc = ajp13_marshal_shutdown_into_msgb(msg,
pool,
NULL);
-if(rc) {
+if (JK_TRUE == rc) {
jk_b_end(msg);
if(0 jk_tcp_socket_sendfull(sd,
@@ -670,13 +671,13 @@
}
} else {
char b[] = {(char)254, (char)15};
-int rc = send(sd, b, 2, 0);
-if(2 == rc) {
+if(2 == send(sd, b, 2, 0)) {
rc = JK_TRUE;
}
}
jk_close_socket(sd);
-if(2 == rc) {
+if(JK_TRUE == rc) {
+// shutdown message sent - give it a moment to finish.
if(WAIT_OBJECT_0 == WaitForSingleObject(hTomcat, 30*1000))
{
return;
}
Index: nt_service.dsp
===
RCS file:
/home/cvspublic/jakarta-tomcat/src/native/mod_jk/nt_service/nt_service.dsp,v
retrieving revision 1.1
diff -u -r1.1 nt_service.dsp
--- nt_service.dsp 2000/08/26 02:03:53 1.1
+++ nt_service.dsp 2000/10/25 04:19:10
@@ -42,7 +42,7 @@
# PROP Ignore_Export_Lib 0
# PROP Target_Dir ""
# ADD BASE CPP /nologo /W3 /GX /O2 /D "WIN32" /D "NDEBUG" /D "_CONSOLE" /D
"_MBCS" /YX /FD /c
-# ADD CPP /nologo /W3 /GX /O2 /I "../jk" /D "WIN32" /D "NDEBUG" /D
"_CONSOLE" /D "_MBCS" /YX /FD /c
+# ADD CPP /nologo /W3 /GX /O2 /I "../common" /D "WIN32" /D "NDEBUG" /D
"_CONSOLE" /D "_MBCS" /YX /FD /c
# ADD BASE RSC /l 0x409 /d "NDEBUG"
# ADD RSC /l 0x409 /d "NDEBUG"
BSC32=bscmake.exe
@@ -66,7 +66,7 @@
# PROP Ignore_Export_Lib 0
# PROP Target_Dir ""
# ADD BASE CPP /nologo /W3 /Gm /GX /ZI /Od /D "WIN32" /D "_DEBUG" /D
"_CONSOLE" /D "_MBCS" /YX /FD /GZ /c
-# ADD CPP /nologo /W3 /Gm /GX /ZI /Od /I "../jk" /D "WIN32" /D "_DEBUG" /D
"_CONSOLE" /D "_MBCS" /YX /FD /GZ /c
+# ADD CPP /nologo /W3 /Gm /GX /ZI /Od /I "../common" /D "WIN32" /D "_DEBUG"
/D "_CONSOLE" /D "_MBCS" /YX /FD /GZ /c
# ADD BASE RSC /l 0x409 /d "_DEBUG"
# ADD RSC /l 0x409 /d "_DEBUG"
BSC32=bscmake.exe
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Why tomcat 3.x makes redirects (302) absolute ?
Ohh unpleasure findings ( and i do need to read the damn RFC too :-) Tomcat 3.2 seems to have another bug!!! i've obtained this ( by means of telnet ) from different http servers, after done a GET / in all of them, i obtained This is from IIS 5.0 first finding: How IIS makes this work with respect the RFC ??? if not seems to put an absolute path at all... 8-- -- HTTP/1.1 302 Object moved Server: Microsoft-IIS/5.0 Date: Sun, 05 Nov 2000 04:48:33 GMT Location: /inicio.asp Connection: Keep-Alive Content-Length: 161 Content-Type: text/html Set-Cookie: ASPSESSIONIDGGQGGUVY=LGBPJBJDLHDMPPJJNLDMKLHA; path=/ Cache-control: private headtitleSe ha movido el objeto/title/head bodyh1Se ha movido el obje to/h1Este objeto se puede encontrar en a HREF="/inicio.asp"aquÝ/a./body 8-- This from remote ( myself from outside ) Tomcat 3.2 Second Finding: note the line jump after Location: header, it seems to have a bug. 8-- HTTP/1.0 302 Encontrado Content-Type: text/html Location: http://hippo:8080/ /index.html Content-Length: 186 Servlet-Engine: Tomcat Web Server/3.2 beta 4 (JSP 1.1; Servlet 2.2; Java 1.3.0; Windows 2000 5.0 x86; java.vendor=Sun Microsystems Inc.) headtitleDocumento trasladado/title/head bodyh1Documento trasladado/h1 Este Documento ha sido trasladado a href="http://hippo:8080/ /index.html"here/a.p /body 8-- This is from a remote Tomcat 3.3 Third finding : another bug that need fixing .. 8-- HTTP/1.0 302 Encontrado Content-Type: text/html Location: http://localhost:8080/index.html Content-Length: 187 headtitleDocumento trasladado/title/head bodyh1Documento trasladado/h1 Este Documento ha sido trasladado a href="http://localhost:8080/index.html"her e/a.p /body 8-- What do you think? Saludos , Ignacio J. Ortega - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Why tomcat 3.x makes redirects (302) absolute ?
Nacho wrote: Ohh unpleasure findings ( and i do need to read the damn RFC too :-) Tomcat 3.2 seems to have another bug!!! i've obtained this ( by means of telnet ) from different http servers, after done a GET / in all of them, i obtained This is from IIS 5.0 first finding: How IIS makes this work with respect the RFC ??? if not seems to put an absolute path at all... The fact that other servers break the rules is no excuse for Tomcat to do so. If your NAT server or proxy cannot handle this right, your NAT server or proxy is BROKEN. Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/util FileUtil.java
craigmcc00/11/04 21:28:53
Modified:src/share/org/apache/tomcat/util Tag: tomcat_32
FileUtil.java
Log:
Update pathname parsing to deal with multiple '\' characters on NetWare
platforms.
Submitted by: Mike Anderson [EMAIL PROTECTED]
Revision ChangesPath
No revision
No revision
1.9.2.5 +15 -7 jakarta-tomcat/src/share/org/apache/tomcat/util/FileUtil.java
Index: FileUtil.java
===
RCS file: /home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/util/FileUtil.java,v
retrieving revision 1.9.2.4
retrieving revision 1.9.2.5
diff -u -r1.9.2.4 -r1.9.2.5
--- FileUtil.java 2000/10/11 00:24:45 1.9.2.4
+++ FileUtil.java 2000/11/05 05:28:53 1.9.2.5
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/util/FileUtil.java,v 1.9.2.4
2000/10/11 00:24:45 arieh Exp $
- * $Revision: 1.9.2.4 $
- * $Date: 2000/10/11 00:24:45 $
+ * $Header:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/util/FileUtil.java,v 1.9.2.5
2000/11/05 05:28:53 craigmcc Exp $
+ * $Revision: 1.9.2.5 $
+ * $Date: 2000/11/05 05:28:53 $
*
*
*
@@ -267,12 +267,20 @@
patchPath = sb.toString();
}
- // fix path on NetWare
+ // fix path on NetWare - all '/' become '\\' and remove duplicate '\\'
if (System.getProperty("os.name").startsWith("NetWare")
path.length() =3
- path.indexOf(':') 0)
- patchPath = patchPath.replace('/', '\\');
-
+ path.indexOf(':') 0) {
+char ca[] = patchPath.replace('/', '\\').toCharArray();
+StringBuffer sb = new StringBuffer();
+for (int i = 0; i ca.length; i++) {
+if ((ca[i] != '\\') ||
+(ca[i] == '\\' i 0 ca[i-1] != '\\')) {
+sb.append(ca[i]);
+}
+}
+patchPath = sb.toString();
+}
return patchPath;
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Why tomcat 3.x makes redirects (302) absolute ?
- Original Message - From: "Nacho" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, November 04, 2000 9:32 PM Subject: RE: Why tomcat 3.x makes redirects (302) absolute ? Hola Craig: The fact that other servers break the rules is no excuse for Tomcat to do so. If your NAT server or proxy cannot handle this right, your NAT server or proxy is BROKEN. it's a dangling SHOULD in the rfc2068... they follow the rules, but it's a HTTP1.1 feature for a HTTP1.0 container as tomcat 3.x is it's not posible but Tomcat 4.0 can do this way if you want.. :-) I don't agree. The Location response-header field is used to redirect the recipient to a location other than the Request-URI for completion of the request or identification of a new resource. For 201 (Created) responses, the Location is that of the new resource which was created by the request. For 3xx responses, the location SHOULD indicate the server's preferred URI for automatic redirection to the resource. The field value consists of a single absolute URI. Location = "Location" ":" absoluteURI I think it means that if there's a Location header for 30x responses, it has to be absolute. Othewise the last line would read something like : Location = "Location" ":" absoluteURI | relativeURI or something. I think that's why the servlet spec says the uri is absolute. Of course, an intelligent client would know how to handle both ;) Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-4.0/catalina build.xml
remm00/11/04 22:22:51
Modified:catalina build.xml
Log:
- Conditional compilation variables were not properly set for some reason,
probably because this buildfile is actually called from the main buildfile.
As a result, neither Tyrex nor JTA is needed anymore to build Tomcat 4.
Sorry for the problem ...
Bug reported by Terena Chinn-Fujii.
Revision ChangesPath
1.22 +7 -6 jakarta-tomcat-4.0/catalina/build.xml
Index: build.xml
===
RCS file: /home/cvs/jakarta-tomcat-4.0/catalina/build.xml,v
retrieving revision 1.21
retrieving revision 1.22
diff -u -r1.21 -r1.22
--- build.xml 2000/11/05 01:16:36 1.21
+++ build.xml 2000/11/05 06:22:50 1.22
@@ -26,12 +26,6 @@
mkdir dir="${catalina.build}/conf"/
mkdir dir="${catalina.build}/lib"/
mkdir dir="${catalina.build}/server"/
-
-!-- === Conditional Compilation Falgs --
-available property="tyrex.present"
- classname="tyrex.jdbc.ServerDataSource" /
-available property="jta.present"
- classname="javax.transaction.UserTransaction" /
/target
@@ -73,6 +67,13 @@
!-- = BUILD: Compile Server Components = --
target name="build-main" depends="build-static"
+
+
+!-- === Conditional Compilation Falgs --
+available property="tyrex.present"
+ classname="tyrex.jdbc.ServerDataSource" /
+available property="jta.present"
+ classname="javax.transaction.UserTransaction" /
!-- Compile internal server components --
javac srcdir="src/share" destdir="${catalina.build}/classes"
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
