Possible BUG in JSP Code Compiler
Hi everyone, I assume there is a BUG in the JSP Code Compiler somewhere, because the following does not work as it should: [...] % // Retrieve user object for this session Object obj = request.getSession().getAttribute(user); // Just make sure, what class we have System.out.println(obj.getClass().toString()); // Check instance, should return true. if (obj instanceof some.User) currentUser = (somepkg.User) obj; else System.out.println(WEIRD! How can that be???); % User is the interface for describing a User and its properties, UserImpl is the actual implementation. obj.getClass().toString() shows, that obj is instance of somepkg.UserImpl, but instanceof returns false. Even if i try obj.instanceof somepkg.UserImpl it fails. Casting throws a ClassCastException. Can anyone verify this behaviour? I am new to this list, so please apologize if this has been reported already. Thanks for any comment on this. Bye, Levent.
[PATCH] - Changes to jsp examples index.html file
the following attachment contains a file with the neccesary patches to the index.html file which will be used to to make the checkbox and the colors example work. the file is in a unix file format. it was produced using the following command.. cvs diff -u index.html patchindex.txt using the cygnus unix environment. so it is in a unix file format. thanx in advance, Hiten Pandya [EMAIL PROTECTED] _ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. Index: index.html === RCS file: /home/cvspublic/jakarta-tomcat-4.0/webapps/examples/jsp/index.html,v retrieving revision 1.1 diff -u -r1.1 index.html --- index.html 2000/08/17 00:58:03 1.1 +++ index.html 2001/07/11 08:38:16 @@ -85,10 +85,8 @@ td WIDTH=30%a href=sessions/crt.htmlimg SRC=../images/code.gif HSPACE=4 BORDER=0 height=24 width=24 align=TOP/aa href=sessions/crt.htmlSource/a/td /tr -tr VALIGN=TOP -tdCheckboxnbsp;/td -td VALIGN=TOP WIDTH=30%a href=/checkbox/check.htmlimg SRC=../images/execute.gif HSPACE=4 BORDER=0 align=TOP/aa href=checkbox/check.htmlExecute/a/td +td VALIGN=TOP WIDTH=30%a href=checkbox/check.htmlimg SRC=../images/execute.gif HSPACE=4 BORDER=0 align=TOP/aa href=checkbox/check.htmlExecute/a/td td WIDTH=30%a href=colors/cresult.htmlimg SRC=../images/code.gif HSPACE=4 BORDER=0 height=24 width=24 align=TOP/aa href=checkbox/cresult.htmlSource/a/td /tr @@ -96,7 +94,7 @@ tr VALIGN=TOP tdColornbsp;/td -td VALIGN=TOP WIDTH=30%a href=/colors/colors.htmlimg SRC=../images/execute.gif HSPACE=4 BORDER=0 align=TOP/aa href=colors/colors.htmlExecute/a/td +td VALIGN=TOP WIDTH=30%a href=colors/colors.htmlimg SRC=../images/execute.gif HSPACE=4 BORDER=0 align=TOP/aa href=colors/colors.htmlExecute/a/td td WIDTH=30%a href=colors/clr.html.htmlimg SRC=../images/code.gif HSPACE=4 BORDER=0 height=24 width=24 align=TOP/aa href=colors/clr.htmlSource/a/td /tr
RE: [DOC] Vote on oustanding doc issues?
Unless and until there's a 3.3 or 4.0 final release, *3.2* is the latest Tomcat release, and deserves to be documented on the web site. Ah, but that's exactly my point. I see two versions of Tomcat docs up there now and I'm like, wtf? Why have the 3.3 docs online then? Now that I've RTFM, I'm enlightened. So what I'm saying is this: once 3.3 is final then we aren't expected to update the 3.2.x docs. The 3.2.x docs become the 3.3 docs after modification - we don't have to maintain a version 3.2.x docs. This is my take on Alex's question of should we maintain separate versions of the doc for older versions? So when 4.1 comes out, do we maintain 4.0 documentation, or does it become 4.1 documentation? My opinion is the latter... - r
unsubscribe tomcat-dev
Please unsubscribe me from mailing list. Thank You
Re: [DOC] TOC - thoughts
Rob S. wrote: There is a WHACK of info in that TOC. Your copyright is well-deserved =) First off, I think we should have an ultra-quick install guide. Until there's an ultra-quick install script, there can't be a ultra-quick install guide. For 3.x at least, there are so many different options, especially when you start plugging in to Apache, that I don't think it's possible. PI.1.1: I agree with the big picture view of things, but from what's there, it almost looks like you're explaining the parts that I as an admin, would expect to see in the installation documentation. Was there something more to this section than a description of Tomcat's internal layout? Not internal, but architectural -- like Apache JVM Tomcat Connector (port 8080) mod_jk -- Connector (port 8007) Web Applications example mylittlewebapp Or whatever... PI.1.2: Agree with comments, remove to appendix. OK, done. PI.2.1: I love pictures! Some nice diagrams in here would go a lllong way. Not sure about the choose OS or install Java sections. I mean, there's catering to the LCD and there's catering to the LCD... These would just be a few sentences, mostly saying how Tomcat is platform-neutral. However, you do need to make sure JAVA_HOME is set (or at least know what it is if the script can't find it) etc. I think a lot of PI.2 is overkill, and some unnecessary, dependant upon the implied length of the sections from the TOC I suppose... I mean one or two sentences to downloading JDK, sure, but more than that? Definitely more suited to a book than good enough docs ;) Right, this doc started life as a book outline for a book I may yet write. I like outlining to great detail... It saves me from having to think too much later. I'll leave it in for now as a placeholder, but I expect it'll remain empty for a while. -- Alex Chaffee mailto:[EMAIL PROTECTED] jGuru - Java News and FAQs http://www.jguru.com/alex/ Creator of Gamelan http://www.gamelan.com/ Founder of Purple Technology http://www.purpletech.com/ Curator of Stinky Art Collective http://www.stinky.com/
Re: [DOC] TOC - thoughts
Christopher Cain wrote: Rob S. wrote: [snip] First off, I think we should have an ultra-quick install guide. If you're like a lot of geeks, you know your stuff. You need to know a quick few steps, a quick 2-3 gotchas, and BAM that's it. I want to make sure the quick-and-dirty impatient install is available to the people who can take advantage of it; admins experienced with other containers, trying Tomcat for the first time perhaps. +1 PI.2.1: I love pictures! Some nice diagrams in here would go a lllong way. Not sure about the choose OS or install Java sections. I mean, there's catering to the LCD and there's catering to the LCD... I haven't yet had a chance to look over the TOC (planning on doing it tonight), but one of the docs I have lying around is a step-by-step on installing java on Linux *specifically* in preparation for a Tomcat build/install. Granted, the README file hits the important stuff, like what needs to be in the CLASSPATH, etc. I was actually thinking of morphing it into a more general (and quick) guide to preping your OS for a Tomcat build/install (I have some Windoze notes lying around as well). I could very quickly touch on Java installation, including a few Linux-specific tips above and beyond the rather obvious actual install, cover the environment varibles that need to be defined for a build, reiterate the jakarta directory structure that needs to be in place, etc. Basically, everything up to the point of the actual build. That would be great, and that's pretty much what the TOC outlines (though not in that detail). The problem with having OS-specific quick-and-dirty install guides is that if one aspect changes, the separate guides get out of sync. I'd suggest you clearly divide the following three parts: - Pre-install - Standalone install - Integrating with Web server Since that's the structure I'm using in the major parts of the Install Guide of the TOC. Well, my thoughts on the aforementioned doc I was planning are to provide a list of the available JDKs for each platform, what else one needs to download for certain optional functionality (SSL, etc.), where to get each of them, and any relevant comments on software selection. Mainly just the huge stuff, like the infamous Sun 1.3.1 JDK for Linux completely broken under the new gcc threading libraries. (That one really pissed me off.) This might fall under the category of too much information as Rob is stating, but my feeling is that it is easy enough to skip over entire sections (assuming they're laid out logically) in a Preping your OS for Tomcat doc, and those users who are planning on building out a new box (or reformatting an existing box) specifically for a web server will appreciate such heads-up info. Getting Tomcat up and running on a barebones OS install is pretty rare for us developers, but it happens quite frequently in the corporate world. The bigger the master Tomcat documentation library, from the essentials to the sublimely tangential steps along the way, the more comfortable corporations will feel about choosing Tomcat over a proprietary solution. As long as someone is willing to write such things, which in this case I am, why not just throw it in the mix for the few people who might benefit from it? Of course, I completely agree that there also needs to be some short-and-sweet versions of how to do install-type things, so maybe an abbreviated version of my Preping doc would also be in order. I like it. Please see how it would fit in with the proposed pre-install / standalone install chapters. -- Alex Chaffee mailto:[EMAIL PROTECTED] jGuru - Java News and FAQs http://www.jguru.com/alex/ Creator of Gamelan http://www.gamelan.com/ Founder of Purple Technology http://www.purpletech.com/ Curator of Stinky Art Collective http://www.stinky.com/
Re: [DOC] Table of Contents
Punky Tse wrote: 3) How about putting all the installation and configuration of Tomcat standalone first, and then followed by some chapters (advanced topics) about Running Tomcat behind web servers? It's already organized that way. See the first paragraph of the editorial notes: I think there should be a chapter or series of chapters on installing Tomcat standalone, that covers *everything* or almost everything start-to-finish. Then we also need separate chapters for installing behind each Web server. Then come chapters on administration and advanced configuration issues. I have a feeling you may have missed the attachment. See the post I just made for the latest one (in much detail). Alex, What I mean is to swap Part II with Part III like below: I. Standalone Installation Guide II. Deploying and Configuring, or Tomcat Administrator's Guide III. Installation Behind a Web Server Guide IV. Performance Tuning Guide V. Tomcat Developer's Guide (writing code for Tomcat itself) I treat Installation Behind a Web Server Guide as advanced topics. For general tomcat users, they should be more interested in configuring Tomcat than in making it running behind web server. Punky I agree with you on the motivation (that behind is an advanced topic), but I don't think that means we should automatically put it behind :-) the admin guide. Instead, someone reading start to finish should be able to get an installation running -- perhaps skipping the Apache part if they need to -- *then* they can play around with administering what they've got. It's a judgement call, and if we make them separate docs, then reordering is trivial. -- Alex Chaffee mailto:[EMAIL PROTECTED] jGuru - Java News and FAQs http://www.jguru.com/alex/ Creator of Gamelan http://www.gamelan.com/ Founder of Purple Technology http://www.purpletech.com/ Curator of Stinky Art Collective http://www.stinky.com/
Re: [DOC] Vote on oustanding doc issues?
Craig R. McClanahan wrote: On Mon, 9 Jul 2001, Alex Chaffee wrote: Bundle the 3.2.x docs with 3.2.x and only have the 3.3 docs online (latest Tomcat release). If you want the 3.2.x docs, get them with the binary or whatever. I certainly don't think we should keep old versions of documentation updated. I mean, why would updated 3.0 or 3.1 docs be useful? Unless and until there's a 3.3 or 4.0 final release, *3.2* is the latest Tomcat release, and deserves to be documented on the web site. OK, but my point is that as we improve the 3.x docs -- regardless of the value of x -- the 3.2 docs will become less relevant. Right now there are many differences between the 3.2 and 3.3 docs, but they're mostly in the connector docs, which AFAIK haven't changed much if at all in operation. This leads me to conclude that the docs in the 3.3 tree are just as valid when applied to 3.2, except that they're better docs, since more people have had a chance to revise them. That's why I'd like to remove the Tomcat 3 docs that happened to be in the depot at the time 3.2 shipped in favor of the latest version of the Tomcat 3 docs (which happen to be in the 3.3 dev tree). Perhaps the easiest way to do this would be with a separate depot. I'm shying away from that for the reasons you (Craig) brought up. It's nice for docs to be in the same depot as the code... There's no reason to banish the current Tomcat released version, or any other version that is being actively developed. And it's quite easy to arrange the user interface so that it's obvious which version you are looking at (for example, including Tomcat X.Y in the header or footer of the pages about that version). Again, apart from 3 vs 4, the difference between versions 3.2 and 3.3 is small, as far as docs are concerned, so announcing Tomcat 3.2 in the header wouldn't be very salient, and would just promote forking of docs. We seem to be in this quandary because the docs have not really been part of the release process -- they get released slapdash relative to the code milestones. By the way, it seems like the majority of the existing documentation is about installation. If there were a clean, robust install script, it would remove 90% of the text on the site. Maybe before we write (rewrite) install docs we should write an install script. I know that was on your todo list for 4 -- how's that coming? -- Alex Chaffee mailto:[EMAIL PROTECTED] jGuru - Java News and FAQs http://www.jguru.com/alex/ Creator of Gamelan http://www.gamelan.com/ Founder of Purple Technology http://www.purpletech.com/ Curator of Stinky Art Collective http://www.stinky.com/
cvs commit: jakarta-tomcat-4.0/tester/web JspParams01.jsp JspParams02.jsp
craigmcc01/07/11 10:35:37 Modified:tester/src/bin tester.xml Added: tester/web JspParams01.jsp JspParams02.jsp Log: Add unit tests to verify that jsp:params is not allowed inside jsp:incluce Revision ChangesPath 1.1 jakarta-tomcat-4.0/tester/web/JspParams01.jsp Index: JspParams01.jsp === jsp:include page=JspParams01a.jsp flush=true jsp:params jsp:param name=foo value=bar/ /jsp:params /jsp:include 1.1 jakarta-tomcat-4.0/tester/web/JspParams02.jsp Index: JspParams02.jsp === jsp:forward page=JspParams01a.jsp jsp:params jsp:param name=foo value=bar/ /jsp:params /jsp:forward
RE: Table of Contents
P.S. What hacker I mean is: The one who read the source code and make change to it so that the whole system get benefit from it. So you are hacker. (but me not yet). The guy who break the system is cracker, or black hacker to be specific. ??? A cracker is a criminal hacker. not someone who broke introduced a bug ;-)
Re: Jasper and parsed tree
On Wed, 11 Jul 2001, John Yu wrote: I'm new to Tomcat/Jasper. I have a question regarding Jasper: Does Jasper parse a JSP into a DOM-like objects. In other words, does Jasper create in-memory parsed tree of the the JSP file? It does not currently do this. Essentially, Jasper today is a bunch of pattern matchers that have associated code generators that are triggered when the patterns are recognized. I notice from Tomcat 4.0's documentation that there's some plan to upgrade Jasper. I'm wondering how that's going and whether the upgrade does anything related to the above area I mentioned. In Tomcat 4.0, the majority of the work was to support the new JSP 1.2 features. The fundamental architecture of Jasper is still pretty much what it was in 3.2. One of the things I'd like to see happen in the 4.x world (and I'm working to acquire some development resources for it) would be a fresh start, looking at JSP page compilation through the eyes of an experienced compiler writer that can leverage all of the tricks optimizing compilers have been using for the last 30 years. There are *lots* of opportunities to generate smaller/faster code, even for the standard JSP 1.2 syntax -- there will be even more opportunities as the JSP Standard Tag Library matures (for example, the page compiler should be able to recognize the JSPTL iteration tag and generate standard Java loop handling code, instead of treating it as a normal custom tag). Thanks in advance. -- John Yu Scioworks Technologies e: [EMAIL PROTECTED]w: +(65) 873 5989 w: http://www.scioworks.com m: +(65) 9782 9610 Craig
Re: Possible BUG in JSP Code Compiler
I do stuff like this all the time (although not with scriptlets :-). The best thing to do would be to create a small, reproducible test case and then submit it (with a bug report) to our bug tracking system: http://nagoya.apache.org/bugzilla/ On Wed, 11 Jul 2001, Levent Gündogdu wrote: Hi everyone, I assume there is a BUG in the JSP Code Compiler somewhere, because the following does not work as it should: Note that any problem that exists is most likely in *your* code, because the compiler just copies scriptlet code through verbatim. Craig
cvs commit: jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler TagEndGenerator.java
horwat 01/07/11 13:17:49
Modified:jasper/src/share/org/apache/jasper/compiler
TagEndGenerator.java
Log:
Changed to a more meaningful and unique variable name.
Bugzilla #2364
Revision ChangesPath
1.8 +2 -2
jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/TagEndGenerator.java
Index: TagEndGenerator.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/TagEndGenerator.java,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- TagEndGenerator.java 2001/07/10 20:32:01 1.7
+++ TagEndGenerator.java 2001/07/11 20:17:42 1.8
@@ -179,9 +179,9 @@
// TryCatchFinally
if (implementsTryCatchFinally) {
- writer.println(} catch (Throwable exception) {);
+ writer.println(} catch (Throwable _jspx_exception) {);
writer.pushIndent();
- writer.println(thVarName+.doCatch(exception););
+ writer.println(thVarName+.doCatch(_jspx_exception););
writer.popIndent();
}
cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets CGIServlet.java
amyroh 01/07/11 14:15:50
Modified:catalina/src/share/org/apache/catalina/servlets
CGIServlet.java
Log:
Fixes the empty content_length problem -- patch submitted by Gene Wadleigh.
Revision ChangesPath
1.2 +26 -15
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/CGIServlet.java
Index: CGIServlet.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/CGIServlet.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- CGIServlet.java 2001/06/01 00:20:19 1.1
+++ CGIServlet.java 2001/07/11 21:15:47 1.2
@@ -1,6 +1,6 @@
/*
- * CGIServlet.java $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/CGIServlet.java,v
1.1 2001/06/01 00:20:19 amyroh Exp $
- * $Revision: 1.1 $, $Date: 2001/06/01 00:20:19 $
+ * CGIServlet.java $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/CGIServlet.java,v
1.2 2001/07/11 21:15:47 amyroh Exp $
+ * $Revision: 1.2 $, $Date: 2001/07/11 21:15:47 $
*
*
*
@@ -281,7 +281,7 @@
*
* @author Martin T Dengler [[EMAIL PROTECTED]]
* @author Amy Roh
- * @version $Revision: 1.1 $, $Date: 2001/06/01 00:20:19 $
+ * @version $Revision: 1.2 $, $Date: 2001/07/11 21:15:47 $
* @since Tomcat 4.0
*
*/
@@ -627,7 +627,7 @@
try {
ServletOutputStream out = res.getOutputStream();
out.println(HTMLHEADTITLE$Name: $/TITLE/HEAD);
- out.println(BODY$Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/CGIServlet.java,v
1.1 2001/06/01 00:20:19 amyroh Exp $p);
+ out.println(BODY$Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/CGIServlet.java,v
1.2 2001/07/11 21:15:47 amyroh Exp $p);
if (cgiEnv.isValid()) {
out.println(cgiEnv.toString());
@@ -669,7 +669,7 @@
/** For future testing use only; does nothing right now */
public static void main(String[] args) {
- System.out.println($Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/CGIServlet.java,v
1.1 2001/06/01 00:20:19 amyroh Exp $);
+ System.out.println($Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/CGIServlet.java,v
1.2 2001/07/11 21:15:47 amyroh Exp $);
}
@@ -685,7 +685,7 @@
* /p
*
* @author Martin Dengler [[EMAIL PROTECTED]]
- * @version $Revision: 1.1 $, $Date: 2001/06/01 00:20:19 $
+ * @version $Revision: 1.2 $, $Date: 2001/07/11 21:15:47 $
* @sinceTomcat 4.0
*
*/
@@ -1083,8 +1083,10 @@
//NOOP per CGI specification section 11.2
} else if(HOST.equalsIgnoreCase(header)) {
String host = req.getHeader(header);
+int idx = host.indexOf(:);
+if(idx 0) idx = host.length();
envp.put(HTTP_ + header.replace('-', '_'),
- host.substring(0, host.indexOf(:)));
+ host.substring(0, idx));
} else {
envp.put(HTTP_ + header.replace('-', '_'),
req.getHeader(header));
@@ -1305,7 +1307,7 @@
* /p
*
* @authorMartin Dengler [[EMAIL PROTECTED]]
- * @version $Revision: 1.1 $, $Date: 2001/06/01 00:20:19 $
+ * @version $Revision: 1.2 $, $Date: 2001/07/11 21:15:47 $
*/
protected class CGIRunner {
@@ -1550,12 +1552,12 @@
}
}
- String postIn = getPostInput(params);
+ /*String postIn = getPostInput(params);
int contentLength = (postIn.length()
+ System.getProperty(line.separator).length());
if (POST.equals(env.get(REQUEST_METHOD))) {
env.put(CONTENT_LENGTH, new Integer(contentLength));
- }
+ }*/
StringBuffer perlCommand = new StringBuffer(perl );
if (command.endsWith(.pl) || command.endsWith(.cgi)) {
@@ -1571,7 +1573,7 @@
* First -- parameters
* Second -- any remaining input
*/
- commandsStdIn = new BufferedOutputStream(proc.getOutputStream());
+ /*commandsStdIn = new BufferedOutputStream(proc.getOutputStream());
if (debug = 2 ) {
log(runCGI stdin=[ + stdin + ], qs=
+ env.get(QUERY_STRING));
@@ -1590,7 +1592,7 @@
/* assume if nothing is available after a time, that nothing is
* coming...
*/
-
cvs commit: jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/runtime PageContextImpl.java
remm01/07/11 15:51:43
Modified:jasper/src/share/org/apache/jasper/runtime
PageContextImpl.java
Log:
- Fix infinite looping bug when doing an include followed by a forward.
The included attribute is now unset before forwarding, so that the JSP we
forward to doesn't think it's been included.
Bug reported by Eduardo Pelegri-Llopart.
Revision ChangesPath
1.12 +13 -4
jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/runtime/PageContextImpl.java
Index: PageContextImpl.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/runtime/PageContextImpl.java,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -r1.11 -r1.12
--- PageContextImpl.java 2001/07/10 20:20:02 1.11
+++ PageContextImpl.java 2001/07/11 22:51:40 1.12
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/runtime/PageContextImpl.java,v
1.11 2001/07/10 20:20:02 horwat Exp $
- * $Revision: 1.11 $
- * $Date: 2001/07/10 20:20:02 $
+ * $Header:
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/runtime/PageContextImpl.java,v
1.12 2001/07/11 22:51:40 remm Exp $
+ * $Revision: 1.12 $
+ * $Date: 2001/07/11 22:51:40 $
*
*
*
@@ -396,7 +396,16 @@
throws ServletException, IOException
{
String path = getAbsolutePathRelativeToContext(relativeUrlPath);
-context.getRequestDispatcher(path).forward(request, response);
+String includeUri
+= (String) request.getAttribute(Constants.INC_SERVLET_PATH);
+if (includeUri != null)
+request.removeAttribute(Constants.INC_SERVLET_PATH);
+try {
+context.getRequestDispatcher(path).forward(request, response);
+} finally {
+if (includeUri != null)
+request.setAttribute(Constants.INC_SERVLET_PATH, includeUri);
+}
}
Stack writerStack = new Stack();
RE: [DOC] Vote on oustanding doc issues?
I like this compromise. I will propose that we get rid of the 3.2 docs on the site -- once I'm convinced they're similar enough. There's still that old 3.3 is a rogue release sentiment floating around, and people might not appreciate giving 3.3 implied legitimacy by making it the official documentation... Yes, many won't like it at all. The official TC 3.x release is TC 3.2.2. 3.3 is a rewrite but many documentations in TC 3.2/3.3 could (SHOULD) be merged and differences commented Woah, I thought the committers worked that out a long time ago. Well, I don't want to open any cans of worms so AFAIC, the TC3 doc people can do what they want (of course), although I don't think maintaining 2 sets of docs is expected, a good idea, or will even happen =) By sure that 3.3 team will do it's part of the job. If there is difference (architecture, modularity, config) we'll comment it. Just show us how to do that (need some docs to figure how to meet the concensus) Please never forget that's the documentation call and PRE-PROPOSAL came from someone working on 3.3 and who asked to have a separate CVS for doc :)
RE: [DOC] Vote on oustanding doc issues?
OK, but my point is that as we improve the 3.x docs -- regardless of the value of x -- the 3.2 docs will become less relevant. Right now there are many differences between the 3.2 and 3.3 docs, but they're mostly in the connector docs, which AFAIK haven't changed much if at all in operation. This leads me to conclude that the docs in the 3.3 tree are just as valid when applied to 3.2, except that they're better docs, since more people have had a chance to revise them. That's why I'd like to remove the Tomcat 3 docs that happened to be in the depot at the time 3.2 shipped in favor of the latest version of the Tomcat 3 docs (which happen to be in the 3.3 dev tree). Working on J-T-C, I'll be more than happy to adapt : tomcat-ssl-how-to, mod_jk-howto, workers-howto. IIS-howto, domino-howto netscape-howto could be handled by others JTC members. We're working on having a uniq worker file which will help having an uniq workers-howto. And in that case, the old 3.3 doc will be outdated. Perhaps the easiest way to do this would be with a separate depot. I'm shying away from that for the reasons you (Craig) brought up. It's nice for docs to be in the same depot as the code... Having a separate cvs will help having redactors as commiters. And we could still export from the doc CVS, necessary stuff at release time (millenium, beta, release). By the way, it seems like the majority of the existing documentation is about installation. If there were a clean, robust install script, it would remove 90% of the text on the site. Maybe before we write (rewrite) install docs we should write an install script. I know that was on your todo list for 4 -- how's that coming? I would recommand you to mention Redhat RPM which make any users in tomcat, mod_jk in less than 30 seconds :) That's an easy install and why not using something like NullSoft installer to do the same under Windows ?
cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/authenticator Constants.java FormAuthenticator.java
craigmcc01/07/11 16:39:51
Modified:catalina/src/share/org/apache/catalina/authenticator
Constants.java FormAuthenticator.java
Log:
Update form-based login processing to be consitent with the 2.3 PFD2 spec.
In particular, Catalina now uses redirects (instead of internal forwards)
to switch to the original request page, as required in Section 12.5.3,
Step 7. Thanks also to Vincente Salvador for a very helpful analysis of
what was going on, and what the recommended correction should be.
PR: Bugzilla #853
Submitted by: [EMAIL PROTECTED]
Revision ChangesPath
1.3 +5 -3
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/authenticator/Constants.java
Index: Constants.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/authenticator/Constants.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- Constants.java2000/10/06 05:10:16 1.2
+++ Constants.java2001/07/11 23:39:49 1.3
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/authenticator/Constants.java,v
1.2 2000/10/06 05:10:16 craigmcc Exp $
- * $Revision: 1.2 $
- * $Date: 2000/10/06 05:10:16 $
+ * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/authenticator/Constants.java,v
1.3 2001/07/11 23:39:49 craigmcc Exp $
+ * $Revision: 1.3 $
+ * $Date: 2001/07/11 23:39:49 $
*
*
*
@@ -85,6 +85,8 @@
public static final String FORM_KEY =
org.apache.catalina.security.REQUEST;
public static final String FORM_PASSWORD = j_password;
+public static final String FORM_PRINCIPAL =
+org.apache.catalina.security.PRINCIPAL;
public static final String FORM_USERNAME = j_username;
// Cookie name for single sign on support
1.8 +111 -17
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/authenticator/FormAuthenticator.java
Index: FormAuthenticator.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/authenticator/FormAuthenticator.java,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- FormAuthenticator.java2001/03/14 02:17:20 1.7
+++ FormAuthenticator.java2001/07/11 23:39:50 1.8
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/authenticator/FormAuthenticator.java,v
1.7 2001/03/14 02:17:20 craigmcc Exp $
- * $Revision: 1.7 $
- * $Date: 2001/03/14 02:17:20 $
+ * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/authenticator/FormAuthenticator.java,v
1.8 2001/07/11 23:39:50 craigmcc Exp $
+ * $Revision: 1.8 $
+ * $Date: 2001/07/11 23:39:50 $
*
*
*
@@ -88,7 +88,7 @@
* Authentication, as described in the Servlet API Specification, Version 2.2.
*
* @author Craig R. McClanahan
- * @version $Revision: 1.7 $ $Date: 2001/03/14 02:17:20 $
+ * @version $Revision: 1.8 $ $Date: 2001/07/11 23:39:50 $
*/
public final class FormAuthenticator
@@ -139,9 +139,18 @@
LoginConfig config)
throws IOException {
+if (debug 99)
+debug = 99;
+
+// References to objects we will need later
+HttpServletRequest hreq =
+ (HttpServletRequest) request.getRequest();
+HttpServletResponse hres =
+ (HttpServletResponse) response.getResponse();
+Session session = null;
+
// Have we already authenticated someone?
- Principal principal =
- ((HttpServletRequest) request.getRequest()).getUserPrincipal();
+ Principal principal = hreq.getUserPrincipal();
if (principal != null) {
if (debug = 1)
log(Already authenticated ' +
@@ -149,21 +158,38 @@
return (true);
}
+// Is this the re-submit of the original request URI after successful
+// authentication? If so, forward the *original* request instead.
+if (matchRequest(request)) {
+session = getSession(request);
+if (debug = 1)
+log(Restore request from session ' + session.getId() + ');
+principal = (Principal)
+ session.getSession().getAttribute(Constants.FORM_PRINCIPAL);
+register(request, response, principal, Constants.FORM_METHOD);
+if (restoreRequest(request, session)) {
+if (debug = 1)
+log(Proceed to restored
cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/authenticator FormAuthenticator.java
craigmcc01/07/11 17:00:17
Modified:catalina/src/share/org/apache/catalina/authenticator
FormAuthenticator.java
Log:
Remove extraneous debugging output setting.
Revision ChangesPath
1.9 +4 -7
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/authenticator/FormAuthenticator.java
Index: FormAuthenticator.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/authenticator/FormAuthenticator.java,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- FormAuthenticator.java2001/07/11 23:39:50 1.8
+++ FormAuthenticator.java2001/07/12 00:00:16 1.9
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/authenticator/FormAuthenticator.java,v
1.8 2001/07/11 23:39:50 craigmcc Exp $
- * $Revision: 1.8 $
- * $Date: 2001/07/11 23:39:50 $
+ * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/authenticator/FormAuthenticator.java,v
1.9 2001/07/12 00:00:16 craigmcc Exp $
+ * $Revision: 1.9 $
+ * $Date: 2001/07/12 00:00:16 $
*
*
*
@@ -88,7 +88,7 @@
* Authentication, as described in the Servlet API Specification, Version 2.2.
*
* @author Craig R. McClanahan
- * @version $Revision: 1.8 $ $Date: 2001/07/11 23:39:50 $
+ * @version $Revision: 1.9 $ $Date: 2001/07/12 00:00:16 $
*/
public final class FormAuthenticator
@@ -138,9 +138,6 @@
HttpResponse response,
LoginConfig config)
throws IOException {
-
-if (debug 99)
-debug = 99;
// References to objects we will need later
HttpServletRequest hreq =
Re: Table of Contents
P.S. What hacker I mean is: The one who read the source code and make change to it so that the whole system get benefit from it. So you are hacker. (but me not yet). The guy who break the system is cracker, or black hacker to be specific. ??? A cracker is a criminal hacker. not someone who broke introduced a bug ;-) I mean break INTO the system. :-)
cvs commit: jakarta-tomcat-4.0/tester/web/golden Include06.txt Include07.txt
craigmcc01/07/11 19:41:02
Modified:tester/src/bin tester.xml
tester/web/WEB-INF web.xml
Added: tester/src/tester/org/apache/tester Include06a.java
Include07.java Include07a.java Include07b.java
Include07c.java
tester/web Include06.jsp Include06b.jsp
tester/web/golden Include06.txt Include07.txt
Log:
Add unit tests for a more thorough investigation of Bugzilla #2294. The
ultimate problem was actually caused by the use of the invoker servlet on
the first include (which does a RequestDispatcher.forward() the first time a
particular servlet is invoked).
As a result, the /tester/Include06.jsp test will currently fail the first
time you run it after starting Tomcat, but succeed after that. The underlying
cause is under investigation.
Revision ChangesPath
1.56 +10 -0 jakarta-tomcat-4.0/tester/src/bin/tester.xml
Index: tester.xml
===
RCS file: /home/cvs/jakarta-tomcat-4.0/tester/src/bin/tester.xml,v
retrieving revision 1.55
retrieving revision 1.56
diff -u -r1.55 -r1.56
--- tester.xml2001/07/11 21:18:20 1.55
+++ tester.xml2001/07/12 02:40:52 1.56
@@ -713,6 +713,16 @@
request=${context.path}/Include05.jsp
outContent=Include05b PASSED debug=${debug}/
+!-- == Include Then Include == --
+
+tester host=${host} port=${port} protocol=${protocol}
+ request=${context.path}/Include06.jsp debug=${debug}
+ golden=${golden.path}/Include06.txt/
+
+tester host=${host} port=${port} protocol=${protocol}
+ request=${context.path}/Include07 debug=${debug}
+ golden=${golden.path}/Include07.txt/
+
/target
1.1
jakarta-tomcat-4.0/tester/src/tester/org/apache/tester/Include06a.java
Index: Include06a.java
===
/* = *
* *
* The Apache Software License, Version 1.1 *
* *
* Copyright (c) 1999, 2000, 2001 The Apache Software Foundation. *
* All rights reserved.*
* *
* = *
* *
* Redistribution and use in source and binary forms, with or without modi- *
* fication, are permitted provided that the following conditions are met: *
* *
* 1. Redistributions of source code must retain the above copyright notice *
*notice, this list of conditions and the following disclaimer. *
* *
* 2. Redistributions in binary form must reproduce the above copyright *
*notice, this list of conditions and the following disclaimer in the *
*documentation and/or other materials provided with the distribution. *
* *
* 3. The end-user documentation included with the redistribution, if any, *
*must include the following acknowlegement: *
* *
* This product includes software developed by the Apache Software *
*Foundation http://www.apache.org/. *
* *
*Alternately, this acknowlegement may appear in the software itself, if *
*and wherever such third-party acknowlegements normally appear. *
* *
* 4. The names The Jakarta Project, Tomcat, and Apache Software *
*Foundation must not be used to endorse or promote products derived *
*from this software without prior written permission. For written *
*permission, please contact [EMAIL PROTECTED].*
* *
* 5. Products derived from this software may not be called Apache nor may *
*Apache appear in their names without prior written permission of the *
*Apache Software Foundation.
cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core ApplicationDispatcher.java
craigmcc01/07/11 19:42:05
Modified:catalina/src/share/org/apache/catalina/core
ApplicationDispatcher.java
Log:
Log a few exceptional conditions in addition to throwing the exceptions
required by the spec.
Revision ChangesPath
1.18 +15 -6
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/ApplicationDispatcher.java
Index: ApplicationDispatcher.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/ApplicationDispatcher.java,v
retrieving revision 1.17
retrieving revision 1.18
diff -u -r1.17 -r1.18
--- ApplicationDispatcher.java2001/05/23 21:53:01 1.17
+++ ApplicationDispatcher.java2001/07/12 02:42:02 1.18
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/ApplicationDispatcher.java,v
1.17 2001/05/23 21:53:01 craigmcc Exp $
- * $Revision: 1.17 $
- * $Date: 2001/05/23 21:53:01 $
+ * $Header:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/ApplicationDispatcher.java,v
1.18 2001/07/12 02:42:02 craigmcc Exp $
+ * $Revision: 1.18 $
+ * $Date: 2001/07/12 02:42:02 $
*
*
*
@@ -98,7 +98,7 @@
* codejavax.servlet.ServletResponseWrapper/code.
*
* @author Craig R. McClanahan
- * @version $Revision: 1.17 $ $Date: 2001/05/23 21:53:01 $
+ * @version $Revision: 1.18 $ $Date: 2001/07/12 02:42:02 $
*/
final class ApplicationDispatcher
@@ -297,10 +297,19 @@
throws ServletException, IOException
{
// Reset any output that has been buffered, but keep headers/cookies
- if (response.isCommitted())
+if (response.isCommitted()) {
+if (debug = 1)
+log( Forward on committed response -- ISE);
throw new IllegalStateException
(sm.getString(applicationDispatcher.forward.ise));
-response.resetBuffer();
+}
+try {
+response.resetBuffer();
+} catch (IllegalStateException e) {
+if (debug = 1)
+log( Forward resetBuffer() returned ISE: + e);
+throw e;
+}
// Identify the HTTP-specific request and response objects (if any)
HttpServletRequest hrequest = null;
Re: Jasper and parsed tree
Thanks for the explanation, Craig. JCCSP is JavaCC grammar based. (See http://home.earthlink.net/~shemnon/ ) Would there be any opportunity to merge this into Jasper? (While it's currently GPL, Donno has no problem to place it under BSD.) regards, -- John On Wed, 11 Jul 2001, John Yu wrote: I'm new to Tomcat/Jasper. I have a question regarding Jasper: Does Jasper parse a JSP into a DOM-like objects. In other words, does Jasper create in-memory parsed tree of the the JSP file? It does not currently do this. Essentially, Jasper today is a bunch of pattern matchers that have associated code generators that are triggered when the patterns are recognized. I notice from Tomcat 4.0's documentation that there's some plan to upgrade Jasper. I'm wondering how that's going and whether the upgrade does anything related to the above area I mentioned. In Tomcat 4.0, the majority of the work was to support the new JSP 1.2 features. The fundamental architecture of Jasper is still pretty much what it was in 3.2. One of the things I'd like to see happen in the 4.x world (and I'm working to acquire some development resources for it) would be a fresh start, looking at JSP page compilation through the eyes of an experienced compiler writer that can leverage all of the tricks optimizing compilers have been using for the last 30 years. There are *lots* of opportunities to generate smaller/faster code, even for the standard JSP 1.2 syntax -- there will be even more opportunities as the JSP Standard Tag Library matures (for example, the page compiler should be able to recognize the JSPTL iteration tag and generate standard Java loop handling code, instead of treating it as a normal custom tag). -- John Yu Scioworks Technologies e: [EMAIL PROTECTED]w: +(65) 873 5989 w: http://www.scioworks.com m: +(65) 9782 9610
