Re: [5.0] [PROPOSAL] Extra web.xml to declare compiled JSPs
What about using external entities? ie: ?xml version=1.0 encoding=ISO-8859-1? !DOCTYPE web-app PUBLIC -//Sun Microsystems, Inc.//DTD Web Application 2.3//EN http://java.sun.com/dtd/web-app_2_3.dtd; [ !ENTITY jspservlet system jspservlet.xml ] then, between the servlet and servlet mapping sections jspservlet; -SMD - Original Message - From: Remy Maucherat [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Friday, March 21, 2003 6:05 AM Subject: [5.0] [PROPOSAL] Extra web.xml to declare compiled JSPs Hi, It is not very convinient or easy to insert the declarations for compiled JSPs into the webapp's web.xml file. It also has the disadvantage of adding a lot of mess in the web.xml, which the user may not like. For that reason, I propose that Tomcat parses a new (optional) XML file, with the same DTD as web.xml, which would contain declarations identical to web.xml, and which would be used for declaring the compiled JSPs. I propose naming that file compiledjsp.xml. An additional advantage is that it would allow Tomcat to precompile webapps as they are deployed (otherwise, nasty XML manipulation is needed to do that, and I think overwriting the originial web.xml during deployment is bad). Maybe someone has a better solution for this problem. Any comments ? Remy - 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: [VOTE] Proposed jspc refactoring
I dislike this option immensely. It's entirely contrary to what JSPC is for. It's a tool for generating servlets from JSP that do not require the entire JSP machinery. It produces a web.xml file that maps each jsp page to the generated servlet. The generated servlets are portable between servlet engines. They can be compiled by a normal java compiler. In short, they are very much unlike the output in the work directory. What you are proposing is the same as the precompile option on the URL. Here's a script that will do it for all compliant JSP engines find . -name '*jsp' -printf http://`echo $HOSTNAME`/%P?jsp_precompile\n \ | xargs -n 1 lynx -head -source On Thursday 07 November 2002 04:23 am, Remy Maucherat wrote: Hi, jspc is IMO overly complex, with many features nobody knows how to use, and nobody cares to test (hence sometimes some of them are randomly broken during Jasper refactorings). I propose that: - In Tomcat 5, all jspc options are removed, in favor of allowing only the webapp mode (with its relevant options). This webapp mode would generate code and classes which should be deployed in the work directory, exactly the same as if they were dynamically compiled by Jasper (which has the big advantage of using only one big operation mode for everything). Single file mode is IMO useless (dynamic compilation works fine). - In Tomcat 4.1, the options will stay in for compatibility, but the usage help will be modified to be the same as Tomcat 5. It has to be noted that: - The JSP runtime is now very efficient. The old webapp mode (with its static web.xml) is a hack (and a 100% proprietary one at that). - Precompilation should only occur at webapp deployment time in the general case (the generated code is closely tied to the Jasper runtime release). - Additional features could be added to the manager servlet to, for example, cause precompilation of the deployed webapp in a separate process. - I am -1 to returning to the old webapp option behavior (ie, the generated files should by default be deployed in the work directory, not /WEB-INF/classes). ballot +1 [ ] Remove the options -1 [ ] Do not remove the options /ballot Note: Users may vote, but only committers have binding votes. Remy -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: [VOTE] Proposed jspc refactoring
It's better to look at it as a compiler. It's output happens to be java, but it acts a whole lot more like a compiler than a precompiler. Precompilers are usually more like macro preprocessors. On Friday 08 November 2002 07:05 am, John Trollinger wrote: I have to disagree with this, jspc is a pre compiler, not a webapp packager. John I agree that JSPC needs to be simplified and that the webapp mode should be retained. But the webapp mode should allow for a war file to be generated which is self contained including the precompiled JSP classses. And for the generated war to be able to run from the war file with no need to unpack it. Also I agree that this feature is a proprietary feature of Tomcat and we should no longer try to generate a war that can be deployed in any container. There may be a way to do this: Put the generated JSP class files in a /WEB-INF/jspwork/ directory. This work directory would only be used by jasper for loading jsp pages, the normal work directory would still be used for all other things. Add the jspwork attribute to the DefaultContext and Context config elements. This attribute would specify the directory path within the war file to use for loading the JSP page classes from by Jasper. This would allow JSPC to create a war file which was self contained including the precompiled JSP page classes and be runnable directly from the war or unpacked into a directory. +1 if we modify Tomcat Jasper to support precompiled JSP pages running +from a self contained war file. Regards, Glenn -- To unsubscribe, e-mail: mailto:tomcat-dev- [EMAIL PROTECTED] For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: [VOTE] Proposed jspc refactoring
On Friday 08 November 2002 03:28 pm, Hans Bergsten wrote: Glenn Nielsen wrote: Remy Maucherat wrote: [...] I agree that JSPC needs to be simplified and that the webapp mode should be retained. But the webapp mode should allow for a war file to be generated which is self contained including the precompiled JSP classses. And for the generated war to be able to run from the war file with no need to unpack it. Why add this to JSPC? Isn't it already very easy to use external tools to create the WAR file (the jar command, ant's war task, etc)? I have no objections to cleaning up the JSPC code, but I would like it to stay focused on it's its main task: convert JSP source to servlet source. I have sometimes wished for automatic compilation of the servlet source to class files, but in the name of simplicity and separation of concerns, I think it's better handled by other tools. In one way, it would be better to have the JSPC do the java compilation, because it can tell exactly what the environment is supposed to be. The libraries that are available, etc. It's reproduceable in ant, but it's not a terribly expensive option to maintain in jasper2, since it follows the same path as the runtime compiler. Also I agree that this feature is a proprietary feature of Tomcat and we should no longer try to generate a war that can be deployed in any container. Why not? This works today (at least in TC 4.0.4) and I find it very handy to be able to create a JAR file for all my JSPs that I know I can deploy to any container along with the jasper-runtime.jar. If there are issues with this that I don't know about, please tell me. Otherwise I see no reason to remove this capability. If you can use JSPC to create the servlet source and web.xml fragments, it's easy to use other tools to compile the source and create a WAR with all other parts of the app (servlets, taglibs, web.xml, static stuff, etc.) and deploy it to Tomcat or any other container. As far as I can see, there's no need for a proprietary solution to get this to work. [...] Hans -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: mavenize tomcat
On Thursday 24 October 2002 08:15 pm, Warner Onstine wrote: - Original Message - From: Costin Manolache [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, October 24, 2002 4:50 PM Subject: Re: mavenize tomcat FYI, tomcat5 does have a 'download' target that gets you all the jars, and an 'update' that gets you all the cvs repositories that you need. That's what I use, and it's not that bad ( even if slow ) Interesting, sounds like it is duplicating what Maven can do as it stores all the jars in a common repository. No it doesn't do that at all. It downloads the actual distributions, or CVS trees, of projects into an area specified. No external repository of jars or internal depot of jars. You get real distributions of the dependencies, including docs and licenses. -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: [5.0] building ?
On Monday 14 October 2002 01:19 pm, Costin Manolache wrote: Remy Maucherat wrote: No, but: - my computer is relatively fast (P4m 1.6 these days) - I'll get a new one a lot faster really soon :) Well, I prefer laptops - and I prefer light over fast. And those things are quite expensive. But maybe we could work on your updated script (you said it was a lot faster), and add the utility targets to it. It is faster, but it's only good to compile stuff ( well, it can also start tomcat, but that's still too experimental ). BTW, related - are the tests working ? What's the right script and order to run jsp and container tests ? I would like a target to run the tests ( and to get that into gump ). watchdog works, and the small number of unit tests targeted by the test target works. Catalina's tester doesn't work. I've posted patches to make it work. I can repost, if it would be useful. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: JSP 2.0's J2SE 1.4 Requirement
The spec defines a conforming JSP 2.0 implementation as one that runs on JDK 1.4. A JSP author may therefore assume the new API's are available when creating their webapp. It's a serious issue for, say, Oracle, or IBM, who has a custom Java VM. But, I hadn't noticed that Apache is bundling JDK's with Tomcat. To assemble a conforming platform, a JDK 1.4 must be provided. If you use a 1.3 level JDK, then the conformance test would, presumeably, fail. And some conforming JSP pages that rely on new APIs wouldn't work. I don't see any requirement that a random JSP 2.0 page absolutely not run on JDK 1.2 or 1.3. It's simply out of scope for the spec. It comes down to what JDK level Jakarta wants to support. Tomcat 5.0 MUST run on JDK 1.4. Allowing it to run on JDK 1.3 or 1.2 should not hinder that. On Monday 07 October 2002 04:50 pm, Remy Maucherat wrote: Costin Manolache wrote: iasandcb wrote: Now it's almost clear that SRV 2.4 requires JDK 1.2 and JSP 2.0 does JDK 1.4. The main issue is discrepancy of J2SE requirement between SRV 2.4 and JSP 2.0, which are supposed to come up together. Actually, it isn't. All we know is that the current draft has this requirement. We should find a proper procedure ( for example a vote on tomcat dev ) and then ask our representative in JCP ( Geir for example - he's a very nice person ) to request a change. I don't know what's the proper mechanism yet - but Apache does have a representative and a vote, and we should have a way to have the opinion of tomcat-dev expressed. If the final JSP2.0 will require 1.4 - then we'll have to do that. It would be very unfortunate ( especially for jsp people ), and will require ( IMO ) a separate tomcat without JSPs. My opinion ( and it seems a lot of people have the same opinion ) that portability ( in the sense of beeing able to run on most OS and platforms ) seems to agree with what Apache is doing in most projects ( Apache server runs on more platforms than java - and did that even before 'write once, run everywhere'). We should first explore the alternative for having this opinion confirmed ( vote ? ) and expressed in the expert group. If the EG prefers features over portability - then we need to find a way to create a distribution without JSP ( is this possible ?) and maybe compensate by including cocoon or velocity. Personally, I would support 1.3 (and 1.2 assuming you are willing to download missing libraries). 1.4 brings I/O improvements so it's a nice JDK choice, even if the nio API itself seems useless for Tomcat. I have no problem with including Velocity if people want it. As for Cocoon, it is huge, so this looks like a bad idea. If you're interested in the issue, you should make a proper call for vote. Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Is Compile Failure? was Re: Need some clarifications
Actually, with the recent release of commons-logging, we should be able to get
rid of the explicit LogKit and Log4J. They're there so as to get a complete
build of commons-logging. Tomcat 5 itself doesn't use either directly.
Xerces is a different issue. There was a bug that was preventing Tomcat from
migrating to the latest version. Unfortunately, I no longer remember the
details. Anyone know why we're using 2.1.0 instead of 2.2.0?
On Thursday 03 October 2002 06:43 am, Christian Gross wrote:
Thank-you, but I still seem to get errors.
Namely the logkit from Avalon is referencing an old verion. I fixed it up
to the following
logkit.home=${base.path}/LogKit-1.1
logkit.lib=${logkit.home}
logkit.jar=${logkit.lib}/logkit-1.1.jar
logkit.loc=http://jakarta.apache.org/builds/jakarta-avalon/release/logkit/l
atest/LogKit-1.1-bin.tar.gz
xerces.home=${base.path}/xerces-2_2_0
xerces.lib=${xerces.home}
xercesImpl.jar=${xerces.lib}/xercesImpl.jar
xmlParserAPIs.jar=${xerces.lib}/xmlParserAPIs.jar
xerces.loc=http://xml.apache.org/dist/xerces-j/Xerces-J-bin.2.2.0.tar.gz
I do not know if you can commit changes, but these worked for me, since the
old versions either do not exist or the references have been made updated.
Christian Gross
At 09:40 PM 02/10/2002 -0400, you wrote:
You need to be using the HEAD version of digester. It should have been
built in the directory specified by base.path. Double check that it was
built correctly. I just recreated it in my depends directory, and the
system built fine.
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-5 build.properties.default
This causes all 181 Watchdog JSP tests to fail.
I don't know why yet, and it's probably something simple, but it's not a good
sign.
On Thursday 03 October 2002 08:56 am, [EMAIL PROTECTED] wrote:
remm2002/10/03 05:56:39
Modified:.build.properties.default
Log:
- New Xerces version.
Revision ChangesPath
1.38 +3 -3 jakarta-tomcat-5/build.properties.default
Index: build.properties.default
===
RCS file: /home/cvs/jakarta-tomcat-5/build.properties.default,v
retrieving revision 1.37
retrieving revision 1.38
diff -u -r1.37 -r1.38
--- build.properties.default18 Sep 2002 11:44:21 - 1.37
+++ build.properties.default3 Oct 2002 12:56:39 - 1.38
@@ -104,11 +104,11 @@
# - Xerces XML Parser, version 2.1.0 or later -
-xerces.home=${base.path}/xerces-2_1_0
+xerces.home=${base.path}/xerces-2_2_0
xerces.lib=${xerces.home}
xercesImpl.jar=${xerces.lib}/xercesImpl.jar
xmlParserAPIs.jar=${xerces.lib}/xmlParserAPIs.jar
-xerces.loc=http://xml.apache.org/dist/xerces-j/Xerces-J-bin.2.1.0.tar.gz
+xerces.loc=http://xml.apache.org/dist/xerces-j/Xerces-J-bin.2.2.0.tar.gz
# --
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Is Compile Failure? was Re: Need some clarifications
On Thursday 03 October 2002 12:14 pm, Henri Gomez wrote: Steve Downey wrote: Actually, with the recent release of commons-logging, we should be able to get rid of the explicit LogKit and Log4J. They're there so as to get a complete build of commons-logging. Tomcat 5 itself doesn't use either directly. Xerces is a different issue. There was a bug that was preventing Tomcat from migrating to the latest version. Unfortunately, I no longer remember the details. Anyone know why we're using 2.1.0 instead of 2.2.0? From what I experienced with Xerces j 2.2.0 it seems it does much more validity check and for instance found a '--' somewhere in comments (1 EUR to the first who find where). Previous version of Xerces or crimson didn't got that problem. if we could see which xml/dtd/tld is reported buggy, which will able to see if it's a bug or a features (ie a more strict check of xml rules) Going through my old mail, I was remembering the 2.0.1/2.0.2 problems that were keeping us on xerces nightly for a while. 2.1.0 fixed those problems. This seems to be a problem in parsing the 1.2 taglibs DTD. This one fails http://java.sun.com/dtd/web-jsptaglibrary_1_2.dtd where this one http://java.sun.com/j2ee/dtds/web-jsptaglibrary_1_1.dtd succeeds. Failure is at line 307, column 39. But I don't see anything significant there. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Is Compile Failure? was Re: Need some clarifications
On Thursday 03 October 2002 12:14 pm, Henri Gomez wrote: Steve Downey wrote: Actually, with the recent release of commons-logging, we should be able to get rid of the explicit LogKit and Log4J. They're there so as to get a complete build of commons-logging. Tomcat 5 itself doesn't use either directly. Xerces is a different issue. There was a bug that was preventing Tomcat from migrating to the latest version. Unfortunately, I no longer remember the details. Anyone know why we're using 2.1.0 instead of 2.2.0? From what I experienced with Xerces j 2.2.0 it seems it does much more validity check and for instance found a '--' somewhere in comments (1 EUR to the first who find where). Previous version of Xerces or crimson didn't got that problem. if we could see which xml/dtd/tld is reported buggy, which will able to see if it's a bug or a features (ie a more strict check of xml rules) OK, from the 'this shouldn't work department', this patch 'fixes' the problem: Index: ./jsr152/src/share/dtd/web-jsptaglibrary_1_2.dtd === RCS file: /home/cvspublic/jakarta-servletapi-5/jsr152/src/share/dtd/web-jsptaglibrary_1_2.dtd,v retrieving revision 1.1.1.1 diff -u -r1.1.1.1 web-jsptaglibrary_1_2.dtd --- ./jsr152/src/share/dtd/web-jsptaglibrary_1_2.dtd13 Aug 2002 16:20:58 - 1.1.1.1 +++ ./jsr152/src/share/dtd/web-jsptaglibrary_1_2.dtd3 Oct 2002 20:42:30 - @@ -304,6 +304,7 @@ java.lang.String is default. declare Whether the variable is declared or not. + True is the default. scopeThe scope of the scripting varaible Something quite strange is going on. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Need some clarifications
On Wednesday 02 October 2002 09:38 am, Christian Gross wrote: Hi So I worked myself through the various CVS sources and have a couple of official position questions to ask. The CVS projects jakarta-tomcat-catalina and jakarta-tomcat-jasper, will be forming the Tomcat 5 work? jakarta-servletapi-5, jakarta-tomcat-5, jakarta-tomcat-catalina, jakarta-tomcat-connectors, jakarta-tomcat-jasper, and jakarta-watchdog-4.0 are the CVS repositories involved in Tomcat 5.0 The CVS project jakarta-tomcat-4.0 is the 4.x branch? Yes The CVS project jakarta-tomcat is anything before 4.0 Tomcat 3.x, at least. The CVS project jakarta-tomcat-5.0 does nothing?? It's the master project for the whole Tomcat 5.0 project. To use it, start with a directory like tc5-workspace. In that directory: export CVSROOT=:pserver:[EMAIL PROTECTED]:/home/cvspublic cvs co jakarta-servletapi-5 cvs co jakarta-tomcat-5 cvs co jakarta-tomcat-catalina cvs co jakarta-tomcat-connectors cvs co jakarta-tomcat-jasper then, in jakarta-tomcat-5 create a build.properties file with the following definition base.path = /home/sdowney/tc5-workspace/depends (replace /home/sdowney/tc5-workspace with path to your workspace. I don't know if relative will work. I stopped dinking when I got my build system to function) You need ant 1.5 to build Tomcat 5 export ANT_HOME=/home/sdowney/tools/jakarta-ant-1.5 PATH=$PATH:$ANT_HOME/bin ant download The download target in Tomcat 5 gets the necessary ancillary libraries to build the system. I'm using JDK 1.4, which has a few things built in. You may need to install some things in JDK 1.3, like JCE. I'm not sure. Then: ant build ant test [Not many tests at the moment] If you're contributing, you may also want to do ant -Dfull.dist=on build That will force a full compile, rather than checking which optional components are available and setting things on or off based on the presense or absense of classes. That useful for building a customized version, but for testing purposes, a full build is better. To run the watchdog conformance test suite: ant watchdog -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Is Compile Failure? was Re: Need some clarifications
You need to be using the HEAD version of digester. It should have been built in the directory specified by base.path. Double check that it was built correctly. I just recreated it in my depends directory, and the system built fine. A number of the dependencies are unreleased at this point. 'ant download' tries to grab the correct ones. On Wednesday 02 October 2002 07:54 pm, Christian Gross wrote: Thanks for your answer. That helps quite a bit. Now I have another issue... build-catalina: [javac] Compiling 94 source files to D:\Instructor\Projects\jakarta-tomcat-c atalina\build\server\classes [javac] D:\Instructor\Projects\jakarta-tomcat-catalina\catalina\src\share\or g\apache\catalina\startup\ContextConfig.java:537: cannot resolve symbol [javac] symbol : method setEntityResolver (org.apache.catalina.util.Schema Resolver) [javac] location: class org.apache.commons.digester.Digester [javac] tldDigester.setEntityResolver(tldEntityResolver); [javac]^ [javac] D:\Instructor\Projects\jakarta-tomcat-catalina\catalina\src\share\or g\apache\catalina\startup\ContextConfig.java:595: cannot resolve symbol [javac] symbol : method setEntityResolver (org.apache.catalina.util.Schema Resolver) [javac] location: class org.apache.commons.digester.Digester [javac] webDigester.setEntityResolver(webEntityResolver); [javac]^ [javac] D:\Instructor\Projects\jakarta-tomcat-catalina\catalina\src\share\or g\apache\catalina\util\SchemaResolver.java:154: cannot resolve symbol [javac] symbol : method setPublicId (java.lang.String) [javac] location: class org.apache.commons.digester.Digester [javac] digester.setPublicId(publicId); [javac] ^ [javac] Note: Some input files use or override a deprecated API. [javac] Note: Recompile with -deprecation for details. [javac] 3 errors BUILD FAILED file:D:/Instructor/Projects/jakarta-tomcat-catalina/catalina/build.xml:801: Comp ile failed; see the compiler error output for details. I checked out digester 1.3 and 1.2 and there does not seem to be a method setEntityResolver. Or am I missing something? Christian Gross At 14:18 02/10/2002 -0400, you wrote: On Wednesday 02 October 2002 09:38 am, Christian Gross wrote: Hi So I worked myself through the various CVS sources and have a couple of official position questions to ask. The CVS projects jakarta-tomcat-catalina and jakarta-tomcat-jasper, will be forming the Tomcat 5 work? jakarta-servletapi-5, jakarta-tomcat-5, jakarta-tomcat-catalina, jakarta-tomcat-connectors, jakarta-tomcat-jasper, and jakarta-watchdog-4.0 are the CVS repositories involved in Tomcat 5.0 The CVS project jakarta-tomcat-4.0 is the 4.x branch? Yes The CVS project jakarta-tomcat is anything before 4.0 Tomcat 3.x, at least. The CVS project jakarta-tomcat-5.0 does nothing?? It's the master project for the whole Tomcat 5.0 project. To use it, start with a directory like tc5-workspace. In that directory: export CVSROOT=:pserver:[EMAIL PROTECTED]:/home/cvspublic cvs co jakarta-servletapi-5 cvs co jakarta-tomcat-5 cvs co jakarta-tomcat-catalina cvs co jakarta-tomcat-connectors cvs co jakarta-tomcat-jasper then, in jakarta-tomcat-5 create a build.properties file with the following definition base.path = /home/sdowney/tc5-workspace/depends (replace /home/sdowney/tc5-workspace with path to your workspace. I don't know if relative will work. I stopped dinking when I got my build system to function) You need ant 1.5 to build Tomcat 5 export ANT_HOME=/home/sdowney/tools/jakarta-ant-1.5 PATH=$PATH:$ANT_HOME/bin ant download The download target in Tomcat 5 gets the necessary ancillary libraries to build the system. I'm using JDK 1.4, which has a few things built in. You may need to install some things in JDK 1.3, like JCE. I'm not sure. Then: ant build ant test [Not many tests at the moment] If you're contributing, you may also want to do ant -Dfull.dist=on build That will force a full compile, rather than checking which optional components are available and setting things on or off based on the presense or absense of classes. That useful for building a customized version, but for testing purposes, a full build is better. To run the watchdog conformance test suite: ant watchdog -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] Christian Gross Software Engineering Consultant http://www.devspace.com North America: 1-450-675-4208 Europe +41.1.701.1166 -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [SECURITY] Apache Tomcat 4.x JSP source disclosure vulnerability
On Tuesday 24 September 2002 05:26 pm, Jon Scott Stevens wrote: on 2002/9/24 4:59 AM, Remy Maucherat [EMAIL PROTECTED] wrote: A security vulnerability has been confirmed to exist in all Apache Tomcat 4.x releases (including Tomcat 4.0.4 and Tomcat 4.1.10), which allows to use a specially crafted URL to return the unprocessed source of a JSP page, or, under special circumstances, a static resource which would otherwise have been protected by security constraint, without the need for being properly authenticated. Once again...JSP sucks and Velocity is the right way to go...you will never have to worry about your container spilling your beans (pun intended). Perhaps you would prefer this exploit? http://localhost:8080/velexample/servlet/org.apache.catalina.servlets.DefaultServlet/sample.vm Horrors! Velocity is insecure! The DefaultServlet exploit is a general security problem in Tomcat. JSP may be somewhat more vulnerable, due to the (somewhat naieve) expectation that the source will be confidential, but it's not really JSP per se that is at fault. I wonder what could be done with the CGIServlet, for example. The root cause is the InvokerServlet. It's inherently insecure. It can be used not just to execute an arbitrary servlet, but to actually load any java class. And loading a class is not side-effect free. Given that Tomcat gets around 100k+ downloads/week...imagine how many servers now need to be updated and how much money and time that will cost to do so? http://jakarta.apache.org/velocity/ Wake up people. Velocity is faster and more secure than JSP will ever be. As long as it's running on an insecure container, it's really no safer. -jon -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[5][PATCH]catalina/tester fix golden files for new request listener noise
JSP includes now trigger request listeners with the attributes for dispatcher types and dispatcher request paths. This patch adds the output from the request listener to the golden files. Index: JspInclude01a.txt === RCS file: /home/cvspublic/jakarta-tomcat-catalina/tester/web/golden/JspInclude01a.txt,v retrieving revision 1.1.1.1 diff -u -r1.1.1.1 JspInclude01a.txt --- JspInclude01a.txt 18 Jul 2002 16:47:25 - 1.1.1.1 +++ JspInclude01a.txt 23 Sep 2002 17:36:30 - @@ -1,6 +1,8 @@ This is before the include Include00a PASSEDSessionListener01: sessionCreated() SessionListener02: sessionCreated() +RequestListener01: attributeReplaced(org.apache.catalina.core.DISPATCHER_TYPE,8) +RequestListener01: attributeReplaced(org.apache.catalina.core.DISPATCHER_REQUEST_PATH,/JspInclude01.jsp) This is after the include Index: JspInclude02a.txt === RCS file: /home/cvspublic/jakarta-tomcat-catalina/tester/web/golden/JspInclude02a.txt,v retrieving revision 1.1.1.1 diff -u -r1.1.1.1 JspInclude02a.txt --- JspInclude02a.txt 18 Jul 2002 16:47:25 - 1.1.1.1 +++ JspInclude02a.txt 23 Sep 2002 17:36:30 - @@ -1,6 +1,8 @@ This is before the include Include00a PASSEDSessionListener01: sessionCreated() SessionListener02: sessionCreated() +RequestListener01: attributeReplaced(org.apache.catalina.core.DISPATCHER_TYPE,8) +RequestListener01: attributeReplaced(org.apache.catalina.core.DISPATCHER_REQUEST_PATH,/JspInclude02.jsp) This is after the include -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[PATCH][5] Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/authenticator SSLAuthenticator.java
JDK 1.4's javac doesn't like this. It's complaining about casting Object to
X509Certificate[].
On Saturday 21 September 2002 02:50 am, [EMAIL PROTECTED] wrote:
billbarker2002/09/20 23:50:30
Modified:catalina/src/share/org/apache/catalina/authenticator
SSLAuthenticator.java
Log:
Final level in replacing CertificatesValve under Coyote.
This is a little hackish, but is portable to 4.x without changing the
API. Here, it should probably change once Coyote is properly exposed to
Catalina.
If there aren't any major complaints, I'll port to the 4.1 branch later.
Revision ChangesPath
1.2 +7 -4
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/authenticato
r/SSLAuthenticator.java
Index: SSLAuthenticator.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/au
thenticator/SSLAuthenticator.java,v retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- SSLAuthenticator.java 18 Jul 2002 16:48:02 - 1.1
+++ SSLAuthenticator.java 21 Sep 2002 06:50:30 - 1.2
@@ -150,6 +150,9 @@
log( Looking up certificates);
X509Certificate certs[] = (X509Certificate[])
request.getRequest().getAttribute(Globals.CERTIFICATES_ATTR); + if ((certs
== null) || (certs.length 1)) {
+ certs =
request.getRequest().getAttribute(Globals.SSL_CERTIFICATE_ATTR); +}
if ((certs == null) || (certs.length 1)) {
if (debug = 1)
log( No certificates included with this request);
Index: SSLAuthenticator.java
===
RCS file: /home/cvspublic/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/authenticator/SSLAuthenticator.java,v
retrieving revision 1.3
diff -u -r1.3 SSLAuthenticator.java
--- SSLAuthenticator.java 21 Sep 2002 07:25:21 - 1.3
+++ SSLAuthenticator.java 22 Sep 2002 19:46:43 -
@@ -151,7 +151,7 @@
X509Certificate certs[] = (X509Certificate[])
request.getRequest().getAttribute(Globals.CERTIFICATES_ATTR);
if ((certs == null) || (certs.length 1)) {
-certs = request.getRequest().getAttribute(Globals.SSL_CERTIFICATE_ATTR);
+certs = (X509Certificate[]) request.getRequest().getAttribute(Globals.SSL_CERTIFICATE_ATTR);
}
if ((certs == null) || (certs.length 1)) {
if (debug = 1)
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Jasper 2 Question
On Friday 20 September 2002 06:18 am, Pier Fumagalli wrote: Hm The original question was about line numbers on JSPs, when they are compiled, and when they are executed and throw exceptions, right? Yes, it was... I said use some tea because Tea, developed by Disney, goes exactly in that direction, not having middle layer .java files over which the line number get messed up, they simply compile a template straight into .class having both the advantage of compiled templates, and the advatage that line numbers, both at compilation and runtime, are preserved... No, the original question was about the debugging capabilities that have been removed from jasper2. Jasper used to mark the begin and end points in the original source in the java translation as comments in the form: // HTML // begin [file=/index.jsp;from=(0,0);to=(4,0)] Restoring that ability would be somewhat difficult as the parser doesn't track the endpoints of the nodes, just the starts. Jasper2 is able to output data that might be compatible with JSR-45. No one's really sure, yet. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Jasper 2 Question
On Friday 20 September 2002 07:27 am, peter lin wrote: I would also like to see the comments in jasper1 ported over to jasper2. Now if only I didn't need sleep, I'd do it myself and submit a patch. the code changed quite a bit between jasper1 and jasper2. the class responsible is in jasper/compiler/Generator in case you get the urge to port the comments over :) Plus adding the end Mark in Node.Node. And classifying the Nodes in a similar manner to the old Generators. peter John Trollinger wrote: To answer your original question, I do not believe there is any enhancements to add documentation back to the generated servelt code. If you would like to see this enhancement you can allways suggest it to the tomcat developers, or you could add the code in yourself and submit a patch. And don't buy all the velocity hype... :-) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Jasper 2 Question
Jasper2 is targeting JSR45, Debugging Support for Other Languages. On Thursday 19 September 2002 06:28 pm, Lenny Karpel wrote: ok .. now I am really confused .. here is the tomcat development group .. the 'Official Reference Implementation' for JSP .. and I am being told by people within this group .. to NOT use it .. this is truly amazing .. how can this possibly be .. my original question is about 'bugs' in jasper2 .. not about what tools I should use .. my question is not one of religion .. once again .. the quote from the intellij site .. As for Tomcat 4.1.x support, I'm afraid we are out-of-luck here. Tomcat 4.0.4 used to generate useful comments in the servlet code, that allowed the integration plugin to map jsp line numbers to servlet line numbers. But from the new version of Tomcat (Jasper2 in particular), this functionality is missing. At least I haven't been able to find anything to enable comment generation, and nobody from Tomcat user-list answered my question about this. for myself .. all I want to know .. is if this 'situation' in jasper2 will be fixed .. if so .. when .. if not .. why .. we use JSP here .. as do quite a few others .. in quite a few places .. i did not post this question to find out that the developers of JSP (jasper) would rather I use something else .. could this possibly be how the 'managers' of this development effort feel ?? -Original Message- From: Bojan Smojver [mailto:[EMAIL PROTECTED]] Sent: Thursday, September 19, 2002 3:25 PM To: Tomcat Dev List Subject: RE: Jasper 2 Question On Fri, 2002-09-20 at 04:30, Lenny Karpel wrote: is it right that when I ask a serious question about jasper2 that I get these totally ridiculous answers ? Well, Jon and Pier are known to throw in a curly one from time to time, which keeps all of us here on the list in good spirits ;-) Anyway, there is a serious side to all this as JSP's are inherently evil. You'll find that creating true MVC applications in Velocity is almost trivial. I suggest you do read Jon's article. The fact that JSP's are official, doesn't mean they are good. Bojan -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/buf DateTool.java
OK, ignore my last message.
But, it's not just less paranoid. It's more correct. If rfc1123Format were
used elsewhere, the lock on Class.DateTool would not be sufficient.
Actually, refreshing my memory on this bug, synchronization is insufficient.
http://developer.java.sun.com/developer/bugParade/bugs/4228335.html
The upshot is that DateFormats need to be either thread local, or created new
each time.
On Wednesday 18 September 2002 12:20 am, [EMAIL PROTECTED] wrote:
billbarker2002/09/17 21:20:24
Modified:util/java/org/apache/tomcat/util/buf DateTool.java
Log:
A little less paraniod than the last one, but functionally the same.
Revision ChangesPath
1.7 +6 -2
jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/buf/DateTool.jav
a
Index: DateTool.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/buf/Da
teTool.java,v retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- DateTool.java 18 Sep 2002 03:50:04 - 1.6
+++ DateTool.java 18 Sep 2002 04:20:24 - 1.7
@@ -141,8 +141,12 @@
// Called from MessageBytes.setTime
/**
*/
-public static synchronized String format1123( Date d ) {
- return format1123(d, rfc1123Format);
+public static String format1123( Date d ) {
+ String dstr=null;
+ synchronized(rfc1123Format) {
+ dstr = format1123(d, rfc1123Format);
+ }
+ return dstr;
}
public static String format1123( Date d,DateFormat df ) {
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/buf DateTool.java
On Wednesday 18 September 2002 08:34 am, Henri Gomez wrote: The upshot is that DateFormats need to be either thread local, or created new each time. Created each time is exactly what we want to avoid ;) Sacrificing correctness for speed isn't a great trade-off. After all, if it doesn't have to work, I can make it a LOT faster. In this case, it looks like the problem with SimpleDateFormat is manageable with synchronization. SDF can leak some of its internal state with get/setCalendar. Since in the connectors DateTool, the formatter instance is private, and get/setCalendar is never called, syncing on the instance should be sufficient. It looks like the same problem exists in catalina's DateTool. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[PATCH] catalina DateTool thread safety issue
This patch mirrors that in connectors. DateTool in catalina util is largely
obsolete, in any case. The patch cuts out unused code.
? share/org/apache/catalina/startup/CatalinaService.java.smd
Index: share/org/apache/catalina/util/CookieTools.java
===
RCS file: /home/cvspublic/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/util/CookieTools.java,v
retrieving revision 1.1.1.1
diff -u -w -r1.1.1.1 CookieTools.java
--- share/org/apache/catalina/util/CookieTools.java 18 Jul 2002 16:47:45 - 1.1.1.1
+++ share/org/apache/catalina/util/CookieTools.java 18 Sep 2002 23:35:05 -
@@ -143,10 +143,10 @@
if (version == 0) {
buf.append (;Expires=);
if (cookie.getMaxAge() == 0)
-DateTool.oldCookieFormat.format(new Date(1), buf,
+DateTool.formatOldCookie(new Date(1), buf,
new FieldPosition(0));
else
-DateTool.oldCookieFormat.format
+DateTool.formatOldCookie
(new Date( System.currentTimeMillis() +
cookie.getMaxAge() *1000L), buf,
new FieldPosition(0));
Index: share/org/apache/catalina/util/DateTool.java
===
RCS file: /home/cvspublic/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/util/DateTool.java,v
retrieving revision 1.1.1.1
diff -u -w -r1.1.1.1 DateTool.java
--- share/org/apache/catalina/util/DateTool.java 18 Jul 2002 16:47:45 - 1.1.1.1
+++ share/org/apache/catalina/util/DateTool.java 18 Sep 2002 23:35:05 -
@@ -79,55 +79,34 @@
*/
public class DateTool {
-private static StringManager sm =
-StringManager.getManager(org.apache.catalina.util);
-
/** US locale - all HTTP dates are in english
*/
public final static Locale LOCALE_US = Locale.US;
/** GMT timezone - all HTTP dates are on GMT
*/
-public final static TimeZone GMT_ZONE = TimeZone.getTimeZone(GMT);
-
-/** format for RFC 1123 date string -- Sun, 06 Nov 1994 08:49:37 GMT
- */
-public final static String RFC1123_PATTERN =
-EEE, dd MMM y HH:mm:ss z;
-
-// format for RFC 1036 date string -- Sunday, 06-Nov-94 08:49:37 GMT
-private final static String rfc1036Pattern =
-E, dd-MMM-yy HH:mm:ss z;
-
-// format for C asctime() date string -- Sun Nov 6 08:49:37 1994
-private final static String asctimePattern =
-EEE MMM d HH:mm:ss y;
+private final static TimeZone GMT_ZONE = TimeZone.getTimeZone(GMT);
/** Pattern used for old cookies
*/
public final static String OLD_COOKIE_PATTERN = EEE, dd-MMM- HH:mm:ss z;
-/** DateFormat to be used to format dates
- */
-public final static DateFormat rfc1123Format =
-new SimpleDateFormat(RFC1123_PATTERN, LOCALE_US);
-
/** DateFormat to be used to format old netscape cookies
*/
-public final static DateFormat oldCookieFormat =
+private final static DateFormat oldCookieFormat =
new SimpleDateFormat(OLD_COOKIE_PATTERN, LOCALE_US);
-public final static DateFormat rfc1036Format =
-new SimpleDateFormat(rfc1036Pattern, LOCALE_US);
-
-public final static DateFormat asctimeFormat =
-new SimpleDateFormat(asctimePattern, LOCALE_US);
-
static {
-rfc1123Format.setTimeZone(GMT_ZONE);
oldCookieFormat.setTimeZone(GMT_ZONE);
-rfc1036Format.setTimeZone(GMT_ZONE);
-asctimeFormat.setTimeZone(GMT_ZONE);
+}
+
+public static StringBuffer formatOldCookie(
+ Date d,
+ StringBuffer buf,
+ FieldPosition fieldPosition) {
+ synchronized (oldCookieFormat) {
+return oldCookieFormat.format(d, buf, fieldPosition);
+ }
}
}
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Catalina tester failure on JSP Document Parsing
I'm seeing the following error on catalina's tester app, running it under Tomcat 5: [echo] - JSP Document Parsing - [tester] EXPECTED: == [tester] atextb/b/aatextb/b/acdtext/d/ccdtext/d/cef/ftextf/f/eef/ftextf/f/e [tester] [tester] RECEIVED: == [tester] atextb//aatextb//acdtext/d/ccdtext/d/cef/textf//eef/textf//e [tester] [tester] FAIL [GET /tester/JspDoc01.jsp HTTP/1.0] Failed Golden File Comparison However, I'm not sure the test is actually correct. It's failing because of the empty elements being converted from b/b to b/, and from f/f to /f. But, under XML, those are identical ways of saying the same thing. If my analysis is correct, then the golden text needs to be changed, and here is a patch for it. Otherwise, there's a deeper problem. Index: golden/JspDoc01.txt === RCS file: /home/cvspublic/jakarta-tomcat-catalina/tester/web/golden/JspDoc01.txt,v retrieving revision 1.1.1.1 diff -u -w -r1.1.1.1 JspDoc01.txt --- golden/JspDoc01.txt 18 Jul 2002 16:47:25 - 1.1.1.1 +++ golden/JspDoc01.txt 11 Sep 2002 22:10:51 - @@ -1 +1 @@ -atextb/b/aatextb/b/acdtext/d/ccdtext/d/cef/ftextf/f/eef/ftextf/f/e +atextb//aatextb//acdtext/d/ccdtext/d/cef/textf//eef/textf//e \ No newline at end of file -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Catalina tester failure on JSP Document Parsing
The tests for Tomcat4 are in jakarta-tomcat-4.0/tester, while the tests for tomcat 5 are in jakarta-tomcat-catalina/tester, so fixing them shouldn't be a problem in that sense. Howver, since tomcat 4 is now shipping with jasper2, isn't it a problem for tomcat 4, also? In any case, given the lack of depth in this test, I think the right answer is to change it to eliminate the empty tags. I think it's really trying just to see if JSP Document is there as a feature, not really checking the handling of XML. On Wednesday 11 September 2002 06:21 pm, Kin-Man Chung wrote: I'd suggest that we remove this test. Jasper 2 and jasper produces different but correct XML view of the JSP document. If the golden file is fixed to pass in TC5, it would then fail in TC4.0. Date: Wed, 11 Sep 2002 18:10:59 -0400 From: Steve Downey [EMAIL PROTECTED] Subject: Catalina tester failure on JSP Document Parsing To: [EMAIL PROTECTED] I'm seeing the following error on catalina's tester app, running it under Tomcat 5: [echo] - JSP Document Parsing - [tester] EXPECTED: == [tester] atextb/b/aatextb/b/acdtext/d/ccdtext/d/ce f/ ftextf/f/eef/ftextf/f/e [tester] [tester] RECEIVED: == [tester] atextb//aatextb//acdtext/d/ccdtext/d/cef/te xtf/ /eef/textf//e [tester] [tester] FAIL [GET /tester/JspDoc01.jsp HTTP/1.0] Failed Golden File Comparison However, I'm not sure the test is actually correct. It's failing because of the empty elements being converted from b/b to b/, and from f/f to /f. But, under XML, those are identical ways of saying the same thing. If my analysis is correct, then the golden text needs to be changed, and here is a patch for it. Otherwise, there's a deeper problem. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Contributing patches/enhancements?
From my experience, it depends if it's a bug or an enhancement. If it's a bug, Bugzilla is your friend. Someone will eventually have to deal with it before a release. Just posting to the mailing list means that it's likely to get lost. And patches for bugs tend to be fairly stable over time. On the other hand, putting enhancements in Bugzilla isn't as effective. Bugzilla isn't very good for discussion. And enhancements often are more invasive to the code, so a patch isn't as likely to be effective later. Just my $0.02 On Wednesday 11 September 2002 06:16 pm, Eddie Ruvinsky wrote: Hello, I have a process question about how I could contribute Tomcat source patches/enhancements? Would I open a Bugzilla and attach a diff text file, then wait for an official Tomcat contributor to review it and add it into the source tree? Thanks, Eddie - Yahoo! - We Remember 9-11: A tribute to the more than 3,000 lives lost -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina build.xml gump.xml
Perhaps you could also change
ant dir=${basedir}/catalina target=${catalina.target}/
back to target=deploy, since you deleted the catalina.target property?
On Tuesday 10 September 2002 01:26 pm, [EMAIL PROTECTED] wrote:
bobh2002/09/10 10:26:17
Modified:.build.xml gump.xml
Log:
- Larry Isaacs suggests that using an additional target is more
typical way to handle this situation (different build paths for gump
vs other build.xml)
Revision ChangesPath
1.7 +10 -3 jakarta-tomcat-catalina/build.xml
Index: build.xml
===
RCS file: /home/cvs/jakarta-tomcat-catalina/build.xml,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- build.xml 10 Sep 2002 15:53:38 - 1.6
+++ build.xml 10 Sep 2002 17:26:17 - 1.7
@@ -11,9 +11,6 @@
!-- Build Defaults --
!--property name=catalina.build
value=${basedir}/catalina/build/--
- !-- used by gump to keep from building more that just catalina --
- property name=catalina.target value=deploy /
-
!-- Source dependencies --
property name=api.home
value=${basedir}/../jakarta-servletapi-5/
@@ -46,6 +43,16 @@
description=Build and deploy all components
echoTarget: Catalina - Deploy .../echo
ant dir=${basedir}/catalina target=${catalina.target}/
+echoTarget: Webapps - Deploy .../echo
+ant dir=${basedir}/webapps target=deploy/
+ /target
+
+ !-- == DEPLOY: Deploy Core Components
=== -- + !-- used by gump to build just catalina and not
the j-t-connectors -- + target name=deploy-catalina
depends=deploy-static
+ description=Build and deploy all components
+echoTarget: Catalina - Deploy .../echo
+ant dir=${basedir}/catalina target=deploy-catalina/
echoTarget: Webapps - Deploy .../echo
ant dir=${basedir}/webapps target=deploy/
/target
1.8 +1 -2 jakarta-tomcat-catalina/gump.xml
Index: gump.xml
===
RCS file: /home/cvs/jakarta-tomcat-catalina/gump.xml,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- gump.xml10 Sep 2002 16:16:54 - 1.7
+++ gump.xml10 Sep 2002 17:26:17 - 1.8
@@ -10,8 +10,7 @@
project name=jakarta-tomcat-catalina
packageorg.apache.catalina/package
-ant target=deploy
- property name=catalina.target value=deploy-catalina /
+ant target=deploy-catalina
property name=jtc.home project=jakarta-tomcat-connectors
reference=home/
property name=catalina.home project=jakarta-tomcat-catalina
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup ContextConfig.java
Broken build, please revert this. Log has no log method. (Second time today. Bound to happen once in while.) On Tuesday 10 September 2002 03:40 pm, [EMAIL PROTECTED] wrote: jfarcand2002/09/10 12:40:25 Modified:catalina/src/share/org/apache/catalina/startup ContextConfig.java Log: Change the logging levelo from Info to Log when performance information are displayed.CVS: -- -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[5][PATCH] catalina/tester fix some false positive and false negative tests
This patch builds tester against the servletapi-5 classes and repairs the URLs in the JSP examples used by tester. These were causing some false positve and false negative test results. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [5][PATCH] catalina/tester fix some false positive and false negative tests
sigh/
On Tuesday 10 September 2002 10:56 pm, Steve Downey wrote:
This patch builds tester against the servletapi-5 classes and repairs the
URLs in the JSP examples used by tester. These were causing some false
positve and false negative test results.
Index: build.xml
===
RCS file: /home/cvspublic/jakarta-tomcat-catalina/tester/build.xml,v
retrieving revision 1.1.1.1
diff -u -w -r1.1.1.1 build.xml
--- build.xml 18 Jul 2002 16:47:24 - 1.1.1.1
+++ build.xml 11 Sep 2002 02:54:01 -
@@ -8,14 +8,14 @@
property file=${user.home}/build.properties/
property name=build.compiler value=classic/
- property name=servletapi.home value=../../jakarta-servletapi-4/dist/
+ property name=api.home value=../../jakarta-servletapi-5/dist/
property name=tester.buildvalue=${basedir}/build/
property name=tester.deploy value=${basedir}/../build/
property name=tester.dist value=${basedir}/dist/
!-- == Derived Property Values = --
property name=ant.jar value=${ant.home}/lib/ant.jar/
- property name=servlet.jar value=${servletapi.home}/lib/servlet.jar/
+ property name=servlet-api.jar value=${api.home}/jsr154/dist/lib/servlet-api.jar/
!-- === BUILD: Create Directories == --
target name=build-prepare
@@ -56,7 +56,7 @@
!-- Compile tester components and tools --
javac srcdir=src/tester destdir=${tester.build}/classes
- classpath=${ant.jar}:${servlet.jar}:${xerces.jar}
+ classpath=${ant.jar}:${servlet-api.jar}:${xercesImpl.jar}
deprecation=off debug=on optimize=off
excludes=**/CVS/**/
@@ -87,7 +87,7 @@
tofile=${tester.build}/web/WEB-INF/classes/org/apache/tester/Unpacked05.txt/
!-- Install Xerces --
-copy todir=${tester.build}/web/WEB-INF/lib file=${xerces.jar}/
+copy todir=${tester.build}/web/WEB-INF/lib file=${xercesImpl.jar}/
!-- Create and install tester library --
mkdir dir=${tester.build}/web/WEB-INF/lib/
Index: src/bin/tester.xml
===
RCS file: /home/cvspublic/jakarta-tomcat-catalina/tester/src/bin/tester.xml,v
retrieving revision 1.2
diff -u -w -r1.2 tester.xml
--- src/bin/tester.xml 9 Aug 2002 02:12:13 - 1.2
+++ src/bin/tester.xml 11 Sep 2002 02:54:01 -
@@ -8,11 +8,15 @@
!-- property name=protocol value=HTTP/1.0/ --
property name=protocol value=/ !-- Use HttpURLConnection --
property name=context.path value=/tester/
- property name=examples.path value=/examples/
+ property name=examples.path value=/jsp-examples/
property name=golden.pathvalue=${context.path}/golden/
property name=manager.path value=/manager/
property name=reload.pathvalue=/tester/
- taskdef name=tester classname=org.apache.tester.TestClient/
+ taskdef name=tester classname=org.apache.tester.TestClient
+classpath
+ pathelement location=${catalina.home}/webapps/tester/WEB-INF/lib/tester.jar/
+/classpath
+ /taskdef
target name=all depends=ROOT,Authentication,CaseSensitive,Decoding,ErrorPage,FilterRequest,FilterResponse,Jndi,Jsp,Lifecycle,RequestDispatcher,Resources,Security,ServletContext,ServletRequest,ServletResponse,HttpSession,XercesTest/
@@ -110,33 +114,23 @@
status=404/
!-- Should be able to execute the Date example --
-touch file=${catalina.home}/webapps/examples/jsp/dates/date.jsp/
tester host=${host} port=${port} protocol=${protocol}
- request=${examples.path}/jsp/dates/date.jsp debug=${debug}
+ request=${examples.path}/dates/date.jsp debug=${debug}
status=200/
!-- Should not be able to view the source of the Date example --
-touch file=${catalina.home}/webapps/examples/jsp/dates/date.jsp/
tester host=${host} port=${port} protocol=${protocol}
- request=${examples.path}/jsp/dates/date.Jsp debug=${debug}
+ request=${examples.path}/dates/date.Jsp debug=${debug}
status=404/
!-- Should not be able to view the source of the Date example --
-touch file=${catalina.home}/webapps/examples/jsp/dates/date.jsp/
tester host=${host} port=${port} protocol=${protocol}
- request=${examples.path}/jsp/dates/Date.jsp debug=${debug}
+ request=${examples.path}/dates/Date.jsp debug=${debug}
status=404/
!-- Should not be able to view the source of the Date example --
-touch file=${catalina.home}/webapps/examples/jsp/dates/date.jsp/
tester host=${host} port=${port} protocol=${protocol}
- request=${examples.path}/jsp/Dates/date.jsp debug=${debug}
- status=404/
-
-!-- Should not be able to view the source of the Date example --
-touch file=${catalina.home}/webapps/examples/jsp/dates/date.jsp/
-tester host=${host} port=${port} protocol=${protocol}
- request
[5][PATCH] Enable manager app in catalina/tester deployment
The tester app needs to unload and reload the tester webapp, but, of course,
the manager app is not enabled by default. This adds a tomcat-users.xml so
that it can be deployed and run automatically.
Now there are only a few failures left that I'm seeing.
The tomcat-users.xml should go into a new directory conf, under src. i.e.
jakarta-tomcat-catalina/tester/src/conf.
Index: build.xml
===
RCS file: /home/cvspublic/jakarta-tomcat-catalina/tester/build.xml,v
retrieving revision 1.1.1.1
diff -u -w -r1.1.1.1 build.xml
--- build.xml 18 Jul 2002 16:47:24 - 1.1.1.1
+++ build.xml 11 Sep 2002 03:50:23 -
@@ -8,19 +8,20 @@
property file=${user.home}/build.properties/
property name=build.compiler value=classic/
- property name=servletapi.home value=../../jakarta-servletapi-4/dist/
+ property name=api.home value=../../jakarta-servletapi-5/dist/
property name=tester.buildvalue=${basedir}/build/
property name=tester.deploy value=${basedir}/../build/
property name=tester.dist value=${basedir}/dist/
!-- == Derived Property Values = --
property name=ant.jar value=${ant.home}/lib/ant.jar/
- property name=servlet.jar value=${servletapi.home}/lib/servlet.jar/
+ property name=servlet-api.jar value=${api.home}/jsr154/dist/lib/servlet-api.jar/
!-- === BUILD: Create Directories == --
target name=build-prepare
mkdir dir=${tester.build}/
mkdir dir=${tester.build}/bin/
+mkdir dir=${tester.build}/conf/
mkdir dir=${tester.build}/classes/
mkdir dir=${tester.build}/lib/
/target
@@ -30,7 +31,6 @@
target name=build-static depends=build-prepare
!-- Executable Commands --
-mkdir dir=${tester.build}/bin/
copy todir=${tester.build}/bin
fileset dir=src/bin /
/copy
@@ -38,8 +38,11 @@
fixcrlf srcdir=${tester.build}/bin includes=*.bat eol=crlf/
chmod perm=+x file=${tester.build}/bin/tester.sh/
+copy todir=${tester.build}/conf
+ fileset dir=src/conf /
+/copy
+
!-- Compiled Classes --
-mkdir dir=${tester.build}/classes/
!-- Web Application --
mkdir dir=${tester.build}/web/
@@ -56,7 +59,7 @@
!-- Compile tester components and tools --
javac srcdir=src/tester destdir=${tester.build}/classes
- classpath=${ant.jar}:${servlet.jar}:${xerces.jar}
+ classpath=${ant.jar}:${servlet-api.jar}:${xercesImpl.jar}
deprecation=off debug=on optimize=off
excludes=**/CVS/**/
@@ -87,7 +90,7 @@
tofile=${tester.build}/web/WEB-INF/classes/org/apache/tester/Unpacked05.txt/
!-- Install Xerces --
-copy todir=${tester.build}/web/WEB-INF/lib file=${xerces.jar}/
+copy todir=${tester.build}/web/WEB-INF/lib file=${xercesImpl.jar}/
!-- Create and install tester library --
mkdir dir=${tester.build}/web/WEB-INF/lib/
@@ -132,6 +135,7 @@
target name=deploy-prepare
mkdir dir=${tester.deploy}/
mkdir dir=${tester.deploy}/bin/
+mkdir dir=${tester.deploy}/conf/
/target
@@ -145,6 +149,10 @@
fixcrlf srcdir=${tester.deploy}/bin includes=*.sh eol=lf/
fixcrlf srcdir=${tester.deploy}/bin includes=*.bat eol=crlf/
chmod perm=+x file=${tester.deploy}/bin/tester.sh/
+
+copy todir=${tester.deploy}/conf overwrite=yes
+ fileset dir=${tester.build}/conf /
+/copy
!-- Unpacked Shared Classes --
mkdir dir=${tester.deploy}/shared/classes/
!--
NOTE: By default, no user is included in the manager role required
to operate the /manager web application. If you wish to use this app,
you must define such a user - the username and password are arbitrary.
--
tomcat-users
user name=tomcat password=tomcat roles=tomcat,role1,manager /
/tomcat-users
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[5][PATCH]JSP examples now at different URI
Rather than being under /examples/jsp/, they're now under /jsp-examples/. The
plugin needs to be aware of the full URI, but everything else is context
relative.
? .classpath
? .cvsignore
? .project
Index: jsr152/examples/WEB-INF/web.xml
===
RCS file: /home/cvspublic/jakarta-servletapi-5/jsr152/examples/WEB-INF/web.xml,v
retrieving revision 1.1.1.1
diff -u -w -r1.1.1.1 web.xml
--- jsr152/examples/WEB-INF/web.xml 27 Aug 2002 13:16:52 - 1.1.1.1
+++ jsr152/examples/WEB-INF/web.xml 6 Sep 2002 18:41:11 -
@@ -198,7 +198,7 @@
web-resource-collection
web-resource-nameProtected Area/web-resource-name
!-- Define the context-relative URL(s) to be protected --
- url-pattern/jsp/security/protected/*/url-pattern
+ url-pattern/security/protected/*/url-pattern
!-- If you list http methods, only those methods are protected --
http-methodDELETE/http-method
http-methodGET/http-method
@@ -217,8 +217,8 @@
auth-methodFORM/auth-method
realm-nameExample Form-Based Authentication Area/realm-name
form-login-config
-form-login-page/jsp/security/protected/login.jsp/form-login-page
-form-error-page/jsp/security/protected/error.jsp/form-error-page
+form-login-page/security/protected/login.jsp/form-login-page
+form-error-page/security/protected/error.jsp/form-error-page
/form-login-config
/login-config
Index: jsr152/examples/WEB-INF/classes/servletToJsp.java
===
RCS file: /home/cvspublic/jakarta-servletapi-5/jsr152/examples/WEB-INF/classes/servletToJsp.java,v
retrieving revision 1.1.1.1
diff -u -w -r1.1.1.1 servletToJsp.java
--- jsr152/examples/WEB-INF/classes/servletToJsp.java 27 Aug 2002 13:16:53 - 1.1.1.1
+++ jsr152/examples/WEB-INF/classes/servletToJsp.java 6 Sep 2002 18:41:11 -
@@ -9,7 +9,7 @@
try {
// Set the attribute and Forward to hello.jsp
request.setAttribute (servletName, servletToJsp);
- getServletConfig().getServletContext().getRequestDispatcher(/jsp/jsptoserv/hello.jsp).forward(request, response);
+ getServletConfig().getServletContext().getRequestDispatcher(/jsptoserv/hello.jsp).forward(request, response);
} catch (Exception ex) {
ex.printStackTrace ();
}
Index: jsr152/examples/error/err.jsp
===
RCS file: /home/cvspublic/jakarta-servletapi-5/jsr152/examples/error/err.jsp,v
retrieving revision 1.1.1.1
diff -u -w -r1.1.1.1 err.jsp
--- jsr152/examples/error/err.jsp 27 Aug 2002 13:16:51 - 1.1.1.1
+++ jsr152/examples/error/err.jsp 6 Sep 2002 18:41:11 -
@@ -12,7 +12,7 @@
if (request.getParameter(name) == null) {
%
- %@ include file=/jsp/error/error.html %
+ %@ include file=/error/error.html %
%
} else {
foo.setName(request.getParameter(name));
Index: jsr152/examples/error/err.txt
===
RCS file: /home/cvspublic/jakarta-servletapi-5/jsr152/examples/error/err.txt,v
retrieving revision 1.1.1.1
diff -u -w -r1.1.1.1 err.txt
--- jsr152/examples/error/err.txt 27 Aug 2002 13:16:51 - 1.1.1.1
+++ jsr152/examples/error/err.txt 6 Sep 2002 18:41:11 -
@@ -12,7 +12,7 @@
if (request.getParameter(name) == null) {
%
- %@ include file=/jsp/error/error.html %
+ %@ include file=/error/error.html %
%
} else {
foo.setName(request.getParameter(name));
Index: jsr152/examples/forward/forward.jsp
===
RCS file: /home/cvspublic/jakarta-servletapi-5/jsr152/examples/forward/forward.jsp,v
retrieving revision 1.1.1.1
diff -u -w -r1.1.1.1 forward.jsp
--- jsr152/examples/forward/forward.jsp 27 Aug 2002 13:16:51 - 1.1.1.1
+++ jsr152/examples/forward/forward.jsp 6 Sep 2002 18:41:11 -
@@ -11,7 +11,7 @@
if (percent 0.5) {
%
-jsp:forward page=/jsp/forward/one.jsp/
+jsp:forward page=/forward/one.jsp/
% } else { %
Index: jsr152/examples/forward/forward.txt
===
RCS file: /home/cvspublic/jakarta-servletapi-5/jsr152/examples/forward/forward.txt,v
retrieving revision 1.1.1.1
diff -u -w -r1.1.1.1 forward.txt
--- jsr152/examples/forward/forward.txt 27 Aug 2002 13:16:51 - 1.1.1.1
+++ jsr152/examples/forward/forward.txt 6 Sep 2002 18:41:11 -
@@ -11,7 +11,7 @@
if (percent 0.5) {
%
-jsp:forward page=/jsp/forward/one.jsp/
+jsp:forward page=/forward/one.jsp/
% } else { %
Index: jsr152/examples/include/include.jsp
===
RCS file: /home/cvspublic/jakarta-servletapi-5/jsr152/examples/include/include.jsp,v
retrieving revision 1.1.1.1
diff -u -w -r1.1.1.1 include.jsp
--- jsr152/examples/include/include.jsp 27 Aug 2002 13:16:51 - 1.1.1.1
+++ jsr152/examples/include/include.jsp 6 Sep
[5][PATCH]o.a.j.runtime.* import in gen'd JSP
Generated JSP classes import org.apache.jasper.runtime.*. According to the JSP
spec the default imports should be java.lang.*, javax.servlet.*,
javax.servlet.jsp.* and javax.servlet.http.*.
The classes from o.a.j.runtime should be fully qualified, rather than
imported. As far as I can tell, this is restricted to HttpJspBase and
JspRuntimeLibrary.
Index: Constants.java
===
RCS file: /home/cvspublic/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/Constants.java,v
retrieving revision 1.7
diff -u -w -r1.7 Constants.java
--- Constants.java 21 Aug 2002 16:21:56 - 1.7
+++ Constants.java 6 Sep 2002 04:46:08 -
@@ -74,7 +74,7 @@
/**
* The base class of the generated servlets.
*/
-public static final String JSP_SERVLET_BASE = HttpJspBase;
+public static final String JSP_SERVLET_BASE = org.apache.jasper.runtime.HttpJspBase;
/**
* _jspService is the name of the method that is called by
@@ -96,7 +96,6 @@
javax.servlet.*,
javax.servlet.http.*,
javax.servlet.jsp.*,
- org.apache.jasper.runtime.*,
};
/**
Index: compiler/Generator.java
===
RCS file: /home/cvspublic/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Generator.java,v
retrieving revision 1.91
diff -u -w -r1.91 Generator.java
--- compiler/Generator.java 6 Sep 2002 00:15:32 - 1.91
+++ compiler/Generator.java 6 Sep 2002 04:46:10 -
@@ -866,7 +866,7 @@
prepareParams(n);
}
-out.printin(JspRuntimeLibrary.include(request, response, +
+out.printin(org.apache.jasper.runtime.JspRuntimeLibrary.include(request, response, +
pageParam );
printParams(n, pageParam, page.isLiteral());
out.println(, out, + isFlush + ););
@@ -986,15 +986,15 @@
java.lang.reflect.Method meth =
JspRuntimeLibrary.getReadMethod(bean, property);
String methodName = meth.getName();
- out.printil(out.write(JspRuntimeLibrary.toString( +
+ out.printil(out.write(org.apache.jasper.runtime.JspRuntimeLibrary.toString( +
((( + beanName + )pageContext.findAttribute( +
\ + name + \)). + methodName + (;);
} else {
// The object could be a custom action with an associated
// VariableInfo entry for this name.
// Get the class name and then introspect at runtime.
- out.printil(out.write(JspRuntimeLibrary.toString +
- (JspRuntimeLibrary.handleGetProperty +
+ out.printil(out.write(org.apache.jasper.runtime.JspRuntimeLibrary.toString +
+ (org.apache.jasper.runtime.JspRuntimeLibrary.handleGetProperty +
(pageContext.findAttribute(\ +
name + \), \ + property + \))););
}
@@ -1011,18 +1011,18 @@
n.setBeginJavaLine(out.getJavaLine());
if (*.equals(property)){
- out.printil(JspRuntimeLibrary.introspect( +
+ out.printil(org.apache.jasper.runtime.JspRuntimeLibrary.introspect( +
pageContext.findAttribute( +
\ + name + \), request););
} else if (value == null) {
if (param == null)
param = property; // default to same as property
- out.printil(JspRuntimeLibrary.introspecthelper( +
+ out.printil(org.apache.jasper.runtime.JspRuntimeLibrary.introspecthelper( +
pageContext.findAttribute(\ + name + \), \ +
property + \, request.getParameter(\ + param +
\), + request, \ + param + \, false););
} else if (value.isExpression()) {
- out.printil(JspRuntimeLibrary.handleSetProperty( +
+ out.printil(org.apache.jasper.runtime.JspRuntimeLibrary.handleSetProperty( +
pageContext.findAttribute(\ + name + \), \
+ property + \,);
out.print(attributeValue(value, false, null, null));
@@ -1035,7 +1035,7 @@
// optimize the case where the bean is exposed with
// jsp:useBean, much as the code here does for
// getProperty.)
-out.printil(JspRuntimeLibrary.handleSetPropertyExpression( +
+out.printil(org.apache.jasper.runtime.JspRuntimeLibrary.handleSetPropertyExpression( +
pageContext.findAttribute(\ + name + \), \
+ property + \,
+ quote(value.getValue()) + ,
@@ -1050,13 +1050,13 @@
// that body.
String valueVarName = generateNamedAttributeValue(
value.getNamedAttributeNode() );
-out.printil(JspRuntimeLibrary.introspecthelper( +
+out.printil(org.apache.jasper.runtime.JspRuntimeLibrary.introspecthelper( +
pageContext.findAttribute(\ + name + \), \
+ property + \,
+ valueVarName
+ , null, null, false););
} else {
- out.printin(JspRuntimeLibrary.introspecthelper( +
+
Re: [4.1.10] New test milestone released
There's a tester application in Catalina. Watchdog is the basis for the official test kit for the servlet and JSP specs. It's portable and generic. Tester, on the other hand, is Tomcat specific. So putting Tomcat regression tests in it is very appropriate. On Monday 02 September 2002 09:30 am, Ignacio J. Ortega wrote: De: Remy Maucherat [mailto:[EMAIL PROTECTED]] Enviado el: 2 de septiembre de 2002 11:35 Thanks for the test case. (maybe we could add all your nasty tests in the tester) tester? you are talking about watchdog ? Saludos , Ignacio J. Ortega -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Spec question: RE BUG 12052
I think you're missing the virtual server angle. There is NOT a 1-1 mapping from ip address to DNS name. It's N-M. Even from the standpoint of a single machine which received the request, there are many possible names for the IP address. So, given a request like: GET /pub/WWW/TheProject.html HTTP/1.1 Host: www.w3.org The only way to know which host the client intended is the Host header. So, yes, this is spoofable, and should not be used as a security mechanism. It was never designed to be one. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Friday, August 30, 2002 2:50 PM To: Tomcat Developers List Subject: RE: Spec question: RE BUG 12052 On Fri, 30 Aug 2002, Ignacio J. Ortega wrote: It may very well be a security issue ( and quite a big one ! ). There are sites using all kinds of firewalls and settings in httpd.conf to restrict access to some hosts or ports ( say from internal network ). If Host: info is used for security checkings - it would be trivial to bypass some of this security. In particular - people may have servlets that check getServerName() to find if 'localhost' was used - the spec change will leave them with a huge hole ( any request with forged Host: localhost will pass ). Good Comment.. In the particular case you have pointed, it's a user problem, a request with Host: Localhost can be only be issued by someone with Remote Ip=localhost.. 'localhost' is just an example. The server may have 2 ip addresses, one visible from outside and one restricted by firewalls to only internal users ( and used for example for content updates ). In servlet 2.2 and 2.3, it is perfectly valid to use getServerName() and get the address that received the request. Since the servlet spec doesn't provide any 'declarative' support for this kind of access control - I think this is a valid solution. A firewall or routing can protect the internal address ( say 10.0.0.1 - on a network card connected only to the internal net, and a firewall restricting outside access to this IP ). In 2.4 this will fail ( opening potential holes ) and in addition this kind of check will be impossible to implement - since the address where the request was received will no longer be available. So one can take some security measures to check the correctness of the request.. For example ? All other use case i can imagine fall within the users problems, if the correct VS has received the request, it's the Remote IP appropiate for that VS? matchs port where the request has been received the port where is suppoussed that the VS is? If by 'user' you mean the servlet author - I disagree. Such checks are prefectly reasonable and correct IMO. But By far in the Journey we have learned something, never trust a Host Header without first trust the Remote IP, at least for ultra-secure apps.. Well, the remoteIP is much more difficult to test - if you're a big organization you may have dozens of internal IPs. And most people do trust their firewalls to restrict access to a particular IP, I've seen this kind of setup in several cases ( where you use a special interface for internal users ). And another thing, i wonder if it would be appropiate to check if a request came from the (at least) correct port before dispatching it to the VS.. at least within TC, and check if Apache2 is taking any measures to be certain of this fact.. The comment in apache sugest that Host shouldn't be trusted. If they started to trust it sudenly - they should at least modify the comment and explain how is this trust justified. Host is sent by the user - it is trivial to forge. The port and host that actually receives the request are pretty safe and difficult to trick, especially if a firewall is used in front. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[5][PATCH] Build and run the catalina tester webapp against tomcat5
This patch builds the catalina tester app in the context of tomcat-5, and installs and runs in the tmp directory, the same way that watchdog is run. I had to change a couple of the build variables in tester, to match some of the new ones. Also the examples web app is not expanded by default, so the 'touch' tasks had to be removed. Since the tomcat.base is rebuilt every run, the touches are redundant. Unfortunately, many of the tester tests are failing. I don't know, yet, if they are bugs in tester or bugs in tomcat. But at least there's a baseline for comparison. -- Steve Downey -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: HTTP Host Request header and TC Connectors
My understanding is that this is really a client issue, rather than server. By the time a connector gets it, it's too late to do much about it. A little bit of research indicates that the user agents I have about will put the IP address in the Host header if the URI is specified by IP. That seems the only reasonable thing to do. The name of the host in that case is the IP address. I suppose that if you were doing something bizzare like HTTP over a unix domain socket you wouldn't have a host name of any kind. But that's pretty far out there. But, on the TC side, I don't think the connector should rewrite the header if it's empty. On Wednesday 28 August 2002 12:26 pm, Ryan Lubke wrote: Hi, Looking for a little input from the HTTP gurus here. Given the following: If the requested URI does not include an Internet host name for the service being requested, then the Host header field MUST be given with an empty value. So, I'm looking for other interpretations of what the above means. My interpretation at this point is the serviced targeted by the request URI is identified via an IP address vs a host name, that the Host request header will be sent but with an empty value. Does anyone agree/disagree? The reason I ask is that if an empty Host header is sent to Tomcat, and a redirect is sent back, the value of the Location header is useless, i.e. http:///index.jsp. I'm trying to determine if this is a problem with the client implementation's interpretation of the spec, or a problem with Tomcat. Thanks, -rl -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Jasper 2 class files
Is jspcache the place that Tomcat is looking for generated classes? If so, then the custom JSP classloader is doing its magic. The java and class files produced by the JspC command line compiler should be able to be jared up and placed into the WEB-INF directory, like any other servlet. And the web.xml then maps the jsp URIs to servlets. Jasper 1 could do this, I provided some of the patches to make it work. The real test is to take all of the output from JspC and create a WAR file from it. Without the base jsp files. This WAR should operate in ANY servlet container. On Wednesday 21 August 2002 02:22 pm, John Trollinger wrote: Greg, I took this off of the bug tracking because it is not a bug and I thought there are people a lot smarter than me in this mailing list that could help answer you questions. I do not know how jasper differentiates between hello.jsp and /anydir/hello.jsp when the both compile to a class org.jasper.jsp.hello_jsp but it does work... My hello.jsp in the root dir prints hello Jasper world and my hello.jsp in the subdir prints hello john world. It works without a hitch.. (notice that I have removed the .java files for the 2 hello world files and it did not regenerate them) Here is my file list Directory of C:\appserver\Tomcat\jspcache 08/21/2002 02:19 PMDIR . 08/21/2002 02:19 PMDIR .. 08/21/2002 11:47 AM 3,496 date_jsp.java 08/21/2002 11:52 AM 2,975 hello_jsp.class 08/21/2002 11:51 AM 2,883 index_jsp.class 08/21/2002 11:51 AM 1,863 index_jsp.java 08/21/2002 01:27 PMDIR subdir 4 File(s) 11,217 bytes Directory of C:\appserver\Tomcat\jspcache\subdir 08/21/2002 01:27 PMDIR . 08/21/2002 01:27 PMDIR .. 08/21/2002 11:47 AM 3,334 date2_jsp.java 08/21/2002 11:52 AM 2,970 hello_jsp.class Here is my jsp.xml !-- Automatically created by Tomcat JspC. Place this fragement in the web.xml before all icon, display-name, description, distributable, and context-param elements. -- servlet servlet-nameorg.apache.jsp.date_jsp/servlet-name servlet-classorg.apache.jsp.date_jsp/servlet-class /servlet servlet servlet-nameorg.apache.jsp.hello_jsp/servlet-name servlet-classorg.apache.jsp.hello_jsp/servlet-class /servlet servlet servlet-nameorg.apache.jsp.date2_jsp/servlet-name servlet-classorg.apache.jsp.date2_jsp/servlet-class /servlet servlet servlet-nameorg.apache.jsp.hello_jsp/servlet-name servlet-classorg.apache.jsp.hello_jsp/servlet-class /servlet servlet-mapping servlet-nameorg.apache.jsp.date_jsp/servlet-name url-pattern/date.jsp/url-pattern /servlet-mapping servlet-mapping servlet-nameorg.apache.jsp.hello_jsp/servlet-name url-pattern/hello.jsp/url-pattern /servlet-mapping servlet-mapping servlet-nameorg.apache.jsp.date2_jsp/servlet-name url-pattern/subdir/date2.jsp/url-pattern /servlet-mapping servlet-mapping servlet-nameorg.apache.jsp.hello_jsp/servlet-name url-pattern/subdir/hello.jsp/url-pattern /servlet-mapping !-- All session-config, mime-mapping, welcome-file-list, error-page, taglib, resource-ref, security-constraint, login-config, security-role, env-entry, and ejb-ref elements should follow this fragment. -- -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Jasper 2 class files
Bingo! It can't!
{BTW, it shouldn't be org.jasper.x, as that's Paul Jasper's site,
whoever he is}
What should be happening with JspC [and in the JspServlet IMO] is:
/hello.jsp = org.apache.jsp.hello_jsp in {output}/hello_jsp.java
/subdir/hello.jsp = org.apache.jsp.subdir.hello_jsp in
{output}/subdir/hello_jsp.java
with the resultant web.xml fragment:
servlet
servlet-nameorg.apache.jsp.hello_jsp/servlet-name
servlet-classorg.apache.jsp.hello_jsp/servlet-class
/servlet
servlet
servlet-nameorg.apache.jsp.subdir.hello_jsp/servlet-name
servlet-classorg.apache.jsp.subdir.hello_jsp/servlet-class
/servlet
servlet-mapping
servlet-nameorg.apache.jsp.hello_jsp/servlet-name
url-pattern/hello.jsp/url-pattern
/servlet-mapping
servlet-mapping
servlet-nameorg.apache.jsp.subdir.hello_jsp/servlet-name
url-pattern/subdir/hello.jsp/url-pattern
/servlet-mapping
Then they can be compiled by an ordinary javac ant task, and warred and
deployed in any servlet container.
Now, why might you want to do this?
The resultant WAR file can be put into a container that doesn't have JSP or
tools.jar support. It's great for embedded applications. Much lower
overhead, and more predictable response. It's also great for QA. You test
exactly the bits that get shipped.
-Original Message-
From: John Trollinger [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, August 21, 2002 3:16 PM
To: 'Tomcat Developers List'
Subject: RE: Jasper 2 class files
If you take the generated class files and war them up and just call them
as servlets how does the classloader differentiate
/org.jasper.jsp.hello_jsp from /subdir/org.jasper.jsp.hello_jsp. I can
see how it does it when a JSP file exists but if you just move the
generated files over I don't see how the classloader could figure this
out?
If this is in your web.xml how does it know one hello_jsp from the other
without the jsp pages there and without going through jasper?
servlet
servlet-nameorg.apache.jsp.hello_jsp/servlet-name
servlet-classorg.apache.jsp.hello_jsp/servlet-class
/servlet
servlet-mapping
servlet-nameorg.apache.jsp.hello_jsp/servlet-name
url-pattern/subdir/hello.jsp/url-pattern
/servlet-mapping
-Original Message-
From: Steve Downey [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, August 21, 2002 2:56 PM
To: Tomcat Developers List
Subject: Re: Jasper 2 class files
Is jspcache the place that Tomcat is looking for generated classes? If
so,
then the custom JSP classloader is doing its magic.
The java and class files produced by the JspC command line compiler
should be
able to be jared up and placed into the WEB-INF directory, like any
other
servlet. And the web.xml then maps the jsp URIs to servlets.
Jasper 1 could do this, I provided some of the patches to make it work.
The real test is to take all of the output from JspC and create a WAR
file
from it. Without the base jsp files. This WAR should operate in ANY
servlet
container.
On Wednesday 21 August 2002 02:22 pm, John Trollinger wrote:
Greg,
I took this off of the bug tracking because it is not a bug and I
thought there are people a lot smarter than me in this mailing list
that
could help answer you questions.
I do not know how jasper differentiates between hello.jsp and
/anydir/hello.jsp when the both compile to a class
org.jasper.jsp.hello_jsp but it does work...
My hello.jsp in the root dir prints hello Jasper world and my
hello.jsp
in the subdir prints hello john world. It works without a hitch..
(notice that I have removed the .java files for the 2 hello world
files
and it did not regenerate them)
Here is my file list
Directory of C:\appserver\Tomcat\jspcache
08/21/2002 02:19 PMDIR .
08/21/2002 02:19 PMDIR ..
08/21/2002 11:47 AM 3,496 date_jsp.java
08/21/2002 11:52 AM 2,975 hello_jsp.class
08/21/2002 11:51 AM 2,883 index_jsp.class
08/21/2002 11:51 AM 1,863 index_jsp.java
08/21/2002 01:27 PMDIR subdir
4 File(s) 11,217 bytes
Directory of C:\appserver\Tomcat\jspcache\subdir
08/21/2002 01:27 PMDIR .
08/21/2002 01:27 PMDIR ..
08/21/2002 11:47 AM 3,334 date2_jsp.java
08/21/2002 11:52 AM 2,970 hello_jsp.class
Here is my jsp.xml
!--
Automatically created by Tomcat JspC.
Place this fragement in the web.xml before all icon, display-name,
description, distributable, and context-param elements.
--
servlet
servlet-nameorg.apache.jsp.date_jsp/servlet-name
servlet-classorg.apache.jsp.date_jsp/servlet-class
/servlet
servlet
servlet-nameorg.apache.jsp.hello_jsp/servlet-name
servlet-classorg.apache.jsp.hello_jsp
RE: Jasper 2 class files
However, in the context of JspC, it's a problem to map them to the same package and class name. The custom URLClassLoader works within the JSP engine, but the general servlet class loader doesn't know about those rules. So when it sees those entries in web.xml, it will map all hello.jsp files, no matter where they reside, to org.apache.jsp.hello_jsp. -Original Message- From: Glenn Nielsen [mailto:[EMAIL PROTECTED]] Sent: Wednesday, August 21, 2002 7:54 PM To: Tomcat Developers List Subject: Re: Jasper 2 class files Yes, you can have two JSP pages with the same name but in different directories and everything will work fine even though they have the same package and class name. This is because a custom URLClassLoader is created for each individual JSP page. That class loader only loads the one java class for that one JSP page. For example: /myapp/this/hello.jsp /muapp/that/hello.jsp The class files will end up in: $CATALINA_BASE/work/Standalone/localhost/myapp/this/hello.class $CATALINA_BASE/work/Standalone/localhost/myapp/that/hello.class Since two different URLClassLoaders are used Jasper can load each of the above two classes even though they have the same package and class name. The old methods Jasper used for loading java classes generated for JSP pages was very inefficient. The above change simplified Jasper and improved its performance by 25%. Regards, Glenn John Trollinger wrote: Greg, I took this off of the bug tracking because it is not a bug and I thought there are people a lot smarter than me in this mailing list that could help answer you questions. I do not know how jasper differentiates between hello.jsp and /anydir/hello.jsp when the both compile to a class org.jasper.jsp.hello_jsp but it does work... My hello.jsp in the root dir prints hello Jasper world and my hello.jsp in the subdir prints hello john world. It works without a hitch.. (notice that I have removed the .java files for the 2 hello world files and it did not regenerate them) Here is my file list Directory of C:\appserver\Tomcat\jspcache 08/21/2002 02:19 PMDIR . 08/21/2002 02:19 PMDIR .. 08/21/2002 11:47 AM 3,496 date_jsp.java 08/21/2002 11:52 AM 2,975 hello_jsp.class 08/21/2002 11:51 AM 2,883 index_jsp.class 08/21/2002 11:51 AM 1,863 index_jsp.java 08/21/2002 01:27 PMDIR subdir 4 File(s) 11,217 bytes Directory of C:\appserver\Tomcat\jspcache\subdir 08/21/2002 01:27 PMDIR . 08/21/2002 01:27 PMDIR .. 08/21/2002 11:47 AM 3,334 date2_jsp.java 08/21/2002 11:52 AM 2,970 hello_jsp.class Here is my jsp.xml !-- Automatically created by Tomcat JspC. Place this fragement in the web.xml before all icon, display-name, description, distributable, and context-param elements. -- servlet servlet-nameorg.apache.jsp.date_jsp/servlet-name servlet-classorg.apache.jsp.date_jsp/servlet-class /servlet servlet servlet-nameorg.apache.jsp.hello_jsp/servlet-name servlet-classorg.apache.jsp.hello_jsp/servlet-class /servlet servlet servlet-nameorg.apache.jsp.date2_jsp/servlet-name servlet-classorg.apache.jsp.date2_jsp/servlet-class /servlet servlet servlet-nameorg.apache.jsp.hello_jsp/servlet-name servlet-classorg.apache.jsp.hello_jsp/servlet-class /servlet servlet-mapping servlet-nameorg.apache.jsp.date_jsp/servlet-name url-pattern/date.jsp/url-pattern /servlet-mapping servlet-mapping servlet-nameorg.apache.jsp.hello_jsp/servlet-name url-pattern/hello.jsp/url-pattern /servlet-mapping servlet-mapping servlet-nameorg.apache.jsp.date2_jsp/servlet-name url-pattern/subdir/date2.jsp/url-pattern /servlet-mapping servlet-mapping servlet-nameorg.apache.jsp.hello_jsp/servlet-name url-pattern/subdir/hello.jsp/url-pattern /servlet-mapping !-- All session-config, mime-mapping, welcome-file-list, error-page, taglib, resource-ref, security-constraint, login-config, security-role, env-entry, and ejb-ref elements should follow this fragment. -- -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: jasper package
For the command line compiler, I've found it very useful. It specifies the
base package for the compiled jsp pages. By matching that with the directory
that the pages are output into, I can then point an ant javac task at them
and validate that everything compiles correctly, as part of an automated
build.
That is, /index.jsp would go into
${output}/com/netfolio/compiled_jsp/index.java, and /dir/index.jsp would go
into ${output}/com/netfolio/compiled_jsp/dir/index.java. So compiling them
is just a matter of a plain compile of the ${output} directory.
When JspC is working, that is. Haven't checked recently, but it's been
broken as often as not.
The runtime jsp compiler produces, or used to produce, java files that
aren't suitable for compiling as a batch. The package didn't match up with
the directory name. It simplified class reloading, IIRC, though.
-Original Message-
From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]]
Sent: Monday, August 19, 2002 6:11 PM
To: Tomcat Developers List
Subject: Re: jasper package
On Mon, 19 Aug 2002, [gb2312] Yunfeng Hou wrote:
Date: Mon, 19 Aug 2002 11:35:17 +0800 (CST)
From: [gb2312] Yunfeng Hou [EMAIL PROTECTED]
Reply-To: Tomcat Developers List [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: jasper package
Jasper has command line option to set package name,
but not true for JspServlet, I made some change to
give user a chance to set the packageName in the
servlet init parameter.
Personally, I think supporting this at all is a *really* bad idea ... the
JSP spec is very clear that the container is free to put the generated
classes in whatever package it wants to (even different ones for different
pages), so it seems very counter-productive to allow a user to tie
themselves to a particular version of the JSP page compiler on a
particular container that happens to implement this kind of option.
A desire to do this in the first place probably comes from wanting to use
unpackaged classes without importing them -- which is both against the JSP
spec and is also frowned on in general by the Java compiler in JDK 1.4 and
later. You're MUCH better off putting your classes into packages and
explicitly importing them.
Craig McClanahan
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: jasper package
The compiler driver and classloader used by tomcat does a lot of magic to get it to work. All jsp files named, for example, index.jsp, will be compiled to a class named org.apache.jsp.index$jsp.java. It will be in a directory with the same name as the directory of the jsp file, but that's not represented in the package name. The classloader knows where the class file will reside, and then strips out everything but the filename part of the URI, prepends org.apache.jsp to it, and loads that class. The base VM classloader CAN NOT load the generated class files. So debugging with an IDE that doesn't have special hacks is a bit difficult. Even if you can convince it to load servlets and debug that code, convincing it to set a breakpoint in some class named org.apache.jsp.index$jsp, and leaving it to figure out which one, is usually impossible. Unless things have changed recently, then go ahead and ignore all this. I know this applied for 4.0.3. -Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] Sent: Tuesday, August 20, 2002 1:28 AM To: Tomcat Developers List Subject: Re: jasper package On Tue, 20 Aug 2002, [gb2312] Yunfeng Hou wrote: Date: Tue, 20 Aug 2002 13:13:14 +0800 (CST) From: [gb2312] Yunfeng Hou [EMAIL PROTECTED] Reply-To: Tomcat Developers List [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Subject: Re: jasper package A desire to do this in the first place probably comes from wanting to use unpackaged classes without importing them -- which is both against the JSP spec and is also frowned on in general by the Java compiler in JDK 1.4 and later. You're MUCH better off putting your classes No, I want this because I need it to debug my generated class file at runtime. Currently, jasper will always generate class in org.apache.jsp. For example, /abc/test.jsp will have class in $scratchDir/abc, and /abc/def/test.jsp will be generated in $scratchDir/abc/def, with the same package - org.apache.jsp! I can not even compile these classes, do you think it a good design? Or, what I need is compile and debug, I do not need that flexibility to specify package name, at least, I think jasper should support this: these jsps will have package name org.apache.jsp.abc and org.apache.jsp.abc.def respectively. The Java compiler used by Tomcat doesn't have any problems compiling the sources that are currently being generated. What compiler are you trying to use that has problems with it? That's where your problem really appears to lie. Yunfeng Hou Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] attachment: winmail.dat -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Watchdog aggregation of headers may be incorrect
On Sunday 18 August 2002 08:39 am, Remy Maucherat wrote:
Steve Downey wrote:
On Saturday 17 August 2002 01:40 pm, Remy Maucherat wrote:
Steve Downey wrote:
SNIP/
The real problem, for the servlet spec implementation, is that not just
getHeaders() is affected. getHeader() must be also. getHeader, if there
are multiple values, needs to return the same thing as the first value
returned by getHeaders(), not the whole header from the first of
multiple headers.
Sorry, but no. The opposite statement doesn't work.
getHeader MUST return the first header line, unless in the case there
are multiple headers with the same name in the client message, in which
case you would know that they can be parsed/combined at will.
Since it is too complex and inefficient to implement that, I'd leave it
at that, and let the application handle the cases where the client is
having some fun.
Remy
Given:
H:A,B
H:C
getHeader() should either return ``A'' or ``A,B,C''. Returning ``A,B'',
as it does now, can't be right. It introduces semantic differences
between multiple headers and comma-separated lists where their must be
none.
Yes, it is right.
Consider:
H: A, B
In that case, getHeader() has to return A, B since it is not known if
this header is comma separated, as per the spec definition.
Ah. That's where we're going in separate directions. I'm assuming that it is
known. The HTTP spec defines which headers are comma separated. So it's just
a matter of checking against that list in order to know how to treat multiple
values. According to the current servlet spec we have to, since we need to
parse out the values for headers that are comma separated lists.
getHeaders(Date) should not break apart the date into two values.
In the case:
H: A, B
H: C
Well, you have multiple choices, all of which are valid.
- you may want to return the same thing as above, which means you return
A, B
- you can also return A
Returning A, B, C is incorrect, as you have to return the first value
of the header.
Since implementing the first option is easier, I'd leave the current
behavior.
getHeaders indicate that the header is comma separated, so it should be
parsed. This is not currently done, but indeed it should be done.
Hacking MimeHeaders can result in a correct *and* efficient implementation.
getHeaders() by itself doesn't tell you that the header is comma separated.
getHeaders(Date) should give you Wed, 15 Nov 1995 06:25:24 GMT, not
{Wed, 15 Nov 1995 06:25:24 GMT}.
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Watchdog aggregation of headers may be incorrect
On Sunday 18 August 2002 11:02 am, [EMAIL PROTECTED] wrote: My understanding - the HTTP spec doesn't ( and can't ) define a complete list of headers supporting multiple values. That's impossible given that additional headers are supported. The spec does exactly that. It enumerates the processing for the headers it defines. In section 5.3, Unrecognized header fields are treated as entity-header fields. [section 5.3] In section 7.1, Entity Header Fields The extension-header mechanism allows additional entity-header fields to be defined without changing the protocol, but these fields cannot be assumed to be recognizable by the recipient. Unrecognized header fields SHOULD be ignored by the recipient and MUST be forwarded by transparent proxies. extension-header field-value is not defined as being a comma separated list, so it shouldn't be treated as such. The on point case would be a webdav server running inside a servlet container. The webdav protocol actually does define a header that contains a list of values, the DAV header. So should the webdav servlet expect the extension-header to be parsed for it? It might be nice, but I can't see that it's required. If the servlet spec requires getHeader() to return the 'concatenated value for multi-headers' - then the spec can't be implemented. If it requires getHeaders() to split headers that are multi-value and were sent concatenated - it can't be implemented ( and it's an API bug ) It can be done only for the list of headers defined in the spec. Can't be implemented is a little strong. After all, Tomcat used to pass this test. The old connector used to parse out the Accept-Languages header, so as to get the correct locale. I'd bet anything that the fact that this was visible via getHeaders() is why the test is written the way it is. Tomcat was actually used as a reference. But, API bug is what I was arguing for originally. With getHeader and getHeaders as speced, an application has no way of getting at the headers as sent. The key is the 'list of headers defined in the spec'. The HTTP spec is affirmative on which headers cant contain values separated by commas. see list at end Returning whatever was found in the original request is IMO the only reasonable solution. I doesn't think apache ( or other servers ) are spliting/merging received headers either. I'm looking at httpd. It looks like it does merge received headers. That is, Accept-Language:A, Accept-Language:B gets combined into Accept-Language:A,B. Then ap_table_get() returns a single string, with all of the values. There is no API equivalent to getHeaders(). The user application should use getHeaders() and split each header ( or merge them ) if it knows a header is multi-value. Well, there is a trick that can be used in deciding to split/merge: if the user calls getHeader(Foo), and we have multiple Foo headers, then we can concatenate them and return the result. That seems to be, effectively, what httpd does. If the user calls getHeaders(Foo) and we have headers with ',', then we split them. ( if he would call getHeaders(Date) - it would be his error ). However that's a bad solutuion - many apps call getHeaders() for all headers ( like request dump, etc ). Costin Headers which can have a list of values, according to RFC 2616: Accept Accept-Charset Accept-Encoding Accept-Language Accept-Ranges Allow Cache-Control Connection Content-Encoding Content-Language Expect If-Match If-None-Match Pragma Proxy-Authenticate TE Trailer Transfer-Encoding Upgrade Vary Via Warning WWW-Authenticate Accept-Ranges, Vary and WWW-Authenticate are response headers, and should not be part of a request. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Watchdog aggregation of headers may be incorrect
On Saturday 17 August 2002 09:00 am, Remy Maucherat wrote: Patrick Luby wrote: Steve, Your assessment is correct: an aggregate header like: header1: val1, val2 should be converted to this for the HttpRequest: header1: val1 header1: val2 No, this is not correct. You are allowed to do that only if the application knows it makes sense to do so (ie, only when it call getHeaders). If it is to be done, it should be done based on what the HTTP/1.1 spec defines. The application needs to expect the possibility of multiple values for all of the headers that allow them. Or just ask for the first one. Parsing the header line into values probably shouldn't be left to the application, although it is at the moment. Some code to do that should be added in the adapter. Do you mean in the implementation of HttpServletRequest? I was thinking of doing the work in MimeHeaders. Perhaps subclassing MimeHeaders into Http11Headers, in order to allow other RFCHeaders? Certainly Http11Protocol knows what kind of headers it's parsing. Tomcat 4 used to do this conversion correctly but then it stopped doing the conversion a few months ago. This should be fixed as it is Servlet spec non-compliance. However, I am not sure where the parsing of headers is now performed in Tomcat? Can anyone point Steve to where this header parsing of the ServerSocket input stream is being done? No, this musn't be done there, as it would screw up many headers. Please read the chapter on multivalued headers in the HTTP/1.1 spec. Right, at the lowest level, headers are being handled generically. Something needs to be aware of the semantics of HTTP/1.1 headers. Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Watchdog aggregation of headers may be incorrect
On Saturday 17 August 2002 12:13 pm, Patrick Luby wrote:
Remy,
Remy Maucherat wrote:
No, this is not correct.
You are allowed to do that only if the application knows it makes sense
to do so (ie, only when it call getHeaders).
Some code to do that should be added in the adapter.
This makes more sense than my original thoughts since the Watchdog
failures are only happening in tests that invoke the getHeaders() method.
I suspect that the tests are not strong enough. There are other cases that
aren't handled correctly, but aren't being tested for. Let's take the 'worst'
case:
AcceptLanguage: en-us, ga-us;q=0.7
AcceptLanguage: x-redneck:q=0.01
getHeader(AcceptLanguage) ought to return en-us, and three values ought to
be returned through the enumerator getHeaders(AcceptLanguage), {en-us,
ga-us;q=0.7, x-redneck:q=0.01}.
This is sort of an oddball corner case, as any real client would likely send
either one header or three. But it is an allowable case.
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Watchdog aggregation of headers may be incorrect
On Saturday 17 August 2002 12:47 pm, Remy Maucherat wrote: Steve Downey wrote: On Saturday 17 August 2002 09:00 am, Remy Maucherat wrote: Patrick Luby wrote: Steve, Your assessment is correct: an aggregate header like: header1: val1, val2 should be converted to this for the HttpRequest: header1: val1 header1: val2 No, this is not correct. You are allowed to do that only if the application knows it makes sense to do so (ie, only when it call getHeaders). If it is to be done, it should be done based on what the HTTP/1.1 spec defines. The application needs to expect the possibility of multiple values for all of the headers that allow them. Or just ask for the first one. Parsing the header line into values probably shouldn't be left to the application, although it is at the moment. I gave you the HTTP/1.1 answer. For Header H: A,B If A,B is semantically equivalent to: H: A H: B then you can parse for the comma. So since you can't know what the application considers to be semantically equivalent, the fact that it calls getHeaders is a big hint, and you can do the comma parsing. Please read the HTTP specification. I keep a copy handy, for just such an occasion. However, my reading is someone different from yours. I think this is the relevant section [RFC 2616, section 4.2], that describes what happens when multiple headers are sent: Multiple message-header fields with the same field-name MAY be present in a message if and only if the entire field-value for that header field is defined as a comma-separated list [i.e., #(values)]. It MUST be possible to combine the multiple header fields into one field-name: field-value pair, without changing the semantics of the message, by appending each subsequent field-value to the first, each separated by a comma. The order in which header fields with the same field-name are received is therefore significant to the interpretation of the combined field value, and thus a proxy MUST NOT change the order of these field values when a message is forwarded. So it's saying the opposite: H:A H:B MUST be semantically equivalent to H:A,B as long as H is defined to have be a comma separated list. If it doesn't, it seems the result is undefined. Now, the spec refers to not changing the semantics, but the MUST means that it is a requirement for the implementation. In other words, if combining the two headers into one comma separated list, for headers with a #(values) content model, changes the semantics, the implementation is non-conformant. The specification does not require that the implementation guess at the semantics an application believes apply, the specification defines the semantics that will apply. The real problem, for the servlet spec implementation, is that not just getHeaders() is affected. getHeader() must be also. getHeader, if there are multiple values, needs to return the same thing as the first value returned by getHeaders(), not the whole header from the first of multiple headers. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Watchdog aggregation of headers may be incorrect
On Saturday 17 August 2002 01:40 pm, Remy Maucherat wrote: Steve Downey wrote: SNIP/ The real problem, for the servlet spec implementation, is that not just getHeaders() is affected. getHeader() must be also. getHeader, if there are multiple values, needs to return the same thing as the first value returned by getHeaders(), not the whole header from the first of multiple headers. Sorry, but no. The opposite statement doesn't work. getHeader MUST return the first header line, unless in the case there are multiple headers with the same name in the client message, in which case you would know that they can be parsed/combined at will. Since it is too complex and inefficient to implement that, I'd leave it at that, and let the application handle the cases where the client is having some fun. Remy Given: H:A,B H:C getHeader() should either return ``A'' or ``A,B,C''. Returning ``A,B'', as it does now, can't be right. It introduces semantic differences between multiple headers and comma-separated lists where their must be none. The problem is that the client has no way of telling if it's supposed to use getHeader or getHeaders. Other than saying that if it's possible for there to be multiple values, you have to use getHeaders. IAC, why must getHeader return the first header line? It's documented to return 'the first head sic in the request', or 'a String containing the value of the requested header'. If getHeaders() returns 'all the values of the specified request header', and returns ``A'' rather than ``A,B'', then it's inconsistent for getHeader to return ``A, B''. If a servlet really wants to do the parsing itself, then getHeader only gets it part of the headers, and it has no way of getting all of the header lines, since getHeaders() doesn't do that, according to the interpretation of the spec embodied in Watchdog, the basis for the TCK. Complex and inefficient might be a reason for _changing_ the spec. It's a bad reason for not implementing the spec. Also, I don't think it's that bad. The cases where multiple values are allowed is denumerable. So it comes down to creating an enumerator that can run seamlessly over the values in distinct header lines. Now, I'll admit this is all a bit on the language-lawyerish angels-dancing-on-pins side. But this is the reference implementation, and it is currently failing the servlet test suite. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [5] Config
SNIP/ What do you think ? I love it :) This really seems to pick the best APIs for the job. It's a good idea to use JNDI for configuration storing indeed, as it allows enterprise scale deployments, and seems generally better suited than JMX. Remy To the extent that JNDI and JMX do the jobs they were designed for, it makes perfect sense. JNDI is all about locating and retrieving data by name. JMX is mostly a runtime mechanism for component management. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[5][PATCH] Fix the JUnit tests in Catalina
This patch fixes the JUnit tests in Catalina to run against the ROOT webapp. Now 'ant test' succeeds. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [5][PATCH] Fix the JUnit tests in Catalina
Steve Downey wrote:
This patch fixes the JUnit tests in Catalina to run against the ROOT webapp.
Now 'ant test' succeeds.
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Index: catalina/build.xml
===
RCS file: /home/cvspublic/jakarta-tomcat-catalina/catalina/build.xml,v
retrieving revision 1.17
diff -u -r1.17 build.xml
--- catalina/build.xml 15 Aug 2002 13:56:31 - 1.17
+++ catalina/build.xml 16 Aug 2002 17:50:09 -
@@ -15,7 +15,7 @@
property name=catalina.dist value=${catalina.home}/dist/
property name=test.failonerror value=true/
property name=test.runner value=junit.textui.TestRunner/
- property name=test.webapp value=../webapps/build/examples/
+ property name=test.webapp value=../webapps/build/ROOT/
property name=test.webapp.war value=${java.io.tmpdir}/webapp.war/
!-- Source dependencies --
Index: catalina/src/test/org/apache/naming/resources/BaseDirContextTestCase.java
===
RCS file:
/home/cvspublic/jakarta-tomcat-catalina/catalina/src/test/org/apache/naming/resources/BaseDirContextTestCase.java,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 BaseDirContextTestCase.java
--- catalina/src/test/org/apache/naming/resources/BaseDirContextTestCase.java 18 Jul
2002 16:47:31 - 1.1.1.1
+++ catalina/src/test/org/apache/naming/resources/BaseDirContextTestCase.java 16 Aug
+2002 17:50:10 -
@@ -139,8 +139,7 @@
* directory context.
*/
protected static final String topLevelNames[] =
-{ images, jsp, servlets, META-INF, WEB-INF };
-
+{ index.jsp, jakarta-banner.gif, tomcat.gif, tomcat-power.gif,
+META-INF, WEB-INF };
/**
* The set of names that should be present in the WEB-INF
@@ -247,7 +246,7 @@
// Look up the WEB-INF entry
Object webInfEntry = context.lookup(WEB-INF);
assertNotNull(Found WEB-INF entry, webInfEntry);
-assert(WEB-INF entry is a DirContext,
+assertTrue(WEB-INF entry is a DirContext,
webInfEntry instanceof DirContext);
DirContext webInfContext = (DirContext) webInfEntry;
@@ -303,7 +302,7 @@
// Look up the WEB-INF entry
Object webInfEntry = context.lookup(WEB-INF);
assertNotNull(Found WEB-INF entry, webInfEntry);
-assert(WEB-INF entry is a DirContext,
+assertTrue(WEB-INF entry is a DirContext,
webInfEntry instanceof DirContext);
DirContext webInfContext = (DirContext) webInfEntry;
@@ -353,20 +352,20 @@
while (ne.hasMore()) {
Object next = ne.next();
-assert(list() returns NameClassPair instances,
+assertTrue(list() returns NameClassPair instances,
next instanceof NameClassPair);
NameClassPair ncp = (NameClassPair) next;
-assert(Name ' + ncp.getName() + ' is expected,
+assertTrue(Name ' + ncp.getName() + ' is expected,
isListed(ncp.getName(), list));
if (isDirContext(ncp.getName())) {
-assert(Class ' + ncp.getClassName() + ' is ' +
+assertTrue(Class ' + ncp.getClassName() + ' is ' +
contextClassName + ',
contextClassName.equals(ncp.getClassName()));
}
-assert(Relative is 'true', ncp.isRelative());
+assertTrue(Relative is 'true', ncp.isRelative());
}
@@ -391,30 +390,30 @@
while (ne.hasMore()) {
Object next = ne.next();
-assert(listBindings() returns Binding instances,
+assertTrue(listBindings() returns Binding instances,
next instanceof Binding);
Binding b = (Binding) next;
-assert(Name ' + b.getName() + ' is expected,
+assertTrue(Name ' + b.getName() + ' is expected,
isListed(b.getName(), list));
if (isDirContext(b.getName())) {
-assert(Class ' + b.getClassName() + ' is ' +
+assertTrue(Class ' + b.getClassName() + ' is ' +
contextClassName + ',
contextClassName.equals(b.getClassName()));
}
-assert(Relative is 'true', b.isRelative());
+assertTrue(Relative is 'true', b.isRelative());
Object object = b.getObject();
assertNotNull(Name ' + b.getName() + ' has a non-null object,
object);
-if (b.getName().equals(web.xml)) {
-assert(Entry ' + b.getName() + ' is a Resource,
- object instanceof Resource);
-} else {
-assert(Entry ' + b.getName
Watchdog aggregation of headers may be incorrect
Watchdog now merges headers, by design. ie (from the checking message) Modified logic to send duplicate headers as one aggregated header vs. two headers: header1: val1 header1: val2 -will now be- header1: val1, val2 Due to this, it looks like a couple of tests are failing. GetHeadersTest and HttpServletRequestWrapperGetHeadersTest. GetHeadersTest looks for two Accept-Language headers, en-us and ga-us. It does work if they are sent as Accept-Language:en-us Accept-Language:ga-us But, being sent as: Accept-Language:en-us, ga-us it is presented to the servlet as ONE header, with the value en-us, ga-us However, I'm not sure that it shouldn't be. Parsing a multivalued header is not only diffcult, it seems to depend on which header is being parsed. Certainly full interpretation is very dependent on the header, e.g. Accept-Language: da, en-gb;q=0.8, en;q=0.7 Date: Wed, 15 Nov 1995 06:25:24 GMT The first has three values, the second has one. Interpretation depends on the name of the header. I don't believe the Request.getHeaders() mechanism should try and interpret the values after the :. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Watchdog aggregation of headers may be incorrect
On Friday 16 August 2002 09:43 pm, Patrick Luby wrote: SNIP/ Tomcat 4 used to do this conversion correctly but then it stopped doing the conversion a few months ago. I'll bet dollars to donuts that it was exactly when Coyote was brought in as the connector, replacing the older o.a.c.connector.http.HttpProcessor. Looking at it, it does a lot more detailed parsing of the HTTP headers while receiving the request. Coyote does a lot more lazy evaluation, holding everything in MessageBytes for as long as possible. This saves on unnecessary object creation and GC. This should be fixed as it is Servlet spec non-compliance. However, I am not sure where the parsing of headers is now performed in Tomcat? This shouldn't be handled as part of parsing headers off the wire. I think it should probably be handled in org.apache.tomcat.util.http.MimeHeaders, when the value, or values, is/are actually requested. Header names can be mapped to different content models. This might improve performace in getIntHeader and getDateHeader.X-headers and unknown headers should probably get mapped to TEXT. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [5][PATCH]Run Watchdog from the jakarta-tomcat-5 build.xml
Thanks for pointing the tomcat5 task out. I'm trying to reimplement with
that, and have run into a couple of snags.
First is that o.a.c.startup.CatalinaService doesn't distinguish between
catalina.home and catalina.base. setHome() actually sets both of them.
Adding a setBase() is trivial, but it affects the semantics of
initialization. Any current client expects both to be set by a call to
setHome(), and just moving the setProperty to setBase() breaks that. Of
course if the setProperty(catalina.base,s) is left in setHome(), then
initialization is order dependent. For now, and I just added a setBase()
and ignored the problem.
The next problem was that the task runs in VM. Ant's xercesImpl chokes
on parsing the schemas. This is the known dependency on Xerces 2.0.1.
Replacing the xercesImpl.jar in Ant fixed that, but that seems an ugly
requirement.
In any case, after doing that, Catalina service starts up, but doesn't
seem to be able to find the servlet apis to compile JSP pages. As an
added irritation, stdout isn't redirected to catalina.out, and it is
quite noisy.
So, my current patch may not be the best possible, but it does have the
advantage of working.
I think it will make more sense to use the launcher as the basis for a
task to run tomcat. Running it in process leads to a lot of state
leaking over. For testing I think it's safer to run it as much as
possible in its own environment.
This is what I was using for the tomcat5 task:
property name=tools.jar
location=${java.home}/../lib/tools.jar /
path id=tomcatcp
pathelement location=${tomcat.build}/server/classes/
pathelement location=${tools.jar} /
fileset dir=${tomcat.build}/server/lib
include name=**/*.jar/
/fileset
fileset dir=${tomcat.build}/common/lib
include name=**/*.jar/
/fileset
fileset dir=${tomcat.build}/common/endorsed
include name=**/*.jar/
/fileset
fileset dir=${tomcat.build}/shared/lib
include name=**/*.jar/
/fileset
/path
taskdef name=tomcat5
classname=org.apache.catalina.startup.CatalinaService
classpathref=tomcatcp /
tomcat5 do=start
home=${tomcat.build}
base=${basedir}/tmp/tomcat
wait=false/
[EMAIL PROTECTED] wrote:
On Wed, 14 Aug 2002, Steve Downey wrote:
This patch starts up a copy of tomcat with the watchdog war files, runs
watchdog against it, and shuts down tomcat afterwards. It uses the Launcher
to run tomcat in the background, and puts the webapps, work, logs and conf
directories in a tmp dir so as not to muck up the build.
The only part I really don't like is that there isn't a good way to know that
tomcat is up and running, so for now there's a sleep between launching tomcat
and starting the watchdog tests.
For tomcat5 ? Well, it is - if you use the task ( take a look at
build2.xml ). The task will start tomcat inprocess, and will return
after all the startup is done ( and continue with the next task ).
( unless you have wait=true )
Costin
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [5][PATCH]Run Watchdog from the jakarta-tomcat-5 build.xml
Jean-francois Arcand wrote: Steve Downey wrote: Thanks for pointing the tomcat5 task out. I'm trying to reimplement with that, and have run into a couple of snags. First is that o.a.c.startup.CatalinaService doesn't distinguish between catalina.home and catalina.base. setHome() actually sets both of them. Adding a setBase() is trivial, but it affects the semantics of initialization. Any current client expects both to be set by a call to setHome(), and just moving the setProperty to setBase() breaks that. Of course if the setProperty(catalina.base,s) is left in setHome(), then initialization is order dependent. For now, and I just added a setBase() and ignored the problem. The next problem was that the task runs in VM. Ant's xercesImpl chokes on parsing the schemas. This is the known dependency on Xerces 2.0.1. Replacing the xercesImpl.jar in Ant fixed that, but that seems an ugly requirement. The problem should occurs only with Xerces 2.0.2. Is 2.0.2 bundle with ANT 1.5? If you try with the current Xerces nightly build, it should work. This is a big paint because Xerces 2.0.2 seems to be used everywhereThe only solution will be to set the schema validation off, or detect the Xerces version and throw an exception before starting parsing a file. Yes, it's Xerces 2.0.2. At least that's what the README claims. From what I understand it's not sufficient to turn schema validation off, although I haven't verified that. Is there a good way of detecting which version of Xerces is present? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [5][PATCH]Run Watchdog from the jakarta-tomcat-5 build.xml
[EMAIL PROTECTED] wrote:
SNIP/
Well, CatalinaService is not 'completed' - just started :-)
What we do in 3.3 is have 2 setters, and at execute check if:
- if only one is set, the other takes this value
- if none is set, use discovery ( locate the base from the CLASSPATH )
- if both are set, use that.
If you want to implement this - great, if not I'll do it when I find
time ( or I need it ).
See attached patch. I added a method setHomeAndBase() and a couple of
booleans to see if they were set via setters.
The next problem was that the task runs in VM. Ant's xercesImpl chokes
on parsing the schemas. This is the known dependency on Xerces 2.0.1.
Replacing the xercesImpl.jar in Ant fixed that, but that seems an ugly
requirement.
Well... As I said, it is a major problem if we can't use any JAXP but
require a specific parser and version...
One solution is to remove schema validation ( and validation in general )
from tomcat runtime, and have a separate validation program that
can be run on a webapp _before_ it is deployed on tomcat.
There are many other solutions - but requiring anyone using tomcat5
to use Xerces2.0.1 and subjecting every user to hugely expensive
and redundant validation is the worse.
With any luck, by the time Tomcat5 is released, XML parsers with good
schema support will be more common, so it won't be such an issue. It is
unfortunate that the current release of Xerces is broken.
Removing validation from the servlet container reference implementation
somehow seems, well, wrong. I agree that doing validation at deployment
is reasonable, rather than for each startup. Something like what the jsp
compiler does.
SNIP
java fork=false will run it in process, which gives problems with
the shared environment. In particular I get:
[java] INFO: Digester for server.xml created 587
[java] java.lang.LinkageError: loader constraints violated when
linking org/xml/sax/XMLReader class
java fork=true will run it out of process, but the next task won't
execute until tomcat finishes. Not good either.
I think the right answer is either Launcher, which uses [daemon] to
start a background process, or Cactus, which introduces another
dependency, and may still have some issues with the ant environment
leaking through.
Regarding output redirection, I think Patrick mentioned adding some
methods in the startup code to redirect programmatically.
Costin
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Index: catalina/src/share/org/apache/catalina/startup/CatalinaService.java
===
RCS file:
/home/cvspublic/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/CatalinaService.java,v
retrieving revision 1.2
diff -u -w -r1.2 CatalinaService.java
--- catalina/src/share/org/apache/catalina/startup/CatalinaService.java 10 Aug 2002
16:54:15 - 1.2
+++ catalina/src/share/org/apache/catalina/startup/CatalinaService.java 14 Aug 2002
+21:39:39 -
@@ -158,11 +158,34 @@
}
+private boolean homeSet = false;
+private boolean baseSet = false;
+
public void setHome( String s ) {
System.setProperty(catalina.home, s );
+homeSet = true;
+}
+
+public void setBase( String s ) {
System.setProperty(catalina.base, s );
+baseSet = true;
}
+
+protected void setupBaseAndHome() {
+if (homeSet baseSet) return;
+if (!homeSet !baseSet) return;
+if (homeSet !baseSet) {
+System.setProperty(catalina.base, System.getProperty(catalina.home));
+return;
+}
+if (!homeSet baseSet) {
+System.setProperty(catalina.home, System.getProperty(catalina.base));
+return;
+}
+}
+
+
public void setUseNaming( boolean b ) {
useNaming=b;
}
@@ -196,6 +219,7 @@
// make sure the thread loader is set
log.info(Running tomcat5);
Thread.currentThread().setContextClassLoader(
this.getClass().getClassLoader());
+setupBaseAndHome();
if (starting) {
load();
start();
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/catalina build.xml
(jta.present == true) and (full.dist=true or tyrex.present)
If I'm reading this correctly, this won't build the Tyrex dependant components
if jta is not present, EVEN IF full.dist is requested. That means you can set
full.dist on and NOT get a full dist.
If full.dist is set true, then the build should fail if some component is
missing. At least it's that way for all other components.
On Wednesday 14 August 2002 05:39 pm, [EMAIL PROTECTED] wrote:
bobh2002/08/14 14:39:42
Modified:catalina build.xml
Log:
make Tyrex only compile if JTA is present (this was breaking my build.)
Revision ChangesPath
1.16 +7 -4 jakarta-tomcat-catalina/catalina/build.xml
Index: build.xml
===
RCS file: /home/cvs/jakarta-tomcat-catalina/catalina/build.xml,v
retrieving revision 1.15
retrieving revision 1.16
diff -u -r1.15 -r1.16
--- build.xml 13 Aug 2002 16:26:11 - 1.15
+++ build.xml 14 Aug 2002 21:39:42 - 1.16
@@ -348,10 +348,13 @@
/condition
property name=compile.ssi value=true/
condition property=compile.tyrex
- or
-equals arg1=${full.dist} arg2=on /
-equals arg1=${tyrex.present} arg2=true /
- /or
+ and
+equals arg1=${jta.present} arg2=true /
+or
+ equals arg1=${full.dist} arg2=on /
+ equals arg1=${tyrex.present} arg2=true /
+/or
+ /and
/condition
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [5.0] [VOTE] Release numbering scheme and test releases
Milestones imply a series of goals to be met, not just when we feel like it, or every Tuesday. To be a milestone, there need to some objective criteria that everyone can agree have been met. Don't get me wrong, I like frequent builds, I just hate to see a useful release engineering term get debased. Remy Maucherat wrote: Hi, First, a simple vote about the version numbering scheme for Tomcat 5.0. I think the method used for Tomcat 4.1.x is working well and promotes quality, although it certainly delayed the apprition of a stable build of Tomcat 4.1. I propose keeping it for Tomcat 5.0. ballot +1 [ ] Tomcat 5 should use Tomcat 4.1 version numbering scheme and release management -1 [ ] Tomcat 5 should use something else (to be decided later) /ballot Although Tomcat 5 is still far from being feature complete (and won't be in stable form until the servlet JSP specs ship, at the earliest), it could make sense to start releasing test milestones. The build process works, and the binary works (to some extent; of course, many features are missing and many refactorings still need to be made). The milestones will have a 5.0.x number, similar to the current 4.1.x releases. ballot +1 [ ] Start releasing milestones for Tomcat 5.0 on a regular basis soon -1 [ ] No, later /ballot Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[5][PATCH] Patch to BUILDING.txt to identify dependencies for optional components
This patch to BUILDING.txt documents what the optional components enable in
Tomcat, and where the build process expects to find things.
? .project
Index: BUILDING.txt
===
RCS file: /home/cvspublic/jakarta-tomcat-5/BUILDING.txt,v
retrieving revision 1.17
diff -u -r1.17 BUILDING.txt
--- BUILDING.txt 13 Aug 2002 18:05:09 - 1.17
+++ BUILDING.txt 13 Aug 2002 18:39:02 -
@@ -81,8 +81,9 @@
that you unpack ldap.jar and jaas.jar into the lib subdirectory of
the JNDI directory, parallel to jndi.jar.
-* This is optional with JDK 1.3 or later.
-
+* This is optional with JDK 1.3 or later. It is required for building
+ with full.dist=on. The build process expects this to be in
+ {base.path}/jndi-1.2.1.
(4) Download and Install the Xerces 2 Distribution
@@ -280,8 +281,11 @@
http://java.sun.com/products/jdbc/download.html
-* Place the jar in a convenient location.
+* Place the jar in a convenient location. The build process expects it
+ in ${base.path}/jdbc2_0-stdext.
+* No Tomcat class depends on JDBC directly. Tyrex and commons-dbcp
+ depend on it, and it is distributed with a full distribution.
(14) Download and Install an implementation of the JMX 1.0 specification. This
can be either MX4J (http://mx4j.sourceforge.net) or Sun JMX 1.0 Reference
@@ -311,7 +315,10 @@
http://java.sun.com/products/javabeans/glasgow/jaf.html
* Unpack the package into a convenient location so that it
- resides in its own subdirectory.
+ resides in its own subdirectory. The build process expects this by
+ default to be in ${base.path}/jaf-1.0.1
+
+* The Java Activation Framework is used by the JavaMail optional package.
(16) Download and Install JavaMail 1.2
@@ -321,7 +328,10 @@
http://java.sun.com/products/javamail/index.html
* Unpack the package into a convenient location so that
- it resides in its own subdirectory.
+ it resides in its own subdirectory. The build process expects this
+ by default to be in ${base.path}/javamail-1.2
+
+* JavaMail is used to provide JNDI named mail sessions.
(17) Download and Install the JSSE 1.0.2 Reference Implementation
@@ -332,17 +342,25 @@
http://java.sun.com/products/jsse/
* Unpack the reference implementation into a convenient location so that
- it resides in its own subdirectory.
+ it resides in its own subdirectory. The build expects this to be in
+ ${base.path}/jsse-1.0.2.
+
+* This is optional with JDK 1.4 and later.
+
+* Used to provide SSL and Certificate support in Catalina and in Connectors.
(18) Download and Install the Java Transaction APIs
-* Download the Java Transaction API (JTA) package (version 1.0.1) from:
+* Download the Java Transaction API (JTA) package (version 1.0.1a) from:
http://java.sun.com/products/jta/
* Unpack the package into a convenient location so that it resides in its
- own subdirectory.
+ own subdirectory. By default, the Tomcat build expects this to be
+ {base.path}/jta-1_0_1a/
+
+* Used to provide JNDI named transaction factories.
(19) Download and Install the Struts Binary Distribution
Index: build.properties.default
===
RCS file: /home/cvspublic/jakarta-tomcat-5/build.properties.default,v
retrieving revision 1.27
diff -u -r1.27 build.properties.default
--- build.properties.default 13 Aug 2002 16:52:19 - 1.27
+++ build.properties.default 13 Aug 2002 18:39:02 -
@@ -193,9 +193,9 @@
# - Java Transaction API (JTA), version 1.0.1 or later -
-jta.home=${base.path}/jta-spec1_0_1
+jta.home=${base.path}/jta-1_0_1a
jta.lib=${jta.home}
-jta.jar=${jta.lib}/jta-spec1_0_1.jar
+jta.jar=${jta.lib}/jta.jar
# - JUnit Unit Test Suite, version 3.7 or later -
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[5] examples webapp and catalina unit tests
The catalina unit tests depend on the examples webapp, which isn't part of the jakarta-tomcat-catalina repository. I believe Remy had suggested making the examples part of the servlet-api repo, but that isn't done. Should the examples webapp be brought into the jakarta-tomcat-catalina repo, or should the testcase be rewritten, perhaps using the admin webapp? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[5][PATCH]Run Watchdog from the jakarta-tomcat-5 build.xml
This patch starts up a copy of tomcat with the watchdog war files, runs
watchdog against it, and shuts down tomcat afterwards. It uses the Launcher
to run tomcat in the background, and puts the webapps, work, logs and conf
directories in a tmp dir so as not to muck up the build.
The only part I really don't like is that there isn't a good way to know that
tomcat is up and running, so for now there's a sleep between launching tomcat
and starting the watchdog tests.
Index: build.xml
===
RCS file: /home/cvspublic/jakarta-tomcat-5/build.xml,v
retrieving revision 1.26
diff -u -w -r1.26 build.xml
--- build.xml 13 Aug 2002 16:59:12 - 1.26
+++ build.xml 14 Aug 2002 05:05:42 -
@@ -29,6 +29,8 @@
value=${basedir}/../jakarta-tomcat-jasper/jasper2/
property name=jtc.home
value=${basedir}/../jakarta-tomcat-connectors/
+ property name=watchdog.home
+ value=${basedir}/../jakarta-watchdog-4.0/
!-- Build Defaults --
property name=catalina.build value=${catalina.home}/build/
@@ -51,6 +53,7 @@
echo message=catalina.home=${catalina.home}/
echo message=jasper.home=${jasper.home}/
echo message=jtc.home=${jtc.home}/
+echo message=watchdog.home=${watchdog.home}/
ant dir=${catalina.home} target=flags.display/
@@ -151,6 +154,66 @@
/ant
/target
+ !-- === WATCHDOG: Run Watchdog Tests --
+ target name=watchdog
+ description=Watchdog Servlet Container Tests
+ant dir=${watchdog.home} target=dist
+ property name=servlet23api.home value=${api.home}/
+ property name=servlet22api.home value=${basedir}/../jakarta-servletapi/
+/ant
+delete dir=${basedir}/tmp/tomcat/
+mkdir dir=${basedir}/tmp/tomcat/
+copy todir=${basedir}/tmp/tomcat/conf
+ fileset dir=${tomcat.build}/conf/
+/copy
+copy todir=${basedir}/tmp/tomcat/webapps
+ fileset dir=${tomcat.build}/webapps/
+/copy
+copy todir=${basedir}/tmp/tomcat/work
+ fileset dir=${tomcat.build}/work/
+/copy
+copy todir=${basedir}/tmp/tomcat/logs
+ fileset dir=${tomcat.build}/logs/
+/copy
+copy todir=${basedir}/tmp/tomcat/webapps
+ fileset dir=${watchdog.home}/dist/webapps/
+/copy
+
+
+java classname=LauncherBootstrap fork=yes
+ jvmarg value=-Dcatalina.home=${tomcat.build}/
+ jvmarg value=-Dcatalina.base=${basedir}/tmp/tomcat/
+ arg value=-launchfile/
+ arg value=catalina.xml/
+ arg value=-verbose/
+ arg value=catalina/
+ arg value=start/
+ classpath
+pathelement path=${java.class.path}/
+ pathelement path=${tomcat.build}/bin/
+ /classpath
+/java
+
+sleep seconds=15/
+
+ant dir=${watchdog.home}/dist target=all/
+
+java classname=LauncherBootstrap fork=yes
+ jvmarg value=-Dcatalina.home=${tomcat.build}/
+ jvmarg value=-Dcatalina.base=${basedir}/tmp/tomcat/
+ arg value=-launchfile/
+ arg value=catalina.xml/
+ arg value=-verbose/
+ arg value=catalina/
+ arg value=stop/
+ classpath
+pathelement path=${java.class.path}/
+ pathelement path=${tomcat.build}/bin/
+ /classpath
+/java
+
+ /target
+
!-- == DIST: Create Directories --
target name=dist-prepare
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[5][PATCH] BUILDING.txt and build.properties.default refer to old JTA version
BUILDING.txt and the default build properties refer to an older version of the Java Transaction API. The current version is 1.0.1a, where the old version was 1.0.1. The are semantically the same, just documentation changes. The current version of the jta jar file is named jta.jar, rather than jta-spec1_0_1.jar I'm trying to get the Tomcat 5 build to be as smooth as possible out of the box. 'ant download' makes most of it very straightforward. For optional components, it's a little tougher, as many of them are behind license screens. Several of the APIs that Sun provides also don't define a directory for themselves, such as JNDI and JTA. For these I've always placed them in a directory with the same name as the zip file, sans .zip. After this patch, the build is slightly broken if Tyrex isn't available. It appears that compilation of org/apache/naming/factory/TyrexFactory.java and TyrexResourceFactory are conditioned only on JTA. Patch to follow. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [5][PATCH] BUILDING.txt and build.properties.default refer to old JTA version
With patch actually attached ...
On Monday 12 August 2002 03:22 pm, you wrote:
BUILDING.txt and the default build properties refer to an older version of
the Java Transaction API. The current version is 1.0.1a, where the old
version was 1.0.1. The are semantically the same, just documentation
changes. The current version of the jta jar file is named jta.jar, rather
than
jta-spec1_0_1.jar
I'm trying to get the Tomcat 5 build to be as smooth as possible out of the
box. 'ant download' makes most of it very straightforward. For optional
components, it's a little tougher, as many of them are behind license
screens.
Several of the APIs that Sun provides also don't define a directory for
themselves, such as JNDI and JTA. For these I've always placed them in a
directory with the same name as the zip file, sans .zip.
After this patch, the build is slightly broken if Tyrex isn't available. It
appears that compilation of org/apache/naming/factory/TyrexFactory.java
and TyrexResourceFactory are conditioned only on JTA. Patch to follow.
Index: BUILDING.txt
===
RCS file: /home/cvspublic/jakarta-tomcat-5/BUILDING.txt,v
retrieving revision 1.14
diff -u -r1.14 BUILDING.txt
--- BUILDING.txt 7 Aug 2002 14:14:03 - 1.14
+++ BUILDING.txt 12 Aug 2002 19:11:06 -
@@ -337,12 +337,13 @@
(18) Download and Install the Java Transaction APIs
-* Download the Java Transaction API (JTA) package (version 1.0.1) from:
+* Download the Java Transaction API (JTA) package (version 1.0.1a) from:
http://java.sun.com/products/jta/
* Unpack the package into a convenient location so that it resides in its
- own subdirectory.
+ own subdirectory. By default, the Tomcat build expects this to be
+ {base.path}/jta-1_0_1a/
(19) Download and Install the Struts Binary Distribution
Index: build.properties.default
===
RCS file: /home/cvspublic/jakarta-tomcat-5/build.properties.default,v
retrieving revision 1.18
diff -u -r1.18 build.properties.default
--- build.properties.default 8 Aug 2002 05:47:01 - 1.18
+++ build.properties.default 12 Aug 2002 19:11:06 -
@@ -197,9 +197,9 @@
# - Java Transaction API (JTA), version 1.0.1 or later -
-jta.home=${base.path}/jta-spec1_0_1
+jta.home=${base.path}/jta-1_0_1a
jta.lib=${jta.home}
-jta.jar=${jta.lib}/jta-spec1_0_1.jar
+jta.jar=${jta.lib}/jta.jar
# - JUnit Unit Test Suite, version 3.7 or later -
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [5][PATCH] BUILDING.txt and build.properties.default refer to old JTA version
On Monday 12 August 2002 03:22 pm, you wrote: SNIP After this patch, the build is slightly broken if Tyrex isn't available. It appears that compilation of org/apache/naming/factory/TyrexFactory.java and TyrexResourceFactory are conditioned only on JTA. Patch to follow. Patch is NOT to have full.dist=on in ~/build.properties. ~/build.properties is nice when you're only building a group of related projects with the same environment. With unrelated projects, it's a source of much strangeness. I worked with one guy who argued for an /etc/build.properties. Fortunately coworkers kept me for strangling him. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [5.0] Build notes
The only snag is that 'ant download' doesn't download optional
components. And some of them are optional the same way that brakes on a
go-cart are optional. It'll work, just not quite the way you expect it to.
More importantly, any developer building Tomcat needs to build a full
version, otherwise you run the risk of breaking parts of the build that
you happen not to be building because you don't have the optional
component that it depends on. And the build process is fairly quiet
about those missing pieces.
Automating the download of optional components, however, is a bit
tricky, as many of the optional components are behind Sun's license page.
Bob Herrmann wrote:
Yea, I liked your script, this one builds Tomcat 5.
BUILDING.TXT could almost just say All you need is JDK1.4 and Ant1.5
then just type 'ant' and a working Tomcat 5 development tree is built.
(If you are behind a firewall, you may need to adjust proxy settings.)
This should be cross platform (haven't tested it on Win32.)
Cheers,
-bob
project name=CVS Retrieval default=populate
property file=build.properties/
property name=apache.dir value=${user.home}/TC5/
property name=base.path value=${apache.dir}/download/
property name=cvsroot
value=:pserver:[EMAIL PROTECTED]:/home/cvspublic/
target name=populate depends=init,checkout,buildit /
target name=init
tstamp/
mkdir dir=${apache.dir}/
mkdir dir=${base.path}/
/target
target name=checkout depends=init
cvs package=jakarta-servletapi-5
cvsRoot=${cvsroot}
dest=${apache.dir}
/
cvs package=jakarta-tomcat-catalina
cvsRoot=${cvsroot}
dest=${apache.dir}
/
cvs package=jakarta-tomcat-5
cvsRoot=${cvsroot}
dest=${apache.dir}
/
cvs package=jakarta-tomcat-connectors
cvsRoot=${cvsroot}
dest=${apache.dir}
/
cvs package=jakarta-tomcat-jasper
cvsRoot=${cvsroot}
dest=${apache.dir}
/
cvs package=jakarta-tomcat-5
cvsRoot=${cvsroot}
dest=${apache.dir}
/
/target
target name=buildit depends=init
echo message=Commons-logging build dies without this
file=${base.path}/LICENSE /
ant dir=${apache.dir}/jakarta-tomcat-5
target=download /
ant dir=${apache.dir}/jakarta-tomcat-5
target=dist /
/target
/project
On Tue, 2002-08-06 at 13:43, Ian Darwin wrote:
On August 6, 2002 01:01 pm, you wrote:
The main thing missing is a target which sets up the CVS repositories,
so it's quite close to what we have now. Problem is, I'm not too happy
at the idea of doing that automatically.
Trivial to do with Ant, but I agree, it's risky to automate this. OTOH if
it's well documented what it's doing, people should be OK with it.
Ian
project name=CVS Retrieval default=populate
!-- $Id: build.xml,v 1.1 2002/06/11 15:35:57 ian Exp $ --
!-- Maybe find a better way of setting this --
property name=apache.dir value=${user.home}/src/apache/
property name=cvs.root
value=:pserver:[EMAIL PROTECTED]:/home/cvspublic/
target name=init
tstamp/
mkdir dir=${apache.dir}/
/target
target name=populate depends=init
cvs package=jakarta-tomcat-4.0
cvsRoot=${cvs.root}
dest=${apache.dir}
/
cvs package=jakarta-tomcat-connectors
cvsRoot=${cvs.root}
dest=${apache.dir}
/
cvs package=jakarta-tomcat-jasper
cvsRoot=${cvs.root}
dest=${apache.dir}
/
/target
/project
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [5][PATCH]commons-logging built without log4j/LogKit
It's headed in the right direction, I think. But depending on CVS versions of other projects _by_default_ is a bit on the scary side. -Original Message- From: Bill Barker [mailto:[EMAIL PROTECTED]] Sent: Thursday, August 08, 2002 1:32 AM To: Tomcat Developers List Subject: Re: [5][PATCH]commons-logging built without log4j/LogKit Now, like Costin, I'm starting to think that the 5.0 build is scary. - Original Message - From: Steve Downey [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, August 07, 2002 10:00 PM Subject: [5][PATCH]commons-logging built without log4j/LogKit The commons-logging package built by 'ant download' doesn't have support for log4j or LogKit in it, unless the properties happen to be set outside of jakarta-tomcat-5. This patch adds downloads for the released versions of log4j and logkit. -- -- -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [5][PATCH]commons-logging built without log4j/LogKit
If you follow the directions in BUILDING.txt, it's not necessary to download
log4j or LogKit. BUILDING.txt asks for a nightly build of commons-logging,
which would have been built against log4j and LogKit. If they aren't present
at runtime, they won't be used as the implementation of commons-logging. But
if they aren't present at build time, they can't be used.
It's basically the same as, say, the JSSE for a Tomcat build. You need it to
build SSL support, but if not present at runtime it just means that Tomcat
can't do SSL.
On Thursday 08 August 2002 01:46 am, Patrick Luby wrote:
Steve,
Thanks for the patch. I just committed it.
I assume that log4j and LogKit are required dependencies. Any chance
that you could add those items to BUILDING.txt?
Thanks,
Patrick
Steve Downey wrote:
The commons-logging package built by 'ant download' doesn't have support
for log4j or LogKit in it, unless the properties happen to be set outside
of jakarta-tomcat-5. This patch adds downloads for the released versions
of log4j and logkit.
? .project
Index: build.properties.default
===
RCS file: /home/cvspublic/jakarta-tomcat-5/build.properties.default,v
retrieving revision 1.17
diff -u -r1.17 build.properties.default
--- build.properties.default7 Aug 2002 14:14:03 - 1.17
+++ build.properties.default8 Aug 2002 04:54:58 -
@@ -122,8 +122,17 @@
activation.jar=${activation.lib}/activation.jar
# - Log4j -
-log4j.home=${base.path}/log4j
-log4j.jar=${log4j.home}/log4j.jar
+log4j.home=${base.path}/jakarta-log4j-1.2.6
+log4j.lib=${log4j.home}
+log4j.jar=${log4j.lib}/dist/lib/log4j-1.2.6.jar
+log4j.loc=http://jakarta.apache.org/log4j/jakarta-log4j-1.2.6.tar.gz
+
+# - LogKit -
+logkit.home=${base.path}/LogKit-1.0.1
+logkit.lib=${logkit.home}
+logkit.jar=${logkit.lib}/logkit-1.0.1.jar
+logkit.loc=http://jakarta.apache.org/builds/jakarta-avalon/release/logki
t/latest/LogKit-1.0.1-bin.tar.gz +
# - Jaxen ( required by taglibs/standard required by jasper ) -
jaxen.home=${base.path}/jaxen-1.0-FCS
Index: build.xml
===
RCS file: /home/cvspublic/jakarta-tomcat-5/build.xml,v
retrieving revision 1.18
diff -u -r1.18 build.xml
--- build.xml 7 Aug 2002 14:14:03 - 1.18
+++ build.xml 8 Aug 2002 04:54:59 -
@@ -492,6 +492,16 @@
/antcall
--
+antcall target=downloadgz
+ param name=sourcefile value=${log4j.loc}/
+ param name=destfile value=${log4j.jar}/
+/antcall
+
+antcall target=downloadgz
+ param name=sourcefile value=${logkit.loc}/
+ param name=destfile value=${logkit.jar}/
+/antcall
+
antcall target=cvsbuild
param name=location value=${commons-logging.loc}/
param name=subdir value=${commons-logging.home}/
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED] For additional
commands, e-mail: mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [PATCH] JspC package names
I think this has been fixed with the patch to correct bug 5471. That changes how package names are generated in CommandLineContext. I'm glad to see someone else is using jspc. It's been broken so often, I thought I was the only one. -Original Message- From: Mike Schrag [mailto:[EMAIL PROTECTED]] Sent: Monday, February 04, 2002 2:12 PM To: [EMAIL PROTECTED] Subject: [PATCH] JspC package names In 4.0.1, JspC commandline tool is not making package names that correspond to subdirectories in my context directory (i.e. I need /help/testhelp.jsp to become help/testhelp.java and be package help;). There is a setOutputInDirs method on the CommandLineContext that seems like it should toggle this feature. I think I'm patching this in the right place... I don't know for sure that setOutputInDirs is the correct attribute to piggy back on, but regardless I think other people may find this capability useful. Thanks a lot Mike Schrag -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [4.0.2] Bug list
If 5644 is going to be fixed, then 5471 should be too. Right now, given /index.jsp and /subdir/index.jsp, jspc will overwrite the first index.java with the second. It also conflates them in web.xml. I've submitted a patch to the list before. I've also just attached it to the bug report. I also just noticed that jspc.sh doesn't use the value of JAVA_HOME to find java. It expects it on the PATH, apparently. bug 6108. -Original Message- From: Remy Maucherat [mailto:[EMAIL PROTECTED]] Sent: Monday, January 28, 2002 3:43 PM To: [EMAIL PROTECTED] Subject: [4.0.2] Bug list Hi, I've just committed a text file in the 4.0 branch listing the bugs that should be addressed before 4.0.2 Final is released. I'll cut paste it here, for people who may not want to check out the branch. Remy Tomcat 4.0.2 Final bug status - This document lists bug that should be addressed before 4.0.2 Final is released. None of these bugs are regression problems, so it should be acceptable to delay their resolution. 5647jk AJP13 connector will not pass authentication requests 4793webapp mod_webapp connector doesn´t work 4930webapp java.io.StreamCorruptedException: Type code out of range, is 0 with Apache WebApp module 5040webaap EOFException when talking from applet to servlet via mod_webapp 5201catalina Persistent sessions EJB Statefull 5402webapp WarpConnection raise IOException 5483jk I18N fails using AJP 1.3 with Tomcat 4.01 final / Apache 1.3.22 5644jasper JspC produces badly formed classnames if first char is a digit 5735catalina HTTP connector running out of processors under heavy load 5752docs Documentation: Resources link invalid on page http://jakarta.apache.org/tomcat/tomcat-4.0-doc /config/context.html 5760docs Doc-bug: Inexact documented jars in Class Loader INFO 5795catalina Catalina Shutdown relies on localhost causing problems in a Clustered Solaris environment 5820docs Undocumented restriction on inoking manager webapp 5827catalina DataInputStream.readInt returns wrong values 5899servlets HTTP POST parameters ignored in CGIServlet.java 5905jasper JSP Document not correctly processed 6036webapp Problems with URI mapping 3509webapp Apache 1.3.20 mod_webapp Tomcat 4b7 HANGS under Win 5704servlets CgiServlet corrupting images? 4518jasper load-on-startup is not working with jsp page 5759servlets CGI servlet mapping by extension *.cgi does not work 5988jasper Jasper Null Pointer Exception Error FIXED? - 5330catalina JNDI ENC context problem LATER - 5396installer Tomcat start shortcut fails when HTTPS is set FIXED - 5876catalina HttpResponseBase broken FIXED - 5908catalina java.lang.IllegalStateException: zip file closed -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] This electronic mail transmission may contain confidential information and is intended only for the person(s) named. Any use, copying or disclosure by any other person is strictly prohibited. If you have received this transmission in error, please notify the sender via e-mail. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[PATCH] Bug 5471 - JspC broken when compiling webapps
This patch changes CommandLineContext.getServletPackageName() to return a package name based on the path to the JSP as well as the package name supplied on the command line. Without a change like this, a webapp that has files with the same name, such as index.jsp, in more than one place is compiled incorrectly, with both JSP files being mapped to the same servlet. With this patch, the java files are placed in the correct directories, and generation of web.xml works. This electronic mail transmission may contain confidential information and is intended only for the person(s) named. Any use, copying or disclosure by any other person is strictly prohibited. If you have received this transmission in error, please notify the sender via e-mail. bug5471.patch Description: Binary data -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [PATCH] Bug 5471 - JspC broken when compiling webapps
The patch doesn't mangle the class file name, just the package name, so that the resulting java file is put in a directory that matches the path of the jsp file. Just putting the java file in a subdirectory is insufficient, though. Unless the packages are different, there isn't a way to disambiguate the servlets that result from two index.jsp's in the web.xml file. Example: input /index.jsp /subdir/index.jsp result /index.java - contains class index /subdir/index.java - contains class subdir.index If the -p option is used, eg -p com.netfolio.jspservlets /com/netfolio/jspservlets/index.java - contains class com.netfolio.jspservlets.index /com/netfolio/jspservlets//subdir/index.java - contains class com.netfolio.jspservlets.subdir.index -Original Message- From: Kin-Man Chung [mailto:[EMAIL PROTECTED]] Sent: Tuesday, December 18, 2001 4:37 PM To: [EMAIL PROTECTED] Subject: Re: [PATCH] Bug 5471 - JspC broken when compiling webapps Believe or not, Jasper once mangled the file names in a way similar to what is in the patch. It was modified in response to a bug (Bugzilla is currently unavailable, so I can't look up the bug number). The filer complained that for a file with deeply nested path, the resultant file name is too long to work in Window, since there is a 250(?) character file name limit there. I think a better fix is not to mangle the path into the file name, but to put the .java (and .class) files in a directory structure that mirrors the .jsp structure. This is how it work currently, for the non -webapps case. Date: Tue, 18 Dec 2001 15:47:25 -0500 From: Steve Downey [EMAIL PROTECTED] Subject: [PATCH] Bug 5471 - JspC broken when compiling webapps To: [EMAIL PROTECTED] (E-mail) [EMAIL PROTECTED] MIME-version: 1.0 Delivered-to: mailing list [EMAIL PROTECTED] Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N List-Post: mailto:[EMAIL PROTECTED] List-Subscribe: mailto:[EMAIL PROTECTED] List-Unsubscribe: mailto:[EMAIL PROTECTED] List-Help: mailto:[EMAIL PROTECTED] List-Id: Tomcat Developers List tomcat-dev.jakarta.apache.org This patch changes CommandLineContext.getServletPackageName() to return a package name based on the path to the JSP as well as the package name supplied on the command line. Without a change like this, a webapp that has files with the same name, such as index.jsp, in more than one place is compiled incorrectly, with both JSP files being mapped to the same servlet. With this patch, the java files are placed in the correct directories, and generation of web.xml works. This electronic mail transmission may contain confidential information and is intended only for the person(s) named. Any use, copying or disclosure by any other person is strictly prohibited. If you have received this transmission in error, please notify the sender via e-mail. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] This electronic mail transmission may contain confidential information and is intended only for the person(s) named. Any use, copying or disclosure by any other person is strictly prohibited. If you have received this transmission in error, please notify the sender via e-mail. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [PATCH] Bug 5471 - JspC broken when compiling webapps
You may want this one, also. Turns out that jasper.sh is mildly broken on
HEAD. It doesn't grab the libraries in shared/lib or the classes in
shared/classes.
I'm guessing that JspC isn't the most heavily exercised part of the system.
g
Index: jasper.sh
===
RCS file: /home/cvspublic/jakarta-tomcat-4.0/jasper/src/bin/jasper.sh,v
retrieving revision 1.5
diff -u -r1.5 jasper.sh
--- jasper.sh 2001/09/13 15:22:45 1.5
+++ jasper.sh 2001/12/19 00:10:39
@@ -35,7 +35,7 @@
done
JASPER_HOME_1=`dirname $PRG`/..
- echo Guessing JASPER_HOME from catalina.sh to ${JASPER_HOME_1}
+ echo Guessing JASPER_HOME from jasper.sh to ${JASPER_HOME_1}
if [ -d ${JASPER_HOME_1}/conf ] ; then
JASPER_HOME=${JASPER_HOME_1}
echo Setting JASPER_HOME to $JASPER_HOME
@@ -80,6 +80,10 @@
done
CP=$CP:$JASPER_HOME/common/classes
for i in $JASPER_HOME/common/lib/*.jar ; do
+ CP=$CP:$i
+done
+CP=$CP:$JASPER_HOME/shared/classes
+for i in $JASPER_HOME/shared/lib/*.jar ; do
CP=$CP:$i
done
-Original Message-
From: Kin-Man Chung [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, December 18, 2001 5:12 PM
To: [EMAIL PROTECTED]
Subject: RE: [PATCH] Bug 5471 - JspC broken when compiling webapps
I responsed in haste, without reading your patch carefully. :( My
apologies.
I'll get the patch in, later. Thanks.
Date: Tue, 18 Dec 2001 16:44:42 -0500
From: Steve Downey [EMAIL PROTECTED]
Subject: RE: [PATCH] Bug 5471 - JspC broken when compiling webapps
To: 'Tomcat Developers List' [EMAIL PROTECTED]
MIME-version: 1.0
Delivered-to: mailing list [EMAIL PROTECTED]
Mailing-List: contact [EMAIL PROTECTED];
run by ezmlm
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N
List-Post: mailto:[EMAIL PROTECTED]
List-Subscribe: mailto:[EMAIL PROTECTED]
List-Unsubscribe: mailto:[EMAIL PROTECTED]
List-Help: mailto:[EMAIL PROTECTED]
List-Id: Tomcat Developers List tomcat-dev.jakarta.apache.org
The patch doesn't mangle the class file name, just the
package name, so that
the resulting java file is put in a directory that matches
the path of the
jsp file. Just putting the java file in a subdirectory is
insufficient,
though. Unless the packages are different, there isn't a
way to disambiguate
the servlets that result from two index.jsp's in the web.xml file.
Example:
input
/index.jsp
/subdir/index.jsp
result
/index.java - contains class index
/subdir/index.java - contains class subdir.index
If the -p option is used, eg -p com.netfolio.jspservlets
/com/netfolio/jspservlets/index.java - contains class
com.netfolio.jspservlets.index
/com/netfolio/jspservlets//subdir/index.java - contains class
com.netfolio.jspservlets.subdir.index
-Original Message-
From: Kin-Man Chung [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, December 18, 2001 4:37 PM
To: [EMAIL PROTECTED]
Subject: Re: [PATCH] Bug 5471 - JspC broken when compiling webapps
Believe or not, Jasper once mangled the file names in a way
similar to what
is in the patch. It was modified in response to a bug
(Bugzilla is currently
unavailable, so I can't look up the bug number). The filer
complained that
for a file with deeply nested path, the resultant file name
is too long to
work in Window, since there is a 250(?) character file name
limit there.
I think a better fix is not to mangle the path into the
file name, but
to put the .java (and .class) files in a directory structure
that mirrors
the .jsp structure. This is how it work currently, for the
non -webapps
case.
Date: Tue, 18 Dec 2001 15:47:25 -0500
From: Steve Downey [EMAIL PROTECTED]
Subject: [PATCH] Bug 5471 - JspC broken when compiling webapps
To: [EMAIL PROTECTED] (E-mail)
[EMAIL PROTECTED]
MIME-version: 1.0
Delivered-to: mailing list [EMAIL PROTECTED]
Mailing-List: contact [EMAIL PROTECTED];
run by ezmlm
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N
List-Post: mailto:[EMAIL PROTECTED]
List-Subscribe: mailto:[EMAIL PROTECTED]
List-Unsubscribe:
mailto:[EMAIL PROTECTED]
List-Help: mailto:[EMAIL PROTECTED]
List-Id: Tomcat Developers List
tomcat-dev.jakarta.apache.org
This patch changes
CommandLineContext.getServletPackageName() to return a
package name based on the path to the JSP as well as the
package name
supplied on the command line.
Without a change like this, a webapp that has files with
the same name, such
as index.jsp, in more than one place is compiled
incorrectly, with both JSP
files being mapped to the same servlet.
With this patch, the java files are placed in the correct
directories, and
generation of web.xml works.
This electronic
mail transmission
may contain confidential information
RE: DO NOT REPLY [Bug 3839] - Problem bookmarking login page
Train the user not to do that is a cop out. If an application doesn't work the way users expect, it's a problem with the application, not the user. That's usability 101. If the user shouldn't bookmark the login page, they shouldn't ever be exposed to the URI for the login page. That makes it impossible to bookmark. The only URI that the user should see is the URI for the protected resource. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Wednesday, October 03, 2001 6:23 PM To: [EMAIL PROTECTED] Subject: DO NOT REPLY [Bug 3839] - Problem bookmarking login page DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3839. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3839 Problem bookmarking login page [EMAIL PROTECTED] changed: What|Removed |Added -- -- Status|REOPENED|RESOLVED Resolution||WONTFIX --- Additional Comments From [EMAIL PROTECTED] 2001-10-03 15:23 --- The fact that you hd the same problems under WebLogic also should have given you a hint that you might be mis-using this functionality :-). Although the form login page (and form error page) are physically contained in your web application archive, they should not be hyperlinked to by any of your app's pages. Most particularly, it should *not* be your welcome page. If you (temporarily) switch your app to use BASIC authentication instead, it should still work correctly - and there is no possibility to bookmark the login page because there is no such thing. If your app doesn't work in this scenario, then you should modify it so that it can. If you don't, then you're going to be dependent on non-portable behavior of whatever container vendor happens to allow this technique to work - the spec doesn't require it. This electronic mail transmission may contain confidential information and is intended only for the person(s) named. Any use, copying or disclosure by any other person is strictly prohibited. If you have received this transmission in error, please notify the sender via e-mail.
RE: SCRIPT_NAME and PATH_INFO with extension mapping
As far as I can tell, the HTTP and HTML specs are completely silent on this. The CGI spec talks about PATH_INFO et al, but doesn't seem to address extension mapping. As another datapoint, static content with Apache doesn't work if you append path info to an HTML page, i.e. http://www.foo.com/index.html/foo/bar, doesn't deliver index.html. -Original Message- From: Jon Stevens [mailto:[EMAIL PROTECTED]] Sent: Sunday, September 30, 2001 6:50 PM To: tomcat-dev Subject: SCRIPT_NAME and PATH_INFO with extension mapping on 9/30/01 5:47 PM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: the conclusion was that the HTTP spec is wrong and we should follow the Servlet spec. That is complete BS. The servlet spec shouldn't 'override' what is defined in the HTTP spec unless absolutely necessary. This is definitely not a necessary case, but instead an act of stupidity. Workaround - declare each page with exact mappings in web.xml. Making me specify each and every page in my webapp in the web.xml is just plain BS. I bet that a URL like this works: http://www.foo.com/MicrosoftIsBetterThanSun.asp/foo/bar I *know* that this URL works: http://www.foo.com/PHPIsBetterThanJSP.php/foo/bar Essentially, what you are doing by removing this capability is preventing the SCRIPT_NAME from having PATH_INFO and that is not right according to the HTTP spec. I don't think that a Servlet container can override the behavior of the HTTP spec and still claim HTTP compliance. -jon This electronic mail transmission may contain confidential information and is intended only for the person(s) named. Any use, copying or disclosure by any other person is strictly prohibited. If you have received this transmission in error, please notify the sender via e-mail.
RE: [jtc] tabs policy??
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Sunday, June 24, 2001 7:16 AM To: [EMAIL PROTECTED] Subject: Re: [jtc] tabs policy?? On Sun, 24 Jun 2001, Justin Erenkrantz wrote: That just leads to formatting problems because people don't understand that. If you must have tabs, they should be the same as the indention level, not some factor of the indention level. This doesn't have to be complicated. One tab == one indention level. I'm not sure I understand how you reached that conclusion, but this is what causes all the curent problems ( and the reason for people to consider tabs as evil ). Tab size is 8 - or at least used to be before the idea that you can configure this. What's evil is the fact that some editors allow you to change the size of the tab. In a text you can have multiple indentation levels, and it's true that on some typewriters you can use the TAB key to move to the next indentation level On real typewriters, the TAB key (used for TABles) moved to the next TAB stop, which could be anywhere on the line. It would make a nice thumping noise when the carriage hit the stop, too. The notion that tabs == some number of spaces is a modern aberration stemming from DECWriters having tab stops every 8 spaces. They also, perversely, would execute a carriage return when issued a newline. g This electronic mail transmission may contain confidential information and is intended only for the person(s) named. Any use, copying or disclosure by any other person is strictly prohibited. If you have received this transmission in error, please notify the sender via e-mail.
RE: FORM-based authentication idea
-Original Message- From: Michael Jennings [mailto:[EMAIL PROTECTED]] Sent: Thursday, June 21, 2001 11:55 AM To: [EMAIL PROTECTED] Subject: Re: FORM-based authentication idea The best way to think about form-based login is like this: * The login page is (in essence) part of the container, not the application. Therefore, ... * The login page should *never* be referenced directly by any other application page, and ... * The login page should *never* be requested directly by the user. How do you enforce that a particular URL should never be asked for by a user? Installing it under WEB-INF is one way. The container will then enforce the prohibition. However, in general, not publishing the URL anywhere is probably sufficient. It's not as though with form based login that the user ever has to see the URL of the login form. -SMD This electronic mail transmission may contain confidential information and is intended only for the person(s) named. Any use, copying or disclosure by any other person is strictly prohibited. If you have received this transmission in error, please notify the sender via e-mail.
RE: Jasper34: Manglers
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Monday, June 11, 2001 12:18 AM To: [EMAIL PROTECTED] Subject: Re: Jasper34: Manglers On Sun, 10 Jun 2001, Glenn Nielsen wrote: Another advantage of jasper40 using a URLClassLoader for each individual JSP page is that you don't accumulate outdated classes in the classloader that eat up JVM memory when a JSP is recompiled. I haven't looked at jasper33, so please let me know if that is not a problem with it. It is. On a production site it isn't a big factor - there are not too many reloads. Depends. I've done some content publishing work where JSPs are replaced quite often while the engine is running. Of course, there are other ways of accomplishing the same effect, for example including HTML fragments. But it would turn out, often enough, that we'd need to inject some code into the text. Usually something trivial, like a link to the secure side of the same server, or iterating over a dynamic list. I think we'd end up with hundreds, maybe low Ks, of dead classes in memory. This electronic mail transmission may contain confidential information and is intended only for the person(s) named. Any use, copying or disclosure by any other person is strictly prohibited. If you have received this transmission in error, please notify the sender via e-mail.
RE: Trying New Connectors Build Stuff
With cygwin, it should build using ./configure make make check make install. It's just another flavour for autoconf. Although it didn't used to be true, recently I am more surprised when a package does _not_ build using cygtools. However, the unix emulation layer is nowhere near as efficient as win32 native at such important tasks as disk and socket I/O. It's a wonderful user level tool. I use it everyday for many things. But deploying production systems isn't one of the things I'd do. However, since I just recently sold management on linux/apache/tomcat as our next gen platform, and I can put that on my desktop as well, it's not much skin off my nose if the connectors are suboptimal on NT. g -Original Message- From: kevin seguin [mailto:[EMAIL PROTECTED]] Sent: Tuesday, May 15, 2001 10:00 AM To: [EMAIL PROTECTED] Subject: Re: Trying New Connectors Build Stuff So we have 2 cygwin (amy+jon) and 1 msvc (kevin)... I hoped to have more feedback... I'll start with cygwin (since I can get it for free) does it really matter much? it should build with both cygwin and msvc, right? you might just have different makefiles for the two. -kevin. This electronic mail transmission may contain confidential information and is intended only for the person(s) named. Any use, copying or disclosure by any other person is strictly prohibited. If you have received this transmission in error, please notify the sender via e-mail.
RE: JNDI/LDAP realm
As I understand it, you can rebind with different credentials, but you can't have more than one set of credentials on the same connection. That means either synchronizing on the ldap connection, and serializing login, or having multiple connections and parallelizing login. Now, this isn't a terrible issue if the code cleans up promptly when done authenticating, but it is a resource contention issue. If the code doesn't clean up promptly, and relies on finalization, then it will only fail under load. Usually in some horrible manner that will be difficult to trace back to the root cause. -Original Message- From: John Holman [mailto:[EMAIL PROTECTED]] Sent: Monday, May 14, 2001 5:55 PM To: [EMAIL PROTECTED] Subject: Re: JNDI/LDAP realm - Original Message - From: Steve Downey [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, May 14, 2001 5:39 PM Subject: RE: JNDI/LDAP realm The downside to binding with the supplied credentials is that it chews up a file descriptor. For light loads, it's not an issue. For heavy loads, it can be a big issue. If the app server binds administratively, you can get by with two connections, one for reading and one for writing. Or even one, if you're not replicating LDAP. According to the JNDI tutorial at least, Suns's provider for LDAP v3 is supposed to allow rebinding with a different principal.and credentials while keeping the same directory context and underlying network connection. (Although in practice it doesn't always seem to work quite like that). So it might be possible not to need additional file descriptors. Also, note that the LDAP connection is only needed for a brief period at the beginning of a session when the user first authenticates. Not that the present code attempts to be efficient about reusing directory contexts etc. But perhaps I misunderstand what you are saying. All in all, making it configurable is probably a good idea. Agreed. -Original Message- From: Ellen Lockhart [mailto:[EMAIL PROTECTED]] Sent: Sunday, May 13, 2001 12:58 PM To: [EMAIL PROTECTED] Subject: Re: JNDI/LDAP realm I preferred binding to the directory with supplied credentials because it allows the realm implementation to use an anonymous password for the rest of what it needs. To allow for DN's in the directory that may not be composed of the same attributes as other DN's, one thing I was thinking about doing to the one I submitted was to configure what the login attribute is (cn, uid, etc.) and search for it (with anonymous login) to get the dn, then bind to the directory with the resultant DN and the user-entered password to authenticate. This might be a little less efficient than just searching and getting the password as well, but is more secure than having the root password to the ldap server where it might be accessible by someone. - Original Message - From: John Holman [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Sunday, May 13, 2001 5:02 AM Subject: JNDI/LDAP realm The current JNDI realm implementation in Tomcat 4 is based on code I submitted, which was subsequently modified and committed by Craig. Two significant changes he made are: - the original code found the DN of the user by searching the directory. The current implementation, like Ellen Lockhart's recent submission, determines the DN by substituting the username into a string. - the original code supported a mode in which the user is authenticated by binding to the directory with the supplied credentials (as does Ellen's). The code for this was removed, with a comment in the commit log that this mode should be supported probably in a separate implementation class. I did comment on this in an earlier message, but got no response - so I'm trying again now there is another little wave of interest :) Determining the DN. The pattern substitution method in the current implementation is obviously more efficient when applicable but the search method is more general. For example, unlike the current implementation, search can handle the following common use cases: - users are stored within multiple nodes in the directory (e.g. they may be held under different organisational units) - the attribute used in distinguished names is not the same as that the user enters into the basic authentication dialog box (e.g. the user might enter mail address as the username rather than uid; the directory might use commonName as a component of distinguished names rather than uid). So there are really two orthogonal issues for user authentication each with two options: - how the dn for the user
RE: Jasper performance
Given any reasonably timeframe for delivery on a new Jasper to production, jdk 1.1 is likely to be three cycles behind. Supporting legacy systems can only go so far. -Original Message- From: Glenn Nielsen [mailto:[EMAIL PROTECTED]] Sent: Tuesday, May 15, 2001 5:30 PM To: [EMAIL PROTECTED] Subject: Re: Jasper performance I would like to propose that the new Jasper require jdk 1.2. The current version of jasper can be used by those who have jdk 1.1.x. Then we don't have to worry about jumping through hoops trying to get the new jasper to run both in 1.1 and 1.2, plus we can optimize for 1.2. In addition JSP 1.2 will require jdk 1.2 or greater. Regards, Glenn [EMAIL PROTECTED] wrote: Jasper performance has already been identified as an area needing improvement. Discussions and work on this has already started in the main tomcat branch in CVS jakarta-tomcat/proposals/jasper34, but this may be moving to the CVS repository jakarta-tomcat-jasper. This work just started recently, I don't know when it will be ready. It will take few months - it's not that easy. We already added tag pooling in tomcat3.3, and that have a significant effect on performance if you are using tags - but that's just the beginning. The first step is to reorganize the code. Then we'll try to make the code generator more customizable ( probably by using XSLT for some of the operations ). The real performance enhancement will come when we start tunning the generated code - there are many ideas around, but we need the refactoring first. BTW, jasper will share most of the code for the 1.1 and 1.2 APIs, so all enhancements will be available in both 3.x and 4.x ( and other containers as well ). If you have ideas, code or opinions - please get involved, we need you :-) Costin Rickard Öberg wrote: Hi! We are using Tomcat/JBoss and are pleased with the actual functionality. What is killing us right now is the performance of the code generated by Jasper, especially when using taglibs in complex ways. The generated code is way too unoptimized. So, if this has not been asked before (in which case a RTFA is ok, although I've looked already), my question is: When will Jasper be rewritten? Are there any such projects underway now? Have there been any discussions about this yet? Am I the only one seeing this problem, or are more people concernced about it? Thanks, Rickard -- Rickard Öberg Software Development Specialist xlurc - Xpedio Linköping Ubiquitous Research Center Author of Mastering RMI Email: [EMAIL PROTECTED] -- -- Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | -- This electronic mail transmission may contain confidential information and is intended only for the person(s) named. Any use, copying or disclosure by any other person is strictly prohibited. If you have received this transmission in error, please notify the sender via e-mail.
RE: virus warnings and
Mine, unfortunately for this list, isn't configured to be silent. It sends a warning back to the sender. I'm trying to see if we can get it to not do that for 'Precedence: Bulk' mail. It doesn't help that we've got about several developers following this list and the users list. Mea culpa, and I'm trying to get it fixed. -Original Message- From: jean-frederic clere [mailto:[EMAIL PROTECTED]] Sent: Tuesday, May 15, 2001 10:35 AM To: [EMAIL PROTECTED] Subject: Re: virus warnings and Pier P. Fumagalli wrote: Jay Doggett at [EMAIL PROTECTED] wrote: Ok, good call. I had multiple mail rules for this list. I still think that virus posters should get expunged. I didn't get any virus... Pier I also didn't get any virus, but our company mail servers may filter silently these things, but that also means we (the ones that tell no virus) cannot send these virus! Jean-frederic This electronic mail transmission may contain confidential information and is intended only for the person(s) named. Any use, copying or disclosure by any other person is strictly prohibited. If you have received this transmission in error, please notify the sender via e-mail.
RE: JNDI/LDAP realm
The downside to binding with the supplied credentials is that it chews up a file descriptor. For light loads, it's not an issue. For heavy loads, it can be a big issue. If the app server binds administratively, you can get by with two connections, one for reading and one for writing. Or even one, if you're not replicating LDAP. All in all, making it configurable is probably a good idea. -Original Message- From: Ellen Lockhart [mailto:[EMAIL PROTECTED]] Sent: Sunday, May 13, 2001 12:58 PM To: [EMAIL PROTECTED] Subject: Re: JNDI/LDAP realm I preferred binding to the directory with supplied credentials because it allows the realm implementation to use an anonymous password for the rest of what it needs. To allow for DN's in the directory that may not be composed of the same attributes as other DN's, one thing I was thinking about doing to the one I submitted was to configure what the login attribute is (cn, uid, etc.) and search for it (with anonymous login) to get the dn, then bind to the directory with the resultant DN and the user-entered password to authenticate. This might be a little less efficient than just searching and getting the password as well, but is more secure than having the root password to the ldap server where it might be accessible by someone. - Original Message - From: John Holman [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Sunday, May 13, 2001 5:02 AM Subject: JNDI/LDAP realm The current JNDI realm implementation in Tomcat 4 is based on code I submitted, which was subsequently modified and committed by Craig. Two significant changes he made are: - the original code found the DN of the user by searching the directory. The current implementation, like Ellen Lockhart's recent submission, determines the DN by substituting the username into a string. - the original code supported a mode in which the user is authenticated by binding to the directory with the supplied credentials (as does Ellen's). The code for this was removed, with a comment in the commit log that this mode should be supported probably in a separate implementation class. I did comment on this in an earlier message, but got no response - so I'm trying again now there is another little wave of interest :) Determining the DN. The pattern substitution method in the current implementation is obviously more efficient when applicable but the search method is more general. For example, unlike the current implementation, search can handle the following common use cases: - users are stored within multiple nodes in the directory (e.g. they may be held under different organisational units) - the attribute used in distinguished names is not the same as that the user enters into the basic authentication dialog box (e.g. the user might enter mail address as the username rather than uid; the directory might use commonName as a component of distinguished names rather than uid). So there are really two orthogonal issues for user authentication each with two options: - how the dn for the user is determined (configuration template vs directory search) - how authentication is done (system login vs binding as the user) I think it's important that Tomcat supports the missing combinations of options. In fact, the most common strategy when using a directory for authentication is probably search then bind, neither component of which is supported by the current implementation. For example, this is the strategy taken by pam_ldap and by the auth_ldap Apache module. I'd be happy to have a go at adding the missing functionality, but would like some feedback first as to whether people think this is a good idea. Also opinions as to whether we should have one, two or even four classes to implement the different combinations (with multiple classes maybe derived from a base JNDIRealm class). We should take into account which variation is likely to lead to the simplest and clearest configuration documentation ... John. This electronic mail transmission may contain confidential information and is intended only for the person(s) named. Any use, copying or disclosure by any other person is strictly prohibited. If you have received this transmission in error, please notify the sender via e-mail.
RE: Trying New Connectors Build Stuff
Cygwin can add significant overhead in it's emulation layer. If you can do it with gcc -mno-cygwin, that might be a reasonable compromise. -Original Message- From: Pier P. Fumagalli [mailto:[EMAIL PROTECTED]] Sent: Sunday, May 13, 2001 2:01 PM To: [EMAIL PROTECTED] Subject: Re: Trying New Connectors Build Stuff kevin seguin at [EMAIL PROTECTED] wrote: Hmm... Ok, but AFAIK apxs exists also in Apache 2.0, which is the module I'm writing right now... so... iis is next, right ;-) Yes, IIS is next, I just need to install Win2K on my only Intel box I have. It's a very old Pentium 366 and I hope I'll be able to get it working with MSVC or CygWin (BTW, which one do you prefer, guys?) Pier This electronic mail transmission may contain confidential information and is intended only for the person(s) named. Any use, copying or disclosure by any other person is strictly prohibited. If you have received this transmission in error, please notify the sender via e-mail.
[PATCH] bugs 412 and 112 for TC3.3
112 is really simple. Just a check if the TOMCAT_HOME should be '..' after checking for '.' 412 is almost as straightforward. It's a bug in JspC, where CommandLineContext is handed a URI with '\' s in the jspFile. Defensively, I've added a replace in CommandLineContext's constructor. Alternatively, it could be done by the caller. Arguably, it would make more sense in the caller, as a URI should never have a separator other than '/'. In the course of these, I had to deal with a couple other regressions in JspC. Firstly, it won't run, out of the box. JspC doesn't set up any classloaders, and hence does not know about any of the jars other than the boostrap ones. Adding the classloaders to JspC is a bunch of work, so I just added a CLASSPATH for the JSPC target in tomcat.bat. I also added setlocal at the top of the batch file, to keep the environment variables from leaking out when the script crashed. Also an endlocal so that tomcat env would still work. JspC also wasn't logging anything. I added some code to set up the JASPER_LOG logger. This electronic mail transmission may contain confidential information and is intended only for the person(s) named. Any use, copying or disclosure by any other person is strictly prohibited. If you have received this transmission in error, please notify the sender via e-mail. bug412.patch
RE: Jasper34: diffs between 1.1 and 1.2
The only downside I see is that the security manager triggers the use of URLClassloader on a per JSP page basis. As I understand it, this class is broken w.r.t. Java 1.1. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Friday, April 27, 2001 7:12 PM To: [EMAIL PROTECTED] Subject: Jasper34: diffs between 1.1 and 1.2 Hi, There are few diffs between the runtime for 1.1 and 1.2. Some of them are obviously due to API changes ( additions mostly, only one change that I could identify - JspInclude ). Most are due to changes/fixes that went only in one branch ( various optimizations for 3.3, security manager for 4.0 ). We'll need to sync ( not very urgent ). There are few issues: - various optimizations - that's easy, but we need to take care in 1.2 as some objects are created and need pooling ( Note: the runtime is critical for performance - as oposed with the generator. Need to keep garbage close to 0 ) - It would be possible ( given the small diffs ) to use a single codebase, the 1.2, and compile using jsp1.1 to generate a 1.1 runtime. The extra methods will be ignored. The big problem is the change in jsp:include default. One simple way is to use a flag. That would be the best solution for maintainance ( that may not work for a jsp1.3, but for what we have right now the changes are finite and small). What do you think ? Costin This electronic mail transmission may contain confidential information and is intended only for the person(s) named. Any use, copying or disclosure by any other person is strictly prohibited. If you have received this transmission in error, please notify the sender via e-mail.
RE: Jasper34: sandboxing/Priviledged
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Friday, April 27, 2001 8:37 PM To: [EMAIL PROTECTED] Subject: Jasper34: sandboxing/Priviledged snip The other concern is that in one use case for jasper34 it may create problems. We would like JspC-generated pages to work in any Read for 'We would like', 'The JSP Specification requires'. g There's an unfortunate use of the word 'may' in the spec around this point, but it looks to me as though the intent is that the developer 'may', the implementation 'SHALL'. container - that means the runtime and generated code must be included in the WAR ( since not all containers are using jasper - yet ). In that case the runtime will run without priviledges ( well, in general it's better to keep the permissions low ). Costin This electronic mail transmission may contain confidential information and is intended only for the person(s) named. Any use, copying or disclosure by any other person is strictly prohibited. If you have received this transmission in error, please notify the sender via e-mail.
RE: [GUMP] Build Failure - Tomcat 3.x
Index: ErrorHandler.java
===
RCS file:
/home/cvspublic/jakarta-tomcat/src/share/org/apache/tomcat/modules/generator
s/ErrorHandler.java,v
retrieving revision 1.10
diff -u -r1.10 ErrorHandler.java
--- ErrorHandler.java 2001/04/23 01:21:58 1.10
+++ ErrorHandler.java 2001/04/24 14:40:58
@@ -173,7 +173,9 @@
errorServlet=getHandlerForPath( cm, ctx, errorPath );
String cpath=ctx.getPath();
- if( cpath=/) cpath=;
+if( cpath.equals(/) ) {
+cpath=;
+}
// Make sure Jsps will work - needed if the error page is a jsp
if ( null!=errorPath errorPath.startsWith(/) ) {
@@ -290,7 +292,9 @@
errorServlet=getHandlerForPath( cm, ctx, errorPath );
String cpath=ctx.getPath();
- if( cpath=/) cpath=;
+if( cpath.equals(/) ) {
+cpath=;
+}
// Make sure Jsps will work - needed if the error page is a jsp
if ( null!=errorPath errorPath.startsWith(/) ) {
-Original Message-
From: Craig McClanahan [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, April 24, 2001 8:45 AM
To: [EMAIL PROTECTED]
Subject: [GUMP] Build Failure - Tomcat 3.x
This email is autogenerated from the output from:
http://jakarta.apache.org/builds/gump/2001-04-24/jakarta-tomcat.html
Buildfile: build.xml
detect:
msg.jdk12:
[echo] Detected JDK1.2
msg.jsse:
[echo] Detected JSSE
init:
prepare:
[mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat/build/tomcat
[mkdir] Created dir:
/home/rubys/jakarta/jakarta-tomcat/build/tomcat/classes
[mkdir] Created dir:
/home/rubys/jakarta/jakarta-tomcat/build/tomcat/conf
[mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat/build/tomcat/src
[mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat/build/tomcat/lib
[mkdir] Created dir:
/home/rubys/jakarta/jakarta-tomcat/build/tomcat/lib/apps
[mkdir] Created dir:
/home/rubys/jakarta/jakarta-tomcat/build/tomcat/lib/container
[mkdir] Created dir:
/home/rubys/jakarta/jakarta-tomcat/build/tomcat/lib/common
[mkdir] Created dir:
/home/rubys/jakarta/jakarta-tomcat/build/tomcat/logs
[mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat/build/tomcat/bin
[mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat/build/tomcat/doc
[mkdir] Created dir:
/home/rubys/jakarta/jakarta-tomcat/build/tomcat/webapps
[mkdir] Created dir:
/home/rubys/jakarta/jakarta-tomcat/build/tomcat/native
[copy] Copying 10 files to
/home/rubys/jakarta/jakarta-tomcat/build/tomcat/bin
[copy] Copying 19 files to
/home/rubys/jakarta/jakarta-tomcat/build/tomcat/conf
[copy] Copying 42 files to
/home/rubys/jakarta/jakarta-tomcat/build/tomcat/doc
[copy] Copying 89 files to
/home/rubys/jakarta/jakarta-tomcat/build/tomcat/native
[copy] Copying 1 file to
/home/rubys/jakarta/jakarta-tomcat/build/tomcat
[copy] Copying 7 files to
/home/rubys/jakarta/jakarta-tomcat/build/tomcat/bin
[copy] Could not find file
/home/rubys/jakarta/jakarta-ant/dist/lib/jaxp.jar to copy.
[copy] Could not find file
/home/rubys/jakarta/jakarta-ant/dist/lib/parser.jar to copy.
[copy] Copying 1 file to
/home/rubys/jakarta/jakarta-tomcat/build/tomcat/lib/container
[copy] Copying 1 file to
/home/rubys/jakarta/jakarta-tomcat/build/tomcat/lib/container
[copy] Copying 1 file to
/home/rubys/jakarta/jakarta-tomcat/build/tomcat/lib/container
[copy] Copying 1 file to
/home/rubys/jakarta/jakarta-tomcat/build/tomcat/lib/apps
[copy] Copying 1 file to
/home/rubys/jakarta/jakarta-tomcat/build/tomcat/lib/common
[copy] Copying 1 file to
/home/rubys/jakarta/jakarta-tomcat/build/tomcat/lib/common
tomcat_util:
[javac] Compiling 83 source files to
/home/rubys/jakarta/jakarta-tomcat/build/tomcat/classes
[javac] Note: Some input files use or override a deprecated API.
[javac] Note: Recompile with -deprecation for details.
[jar] Building jar:
/home/rubys/jakarta/jakarta-tomcat/build/tomcat/lib/common/core_util.jar
[jar] Building jar:
/home/rubys/jakarta/jakarta-tomcat/build/tomcat/lib/container/tomcat_util.ja
r
tomcat.jar:
[javac] Compiling 1 source file to
/home/rubys/jakarta/jakarta-tomcat/build/tomcat/classes
[jar] Building jar:
/home/rubys/jakarta/jakarta-tomcat/build/tomcat/lib/tomcat.jar
stop-tomcat.jar:
[javac] Compiling 1 source file to
/home/rubys/jakarta/jakarta-tomcat/build/tomcat/classes
[copy] Copying 4 files to
/home/rubys/jakarta/jakarta-tomcat/build/tomcat/classes/org/apache/tomcat/re
sources
[jar] Building jar:
/home/rubys/jakarta/jakarta-tomcat/build/tomcat/lib/stop-tomcat.jar
tomcat_core:
[javac] Compiling 10 source files to
/home/rubys/jakarta/jakarta-tomcat/build/tomcat/classes
[jar] Building
RE: [jetty-discuss] Re: Jasper JSP maintainer required for Jetty project.
-Original Message- From: Mel Martinez [mailto:[EMAIL PROTECTED]] Sent: Tuesday, April 10, 2001 2:56 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: [jetty-discuss] Re: Jasper JSP maintainer required for Jetty project. other servlet engines. Further, it is not clear that the JspC implementation of Jasper even NEEDS web.xml information. Thus, it is clear that another useful Taglib map in web.xml is why JspC needs web.xml. Otherwise the compiler can't find the java classes that implement the tag. Now, you don't need that for JSP-Java, but remember that step is an implementation detail. It's actually JSP-class. I'd like to be able to use JspC as part of a web application packaging tool, and for that, it should be able to generate classes, not just java source. This electronic mail transmission may contain confidential information and is intended only for the person(s) named. Any use, copying or disclosure by any other person is strictly prohibited. If you have received this transmission in error, please notify the sender via e-mail.
RE: TC3.3 Proposal: Refactoring org.apache.jasper.servlet
It's one of the alternate names for Abstract Factory, from the GoF book. AKA toolkit. The idea is that you have a an abstract class with methods such as createThing1 and createThing2, which return abstract Thing1s and Thing2s. A concrete implementation of the factory, xFactory, returns an xThing1 and an xThing2, and a yFactory returns yThing1 and yThing2. A classic example is GUI widgets, where you might have MotifButton, MotifScrollbar, MotifWindow, ..., or Win32Button, Win32Scrollbar, Win32Window, ..., or GtkButton, GtkScrollbar, GtkWindow, ... Here we have CommandLineMangler, CommmandLineContext, CommandLineCompiler, and JspMangler, JspEngineContext, JspCompiler, ... They don't seem to be pure mix and match. That is, it doesn't necessarily make sense to use an XCompiler with an XContext, although it might. So the overhead of having to create a new Factory implementation for a new combination or style isn't that excessive. -Original Message- From: Alex Fernndez [mailto:[EMAIL PROTECTED]] Sent: Friday, March 30, 2001 2:49 AM To: [EMAIL PROTECTED] Subject: Re: TC3.3 Proposal: Refactoring org.apache.jasper.servlet Hi Steve! Steve Downey wrote: Perhaps a Kit pattern is in order? Wow, a Kit pattern. I never heard of that one (or never got that far in the Patterns books :) Is it a standard one? If so, I'll check it out later at home. Un saludo, Alex. This electronic mail transmission may contain confidential information and is intended only for the person(s) named. Any use, copying or disclosure by any other person is strictly prohibited. If you have received this transmission in error, please notify the sender via e-mail.
RE: TC3.3 Proposal: Refactoring org.apache.jasper.servlet
-Original Message- From: Mel Martinez [mailto:[EMAIL PROTECTED]] Sent: Wednesday, March 28, 2001 6:41 PM To: [EMAIL PROTECTED] Subject: RE: TC3.3 Proposal: Refactoring org.apache.jasper.servlet Wow! I go away for a day and there is some great discussion on this thread! I've saved everybody's comments and will incorporate them into the proposal, which I will be working on tonight to formalize. When I've got it ready for review, I will put a proposal doc and any related files in html form into .../jakarta-tomcat/proposals/tomcat33/ doing some static analysis, based on class use of other classes, it looks like this constellation of classes could easily be factored out into their own package: org.apache.jasper.compiler.Compiler org.apache.jasper.compiler.Mangler org.apache.jasper.compiler.CommandLineCompiler org.apache.jasper.compiler.JspCompiler org.apache.jasper.compiler.JavaCompiler org.apache.jasper.compiler.JikesJavaCompiler org.apache.jasper.compiler.SunJavaCompiler org.apache.jasper.compiler.JspCompilationContext org.apache.jasper.JspEngineContext org.apache.jasper.CommandLineContext org.apache.jasper.JasperEngineContext Based on actual use, it looks to me like Mangler and Compiler should be merged. There are no instances of Compiler that do not implement the Mangler interface. The classes that implement JspCompilationContext look to me like they don't all belong in the same package, unless everything here is in the same package. They are interface classes between the Jasper compiler and the outside invoker of the compiler. Here are the classes I'm talking about http://www.panix.com/~sdowney/compilers.gif and the entire compiler package http://www.panix.com/~sdowney/org.apache.jasper.compiler.gif (courtesy Together J) This electronic mail transmission may contain confidential information and is intended only for the person(s) named. Any use, copying or disclosure by any other person is strictly prohibited. If you have received this transmission in error, please notify the sender via e-mail.
RE: TC3.3 Proposal: Refactoring org.apache.jasper.servlet
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Thursday, March 29, 2001 3:04 PM To: [EMAIL PROTECTED] Subject: RE: TC3.3 Proposal: Refactoring org.apache.jasper.servlet On Thu, 29 Mar 2001, Mel Martinez wrote: activities that should be orthogonal. The only dependency should be that the Compiler is a consumer of the products of the Mangler. +1 If we treat the embedded implementation of Mangler as a separate class, which I think is a good idea, each style of JSP compilation works with a triad of somewhat dependant classes. An X-Compiler, an X-Context and an X-Mangler. If we're playing games with the name of the generated class, like decorating it with a version number, then some other part of the system needs to understand the Mangling scheme as well. ClassName does some of this work now, finding out what the 'real' name of the class is. Perhaps a Kit pattern is in order? Refactoring Mangler is highly desireable from my day job point of view, too, since the current mangling scheme can cause problems on Windows. Although we might be able to move to Linux for developers desktops soon. [BTW, I have to thank you for the performance work on Tomcat 3.3. We're starting a new strategic cycle, and evaluating what platforms and technologies to persue in the next 12 months. We were preparing arguments about the value access to source of open software, the recruiting value of working with 'cool' technology, career development, and so forth. But just to be thorough, I took our worst behaved JSP page, which happens to be our home page, and benchmarked it under several engines. TC33 blew the doors off the competition, up to levels of 177 concurrent connections, at which point the benchmark tool starting melting down.] I think the problem starts with the idea to make a JspLoader that 'loads JSP files just as if they were JspLoader is a special thing - it's a great idea ( well, the new model used by JspInterceptor does the same thing in a much cleaner way ). But in any case, should be independent of everything else - just a component that may be used by the "container adapter" classes. Costin DIP, the dependencies should be on interfaces, not on classes. -SMD -- Someone else added this stuff g: This electronic mail transmission may contain confidential information and is intended only for the person(s) named. Any use, copying or disclosure by any other person is strictly prohibited. If you have received this transmission in error, please notify the sender via e-mail.
RE: TC3.3 Proposal: Refactoring org.apache.jasper.servlet
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] So far jasper has been one of the most stable pieces on tomcat ( most bugs I know about are related with the interfacing between jasper and the container ). And it has a huge potential for performance improvement - if we do the right refactoring and provide the right internal APIs. Costin The second most common cause of bugs in Jasper is confusion over when to use File.separator and when to use '/'. It's hard to keep track of, since Jasper does deal with both files and URIs. And the File methods are used to regularize some URIs. Another reason to refactor. This electronic mail transmission may contain confidential information and is intended only for the person(s) named. Any use, copying or disclosure by any other person is strictly prohibited. If you have received this transmission in error, please notify the sender via e-mail.
RE: TC3.3 Proposal: Refactoring org.apache.jasper.servlet
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Wednesday, March 28, 2001 3:46 PM To: [EMAIL PROTECTED] Subject: RE: TC3.3 Proposal: Refactoring org.apache.jasper.servlet On Wed, 28 Mar 2001, Steve Downey wrote: The second most common cause of bugs in Jasper is confusion over when to use File.separator and when to use '/'. It's hard to keep track of, since Jasper does deal with both files and URIs. And the File methods are used to regularize some URIs. Another reason to refactor. I would say this is also part of interfacing the jasper with the container, and not core to the jsp parser and jsp-java convertor ( which in my opinion represents the "core" of jasper ). There is the problem of importing jsps ( and few other cases where files are needed), but again that's related with the API that is needed to plug jasper into a ( cooperating ) container. SNIP ... importing jsp text, determining the file to write java to, finding tag library descriptors, finding the directory to direct the java compiler to write class files to... Files are inherent, at least as long as javac insists on having files. I would love to be able to compile a stream, or array of streams, but that's not happening near term. Almost everything else uses URI's to refer to things. So, for the most part, jasper should not be looking at, or using, files. Streams, yes, as in getResourceAsStream, but mostly not Files. Most current uses of File are wrong, and other parts of Jasper try to compensate. Actually, I don't think that importing needs Files. It should be able to use getResourceAsStream. That may need to work with Files, but that's something that the container deals with, not Jasper. This electronic mail transmission may contain confidential information and is intended only for the person(s) named. Any use, copying or disclosure by any other person is strictly prohibited. If you have received this transmission in error, please notify the sender via e-mail.
RE: TC3.3 Proposal: Refactoring org.apache.jasper.servlet
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Monday, March 26, 2001 1:08 PM To: [EMAIL PROTECTED] Subject: Re: TC3.3 Proposal: Refactoring org.apache.jasper.servlet Hi Mel, In my view, jasper is composed from at least 5 big components: 1. The jsp-java translator. 2. The java-class compiler 3. The Mangler ( managing name mappings ) 4. Runtime - that should be completely independent of all other pieces, since jasper-generated servlets should run without jasper ( as simple servlets ) 5. Interface with the serlvet container ( JspServlet, JspInterceptor and the associated classes). ( putting all other components togheter ) Layer 5 has to include the JspC/CommandLineXXX components, also. They have to provide an environment that looks to the rest of the JSP compiler like a web context, while actually interacting more closely with the filesystem. Mangler needs some work, too. JspC and JspServlet have drifted in their implementations. The bane of code sharing by cut and paste. This electronic mail transmission may contain confidential information and is intended only for the person(s) named. Any use, copying or disclosure by any other person is strictly prohibited. If you have received this transmission in error, please notify the sender via e-mail.
[tc33][PATCH]JspC only produces java files ...
Quite obviously by
design.
However, I would
find it convenient to have it do the compilation to class files as well. As
would some of the some of the HTML techs I work with. We could at least sort out
when they've done something that breaks the java with one less step. [Yes, we've
got a task to get raw java out of the jsp, but it's there
now]
JspC also knows the
correct classpath, and even emits the compiler command that it would use, if
javac was set. At least it does once TC33's JspC logging problem is
fixed.
Index:
CommandLineContext.java===RCS
file:
/home/cvspublic/jakarta-tomcat/src/share/org/apache/jasper/CommandLineContext.java,vretrieving
revision 1.7diff -u -w -r1.7 CommandLineContext.java---
CommandLineContext.java2001/01/07 19:24:121.7+++
CommandLineContext.java2001/03/22 19:04:34@@ -68,6 +68,9
@@import org.apache.jasper.compiler.TagLibraries;import
org.apache.jasper.compiler.CommandLineCompiler;import
org.apache.jasper.compiler.Compiler;+import
org.apache.jasper.compiler.SunJavaCompiler;+import
org.apache.jasper.compiler.JavaCompiler;+import
org.apache.tomcat.util.log.*;//import
org.apache.jasper.runtime.JspLoader;// Use the jasper loader - the
only function used is to add a jar@@ -318,7 +321,30
@@ * compilers that are created.
*/ public
Compiler createCompiler() throws JasperException
{- return new
CommandLineCompiler(this);+String compilerPath =
options.getJspCompilerPath();+Class jspCompilerPlugin =
options.getJspCompilerPlugin();+
JavaCompiler javac;++if (jspCompilerPlugin != null)
{+ try
{+
javac = (JavaCompiler)
jspCompilerPlugin.newInstance();+
} catch (Exception ex)
{+Constants.message("jsp.warning.compiler.class.cantcreate",+
new Object[] { jspCompilerPlugin, ex }, +
Log.FATAL);+
javac = new SunJavaCompiler();+ }+} else
{+ javac =
new
SunJavaCompiler();+}++
if (compilerPath !=
null)+
javac.setCompilerPath(compilerPath);++
Compiler jspCompiler = new
CommandLineCompiler(this);+jspCompiler.setJavaCompiler(javac);+
+ return
jspCompiler; }Index:
JspC.java===RCS
file:
/home/cvspublic/jakarta-tomcat/src/share/org/apache/jasper/JspC.java,vretrieving
revision 1.21diff -u -w -r1.21 JspC.java--- JspC.java2001/03/02
04:51:251.21+++ JspC.java2001/03/22 19:04:34@@ -69,6 +69,7
@@import org.apache.jasper.compiler.TagLibraries;import
org.apache.jasper.compiler.Compiler;import
org.apache.jasper.compiler.CommandLineCompiler;+import
org.apache.jasper.compiler.Mangler;//import
org.apache.jasper.runtime.JspLoader;import
org.apache.jasper.servlet.JasperLoader;@@ -324,6 +325,11
@@// QueueLogger ql = new QueueLogger();//
ql.setVerbosityLevel(verbosityLevel);+
LogManager lm = new LogManager();+
LogHandler lh = new LogHandler();+
lh.setLevel(verbosityLevel);+
lm.addChannel("JASPER_LOG", lh);+
Log.setLogManager(lm);
Constants.jasperLog = Log.getLog("JASPER_LOG", this
);//
Constants.jasperLog.setLogger( ql );@@ -372,17 +378,17
@@
}
}
}-
CommandLineCompiler clc = new
CommandLineCompiler(clctxt);+
Compiler compiler = clctxt.createCompiler();
+ Mangler
mangler = (Mangler)
compiler;+
compiler.compile();-
clc.compile();-
targetClassName =
null;
String
thisServletName;-
if (clc.getPackageName() == null)
{-
thisServletName =
clc.getClassName();+
if (mangler.getPackageName() == null)
{+
thisServletName =
mangler.getClassName();
} else
{-
thisServletName =
clc.getPackageName()-
+ '.' +
clc.getClassName();+
thisServletName =
mangler.getPackageName()+
+ '.' +
mangler.getClassName();
} if
(servletout != null)
{
servletout.write("\n\tservlet\n\t\tservlet-name");
<><><><><><><><><><><><><><><><><><><><><>This electronic mail transmission may contain confidential information and is intended only for the person(s) named. Any use, copying or disclosure by any other person is strictly prohibited. If you have received this transmission in error, please notify the sender via e-mail. <><><><><><><><><><><><><><><><><><><><><>
compile-to-class.patch
RE: cvs commit: jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler JspCompiler.java JspReader.java ParserController.java TagLibraryInfoImpl.java
Javac does need to get at the class files in WEB-INF/classes, for any jsp that, say, uses a bean or tag defined in the WAR. It isn't a requirement that the .java files for those classes be accessible. -Original Message- From: Mel Martinez [mailto:[EMAIL PROTECTED]] Sent: Wednesday, March 21, 2001 9:57 AM To: [EMAIL PROTECTED] Subject: Re: cvs commit: jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler JspCompiler.java JspReader.java ParserController.java TagLibraryInfoImpl.java --- [EMAIL PROTECTED] wrote: remm01/03/20 16:08:53 Modified: jasper/src/share/org/apache/jasper/compiler JspCompiler.java JspReader.java ParserController.java TagLibraryInfoImpl.java Log: - Jasper should run from WARs (or any other repository which provides a directory context to access it). - All Watchdog 4 tests pass (servlets, JSP, JSP-XML). - Of course, the classes and JARs are still extracted from the WAR until the compilation technology is updated (javac wants files :(( ). :-) But javac doesn't have any reason to deal with the contents of the WAR directly. JSP 'files' read out of the .war are being converted to .java files stored in the working directory (i.e. /tmp or wherever). Javac just has to deal with the latter files. It should be possible to modify Jasper to work with an unexpanded .war archive. Not necessarily trivial, but definitely possible, in principle, with no need for new javac compilation tech. Cheers, Mel __ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/ This electronic mail transmission may contain confidential information and is intended only for the person(s) named. Any use, copying or disclosure by any other person is strictly prohibited. If you have received this transmission in error, please notify the sender via e-mail.
RE: [PATCH] TC3.3 tomcat.bat doesn't pick up external CLASSPATH
Ah, then you'll be wanting the contrawise patch to tomcat.sh
Index: tomcat.sh
===
RCS file: /home/cvspublic/jakarta-tomcat/src/shell/tomcat.sh,v
retrieving revision 1.21
diff -u -r1.21 tomcat.sh
--- tomcat.sh 2001/03/15 07:33:19 1.21
+++ tomcat.sh 2001/03/19 13:17:21
@@ -99,14 +99,8 @@
MAIN=org.apache.tomcat.startup.Main
export MAIN
-oldCP=$CLASSPATH
unset CLASSPATH
CLASSPATH=${TOMCAT_HOME}/lib/tomcat.jar
-
-if [ "$oldCP" != "" ]; then
-CLASSPATH=${CLASSPATH}:${oldCP}
-fi
-
export CLASSPATH
## Process options
-Original Message-
From: GOMEZ Henri [mailto:[EMAIL PROTECTED]]
Sent: Monday, March 19, 2001 1:43 AM
To: [EMAIL PROTECTED]
Subject: RE: [PATCH] TC3.3 tomcat.bat doesn't pick up
external CLASSPATH
It's a WANTED feature.
With TC 3.3 there is a new classe loader system. Take
a look at change3.3 file included in distro.
A quick fix for your problem is to copy jaxp / crimson jars
in TOMCAT_HOME/lib/common.
Si la fortune vient en dormant, a n'empche pas les
emmerdements de venir
au rveil.
-- Pierre Dac
-Original Message-
From: Steve Downey [mailto:[EMAIL PROTECTED]]
Sent: Sunday, March 18, 2001 11:57 PM
To: [EMAIL PROTECTED] (E-mail)
Subject: [PATCH] TC3.3 tomcat.bat doesn't pick up external CLASSPATH
Tomcat.bat in TC3.3 doesn't include the outer environment's
CLASSPATH. As
far as I can tell, this means it can't get jaxp.jar or crimson.jar.
The patch checks if the old classpath had any contents before
appending it
to the new environment.
This electronic
mail transmission
may contain confidential information and is intended only for
the person(s)
named. Any use, copying or disclosure by any other person is strictly
prohibited. If you have received this transmission in error,
please notify
the sender via e-mail.
This electronic mail transmission
may contain confidential information and is intended only for the person(s)
named. Any use, copying or disclosure by any other person is strictly
prohibited. If you have received this transmission in error, please notify
the sender via e-mail.
RE: [PATCH] TC3.3 tomcat.bat doesn't pick up external CLASSPATH
Sorry, I wasn't clear. tomcat.sh takes the classpath from the launching environment and prepends lib/tomcat.jar to it. My original patch added this functionality to tomcat.bat. However, if it's a desireable feature to start with an empty classpath, and I agree that it is, the tomcat.sh should be fixed so that it sets the classpath to just lib/tomcat.jar. tomcat.sh and tomcat.bat should be functionally equivalent, at least to the extent that the windows shell allows. -Original Message- From: GOMEZ Henri [mailto:[EMAIL PROTECTED]] Sent: Monday, March 19, 2001 8:46 AM To: [EMAIL PROTECTED] Subject: RE: [PATCH] TC3.3 tomcat.bat doesn't pick up external CLASSPATH Ah, then you'll be wanting the contrawise patch to tomcat.sh I'm not sure to understand perfectly what you say but with the new schema loader you start with an empty CLASSPATH. Depending where are located the .jar, you make them available to container (tomcat), webapps or both. Usefull to fix the XML parser conflicts This electronic mail transmission may contain confidential information and is intended only for the person(s) named. Any use, copying or disclosure by any other person is strictly prohibited. If you have received this transmission in error, please notify the sender via e-mail.
RE: Tester results
Yes, it's a recent version, pulled from CVS shortly after you checked in the fix to tester for the changes to the Filter API. I ran all of the tests, using bin/tester.bat, and I have added manager to the list of tomcat roles. I don't see anything that looks odd in the logs. Here's the section from localhost_log 2001-03-18 11:37:02 Session01: init 2001-03-18 11:37:02 Session02: init 2001-03-18 11:37:02 Manager: restart: Reloading web application at '/tester' 2001-03-18 11:37:02 StandardContext[/tester]: Reloading this Context has started 2001-03-18 11:37:02 Jndi02: destroy 2001-03-18 11:37:02 GetParameterMap00: destroy 2001-03-18 11:37:02 Jndi01: destroy 2001-03-18 11:37:02 GetHeaders01: destroy 2001-03-18 11:37:02 SetBufferSize01: destroy 2001-03-18 11:37:02 Include02: destroy 2001-03-18 11:37:02 Include01: destroy 2001-03-18 11:37:02 SetLocale01: destroy 2001-03-18 11:37:02 GetQueryString01: destroy 2001-03-18 11:37:02 GetParameter01: destroy 2001-03-18 11:37:02 Forward01: destroy 2001-03-18 11:37:02 Include02a: destroy 2001-03-18 11:37:02 GetInputStream01: destroy 2001-03-18 11:37:02 Resources04: destroy 2001-03-18 11:37:02 Session02: destroy 2001-03-18 11:37:02 Resources03: destroy 2001-03-18 11:37:02 Authentication02: destroy 2001-03-18 11:37:02 Session01: destroy 2001-03-18 11:37:02 Resources02: destroy 2001-03-18 11:37:02 Reset01: destroy 2001-03-18 11:37:02 Authentication01: destroy 2001-03-18 11:37:02 Resources01: destroy 2001-03-18 11:37:02 Aggregate02: destroy 2001-03-18 11:37:02 Aggregate01: destroy 2001-03-18 11:37:02 Manager[/tester]: Seeding random number generator class java.security.SecureRandom 2001-03-18 11:37:02 Manager[/tester]: Seeding of random number generator has been completed 2001-03-18 11:37:02 StandardContext[/tester]: Reloading this Context is completed 2001-03-18 11:37:02 Session03: init 2001-03-18 11:37:02 Session01: init 2001-03-18 11:37:02 Session02: init 2001-03-18 11:37:02 Manager: restart: Reloading web application at '/tester' 2001-03-18 11:37:02 StandardContext[/tester]: Reloading this Context has started 2001-03-18 11:37:02 Session03: destroy 2001-03-18 11:37:02 Session02: destroy 2001-03-18 11:37:02 Session01: destroy 2001-03-18 11:37:02 Manager[/tester]: Seeding random number generator class java.security.SecureRandom 2001-03-18 11:37:02 Manager[/tester]: Seeding of random number generator has been completed 2001-03-18 11:37:02 StandardContext[/tester]: Reloading this Context is completed 2001-03-18 11:37:02 Session03: init and from localhost_access_log 127.0.0.1 - - [18/Mar/2001:11:37:01 -0500] "GET /tester/Session01 HTTP/1.1" 200 29 127.0.0.1 - - [18/Mar/2001:11:37:01 -0500] "GET /tester/Session02 HTTP/1.1" 200 29 127.0.0.1 - tomcat [18/Mar/2001:11:37:01 -0500] "GET /manager/reload HTTP/1.1" 200 67 127.0.0.1 - - [18/Mar/2001:11:37:01 -0500] "GET /tester/Session03 HTTP/1.1" 200 84 127.0.0.1 - - [18/Mar/2001:11:37:01 -0500] "GET /tester/WrappedSession01 HTTP/1.1" 200 320 127.0.0.1 - - [18/Mar/2001:11:37:01 -0500] "GET /tester/WrappedSession02 HTTP/1.1" 200 262 127.0.0.1 - tomcat [18/Mar/2001:11:37:02 -0500] "GET /manager/reload HTTP/1.1" 200 67 127.0.0.1 - - [18/Mar/2001:11:37:02 -0500] "GET /tester/WrappedSession03 HTTP/1.1" 200 385 -SMD -Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] Sent: Saturday, March 17, 2001 11:18 PM To: [EMAIL PROTECTED] (E-mail) Subject: Re: Tester results On Sat, 17 Mar 2001, Steve Downey wrote: On Windows 2000 I'm getting failures on tester: FAIL [GET /examples/..] java.io.FileNotFoundException: http://localhost:8080/examples/ http://localhost:8080/examples/ .. This is a Tomcat 4.0 bug (Windows-specific). It works (at least for me) on Linux. FAIL [GET /tester/Session03] Expected data 'Session03 PASSED', got data 'Session03 FAILED - No existing session 43687632F49215A2A42615B6D472' FAIL [GET /tester/WrappedSession03] Expected data 'Session03 PASSED', got data 'Session03 FAILED - No existing session 11239215B4D7D0D5325638B61272F694' Could you check your log files for me on this one? It runs on both platforms for me. I'm also assuming a couple of other things: * You are running the test suite as a whole, or at least the entire "SessionTest" target -- as opposed to calling the tests individually with a browser. This is required because the previous tests in the target are the ones that set up the session. * You have modified your "conf/tomcat-users.xml" to ensure that user "tomcat" is also in role "manager". Otherwise, the context reloads that the tester tries will not work. * You are running a recent build of Tomcat 4.0. The beta 1 release had some problems with saving and restoring sessions. FAIL [GET /tester/Xerces02] java.io.FileNotFoundException: http://localhost:8080/tester/Xerc
[PATCH] fix JcpC compilation of webapps
The -webapp option for JspC is somewhat broken. The compiler does not put out java files into distinct directories, so each file with the same name will overwrite any other file with the same name,e.g. index.jsp. The servlet classes are also not put into a named package. And, at least under Windows, it has some trouble correlating the base URI of the webapp with the URI paths of the jsp files. There is also a lot of existing hacking to accomodate Windows '\' directory separator character. Classic do/undo/redo accomodation. This is mostly a semantic mistake. The only classes that deal with filesystem paths should have to deal with File.separator. URL's never use anything other than '/' as a separator. [pedantictechnically, a URI could use a '\', but only for some scheme other than http pendantic /] That means that if File.toString() is used, it should be converted immediately with replace(File.separatorChar, '/'). Methods like ctxt.getRealPath should be entitled to assume that what they are being passed is a valid part of an URL. The package name fix in CommandLineContext relies on the fix in JspC. The uribase that JspC assembles, based on searching for the WEB-INF directory, had multiple slashes in the path, eg "/examples//jsp//. That was from this line: tUriBase = "/" + f.getName() + "/" + tUriBase; tUriBase always has a leading '/'. This patch doesn't address the bug that JspC can't find tag library descriptors. I'm looking at that now. <><><><><><><><><><><><><><><><><><><><><>This electronic mail transmission may contain confidential information and is intended only for the person(s) named. Any use, copying or disclosure by any other person is strictly prohibited. If you have received this transmission in error, please notify the sender via e-mail. <><><><><><><><><><><><><><><><><><><><><> jasper-webapp-fix1.patch
[PATCH] TC3.3 tomcat.bat doesn't pick up external CLASSPATH
Tomcat.bat in TC3.3 doesn't include the outer environment's CLASSPATH. As far as I can tell, this means it can't get jaxp.jar or crimson.jar. The patch checks if the old classpath had any contents before appending it to the new environment. <><><><><><><><><><><><><><><><><><><><><>This electronic mail transmission may contain confidential information and is intended only for the person(s) named. Any use, copying or disclosure by any other person is strictly prohibited. If you have received this transmission in error, please notify the sender via e-mail. <><><><><><><><><><><><><><><><><><><><><> tomcat.bat.patch
