[PATCH] Tag attributes of type char and short bug
Date: Wed, 05 Sep 2001 14:22:21 -0700 (PDT)
From: Kin-Man Chung [EMAIL PROTECTED]
Subject: [PATH] Tag attributes of type char and short bug
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-MD5: NTIF51okQsoUB2BTXXgn/Q==
This patch fixes 3366 and 3381. This fix was provided by the submitter
[EMAIL PROTECTED] This fix looks good.
Index: TagBeginGenerator.java
===
RCS file:
/home/cvspublic/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/T
agBeginGenerator.java,v
retrieving revision 1.14
diff -u -r1.14 TagBeginGenerator.java
--- TagBeginGenerator.java 2001/07/23 19:57:32 1.14
+++ TagBeginGenerator.java 2001/09/05 21:05:28
@@ -260,7 +260,7 @@
return new Byte((byte) + Byte.valueOf(s).toString() + );
} else if (c == char.class) {
// non-normative, because a normative method would fail to compile
-if (s.length() 1) {
+if (s.length() 0) {
char ch = s.charAt(0);
// this trick avoids escaping issues
return ((char) + (int) ch + );
@@ -293,7 +293,7 @@
} else if (c == Integer.class) {
return new Integer( + Integer.valueOf(s).toString() + );
} else if (c == short.class) {
-return Short.valueOf(s).toString();
+return ((short) + Short.valueOf(s).toString() + );
} else if (c == Short.class) {
return new Short( + Short.valueOf(s).toString() + );
} else if (c == long.class) {
[PATCH] Jsp XML document produces invlaid XML
This patch fixes 3174 and 3351. This fix was supplied by the submitter
[EMAIL PROTECTED] This fix looks good.
Index: XmlOutputter.java
===
RCS file:
/home/cvspublic/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/X
mlOutputter.java,v
retrieving revision 1.15
diff -u -r1.15 XmlOutputter.java
--- XmlOutputter.java 2001/07/25 01:49:10 1.15
+++ XmlOutputter.java 2001/09/05 20:48:36
@@ -94,7 +94,7 @@
/*
* Tells the nesting level of jsp:root tags encountered
- * in the translation unit.
+ * in the translation unit. This is currently unused.
*/
private int jspRootLevel = 0;
@@ -121,15 +121,16 @@
* A translation unit (JSP source file and any files included via
* the include directive) may encounter multiple jsp:root
* tags. This method cumulates all attributes for the
- * jsp:root tag.
+ * jsp:root tag. It also ignores any xmlns:jsp and version
+ * attributes, in favor of the one generated by the compiler.
*/
void addRootAttrs(Attributes attrs) {
jspRootLevel++;
int attrsLength = attrs.getLength();
for (int i = 0; i attrsLength; i++) {
String qName = attrs.getQName(i);
- if (attrs.getQName(i).startsWith(xmlns:jsp)
-jspRootLevel 1) continue;
+ if ((qName.startsWith(xmlns:jsp) ||
+ qName.equals(version))) continue;
rootAttrs.addAttribute(attrs.getURI(i), attrs.getLocalName(i),
attrs.getQName(i), attrs.getType(i), attrs.getValue(i));
}
@@ -149,9 +150,6 @@
*/
void rootEnd() {
jspRootLevel--;
- if (jspRootLevel == 0) {
- append(jsp:root);
- }
}
/**
@@ -263,7 +261,6 @@
StringBuffer buff = new StringBuffer();
AttributesImpl attrs = new AttributesImpl();
-
append(jsp:root, rootAttrs, buff, false);
buff.append(sb.toString());
buff.append(/jsp:root);
[PATCH] Jasper generates bad custom tag variable names
This patch fixes Bug 3019.
If a tag name includes a '-', the generated var name is not a legal Java
identifier name, causing javac compilation errors. The bug is fixed by
substituting '-' with $1. Similarily, '.' is replaced by $2,
and ':' by $3.
runsocks cvs diff -u TagGeneratorBase.java
Index: TagGeneratorBase.java
===
RCS file:
/home/cvspublic/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/T
agGeneratorBase.java,v
retrieving revision 1.2
diff -u -r1.2 TagGeneratorBase.java
--- TagGeneratorBase.java 2000/11/01 20:25:08 1.2
+++ TagGeneratorBase.java 2001/09/06 22:32:12
@@ -119,7 +119,42 @@
return (TagVariableData) tagHandlerStack.peek();
}
+private String substitute(String name, char from, String to) {
+ StringBuffer s = new StringBuffer();
+ int begin = 0;
+ int last = name.length();
+ int end;
+ while (true) {
+ end = name.indexOf(from, begin);
+ if (end == -1)
+ end = last;
+ s.append(name.substring(begin, end));
+ if (end == last)
+ break;
+ s.append(to);
+ begin = end + 1;
+ }
+ return s.toString();
+}
+
+/**
+ * Return a tag variable name from the given prefix and shortTagName.
+ * Not all NMTOKEN's are legal Java identifiers, since they may contain
+ * '-', '.', or ':'. We use the following mapping: substitute - with
+ * $1, . with $2, and : with $3.
+ */
protected String getTagVarName(String prefix, String shortTagName) {
+
+ if (shortTagName.indexOf('-') != -1) {
+ shortTagName = substitute(shortTagName, '-', $1);
+ }
+ if (shortTagName.indexOf('.') != -1) {
+ shortTagName = substitute(shortTagName, '.', $2);
+ }
+ if (shortTagName.indexOf(':') != -1) {
+ shortTagName = substitute(shortTagName, ':', $3);
+ }
+
// Fix: Can probably remove the synchronization now when no vars or
method is static
synchronized (tagVarNumbers) {
String tag = prefix+:+shortTagName;
[PATCH] JSP generated file names are too long
This patches fixes Bug 2917. The name of the .java files generated by Jasper
includes the path name, which can be a problem in Windows if the path name
is long. Since the files are placed under the directories indicated by the
path name, there is really no reason to include the pathname with the file
name.
This fix is based on a submitter's ([EMAIL PROTECTED]) suggestion.
runsocks cvs diff -u JspCompiler.java
Index: JspCompiler.java
===
RCS file:
/home/cvspublic/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/J
spCompiler.java,v
retrieving revision 1.6
diff -u -r1.6 JspCompiler.java
--- JspCompiler.java2001/05/16 06:02:48 1.6
+++ JspCompiler.java2001/09/07 21:24:48
@@ -123,40 +123,14 @@
}
private final String getBaseClassName() {
- String className;
-
+ // Only keep the file name, not the path.
+ int iSep = jsp.lastIndexOf(File.separatorChar) + 1;
+ // By luck, also works when '/' is absent
+ int iEnd = jsp.length();
if (jsp.endsWith(.jsp))
-className = jsp.substring(0, jsp.length() - 4);
-else
-className = jsp;
+ iEnd = iEnd - 4;
-
- // Fix for invalid characters. If you think of more add to the list.
- StringBuffer modifiedClassName = new StringBuffer();
- for (int i = 0; i className.length(); i++) {
- if (Character.isLetterOrDigit(className.charAt(i)) == true)
- modifiedClassName.append(className.substring(i,i+1));
- else
- modifiedClassName.append(mangleChar(className.charAt(i)));
- }
- modifiedClassName.append(_jsp);
- return modifiedClassName.toString();
-}
-
-private static final String mangleChar(char ch) {
-
-if(ch == File.separatorChar) {
- ch = '/';
- }
- String s = Integer.toHexString(ch);
- int nzeros = 5 - s.length();
- char[] result = new char[6];
- result[0] = '_';
- for (int i = 1; i = nzeros; i++)
- result[i] = '0';
- for (int i = nzeros+1, j = 0; i 6; i++, j++)
- result[i] = s.charAt(j);
- return new String(result);
+ return (jsp.substring(iSep, iEnd) + _jsp);
}
/**
[PATH] XML fragments in jsp handled incorrectly
This patch fixes #3350. In a JSP document, the tags in a XML fragment are
always generated before the characters. The current fix preserves their
orders.
misto% runsocks cvs diff -u ParserXJspSaxHandler.java
Index: ParserXJspSaxHandler.java
===
RCS file:
/home/cvspublic/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/P
arserXJspSaxHandler.java,v
retrieving revision 1.13
diff -u -r1.13 ParserXJspSaxHandler.java
--- ParserXJspSaxHandler.java 2001/04/27 18:09:31 1.13
+++ ParserXJspSaxHandler.java 2001/09/12 18:33:59
@@ -233,8 +233,9 @@
// If previous node is a custom tag, call its
// begin tag handler
-if (!name.equals(jsp:root)) {
-Node prevNode = (Node)stack.peek();
+Node prevNode = null;
+ if (!stack.empty()) {
+ prevNode = (Node)stack.peek();
if (prevNode instanceof NodeTag) {
try {
processCustomTagBeginDoIt((NodeTag) prevNode, true);
@@ -273,6 +274,16 @@
}
if (!isCustomTag) {
// uninterpreted tag
+ // If the parent tag is also uninterpreted, then the
+ // characters have to be flushed, to preserve the order
+ // of the tags and charaters that may appear in a XML
+ // fragment, such as axyzb/b/a
+ if (prevNode != null prevNode.isUninterpretedTag()
+ prevNode.getText() != null) {
+ jspHandler.handleCharData(prevNode.start, start,
+ prevNode.getText());
+ prevNode.clearText();
+ }
node.setUninterpreted(true);
jspHandler.handleUninterpretedTagBegin(node.start,
node.start, node.rawName, node.attrs);
@@ -646,6 +657,10 @@
? null
: text.toString().toCharArray();
}
+
+ void clearText() {
+ text = null;
+ }
boolean isRoot() {
return isRoot;
[PATCH] BullPointerException in JakataCommentGenerator
This patch fixes #3079
misto% runsocks cvs diff -u Parser.java
Index: Parser.java
===
RCS file:
/home/cvspublic/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/P
arser.java,v
retrieving revision 1.12
diff -u -r1.12 Parser.java
--- Parser.java 2001/07/12 23:29:31 1.12
+++ Parser.java 2001/09/14 22:39:54
@@ -1095,8 +1095,13 @@
boolean noJspElement = false;
while (reader.hasMoreInput()) {
-if (until != null reader.matches(until))
+if (until != null reader.matches(until)) {
+ if (tmplStart == null)
+ tmplStart = reader.mark();
+ if (tmplStop == null)
+ tmplStop = reader.mark();
return;
+ }
// If the file has changed because of a 'push' or a 'pop'
// we must flush the character data for the old file.
[PATCH] Jspc throws NPE when used without -webapp
This patch fixes the reopen #3529. Now jspc works for taglib when -webapp is
not specified.
The logic used in JspC.java to get the uri root and base is still very
convoluted and should be a prime target for rewrite, maybe later.
misto% runsocks cvs diff -u JspC.java
Index: JspC.java
===
RCS file:
/home/cvspublic/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/JspC.java,
v
retrieving revision 1.11
diff -u -r1.11 JspC.java
--- JspC.java 2001/09/14 05:02:15 1.11
+++ JspC.java 2001/09/17 23:37:53
@@ -699,6 +699,16 @@
} else {
try {
if (ubase != null) {
+try {
+JspCServletContext context =
+new JspCServletContext
+(new PrintWriter(System.out),
+ new URL(file: + ubase.replace('\\','/') +
/));
+tldLocationsCache = new TldLocationsCache(context);
+} catch (MalformedURLException me) {
+System.out.println(** + me);
+}
+
File fjsp = new File(file);
String s = fjsp.getCanonicalPath();
if (s.startsWith(ubase)) {
Re: [PATCH] Jspc throws NPE when used without -webapp
Yea, I have verified that the bug is real, i.e. Jspc fails to find the
tag library when taglib.tld is packaged in a jar file. I have also
verfied that the supplied patch did fix the problem; so we do need it.
Date: Mon, 17 Sep 2001 17:23:53 -0700 (PDT)
From: Craig R. McClanahan [EMAIL PROTECTED]
Subject: Re: [PATCH] Jspc throws NPE when used without -webapp
To: [EMAIL PROTECTED], Kin-Man Chung [EMAIL PROTECTED]
MIME-version: 1.0
X-Spam-Rating: localhost 1.6.2 0/1000/N
Thanks Kin-Man. Can you validate the proposed patch for #3640 as well,
if it is still needed?
Craig
On Mon, 17 Sep 2001, Kin-Man Chung wrote:
Date: Mon, 17 Sep 2001 17:08:35 -0700 (PDT)
From: Kin-Man Chung [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED],
Kin-Man Chung [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: [PATCH] Jspc throws NPE when used without -webapp
This patch fixes the reopen #3529. Now jspc works for taglib when -webapp
is
not specified.
The logic used in JspC.java to get the uri root and base is still very
convoluted and should be a prime target for rewrite, maybe later.
misto% runsocks cvs diff -u JspC.java
Index: JspC.java
===
RCS file:
/home/cvspublic/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/JspC.java,
v
retrieving revision 1.11
diff -u -r1.11 JspC.java
--- JspC.java 2001/09/14 05:02:15 1.11
+++ JspC.java 2001/09/17 23:37:53
@@ -699,6 +699,16 @@
} else {
try {
if (ubase != null) {
+try {
+JspCServletContext context =
+new JspCServletContext
+(new PrintWriter(System.out),
+ new URL(file: + ubase.replace('\\','/')
+
/));
+tldLocationsCache = new
TldLocationsCache(context);
+} catch (MalformedURLException me) {
+System.out.println(** + me);
+}
+
File fjsp = new File(file);
String s = fjsp.getCanonicalPath();
if (s.startsWith(ubase)) {
[PATCH] TC4.0 Throws NPE in JakartaCommentGenerator
This patch fixes the NPE raised when a jsp:useBean has a non empty body.
However, it does not fix the problem reported in #3740, since I couldn't
reproduce the same bug, though the test now works!
misto% runsocks cvs diff -u Parser.java
Index: Parser.java
===
RCS file:
/home/cvspublic/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/P
arser.java,v
retrieving revision 1.13
diff -u -r1.13 Parser.java
--- Parser.java 2001/09/15 01:18:10 1.13
+++ Parser.java 2001/09/20 20:55:57
@@ -1096,11 +1096,12 @@
boolean noJspElement = false;
while (reader.hasMoreInput()) {
+if (tmplStart == null)
+tmplStart = reader.mark();
+if (tmplStop == null)
+tmplStop = reader.mark();
+
if (until != null reader.matches(until)) {
-if (tmplStart == null)
-tmplStart = reader.mark();
-if (tmplStop == null)
-tmplStop = reader.mark();
return;
}
Re: [PATCH] Error in examples/simpletag/foo.jsp
This patch fixes #3739. runsocks cvs diff -u foo.jsp Index: foo.jsp === RCS file: /home/cvspublic/jakarta-tomcat-4.0/webapps/examples/jsp/simpletag/foo.jsp,v retrieving revision 1.2 diff -u -r1.2 foo.jsp --- foo.jsp 2001/09/05 05:14:01 1.2 +++ foo.jsp 2001/09/20 21:28:47 @@ -4,7 +4,6 @@ reserved. -- body -%@ taglib uri=http://jakarta.apache.org/tomcat/debug-taglib; prefix=d% %@ taglib uri=http://jakarta.apache.org/tomcat/examples-taglib; prefix=eg% Radio stations that rock:
[PATCH] TC4.0 Error in setting string literal to Object in custom tags
This patch fixes #3707.
misto% runsocks cvs diff -u TagBeginGenerator.java
Index: TagBeginGenerator.java
===
RCS file:
/home/cvspublic/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/T
agBeginGenerator.java,v
retrieving revision 1.15
diff -u -r1.15 TagBeginGenerator.java
--- TagBeginGenerator.java 2001/09/07 00:18:49 1.15
+++ TagBeginGenerator.java 2001/09/21 21:18:34
@@ -301,7 +301,7 @@
} else if (c == Long.class) {
return new Long( + Long.valueOf(s).toString() + l);
} else if (c == Object.class) {
-return new String( + s + );
+return new String( + writer.quoteString(s) + );
} else {
return ( + c.getName() +
)JspRuntimeLibrary.getValueFromPropertyEditorManager( +
[PATCH] TC4.0 null JasperException
Fixes #3617. Patch supplied by [EMAIL PROTECTED]
(Martijn Koster)
Index: Compiler.java
===
RCS file:
/home/cvspublic/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/C
ompiler.java,v
retrieving revision 1.12
diff -u -r1.12 Compiler.java
--- Compiler.java 2001/09/15 23:47:17 1.12
+++ Compiler.java 2001/09/18 15:40:36
@@ -324,11 +324,12 @@
// Now do the mapping
String mapping = findMapping(map, lineNr);
-if (mapping != null) {
-errorMsg.append(findMapping(map, lineNr));
-errorMsg.append(line);
+if (mapping == null)
errorMsg.append('\n');
-}
+else
+errorMsg.append(mapping);
+errorMsg.append(line);
+errorMsg.append('\n');
}
br.close();
map.clear();
[PATCH] TC4.0 Improvements in validator messages
This patch addresses the problems raised in bug#3367 and #3368. All
the messages from all validators are now displayed, without the stack
trace.
misto% pwd
/home/kchung/tomcat/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper
misto% cat JasperError.java
/*
* The Apache Software License, Version 1.1
*
* Copyright (c) 1999 The Apache Software Foundation. All rights
* reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
*
* 1. Redistributions of source code must retain the above copyright
*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 Group.
*
* THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED
* WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
* OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
* DISCLAIMED. IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR
* ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
* SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
* LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
* USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
* ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
* OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
* OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*
*
* This software consists of voluntary contributions made by many
* individuals on behalf of the Apache Software Foundation. For more
* information on the Apache Software Foundation, please see
* http://www.apache.org/.
*
*/
package org.apache.jasper;
/**
* Errors generated by the JSP engine. It differs from JasperException in
* that it does not print stack trace.
*
* @author Kin-man Chung
*/
public class JasperError extends org.apache.jasper.JasperException {
public JasperError(String reason) {
super(reason);
}
}
misto% runsocks cvs diff -u compiler/JspParseEventListener.java
Index: compiler/JspParseEventListener.java
===
RCS file:
/home/cvspublic/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/J
spParseEventListener.java,v
retrieving revision 1.33
diff -u -r1.33 JspParseEventListener.java
--- compiler/JspParseEventListener.java 2001/07/25 01:08:13 1.33
+++ compiler/JspParseEventListener.java 2001/09/26 01:49:02
@@ -78,10 +78,10 @@
import javax.servlet.jsp.tagext.TagLibraryInfo;
import javax.servlet.jsp.tagext.ValidationMessage;
+import org.apache.jasper.JasperError;
import org.apache.jasper.JasperException;
import org.apache.jasper.Constants;
import org.apache.jasper.JspCompilationContext;
-
import org.apache.jasper.logging.Logger;
import org.xml.sax.Attributes;
@@ -1114,7 +1114,9 @@
* libraries used by the document.
*/
public void validate() throws JasperException {
+ StringBuffer errMessage = new StringBuffer();
Enumeration enum = libraries.getTagLibInfos();
+boolean hasErrors = false;
while (enum.hasMoreElements()) {
TagLibraryInfo tli = (TagLibraryInfo)enum.nextElement();
//@@@ remove cast when TagLibraryInfo is fixed in spec
@@ -1122,14 +1124,23 @@
ValidationMessage[] errors =
((TagLibraryInfoImpl)tli).validate(xo.getPageData());
if ((errors != null) (errors.length != 0)) {
- // for now just report the first error!
- String msg = errors[0].getMessage();
-throw new JasperException(
- Constants.getString(
-jsp.error.taglibraryvalidator.invalidpage,
- new Object[]{tli.getShortName(), msg
Re: [VOTE] New Committer
+1 Welcome, Patrick. Date: Wed, 17 Oct 2001 22:02:13 -0600 (MDT) From: Christopher Cain [EMAIL PROTECTED] Subject: [VOTE] New Committer X-Originating-IP: 216.17.139.153 To: [EMAIL PROTECTED] MIME-version: 1.0 Content-transfer-encoding: 8BIT Delivered-to: mailing list [EMAIL PROTECTED] Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm User-Agent: IMP/PHP IMAP webmail program 2.2.6 X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N List-Post: mailto:[EMAIL PROTECTED] List-Unsubscribe: mailto:[EMAIL PROTECTED] List-Help: mailto:[EMAIL PROTECTED] I would like to nominate Patrick Luby [EMAIL PROTECTED] for committer status. His recent contributions include several security-manager-related patches and documentation help, and appears keen to tackle the Admin Apps functionality as well. I think he would make an excellent addition to the team. Votes please? - Christopher /** * Pleurez, pleurez, mes yeux, et fondez vous en eau! * La moitiƩ de ma vie a mis l'autre au tombeau. *---Corneille */
Re: [PATCH] Tomcat 4.0.1- Proposed fix for Bugzilla 4609
The problem is actually deeper than is reported in the bug report.
1. We also need a fix for flush(), since invoking flush after close
should also throw IOE.
2. The fixes should also be applied to BodyContentImpl.java, since it's just
another JspWriter.
However, doing all these fixes leads to another bug in the Jasper runtime.
And this one is nastier. Suppose we have a jsp:forward somewhere in
the page. The 'forward' would cause out.close() to be invoked; and then
releasePageContext (generated for every page in
JspParseEventListener.generateFooter()) would be invoked, which
would cause out.flush() to be invoked, which in term would cause a
IOException! This all works now because flush called after close does
not cause IOException (a bug). If fact, if the user explicit closes
a JspWriter, releasePageContext would surely causes a IOE.
I am currently looking at this bug and have essentially the same fix
(except for the generateFooter part), but don't know yet how to fix
the problem I described above. If you have any ideas, I'd love hearing
from you!
Date: Tue, 20 Nov 2001 18:19:16 -0500
From: Ryan Lubke [EMAIL PROTECTED]
Subject: [PATCH] Tomcat 4.0.1- Proposed fix for Bugzilla 4609
To: tcdev [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
Hi,
Thought I'd give a shot at patching a bug (4609) I logged.
The basics of the bug is that an IOException is not thrown
if out.close() is called from within a JSP page and
subsequent calls to write() or println(), etc. are made.
The solution I have affects two classes:
org.apache.jasper.runtime.JspWriterImpl
org.apache.jasper.compiler.JspParseEventListener
The modification to JspWriterImpl was simple:
-Added a new boolean instance variable called 'closed'
-When JspWriter.close() is called, set 'closed' to true.
-Modified the JspWriter.ensureOpen() method. If
'closed' is true, or response is null, throw the IOException.
I felt the modification to JspParseEventListener.generateFooter()
was necessary as the page code generated:
snip
} catch (Throwable t) {
if (out != null out.getBufferSize() != 0)
out.clearBuffer();
if (pageContext != null) pageContext.handlePageException(t);
}
/snip
So in this case, now that the IOException is thown, we go into the
throwable, but the call to out.clearBuffer() generates its own
IOException. The problem with this is that the stacktrace becomes
inaccurate. Showing the call to clearBuffer() as the top-most call
on the stack.
So the change I introduced would generate the following code:
snip
if (out != null out.getBufferSize() != 0)
try {
out.clearBuffer();
} catch (java.io.IOException ioe) {
if (t instanceof java.io.IOException) {
if (!(t.getMessage().equals(ioe.getMessage( {
t = ioe;
}
}
}
/snip
So, here if out.clearBuffer() happens to throw an IOException,
check to see if the throwable that brought us to this point
in the code is an IOException as well. If it is, see if
the messages are the same, if they aren't, then there
is a new IO issue and set ioe to the throwable which will
be handled by pageContext.handlePageException. Otherwise
the catch becomes a no-op and pageContext.handlePageException
will use the original throwable. Hope that made sense.
Anyway, comments are definately welcome. Still getting familiar
with the code.
Thanks,
-rl
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[PROPOSAL] 4.0 Jasper rewrite
1 The Problem The current JSP compiler (Jasper) in tomcat 4.0 is essentially an one-pass compiler, with a two stage process. The Jsp page is first parsed, looking for JSP syntatic elements, and a list of generators for these elements are produced. At the second stage, these generators are visited to generate the java program, which is then compiled (by javac) into bytecodes. Such a compiler is simple, light weight and fast, and works very well so far. However, it has the short-comings that are usually associated with an one-pass compiler. For instance, 1.1 It's hard to handle problems that require looking up info in another part of the page. For instance, enforcing the rule that taglib needs to be declared before use would be hard to implement. Right now, any custom tags used before declared are treaded as unprocessed tags (a bug). 1.2 It's hard to add new logic to the parts. For intance, currently, Xml view of the output is added on to the generators as a wrapper, instead of a set of generators on their own, on another visit. 1.3 It doesn't have an uniform error reporting mechanism. For instance, %@ page import directive are collected and generated outside of the generators, where the line number mapping from .java to .jsp files is non-functioning. 1.4 It's hard to do any optimization, other than the basic onces. For instance, optimizations such as taglib object reuse would be hard to do, since it's hard for the compiler to find out about the objects that were generated before. 2 The Proposed Compiler Structure I think it's time to do a rewrite of Jasper. The compilation would be a multi-pass process. 2.1 Jsp Syntax Tree The most important data structure is one that is the internal representation of the JSP page. Call it the Jsp syntax tree if you wish. It is produced by the parser, annotated by the validators, and modified and transformed by the optimizers. 2.2 The Parser It parses the origianl Jsp page and generates the Jsp syntax tree. There are little semantic processing here. Note that there will be 2 parsers, one for the regular jsp syntax, the other for the xml syntax. 2.3 Visitors Once the Jsp syntax tree is generated, it can be manipulated by various visitors. These visitors would use the visitor pattern, so that it only needs to define the actions on the jsp elements it has interest on. 2.3.1 The validator visitor Performs checking (e.g. allowed attribute values) on Jsp elements, and report errors. 2.3.2 The dump visitor Dumps the tree for debugging. Callable from the debugger. 2.3.3 The optimize visitors These optional phases can be added later. I have some ideas. 2.3.4 Xml output visitor Generates xml file only if needed. 2.3.5 Java code generator visitors Generates the Java program. 3. Current status I have been experimenting with Jsp syntax tree class definitions. Nothing working yet. I'll publish some code if there are interest. Comments are welcome. Also let me know if there are interests in helping, either in design or implementation. Thanks! -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Bug 4954 - When specifying CATALINA_BASE explicitly,that dir has to have shared/lib/jasper-*.jar in it
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4954 Looks like a build environment issue. Want to take a look at this? Thanks. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
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]
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 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] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTES] Tomcat 4.0.2 beta 1
ballot [X] +1: Make the release [ ] -1: I'm opposed to the release until the following issues are fixed: Since 4.0.1, there have been lots of bug fixes. It's time. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Jasper error handling extensions
I am in the process of rewriting much of Jasper, and am using an error
handling mechanism very similar in idea to the one you just proposed.
The new jasper would alos support JSR45, which is an interface for source
mapping. The error handler (and other compiler plugins) can be configured
with a configuration file.
Since the compiler is still in the early implementation stage, I'm open
to any suggestions/requirements that you may have, from IDE integration
point of view. Thanks.
Date: Tue, 12 Feb 2002 13:50:07 +0100
From: Martin Kahr [EMAIL PROTECTED]
Subject: Jasper error handling extensions
To: [EMAIL PROTECTED]
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
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
Hi.
I want to implement a simple jsp compiler plugin for the eclipse IDE.
After 1 day analyzing the current (tomcat 4.0.2) jasper code I have not
found any hooks where I can install my code to get the jasper error
messages.
Of course I can parse the text message of the exceptions thrown during
parsing and compilation but I think there should be a better way.
I think about an special ErrorHandler Interface with a concrete
implementation which provides the same error handling (exception
generation) as the current jasper code (leads to minimal code change and
no change of the current interface).
This Error Handler objects are plugged into the parser eigther through
the Options or JspCompilationContext object. (I think Options is the
better one because the ErrorHandler will not change between 2 jsp files)
With this I will be able to implement a special Error Handler (extending
the default one) for my plugin.
Possible Interface (first draft):
public interface JasperErrorHandler {
public void handleParseError(Mark mark, String msg) throws
JasperException;
public void handleCompileError(String msg, JspLineMap map) throws
JasperException;
}
I looked at the code of some IDE which integrate the jasper compiler.
They are duplicating a large number of the orignal jasper code to get
access to the error messages. I think they have the same problems as I
have.
The problem with this is that on each new Tomcat release (with Jasper
code changes) they have to adopt their code :-(
What do you think about this idea ?
nice greetings from vienna
Martin Kahr
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] Tomcat 4.0.4 Beta 2 / Coyote 1.0 Beta 4 release
+1 on both. Date: Thu, 21 Mar 2002 16:25:50 -0800 From: Remy Maucherat [EMAIL PROTECTED] Subject: [VOTE] Tomcat 4.0.4 Beta 2 / Coyote 1.0 Beta 4 release To: Tomcat Developers List [EMAIL PROTECTED] MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600. Content-transfer-encoding: 7bit X-Priority: 3 X-MSMail-priority: Normal Delivered-to: mailing list [EMAIL PROTECTED] Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm X-Spam-Rating: localhost.apache.org 1.6.2 0/1000/N 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 I'd like to propose releasing 4.0.4 beta 2 within a few days (friday at the earliest, next tuesday at the latest). This release will include bugfixes (the list is in the usual release notes document in CVS) as well as the inclusion of the Coyote binaries (conditional to the results of the vote below). The Coyote connector will *not* be enabled by default, but will appear commented out in the default server.xml configuration file. I also plan to make a Coyote 1.0 beta 4 at the same time, to pick up the bugfixes and minor improvements in the Tomcat adaptors. Tomcat 4.0.4 Beta 2 release: ballot +1 [ ] I support the release, and I will help +0 [ ] I support the release -0 [ ] I don't support the release -1 [ ] I'm against the release because: /ballot Inclusion of the Coyote binaries: ballot +1 [ ] Yes -1 [ ] No /ballot My vote is +1 for both. 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]
[PLAN] New Jasper
As I have announced here before, I have been working on rewriting part of Jasper. There are several goals for the new Jasper: 1. To reorganize/simplify parsing and code generation to make it more maintainable and yet runs faster. 2. To be used as a basis for reference implementation for JSP1.3. 3. To be used as a basis for performance optimizations, especially with custom tags. The majority of work has been concentrated on the compiler engine: the parser, the syntax checker, the attribute validator, and the code generator. Most of the utilities (except those related to parsing) and compiler environments (e.g. taglib infos), and runtimes have not been changed. The major change to the compiler has been the introduction of nodes as an internal representation of a JSP page or JSP document. Nodes are created by the parsers; and they are read, annotated, or transformed by other phases of the compiler. The compiler has added some new features (e.g. JSP id, pluggable error handlers); and it conforms the specs better, in terms of parsing and syntax error checking. Not much has changed in the servlet (java) file produced by the code generator, to maintain backward compatibility. Of couse this will be changed, as we move to goal 2 and 3. I have been doing it so far in my own sandbox. The reason for this is not to keep it a secret, but to avoid de-stablizing the current tomcat, since a lot of my early work was mainly experimental. There have been interests recently in making the new Jasper public, so I am going to do that, even though it is not ready to replace the current jasper yet. My plan is to create a new jasper directory (jasper2) under jakarta-tomcat-4.0, and to modify build.xml to allow for building jasper from sources under either jasper(the default) or jasper2 (the new jasper). This arrangement allows both the existing jasper and the new jasper to coexist and be co-developed without affecting each other. One drawback is that some files are duplicated in both directories and bugs fixed in one need to be duplicated in the other. But hopefully such an arranagement is only temporary and when the new jasper is in good enough shape, it will replace the existing one. I plan to put back the new japser source tree in a day or two. If anyone has comments, concerns, or objections, please let me know. Of course, anyone interested in contributing to the new jasper development is also welcome. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [PLAN] New Jasper
Thanks for the pointer. I'll look at both places to see if there are codes/ideas I can borrow. I also would welcome ideas or suggestion about what and how to make jasper better. Pier's is the first complain that I've heard about jasper translation perfromance. :-) Date: Tue, 26 Mar 2002 00:47:12 +0100 From: Ignacio J. Ortega [EMAIL PROTECTED] Subject: RE: [PLAN] New Jasper To: 'Tomcat Developers List' [EMAIL PROTECTED], 'Kin-Man Chung' [EMAIL PROTECTED] MIME-version: 1.0 X-Priority: 3 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 De: Kin-Man Chung [mailto:[EMAIL PROTECTED]] Enviado el: martes 26 de marzo de 2002 0:37 Nice to hear that, one comment, there is a jakarta-tomcat-jasper repository with code Costin and Mel did some time ago as an initial effort to refactor the 3.3 Jasper, i dont know which is the state of the code there but maybe it's good idea to use it for your effort.. Coyote builds from a parallel repostory, so the build file can be borrowed from there.. What do you think? Saludos , Ignacio J. Ortega -- 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: [PLAN] New Jasper
I have noticed that the current Jasper does a lot of string manipulations very slowly, e.g. there are unnecessary copying or concatenations, and the uses of String where StringBuffer should be used. Hopefully I can avoid all of these. But I don't have high hopes that Jasper performance can be improved to the point that an user will notice, because the time spent in Jasper is probably small compared with that spent in javac. Now if we could have jasper generate byte code directly... Date: Mon, 25 Mar 2002 23:40:05 + From: Pier Fumagalli [EMAIL PROTECTED] Subject: Re: [PLAN] New Jasper To: Tomcat Developers List [EMAIL PROTECTED] MIME-version: 1.0 Content-transfer-encoding: 7bit Delivered-to: mailing list [EMAIL PROTECTED] Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm User-Agent: Microsoft-Entourage/10.0.0.1309 X-Antivirus-Data: Virus data file v4189 created Mar 06 2002 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 Kin-Man Chung [EMAIL PROTECTED] wrote: I plan to put back the new japser source tree in a day or two. If anyone has comments, concerns, or objections, please let me know. Of course, anyone interested in contributing to the new jasper development is also welcome. YES PLEASE :) It's quite some time I'm waiting for this... We have a pretty heavily loaded website all using JSP, and the current jasper is just so slow to even considering using it (not the actual servlet, but the code generated). Can't wait to try it out... Pier -- 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: [PLAN] New Jasper
On Mon, 25 Mar 2002, Kin-Man Chung wrote: I have noticed that the current Jasper does a lot of string manipulations very slowly, e.g. there are unnecessary copying or concatenations, and the uses of String where StringBuffer should be used. Hopefully I can avoid all of these. But I don't have high hopes that Jasper performance can be improved to the point that an user will notice, because the time spent in Jasper is probably small compared with that spent in javac. Now if we could have jasper generate byte code directly... I wouldn't worry too much about this kind of optimizations - the page compilation happens only once and it's quite easy to pre-compile the pages with jspc. The place where optimizations do matter the most is the runtime - I would be happy with a generator/compiler that is slower but generates faster code. Even if it is possible to use BCEL to generate bytecodes directly, I think this would be a huge waste of time if done before the runtime is optimized. A clean generator that makes it easier to improve the generated code is better than the fastest generator. Costin I happen to agree with you. My initial effort in performance improvement would certainly be on the generated codes. I wasn't really serious when I suggested that Jasper generates byte codes. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PLAN] New Jasper
The primary reason for not using a parser generator is the grammar for a JSP page is context sensitive, and highly ambiguous, so its parsing does not fit the model used in parsing of conventional languages. Also, the grammar is relative simple, once you get past the attributes, so using a custom parser is actually easier and more flexible. As you'll see when I put back the sources, I tried to write down the grammar for a JSP page, just to put the parser on a more vigorous basis, but there are still cases where the context sensitivity interfere with normal parsing (e.g. the recognition of custom tags). It is much easier for a custom parser to just handle them as special cases. Date: Tue, 26 Mar 2002 08:17:12 -0600 From: Bob Lee [EMAIL PROTECTED] Subject: Re: [PLAN] New Jasper To: Tomcat Developers List [EMAIL PROTECTED], 'Kin-Man Chung' [EMAIL PROTECTED] MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600. Content-transfer-encoding: 7bit X-Priority: 3 X-MSMail-priority: Normal 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 Possibly very stupid question... Is there any reason not to use JavaCC on the JSP compiler? I know the grammar is pretty nasty, but that doesn't make a custom solution any easier either. Bob - Original Message - From: Ignacio J. Ortega [EMAIL PROTECTED] To: 'Tomcat Developers List' [EMAIL PROTECTED]; 'Kin-Man Chung' [EMAIL PROTECTED] Sent: Tuesday, March 26, 2002 8:04 AM Subject: RE: [PLAN] New Jasper De: Kin-Man Chung [mailto:[EMAIL PROTECTED]] Enviado el: martes 26 de marzo de 2002 1:13 Thanks for the pointer. I'll look at both places to see if there are codes/ideas I can borrow. My comment was more geared toward the use of this repository, than to reuse the code there, i think is cleanest to build Jasper2 in his own repo.., Well and if you can borrow some of the code there, much better. :)) Saludos , Ignacio J. Ortega -- 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: tag pooling question
Pulling codes out of iteration tag bodies is very high on my list of optimizations that I wnat to do. I don't think we can do much about general scriplets that contain loops, though. But before we start on jasper optimization work, we'll need benchmarks and performance analysers. I have learnt from experience that performance improvement often comes from surprising places, and that optimizations done at the wrong time and place often do more harm than good. Benchmarks would give us some real metric for us to measure our optimization work, and analyzing tools would let us identify hot spots that need to be improved. I'd appreciate comments, suggestions, and pointers on these two subjects. I'd also appreciate if anyone can donate some real life applications that I can use for benchmarking jasper performance. Thanks in advance. - Kin-man Date: Wed, 27 Mar 2002 15:31:54 -0600 From: Casey Lucas [EMAIL PROTECTED] Subject: Re: tag pooling question To: Tomcat Developers List [EMAIL PROTECTED] MIME-version: 1.0 Content-transfer-encoding: 7bit X-Accept-Language: en 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 That would be nice to have tag pooling in 4.x. It was one of those things that I wanted to do before my day job changed a little. Anyway, a few thoughts: Tag pooling as implemented in 3.x is IMHO a good starting point, but generated code will really benefit if we can handle the more traditional optimizing compiler situations like pulling redundant code (i.e. tag setter methods) out of loops, etc. Hopefully, with the recent talk of new jasper (very exciting), we can have a good place to easily integrate such optimizations. If you have specific questions about 3.x tag pooling, just let me know... I might be able to remember some of it. -casey peter lin wrote: thanks larry for that information. I will take a look before I jump in. Larry Isaacs wrote: This was done by Casey Lucas. However, be aware that it comes with a disadvantage in that because of the extra code, it reduces the number of tags you can get on a JSP be for you hit Bug #6088 http://nagoya.betaversion.org/bugzilla/show_bug.cgi?id=6088 I'm doubtful you can get 100-300 tags on a JSP page in any version of Jasper. Also, check recent posts on this list for a proposed Jasper2 effort that is underway. See: Actually, I managed to make a page with about 140 tags that barely squeezes under the 64K limit. Under moderate load it runs like a dog. When I break it up into smaller pages using action include, it runs much better. http://www.mail-archive.com/tomcat-dev@jakarta.apache.org/msg24054.html Cheers, Larry Peter lin -- 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: [PLAN] New Jasper
I checked out jakarta-tomcat-jasper briefly looked at the files there. I agree with you (and constin) that it can be used as a repository for jasper2. However, files and directory structures are too different from the one used in tomcat 4, and I am a little hesitant to just go in there and wipe out everything, not knowing the current status of that repository, or its intended use (tomcat 3, 4, or both?). In the interest of getting jasper2 out in reasonable time, I am going to stick with my original plan. That'd also give me some time to digest what's in jakarta-tomcat-jasper, and see if jasper2 should move in there. Thanks for the suggestion. Date: Tue, 26 Mar 2002 15:04:16 +0100 From: Ignacio J. Ortega [EMAIL PROTECTED] Subject: RE: [PLAN] New Jasper To: 'Tomcat Developers List' [EMAIL PROTECTED], 'Kin-Man Chung' [EMAIL PROTECTED] MIME-version: 1.0 X-Priority: 3 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 De: Kin-Man Chung [mailto:[EMAIL PROTECTED]] Enviado el: martes 26 de marzo de 2002 1:13 Thanks for the pointer. I'll look at both places to see if there are codes/ideas I can borrow. My comment was more geared toward the use of this repository, than to reuse the code there, i think is cleanest to build Jasper2 in his own repo.., Well and if you can borrow some of the code there, much better. :)) Saludos , Ignacio J. Ortega -- 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: [PLAN] New Jasper
OK, that'd be easier. :) I'll give it a try. Thanks for the suggestion. Date: Wed, 27 Mar 2002 14:59:00 -0800 (PST) From: [EMAIL PROTECTED] Subject: RE: [PLAN] New Jasper X-X-Sender: [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED], Kin-Man Chung [EMAIL PROTECTED] MIME-version: 1.0 X-Authentication-warning: dyn-181.sfo.covalent.net: costinm owned process doing -bs On Wed, 27 Mar 2002, Kin-Man Chung wrote: I checked out jakarta-tomcat-jasper briefly looked at the files there. I agree with you (and constin) that it can be used as a repository for jasper2. However, files and directory structures are too different from the one used in tomcat 4, and I am a little hesitant to just go in there and wipe out everything, not knowing the current status of that repository, or its intended use (tomcat 3, 4, or both?). In the interest of getting jasper2 out in reasonable time, I am going to stick with my original plan. That'd also give me some time to digest what's in jakarta-tomcat-jasper, and see if jasper2 should move in there. Just create a jasper2 directory - and don't touch the old one. The idea is similar with what's in j-t-c - there are multiple 'projects' going on, each using its own conventions. The structure of jasper3.4 shouldn't affect jasper2, and you don't need to 'digest' the old code ( any more than we digest each other's work in connectors ). I can't see how creating the directory in j-t-j can affect your timing. If it's build issue ( build.xml, etc) - it's easy to solve ( Remy already did most of the work for coyote ) costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: tag pooling question
What you said about using simple pages and comparing their performance with their servlet equivalents makes a lot of sense and it's obvious that that needs to be done in any optimization work. However, real life applications benchmarks are also useful for other purposes. They can be used for measuring the overall effectiveness of optimizations: how effective the individual optimizations are, and how they interact with each other. It also would let us find out what optimizations are important in practice, not just in small test cases. I'd use these benchmarks for measuring the progress on optimization works, and as an early warning that certain optimizations are not useful or even harmful. - Kin-man Date: Wed, 27 Mar 2002 14:54:10 -0800 (PST) From: [EMAIL PROTECTED] Subject: Re: tag pooling question X-X-Sender: [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED], Kin-Man Chung [EMAIL PROTECTED] MIME-version: 1.0 X-Authentication-warning: dyn-181.sfo.covalent.net: costinm owned process doing -bs On Wed, 27 Mar 2002, Kin-Man Chung wrote: Pulling codes out of iteration tag bodies is very high on my list of optimizations that I wnat to do. I don't think we can do much about general scriplets that contain loops, though. But before we start on jasper optimization work, we'll need benchmarks and performance analysers. I have learnt from experience that performance improvement often comes from surprising places, and that optimizations done at the wrong time and place often do more harm than good. Benchmarks would give us some real metric for us to measure our optimization work, and analyzing tools would let us identify hot spots that need to be improved. I'd appreciate comments, suggestions, and pointers on these two subjects. I'd also appreciate if anyone can donate some real life applications that I can use for benchmarking jasper performance. The most usefull tools are OptimizeIt and ab. Simple pages would help much better then complex pages - first find out what's the overhead of executin a simple JSP page, with no tags, compare it with the equivalent servlet ( HelloWorld ), and find out what's wrong. Then use a simple hello world Tag, compare it with the equivalent servlet ( or JSP not using tags ), and find what's wrong. Same for a simple iteration tag, compared with a scriptlet If you solve those simple problems, and get the tag version in a reasonable limit, I think we'll all be very happy ( 30% slower would be acceptable for me, even 1/2 the speed of the equivalent scriptlet ). Going after 'real life applications' when the simple hello world tag, or a simple empty jsp page has a clear performance penalty would be a waste of time. ( all that with a reasonable load - I sugest 80 concurent requests ) Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Jasper2
I am opening the discussion in [EMAIL PROTECTED], if you don't mind. I think there are others who may be interested in the topic. jasper2 is in jakarta-tomcat-jasper. You'll need to build jakarta-tomcat-4.0 first, and then jasper2. It just drops the jar files into tomcat build area. Ignore jasper34 in that branch. Be warned that jasper2 is still under development, so it's quality is not release product quality yet. Also, it generates pretty much the same code as tomcat 4.x, for now; so expect comparable performance. Of course we'll need to change that! :-) It's great that you are doing performance evaluation for different versions of tomcat. Can your jstl run in tc3 and tc4 without change? Can we separated performance attributed to containers as opposed to those attributed to jasper? For those jasper performance, how can we identify the most profitable improvements that we should do? - kin-man Date: Wed, 03 Apr 2002 07:29:32 -0500 From: peter lin [EMAIL PROTECTED] Subject: Jasper2 To: Kin-Man Chung [EMAIL PROTECTED] MIME-version: 1.0 Content-transfer-encoding: 7bit X-Accept-Language: en-US hi kin-man, I was planning on checking your latest jasper2 today/tomorrow and compare it against tc3.3 jasper and tc4.0.3 jasper. which branch should I check out to grab jasper 2. As part of my own research, I was planning on writing a complete dynamic website for managing personal photo-albums using scriptlets, beans and jstl. that way I have the same exact site implemented three different ways for performance evaluation. thanks peter Kin-Man Chung wrote: I plan to work on jasper performance, especially those related taglibs. But I want to clean up jasper first, before I tackle the performance. Are you convinced that tag pooling is the answer? First you have the cost of monitor locks; then you also need to go thru hashtable to find the tag from the pool (I assume that's how it works here), and this is cheaper than calling the tag constructor? Can you do some measurements? I think we should attack the iteration tags first. If we can move the loop invariants out of the loop, we would have solved the tag reuse problem. If you are interested in jasper performance, I'd be very glad to work together with you; but let make sure that jasper2 is stable first. Thanks. Date: Tue, 02 Apr 2002 11:37:35 -0500 From: peter lin [EMAIL PROTECTED] Subject: Jasper2 To: Kin-Man Chung [EMAIL PROTECTED] MIME-version: 1.0 Content-transfer-encoding: 7bit X-Accept-Language: en-US hi kin-man, I was planning on porting the tag pool in jasper 3.3 to tomcat 4, until someone mentioned you're working on jasper 2. Are you planning on adding tag pooling? if you are, I can help port the tag pooling to it. peter lin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Jspc documentation
Kin-Man, I have a side question. I am looking for the documentation /comments on the Jasper compiler(jspc)-I have looked through the JspC.java but there are no comment about different compiler options. I wondering if you can point me in a right direction. Thank you. Leo Hmm.. you are right, jspc documentation is hard to find. :-) The only thing I can find is jakarta-tomcat-4.0/jasper/doc/jspc.html. I just read it, and it's still pretty up to date. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Jasper2
Good for you, Remy! Actually, I've already done the optimization for the runtime and it is very significant for simple pages (see my commits last week); when the page does run, it does it very fast now. There's no hotspot left in the runtime (according to OptimizeIt; of course, it won't help taglibs reuse in any way), the rest is up to the compiler. Good for you, Remy! I had problems with the new compiler / runtime environment though (for ex, the include example doesn't work, and the admin webapp can't compile), so it's not ready yet. Like I said, it still needs work. I am going to run those in tester and watchdog to fix them all! :-) I think I've done the part on the container improvements (at least, the additional tweaks won't bring any big performance increase now); the rest seems up to the compiler. Remy Tomcat 4 is still significantly slower than tomcat 3, based on some performance tests Prasad ran. Is this because of the added support for the new servlet and jsp or what? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Jasper2
[EMAIL PROTECTED] wrote: I had problems with the new compiler / runtime environment though (for ex, the include example doesn't work, and the admin webapp can't compile), so it's not ready yet. The include example is wrong in that it includes a page directive %@ page buffer=5 autoFlush=false % The spec says the value of a buffer attribute in the page directive should be suffixed with a mandatory kb. jasper2 just conforms the spec better. :) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit:jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler Node.java
Remy,
I afraid that this patch won't work, because you are initializing
CustomTag.JspAttrs in the constructor, which is too early.
CustomTag.JspAttrs is currently set in Validator, after tld is consulted
to see if the tag attribute can take a request time expression;
and if so, extracts the string between '%=' and '%' etc.
Do you have a test case that causes a NPE?
Date: Thu, 04 Apr 2002 07:03:55 +
From: [EMAIL PROTECTED]
Subject: cvs commit:
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler Node.java
To: [EMAIL PROTECTED]
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
remm02/04/03 23:03:54
Modified:jasper2/src/share/org/apache/jasper/compiler Node.java
Log:
- Fix NPE caused by JSP attributes field not being populated.
Revision ChangesPath
1.2 +8 -3
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Node.java
Index: Node.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Nod
e.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- Node.java 28 Mar 2002 18:46:16 - 1.1
+++ Node.java 4 Apr 2002 07:03:54 - 1.2
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Nod
e.java,v 1.1 2002/03/28 18:46:16 kinman Exp $
- * $Revision: 1.1 $
- * $Date: 2002/03/28 18:46:16 $
+ * $Header:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Nod
e.java,v 1.2 2002/04/04 07:03:54 remm Exp $
+ * $Revision: 1.2 $
+ * $Date: 2002/04/04 07:03:54 $
*
*
*
@@ -663,6 +663,11 @@
this.name = name;
this.prefix = prefix;
this.shortName = shortName;
+jspAttrs = new JspAttribute[attrs.getLength()];
+for (int i = 0; i attrs.getLength(); i++) {
+jspAttrs[i] = new JspAttribute
+(attrs.getLocalName(i), attrs.getValue(i), false);
+}
}
public void accept(Visitor v) throws JasperException {
--
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: cvs commit:jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler Node.java
Date: Thu, 04 Apr 2002 11:20:21 -0800 From: Remy Maucherat [EMAIL PROTECTED] Subject: Re: cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler Node.java To: Tomcat Developers List [EMAIL PROTECTED] MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600. Content-transfer-encoding: 7bit X-Priority: 3 X-MSMail-priority: Normal Delivered-to: mailing list [EMAIL PROTECTED] Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm X-Spam-Rating: localhost.apache.org 1.6.2 0/1000/N 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 Remy, I afraid that this patch won't work, because you are initializing CustomTag.JspAttrs in the constructor, which is too early. CustomTag.JspAttrs is currently set in Validator, after tld is consulted to see if the tag attribute can take a request time expression; and if so, extracts the string between '%=' and '%' etc. The patch is super easy to revert. My problem is that I don't understand anything to the new generator design, so the patch is bad. That's OK. It always takes a while to get into a new piece of code. The new jasper design is really very simple. There are currently only 3 pieces that matters: Parser, Validator, and Generator, representing the 3 phases of the compiler. Parser is reponsible for parsing the page, making sure that the grammar is followed, and generating a list of Nodes. Validator is for checking the validity of the attributes and putting the valid attributes into digested formats, of which CustomTag.JspAttrs is one of them. Generator is for generating the servlet program from the Nodes. We'll probably add a Optimizer phase to jasper later. Do you have a test case that causes a NPE? Just try to run the admin webapp (and click on some tree node; there are also some other small issues with the user admin pages). I'll do that and try to fix it. Thanks for trying out jasper2. 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]
Re: [PATCH] possible speed enhancement to JspServlet.java
Duncan, I looked at your patch carefully, looks like Remy's work on jasper2 already addressed the issues that you are trying to solved. In fact, Remy only creates a compiler for the container, whereas you would have created a compiler for each jsp page. OTOH, you save the modification date for each page in a hashtable, so is potentially faster when checking whether a jsp needs to be send to the compiler. I may incoporate your idea on this one later, maybe reusing the JspServletWrapper class instead of using another hashtabl, since that **IS** a per page object. Thanks again for the patch. If you wish, you should try running with japser2, and compare its performance with the one you patched. Date: Fri, 19 Apr 2002 16:58:54 -0700 (PDT) From: Kin-Man Chung [EMAIL PROTECTED] Subject: Re: [PATCH] possible speed enhancement to JspServlet.java To: [EMAIL PROTECTED] MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-MD5: Pd6UqZXWO7AIRUPw9V+AAQ== 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 Thank you for the patch! It looks interesting! I'll definitely look at it carefully and apply it to jasper or jasper2 when I have time, most probably sometime next week. Date: Fri, 19 Apr 2002 17:09:49 -0400 From: Duncan McLean [EMAIL PROTECTED] Subject: [PATCH] possible speed enhancement to JspServlet.java To: Tomcat Developers List [EMAIL PROTECTED] MIME-version: 1.0 Content-transfer-encoding: 7bit X-Accept-Language: en,pdf Delivered-to: mailing list [EMAIL PROTECTED] Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:0.9.4.1) Gecko/20020314 Netscape6/6.2.2 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 I'm new to this list (and the jasper code), so please let me know if I've submitted this incorrectly. I was doing some profiling of the server side environment that I work on and noticed that quite a bit of time was being used in the JSP engine. After further investigation I noticed that each JSP request that comes into the jasper engine generates a new compiler object and attempt at compilation. As much as 15% of the time of a JSP request is wasted this way. The change I made attempts to read the last modified date from the JSP file being request. A comparison is made against known last modified time for the current compiled version, if they are different then the code flows as it used to. If the times are the same then the rest of loadJSP is skipped. In my test application which relies on calling ~10 jsp files to generate a single page I found a speed improvement of ~25-50ms (on a PIII 650). There may be better ways to do this. I concentrated my fix here because it is where the profiler said the problem was. One drawback of the code I'm submitting is that if there are a large number of JSP's the Hashtable I use to store information may get large. However I can't see that being a problem until a site has 10,000 jsp's. The change I'm submitting may not be the correct way to approach the problem. Either way I think this is an issue that deserves some attention so if someone can suggest a better fix please do. -- 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: [PROPOSAL] jasper2 detection of compile time page include changes
+1 on the idea. With minor changes, we can also implement a compiler server that compiles out-of-date pages in the background thread. This would greatly improve the response time for accessing the pages, when recompilations are needed. Date: Wed, 24 Apr 2002 10:52:51 -0500 From: Glenn Nielsen [EMAIL PROTECTED] Subject: [PROPOSAL] jasper2 detection of compile time page include changes To: [EMAIL PROTECTED] MIME-version: 1.0 Content-transfer-encoding: 7bit X-Accept-Language: en 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 A common problem Tomcat users have is that Jasper does not detect when a compile time included file %@include file=...% changes so that it can recompile dependent JSP pages. This propsoal maps out a possible solution for this. Create a new class (JspDependency) which is used to store mapping of JSP pages to dependent compile time included files. This class will be created for each web application context and the data it depends upon serialized to a special file in the work directory on context stop, and read from that file on context startup. Proposed filename is JSP_DEPENDENCY.ser. Here is how this integrates into Jasper: On context start instantiate a JspDependency object and read in the dependencies from JSP_DEPENDENCY.ser. If there are dependencies, start a background thread which checks for changes in compile time included files once each 5-15 minutes. Perhaps make this configurable. If changes are detected, set flags for dependent JSP pages which are affected. Using a thread to accomplish this rather than having JSP Load do the dependency checks should reduce the request latency overhead for detecting these changes. The JSP Load method will call a method in JspDependency to determine whether the current page needs to be recompiled due to dependency changes. This will just be a quick test of a boolean, actual dependency checks are done by the background thread. The JSP page compiler will call a method in JspDependency to remove all dependencies for the current JSP page on compile start, then call an add method for each compile time include dependency found. After a JSP page compile has completed any changes to dependencies are written back out to the JSP_DEPENDENCY.ser file. Comments or suggestions? Regards, Glenn -- Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | -- -- 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: JSP no reload
It is currently not an option to turn off checking out-of-date jsp pages that triggers recompilations. There has been some efforts recently at speeding up this area in jasper2 (Remy'work, Duncan's patch for timestamp cache, and my recent mods), so you may want to try jasper2 to see if performans better. I think a more useful options is to enable deployment of jsp pages without sources. I sure that'll break the spec though, so I don't know if that idea should be persued. Date: Wed, 24 Apr 2002 22:39:59 -0400 From: Samuel Gabriel [EMAIL PROTECTED] Subject: JSP no reload To: Tomcat Developers List [EMAIL PROTECTED] MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600. Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal 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 Hi All, Is there is a setting in Jasper to disable Tomcat from checking the timestamp on the page everytime there is a request? It seems important as the more include files are there in the JSP page the more checking that could happen, additionaly due to the nature of Java creating a File object and check the file system each time could be an expensive process. Regards Sam -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PATCH] Re: [PROPOSAL] Modification of the code generated byJasper2
See intermixed.
Date: Thu, 09 May 2002 20:48:27 -0400 (EDT)
From: Denis Benoit [EMAIL PROTECTED]
Subject: Re: [PATCH] Re: [PROPOSAL] Modification of the code generated by
Jasper2
Good idea, but I think it would be hard to accomplish as presented. Look
again
at your pseudo-code:
int state = 0;
// try {// 1st try
++state;
...
// try {// 2nd try
++state;
;;;
// }// end of 2nd try
--state;
// try {// 3rd try
++state;
;;;
// }// end of 2nd try
--state;
// }// end of 1st try
You'll notice that both state 2 and state 3 have the value 2 assigned to the
state variable. What is complex here, is that it is hard to find a generic
way to represent all the states possible. Sometimes the states are nested,
like the first with the 2nd and 3rd. Sometimes the states follow one another,
like the second and third.
I realized my mistake as soon as I sent it out. :-)
But there is surely something to do. Suppose we assign distinct values to
the state variable at each step where we enter a pseudo try and a
pseudo finally. Then, theoritically, it should be possible to determine
in the finallies method, just by looking at the value of the state variable
what remains to do. The problem could be to do it in exactly the same order
that would have been done if the page would have nested try/finally clauses.
If we have distinct values for each state, theorectically we can implement
a state transition machine in the finallies. Something like the following.
while (state 0) {
switch (state) {
case 0: ...
state = 3; break; // goto state 3
case 1:
state = 13; break; // goto state 13
...
case 10: ...
state = -1; break // stop
}
}
This way we can specify any sequence we want. Of course there are various
optimizations that one can do here, but I won't go into them here.
If we look at what we have to do in the finallies method, we have
essentially
two types of method call. Either the popBody() or the release() of a Tag.
I'm certainly not expert enough with the JSP specs to take a decision. Is it
critical that we call the release() of the tags in the proper order, if all
what's left to do is release() calls? What about the popBody()?
popBody() simulates popping stacks, and has to be called in order.
If we could do the popBody() calls out of order, say after all the
release()
have been called, then the case of the popBody() is easy to deal with. We
just have to increment a counter for each pushBody() calls and decrement
it after each popBody() calls. In the finallies method we only have to
call popBody() the number of times the value of the counter. If so, the
state variable would only to have to represent the different combinations that
the tags doStartTag() have been called and if their respective release()
have been called.
Unfortunately we cannot call release() before calling popBody(), because
popBody() may use resources released by release(). (I'll need to check
that).
I'm a little cautious about inlining the finallies method, because of
java's 64K per method limitation. One of the first pass of my test JSP did
generate over 64K in the _jsp_service method, so it generated an Invalid
branch exception or something named like that. Once I removed a few tags,
the page worked fine. It's easy to bypass by JSP include, but some people
might find the message cryptic (it is!), to determine what's exactly the
problem. The _jsp_service method can be really long, even without the
finallies being inlined. That's why I had created a new method.
There maybe other ways to branch out part of the code in _jspService to
a method. I am considering moving the body of a tag that does not have
scriptlets out; but that's just a thought at this moments.
Even if we do keep finallies, it may worth looking into passing all the
necessary objects as arguments to it, instead of putting them in a Vector,
at least for the case with samll number of states. I think VM spec allows
256 arguments to a method. :-) We want to avoid unnecessay codes in
the main flow, but can afford to work harder when exceptions occur.
Your idea of getting information from the PageInfo is certainly welcome. This
way we could prevent the creation of the finallies method and
addTagToVector. We could even replace the Vector by an Array that could be
allocated to the proper size at the start of the method. It would prevent to
have to cope with the expansion of a Vector. Your idea of the state
variable,
merit more thought. There may be a way to use it.
Collecting information to PageInfo requires a speparate pass prior to
code
Switching javac for jasper 2
Tomcat has been using sun.tools.javac.Main as the default java compiler for compiling the java files generated by Jasper. This compiler is essentially a JDK1.2 compiler, current deprecated and unsupported. The warning message Note: sun.tools.javac.Main has been deprecated is probably familiar to a lot of people. The compiler to use is com.sun.tools.javac.Main. The only thing that prevented us from switching over to this one is the fact that it does not allow a PrintWriter to be specified for error messages that it may produce, which essentially force tomcat to synchronize all compilation processes, a big performance hit. I believe that J2sdk1.4.1, currently targetted for FCS in fall 2002, will provide a javac.Main which allows us to specify a PrintWriter, essentially removing the need for synchronizing the compilation. We definitely will use that when it becomes available. However, I recently runs into problem with sun.tools.javac.Main which surfaces when a jsp page gets large. Sometimes it produces bogus errors, and somteitmes it even produces bad class files that cannot be loaded by VM. I am contemplating switching over to using com.sun.tools.javac.Main now, for 4.1 (jasper2). If there are objections, please let me know. BTW, anyone know the best way to capture javac error messages written to standard err stream? I want to avoid calling Runtime.getRuntime().exec if there is a way. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PATCH] Re: [PROPOSAL] Modification of the code generated byJasper2
Denis,
First let me mention a couple of improvements over the existing codes
that was generated for flattening out the try/catch block. See if
you agree with me.
1. I notice the following code pattern that is now generated.
bitmask.set(1);
addTagToVector(tags, 1, new Integer(_jspx_eval_eg_foo_0));
if (_jspx_eval_eg_foo_0 != javax.servlet.jsp.tagext.Tag.EVAL_BODY_INCLUD
E) {
out = pageContext.pushBody();
_jspx_th_eg_foo_0.setBodyContent((javax.servlet.jsp.tagext.BodyContent
) out);
_jspx_th_eg_foo_0.doInitBody();
}
and from finallies:
if (bitmask.get(1)) {
if (((Integer)tags.elementAt(1)).intValue() != javax.servlet.jsp.tagext.Ta
g.EVAL_BODY_INCLUDE)
out = pageContext.popBody();
}
I notice that the code bitmask.set(1); is there just for popBody, so
if we move it to inside the test that do pushBody, then we don't need
to do the test in the finallies. See the codes below.
addTagToVector(tags, 1, new Integer(_jspx_eval_eg_foo_0));
if (_jspx_eval_eg_foo_0 != javax.servlet.jsp.tagext.Tag.EVAL_BODY_INCLUD
E) {
bitmask.set(1);
out = pageContext.pushBody();
_jspx_th_eg_foo_0.setBodyContent((javax.servlet.jsp.tagext.BodyContent
) out);
_jspx_th_eg_foo_0.doInitBody();
}
and in finallies:
if (bitmask.get(1)) {
out = pageContext.popBody();
}
Maybe you don't need to change the argument for addTagToVector afterall!
2. We don't really need to call finallies if there is no exceptions, so
the call to finallies can be placed in a catch block instead of a finally
block. This would save us time to check for all the bits that have been
cleared, under normal execution.
Now you mentioned the use of an array to hold tag objects, I have
another idea. Why don't we use a stack to simulate the runtime state?
Each stack entry would have a tag object and a state. State 0 means
call release() only, and state 1 means call popBody() and then release().
We push an entry onto the stack when we enter a tag body, and pop it
when we exit the body. We change the state on the stack top when we do
a pushBody. When an exception is thrown, we just need to pop the entries
from the stack to decide what to do. For efficiency, we can use an
array to simulate the stack, and its size would be the number of nesting
of the tags.
I think this is quite simple and faster. What do you think?
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Switching javac for jasper 2
See below. Date: Thu, 16 May 2002 14:07:36 -0700 (PDT) From: [EMAIL PROTECTED] Subject: Re: Switching javac for jasper 2 X-X-Sender: [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED], Kin-Man Chung [EMAIL PROTECTED] MIME-version: 1.0 Delivered-to: mailing list [EMAIL PROTECTED] Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm X-Antivirus: nagoya (v4198 created Apr 24 2002) X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Authentication-warning: costinm.sfo.covalent.net: costin owned process doing -bs 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 com.sun.tools.javac.Main doesn't seem to be in JDK1.2.x, and that's the target platform, isn't it ? I believe for 4.1.x, it should be 1.3.1 and above. Like I said, 1.2 javac is currently unsupported and deprecated in 1.3 and 1.4, and contain bugs that are hard to work around. Can't image people currently using jdk1.2 wouldn't want to upgrade. I think the best solution for javac is to just bundle ant.jar and use it programmatically ( i.e. new Javac(), etc ). The introspection and hacks required to support multiple compilers are just too ugly - and they already have good solutions in ant. I'll look into that. But even if ant.jar is used programmatically, eventually it still start another process to invoke javac, right? Plus it's yet another jar to be bundled with tomcat; do we really want that? What do others think? We already have enough complexity to support jikes. Costin - Kin-man On Thu, 16 May 2002, Kin-Man Chung wrote: Tomcat has been using sun.tools.javac.Main as the default java compiler for compiling the java files generated by Jasper. This compiler is essentially a JDK1.2 compiler, current deprecated and unsupported. The warning message Note: sun.tools.javac.Main has been deprecated is probably familiar to a lot of people. The compiler to use is com.sun.tools.javac.Main. The only thing that prevented us from switching over to this one is the fact that it does not allow a PrintWriter to be specified for error messages that it may produce, which essentially force tomcat to synchronize all compilation processes, a big performance hit. I believe that J2sdk1.4.1, currently targetted for FCS in fall 2002, will provide a javac.Main which allows us to specify a PrintWriter, essentially removing the need for synchronizing the compilation. We definitely will use that when it becomes available. However, I recently runs into problem with sun.tools.javac.Main which surfaces when a jsp page gets large. Sometimes it produces bogus errors, and somteitmes it even produces bad class files that cannot be loaded by VM. I am contemplating switching over to using com.sun.tools.javac.Main now, for 4.1 (jasper2). If there are objections, please let me know. BTW, anyone know the best way to capture javac error messages written to standard err stream? I want to avoid calling Runtime.getRuntime().exec if there is a way. -- 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: [Kin-Man] Jasper compiling wrong stuff in the wrong place...
Pier, Long time no see/talk/eamil. How are you? Haven't seen that before, and no idea why it's so. You'll need to give me a test case. Why aren't you using jasper2 instead? Glenn's recompilation stuff works great! - Kin-man Date: Fri, 17 May 2002 11:54:38 +0100 From: Pier Fumagalli [EMAIL PROTECTED] Subject: [Kin-Man] Jasper compiling wrong stuff in the wrong place... To: Tomcat Developers List [EMAIL PROTECTED] MIME-version: 1.0 Content-transfer-encoding: 7bit Delivered-to: mailing list [EMAIL PROTECTED] Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm User-Agent: Microsoft-Entourage/10.0.0.1331 X-Antivirus: nagoya (v4198 created Apr 24 2002) 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 When I touch the clsr.jsp jsp example with Tomcat 4.0.4 (and before), Jasper tries to compile also the bean associated with it (although it wasn't modified)... My only problem is that it tries to compile it in the /WEB-INF/ directory of the application (and it doesn't have permissions to write there), so, at the end, it's just throwing me a 500 error... Any clue on why Jasper should be trying to compile a .java into the WEB-INF/classes directory? I mean, even if it is javac trying to do that, giving it the -d parameter, it should always write anything in the work directory, right? Pier -- 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] Re: [PROPOSAL] Modification of the code generated byJasper2
Denis,
Glad that you agree. About the timing for the patch, I think now is OK.
Jasper 2 is fairly stable and the only bug that may interact with our
fix is 4964 and I already have a fix for it; but am hold off committing
it because struts depends on this bug, and my fix would break it! :-(
Now down to details. :-)
Since a popBody is always followed by a release, it would be simpler
to have each stack element consists of two entries:
1. the tag, and
2. the state: 0 - release only
1 - popBody and release.
That way we only need to do one push per tag handler. Of course, all
tags would get state 0 first, and some of them would change to state 1
later.
For efficiency we can use two separate arrays for implementing the
stack: one for holding the tags, the other for keeping track of the state.
The code generated would be like:
stackIndex = -1;
...
++stackIndex; // Entering a tag
MyTag mt = new MyTag();
tagStack[stackIndex] = mt;
stateStack[stackIndex] = 0; // state 0
if (_jspx_eval_myTag != EVAL_BODY_INCLUDE) {
stateStack[stackIndex] = 1;
...
}
...
--currentIndex; // Exiting a tag
This way, the size of the stack is the maximum number of nesting of the
tags, which should much smaller than the number of tags in the page.
Such information is easy to collect in Jasper 2, which can be
done either in Validator.java, or we have a separate pass whose sole
purpose is to collect info such as this.
- Kin-man
Date: Thu, 16 May 2002 23:16:15 -0400 (EDT)
From: Denis Benoit [EMAIL PROTECTED]
Subject: Re: [PATCH] Re: [PROPOSAL] Modification of the code generated by
Jasper2
To: Kin-Man Chung [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
MIME-version: 1.0
Now you mentioned the use of an array to hold tag objects, I have
another idea. Why don't we use a stack to simulate the runtime state?
Each stack entry would have a tag object and a state. State 0 means
call release() only, and state 1 means call popBody() and then release().
We push an entry onto the stack when we enter a tag body, and pop it
when we exit the body. We change the state on the stack top when we do
a pushBody. When an exception is thrown, we just need to pop the entries
from the stack to decide what to do. For efficiency, we can use an
array to simulate the stack, and its size would be the number of nesting
of the tags.
I think this is quite simple and faster. What do you think?
Yes! Yes!
In my last e-mail, I mentionned that there is only two actions that we need
to do in the finallies. This is:
1) do a release() on a Tag
2) do a popBody()
We could push on the stack in this order:
Either:
1- A tag
2- The Action identifier for release (a Constant representing
release())
Or:
1- The Action identifier for popBody (a Constant representing
popBody())
Now the finallies code look like this:
While stack is not empty:
Pop an action
If action is RELEASE then
pop a Tag
Do a Tag.release()
Otherwise /* Action is assumed to be POPBODY */
do a popBody()
So the finallies could very well be inlined because it would be short.
The other modification would be when we begin the pseudo finally block. At
that point we have to remove from the stack what was pushed at the begin of
the pseudo try block. If we do a popBody() in the finally, then we must
pop one element. If we do a release(), we will pop two elements.
In the event of an exception anywhere in the page, the stack would contain
only the actions that must be performed in the order to be performed. Your
solution is clean, efficient and simple!
The stack could very well be an Object[], but if we must rely on arrayCopy(),
to extend the array periodically, would it be really much more efficient than
using a plain Stack object? After all, this is the way a Stack is implemented
by the JDK itself. On the other hand, we know the lower and upper bounds of
the
stack. Each tag will need to be pushed at least once for the release() and
the action identifier will need to be pushed too (so we push two times the
number of Tags in the page). And maybe we will need to push once more for a
popBody() (so one more time to indicate the action).
This would give us an array of size 2 to 3 times the number of tags in the
page.
I think it would be more efficient to allocate an array of 3 times the number
of
tags and save us the occasional overhead of arrayCopy() calls to extend the
array.
Now, I see two ways to determine the size of the array. Either, after
generating the _jsp_service() method, the class Generator could produce the
declaration
Re: [PATCH] Re: [PROPOSAL] Modification of the code generated byJasper2
Now, about the level of nesting, shouldn't the information be available through the PageInfo object? After all, the purpose of this class is A repository for various info about the page under compilation. And Generator currently has access to an instance of it. So, if PageInfo had something like a public int getTagElementsMaxNestingLevel() method, Generator could use it to allocate the arrays. Yes, the information will be available throught PageInfo object, and which is updated in either Validator or Collector (I just make this up). We have two changes on the table: 1. Get the information about the level of the nesting with Visitor, or a separate pass; 2. Remove the finallies and replace it with the two state arrays; For #2, I'm confident that I could do it without problem. For the #1, well, I've taken a quick look at Visitor, but the change seems to me far less obvious. The way I see it, in the constructor we initialize the nesting to zero. Each time: public void visit(Node.CustomTag n) throws JasperException is called we increment the nesting, and right after the call visitBody(n);, just before the method terminate we decrement the nesting count. Obviously, we must keep track of the maximum depth level. The information is ready to be used at the end of the: public static void validate(Compiler compiler, ... method, this is the one that initiates the visit(XXX) calls, right?. Would you like me to propose a patch for #1? For #2? And what about having the maximum CustomTag nesting depth level available through PageInfo? I'll implement maximum tag nesting (though PageInfo) and you can work on #1. Deal? Thanks! Thanks. -- Denis Benoit [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [Kin-Man] Jasper compiling wrong stuff in the wrong place...
Haven't seen that before, and no idea why it's so. You'll need to give me a test case. Test case: touch $CATALINA_HOME/webapps/examples/jsp/colors/colrs.jsp So that Jasper will have to recompile it, and it will try (the first time) to recompile also: $CATALINA_HOME/webapps/examples/WEB-INF/classes/colors/ColorGameBean.java But putting its class back into $CATALINA_HOME/webapps/examples/WEB-INF/classes/colors/ColorGameBean.class Not into $CATALINA_HOME/work/.. That's pretty nasty, as the user under which the Tomcat process is running is not (and can not) write into $CATALINA_HOME/webapps/. I tried that, and couldn't seem to reproduce your problem. I tried both the head branch and the 4.0 branch, on Solaris, there was no recompilation of ColorGameBean.class. What configurations do you have? I looked at the code, and couldn't find the place that would cause the recompilation of the bean classes. Would appreciate if anyone else have insights to this puzzle. :-) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PROPOSAL] Tomcat 4 System.err/System.out logging
However, I'd like to point out that there's no other choice but to upgrade. In many situations, the current Jasper 2 generated servlets don't compile to valid bytecode when using the classic compiler (and you get a VerifyError when loading the class; this happens esp when using JSTL). The J2SE team hasn't touched the old compiler code for more than 2 years, and refuse to fix bugs :-( I'm wondering how hard it would be to use BCEL associated with some extended JavaCC grammar for JSPs... Bah... Pier A distinct possibility, at least for the pages where scriptlets are not used, in which case JavaCC would not be even needed. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] New committer: Denis Benoit
+1 Welcome! And looking forward to working more with you on Jasper performance! Date: Tue, 21 May 2002 19:33:27 -0700 From: Remy Maucherat [EMAIL PROTECTED] Subject: [VOTE] New committer: Denis Benoit To: [EMAIL PROTECTED] MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600. Content-transfer-encoding: 7bit X-Priority: 3 X-MSMail-priority: Normal Delivered-to: mailing list [EMAIL PROTECTED] Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm X-Antivirus: nagoya (v4198 created Apr 24 2002) X-Spam-Rating: localhost.apache.org 1.6.2 0/1000/N 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 I'd like to propose Denis Benoit Denis.Benoit at fbn.ca as a committer on the Tomcat project. Denis has contributed patches to Jasper 2 which brings an impressive performance improvement when using JSP pages which rely heavily on tags, such as the administration web application available in Tomcat 4.1.x. He appears willing to spend time to further improve Jasper 2 performance. He has my +1 as a committer. 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]
Re: [Proposal] Removing 64K limit in jasper 2
I am still in vacation mode, unil Thursday. Just want to giva some quick response. Like Costin, I don't think that there would be much performance penalty by calling a private method. In fact, if we want to reduce the number of unnecessary calls, I have another idea... well I have two ideas, one of which is not related to the 64 K limit. The performance hit comes not only from the extra calls, but also from the local instances (e.g. out and tagStack) that need to be passed to the methods. Also the increase in the number of methods in a class cannot be good to VM performance. Let's hope that Hotspot can do good job here. We'll have to see. 1. In the generated page, there is a lot of consecutive: out.write(some string); out.write(another string); and so on. Why don't we merge all these consecutive strings together? out.write(some string\nanother string); it would greatly reduce the number of write() calls. So it would contribute, in a limited way to reduce the size of the _jsp_service() method. It would be sligthly faster, which is not bad :) by reducing the number of method calls. This is actually in my plan. It would be relative easy to collapse consecutive writes. We should also consider the performance issues Costin raised, and maybe redo the runtime library to achieve better performance in writing out the String/char[] area. The key here is to avoid unnecessary copying. 2. This one has nothing to do with the size, it's just something that I think we should plan for: tag reuse. Some of the pages that have a lot of tags, do so because they have them in an HTML table. A big page can reference 80 or so tags, but these tags can represent only four or five distinct types. It is not so difficult to find 80 tags in a page, but it would be difficult to find one with 80 _distinct_ tag classes! Most of these tags could be reused, that is we often call: tag1 = new SomeTag(); tag1.doStartTag(); tag1.doEndTag(); tag1.release(); tag2 = new SomeTag(); tag2.doStartTag(); tag2.doEndTag(); tag2.release(); There is no real reason to create a new tag for tag2, it could have been replaced by: tag1 = new SomeTag(); tag1.doStartTag(); tag1.doEndTag(); tag1.doStartTag(); tag1.doEndTag(); tag1.release(); Here is the relevant section of the JSP specs (I know Kin-Man, you don't need a reminder, but others might :): public void release() Called on a Tag handler to release state. The page compiler guarantees that JSP page implementation objects will invoke this method on all tag handlers, but there may be multiple invocations on doStartTag and doEndTag in between. So, the specs seem to imply that tag reuse is allowed. Now, why do I brought about this second point, if it is not relevant to the 64K limit? Just that whatever the solution we'll take to address the issue, it should not make tag reuse impossible. I agree with Kin-Man, Tag will take more importance in the future of JSP pages. So we must take whatever measures to optimize them. Most tags won't see a big performance boost from reuse, but some tags can be pretty hefty, and for them, tag reuse can be a big factor. Believe it or not, tag reuse is also in my plan. I am in active discussion with Jan Leuhe in the very topic, and we'll have a proposal soon. Our scheme is very different from the one used in tomcat 3. We want to have a simple scheme that can reuse tag in the current page, especially tags in loops. More about this later. Therefore I would not do anything now that'll make doing tag reuse harder. :-) Now, there were two approach to the 64K problem. Kin-Man proposed creating methods for each custom tags, and Costin proposed a state machine. I tend to agree with Kin-Man for one account, at the current state of the compiler, Kin-Man's method could be done faster. I don't think we should throw away the state machine implementation, but I see it more as a Jasper 3 / Tomcat 5 thing :) At that time, it could be further investigated the benefits and penalties of this approach. But if we choose to delegate each tag to a method, I think it would be important to leave the door open to tag reuse, that is if we do not implement it at the same time. Interpreters with state machines may work well for scriptless pages, and would be an interesting project. It is however not my current focus for now. Comments? -- Denis Benoit [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: [PROPOSAL] Tag pooling/reuse in Jasper 2
I think it a good idea to limit the stacks to some reasonable value. One easy way of accomplishing this is to add a tag object to the stack only when its stack has not reach its maximum size. The neat thing about these two approaches is that they can both be implemented. Once a tag object is obtained from the stack, the compiler can assign it to a local variable, and reuse that local variable for another tag handler in the same page, if needed. The compiler has full control over when a tag object returns to the pool (stack). Like Jan said, we intended to do such optimization for tags in iteration bodies. I know Peter Lin is very interest in this area, and has tools and applications for measuring performance. It'd be good if Peter can run them again after we put back our mods, and tell us what other areas that need to be worked on. - Kin-man Date: Sat, 01 Jun 2002 18:59:14 -0400 (EDT) From: Denis Benoit [EMAIL PROTECTED] Subject: Re: [PROPOSAL] Tag pooling/reuse in Jasper 2 To: Tomcat Developers List [EMAIL PROTECTED], Jan Luehe [EMAIL PROTECTED] MIME-version: 1.0 Delivered-to: mailing list [EMAIL PROTECTED] Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm X-Antivirus: nagoya (v4198 created Apr 24 2002) 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 Hi, For my part, I'm a little concerned about the second approach. If there is a lot of pages with a lot of distinct tags; tags libraries are catching on fast; there may be a problem where Jasper would cache a lot of tags. If there is a sudden burst of use of a given page, the stacks of the tags used by that page could grow significantly. This memory would never be released. If there was some way where the stack could throw away excess tags, then this approach would be very good indeed. The idea I have in mind is the way the Apache 2.X HTTP server manages instances. When some instances have not been used for some time, it starts to shut them down until it reaches the MaxSpareServer number of instances. This way, a sudden burst of use of the web server does not clog the process table or the memory of the machine. This principle was very good. Something similar could very well be as successfull with tag pooling. This is just my .02 On Fri, 31 May 2002, Jan Luehe wrote: Kin-Man and I have been throwing around some ideas of how to support tag pooling and reuse in Jasper 2. According to the spec, only tags with the same set of attributes may be reused (see JSP.10.1.1, p.163, Lifecycle section, item 3): [3] Note that since there are no guarantees on the state of the properties, a tag handler that had some optional properties set can only be reused if those properties are set to a new (known) value. This means that tag handlers can only be reused within the same AttSet (set of attributes that have been set). This means that while the same tag handler instance may be used to service these tags: some_prefix:some_tag a=1 b=2/ some_prefix:some_tag a=1 b=3/ some_prefix:some_tag a=1 b=4/ some_prefix:some_tag a=1 b=5/ it may not be used to service some_prefix:some_tag a=1 b=5 c=3/ One of the ideas we have considered is to support tag reuse on a per-page basis, without allowing tag handlers to be shared across simultaneous page invocations. In this approach, each custom tag is assigned a tag handler variable name at compile time, based on its full name, its attribute names, and its nesting level (with respect to tags with the same name and AttSet). According to this, the two prefix1:tag1 tags in: prefix1:tag1 a=1 b=2/ prefix2:tag2 c=1 d=2 prefix1:tag1 a=1 b=2/ /prefix2:tag2 would be assigned the same tag handler variable name (both are at nesting level 0 with respect to their tag class), whereas the two prefix1:tag1 tags in: prefix1:tag1 a=1 b=2 prefix2:tag2 c=1 d=2 prefix1:tag1 a=1 b=2/ /prefix2:tag2 /prefix1:tag1 would be assigned different tag handler variable names, because they are at different nesting levels. All tag handler variables determined in this fashion would be declared as (local) variables at the beginning of the _jspService() method. The advantages of this approach would be: - No need for synchronization. - Tag handler reuse is determined at compile time. Disadvantages would be: - Tag handlers are not shared across multiple page invocations. - Does not work well with the proposed approach to remove the 64K limit, since a (possibly large) number of tag handlers would have to be passed as arguments to (sub)method calls.
Re: [VOTE] Rate milestone 4.1.3
ballot [ ] Alpha [X] Beta /ballot 4.1.3 should be feature complete (at least according to what is in the release plan; it now has the Ant compiler in Jasper 2 and a more finalized admin webapp), and does not seem to have any major issues, so it looks like a decent beta candidate. Comments ? Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
JspException in jasper 2?
org.apache.jasper.runtime.JspException seems to be serving no purpose, and it conflicts with javax.servlet.jsp.JspException. Any objections to my removing it? BTW, it also exists in tomcat 4/jasper. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Jsp compilation of nested custom tags (porting from weblogic 6 totomcat 4.0.3)
I assume that lOffset is a scripting variable defined either in a variable
element of a tld, or in a TagExtraInfo, and that its declaration (in the
generated java file) is a result of the compiler trying to do its
synchronization with the pagecontext attribute of the same name.
If so, what is the scope of this variable? Is it NESTED or AT_BEGIN?
I can see how the current Jasper implementation can be problematic,
There are two problems here.
First, if the scope is AT_BEGIN, then the scope of the variable should
remain defined until the end of the page, and the current implementation
actually make it unavailable after the end of the tag, which is wrong.
Second, if the tags are nested, as is your case here, then redclaring
it in the nested block would be illegal Java.
Can you file a bug report in bugzilla for this? It would help if you
can also include a small test case, so that fixes can be verified.
Thanks.
Date: Thu, 06 Jun 2002 18:54:11 -0400
From: Pete Gordon [EMAIL PROTECTED]
Subject: Re: Jsp compilation of nested custom tags (porting from weblogic 6 to
tomcat 4.0.3)
To: Tag Libraries Developers List [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
MIME-version: 1.0 (Apple Message framework v481)
Delivered-to: mailing list [EMAIL PROTECTED]
Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
X-Antivirus: nagoya (v4198 created Apr 24 2002)
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
Thanks, Shawn.
Let me summarize for the tomcat-dev list. I have an existing
application with custom tags that runs on weblogic 6, when porting it
over to Tomcat I now am running into an error where the generated java
from a jsp with self nested tags will not compile, the code generated
from jspc simulates the HelloWorld sample below, which is not valid java
code--it would be valid in C, but that's another story.
The first htmlGlobalAttribSearch$jsp.java compile error is line 198,
variable lOffset is already defined. There are several (19) more errors
like this that are also outputed from trying to compile the $jsp.java
file that I have attached.
public class HelloWorld{
public static void main(String args[]){
do{
int i = 5;
do{
int i=10;
}while(false);
}while(false);
}
}
Tomorrow, I will try to create a minimal nested tag example and see if I
can duplicate the problem. Unless someone is aware of this problem
already, and can save me the effort.
Thanks,
Pete Gordon
On Thursday, June 6, 2002, at 03:03 PM, Shawn Bayern wrote:
Hi Pete,
If this is a Tomcat bug, it would be better to mail tomcat-dev about
it
or
to submit a Tomcat bug report in Apache's Bugzilla
(http://nagoya.apache.org/bugzilla). I'd be happy to take a look at
it
myself, but it's difficult to identify the problem in a large compiled
servlet. (I can't attempt to compile it myself since it depends on
some
custom classes not included.) If you could post the compilation
error,
that'd definitely help us determine whether it looks like a Tomcat bug
or
not.
From: Pete Gordon [EMAIL PROTECTED]
Date: Thu Jun 06, 2002 02:32:06 PM US/Eastern
To: 'Tag Libraries Developers List' [EMAIL PROTECTED]
Subject: Jsp compilation of nested custom tags (porting from weblogic 6
to tomcat 4.0.3)
Reply-To: Tag Libraries Developers List taglibs-
[EMAIL PROTECTED]
There is a problem with compiling the genenerated java code
(htmlGlobalAttribSearch$jsp.java) it tells me that variables have
already
been defined. I have compiled the source file and even created a test
HelloWorld.java to test it. It is correct variables have already been
defined, which we found strange as far as the scope variables were
accessible, see the code below
public class HelloWorld{
public static void main(String args[]){
do{
int i = 5;
do{
int i=10;
}while(false);
}while(false);
}
}
The JSP page has several nested custom tags (the same tags) and this is
working on weblogic 6. But the generated java file from tomcat/jasper
does
not compile. The problem is the fci:collection tag being nested a few
times within itself. See the JSP below. I think this is a problem with
the
jspc generated java code. Am I way off base?
Thanks,
Pete Gordon
%@ taglib uri=fciTagLib.tld prefix = fci %
%@ page import=com.fci.arch.service.*%
form action=fci:get resource=site/ method=GET id=form1
name=form1
input type=hidden name=action
value=catalogActions.globalParametric
Re: TC 4.1.3 jasper error
I already committed a fix for this problem a couple of days ago.
The problem is of course private instance variables are beening referenced
in a child class. The 1.3 javac does not flag this as an error, and
1.4 javac gives misleading error messages!
Date: Fri, 07 Jun 2002 11:32:02 -0400 (EDT)
From: [EMAIL PROTECTED]
Subject: Re: TC 4.1.3 jasper error
To: [EMAIL PROTECTED]
MIME-version: 1.0
Content-transfer-encoding: 7bit
Delivered-to: mailing list [EMAIL PROTECTED]
Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
X-Antivirus: nagoya (v4198 created Apr 24 2002)
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
My Eclipse IDE (with Sun JDK 1.3.1_03) give me the following error
for Node.java
I had a hard time compiling Node.java in jasper2 until I made this
change (which I believe doenst change the logic at all)
Index:
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Node.java
===
RCS file:
/home/cvspublic/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compil
er/Node.java,v
retrieving revision 1.9
diff -u -r1.9 Node.java
---
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Node.java
23 May 2002 21:29:38 - 1.9
+++
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Node.java
7 Jun 2002 15:26:43 -
@@ -370,13 +370,13 @@
* @return The text string
*/
public char[] getText() {
- char[] ret = text;
- if ((ret == null) (body != null)) {
+ char[] ret = super.getText();
+ if ((ret == null) (getBody() != null)) {
CharArrayWriter chars = new CharArrayWriter();
- int size = body.size();
+ int size = getBody().size();
for (int i=0; isize; i++) {
- chars.write(body.getNode(i).getText(), 0,
- body.getNode(i).getText().length);
+ chars.write(getBody().getNode(i).getText(), 0,
+ getBody().getNode(i).getText().length);
}
ret = chars.toCharArray();
}
Cheers,
-bob
in :
/**
* When this node was created from a JSP page in JSP syntax, its text
* was stored as a String in the text field, whereas when this node
* was created from a JSP document, its text was stored as one or more
* TemplateText nodes in its body. This method handles either case.
* @return The text string
*/
public char[] getText() {
char[] ret = text;
if ((ret == null) (body != null)) {
CharArrayWriter chars = new CharArrayWriter();
int size = body.size();
for (int i=0; isize; i++) {
chars.write(body.getNode(i).getText(), 0,
body.getNode(i).getText().length);
}
ret = chars.toCharArray();
}
return ret;
}
}
jakarta-tomcat-4.1.3-b1/org/apache/jasper/compiler/Node.java
Cannot make a static reference to the non-static field text
line 373 in Node.ScriptingElement.getText()
line 374 in Node.ScriptingElement.getText()
line 376 in Node.ScriptingElement.getText()
line 378 in Node.ScriptingElement.getText()
line 379 in Node.ScriptingElement.getText()
Did someone else get this error ?
-
Henri Gomez ___[_]
EMAIL : [EMAIL PROTECTED](. .)
PGP KEY : 697ECEDD...oOOo..(_)..oOOo...
PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6
-Original Message-
From: Jean-Francois Nadeau [mailto:[EMAIL PROTECTED]]
Sent: Friday, June 07, 2002 3:41 PM
To: Tomcat Developers List
Subject: RE: mod_jk 4.03 deadlock
Hi.
I found something very interesting this morning in catalina.out file.
Here it is:
java.lang.IllegalStateException: Current state = FLUSHED, new state =
CODING_END
at
java.nio.charset.CharsetEncoder.throwIllegalStateException(Char
setEncoder.java:933)
at
java.nio.charset.CharsetEncoder.encode(CharsetEncoder.java:529)
at
sun.nio.cs.StreamEncoder$CharsetSE.flushLeftoverChar(StreamEnco
der.java:356)
at
sun.nio.cs.StreamEncoder$CharsetSE.implClose(StreamEncoder.java:413)
at sun.nio.cs.StreamEncoder.close(StreamEncoder.java:158)
at
java.io.OutputStreamWriter.close(OutputStreamWriter.java:222)
at java.io.PrintWriter.close(PrintWriter.java:137)
at
org.apache.catalina.connector.ResponseBase.finishResponse(Respo
Re: problem in nested custom tags- Jboss3.0-tomcat4.03.
Looks like the same problem as one decribed in bugzilla #9699 that got reported today. Good timing! :-) Date: Fri, 07 Jun 2002 15:42:54 +0530 From: Anil Agrawal [EMAIL PROTECTED] Subject: problem in nested custom tags- Jboss3.0-tomcat4.03. To: '[EMAIL PROTECTED]' [EMAIL PROTECTED] Cc: '[EMAIL PROTECTED]' [EMAIL PROTECTED] MIME-version: 1.0 Delivered-to: mailing list [EMAIL PROTECTED] Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm X-Antivirus: nagoya (v4198 created Apr 24 2002) 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 respected sir, I am working on Jboss3.0-tomcat4.03. following jsp (uses nested custom tags) working perfactly fine with weblogic6.01. jsp code is logically right also. at compilation time tomcat throws exception == jsp compilation error = D:\jboss-3.0.0_tomcat-4.0.3\catalina\work\localhost\wsc_auth\auth\admin\Assi gnDeassignService$jsp.java:350: Variable 'inputError' is already defined in this method. String inputError = null; == jsp file = auth:getServiceAssignments componentId='%=cId%' serviceName='%=sName%' common:inputError p class=error%=inputError%/p /common:inputError common:businessError p class=error%=businessError%/p /common:businessError common:commandSuccess auth:getAllGroups isAdmin=true common:inputError p class=error%=inputError%/p /common:inputError common:businessError p class=error%=businessError%/p /common:businessError common:commandSuccess /common:commandSuccess /auth:getAllGroups /common:commandSuccess /auth:getServiceAssignments -- 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: cvs commit:jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/runtimePageContextImpl.java
Remy,
I like this much better! No private API used, and cleaner generated
codes!
Some nitpicks! :-) See below.
There seems to be no need for a JspxState object anymore.
Jspx.State.tagCount is really not used, and JspxState.out can be
make local. I should just comment that out for now.
remm2002/06/10 20:35:35
Modified:jasper2/src/share/org/apache/jasper/compiler Generator.java
jasper2/src/share/org/apache/jasper/runtime
PageContextImpl.java
Log:
- Take advantage of the fact that the PageContext is pooled.
- Modify the way the buffer reuse is done to conform with the PageContext
contract (basically, the code moves from the generated servlet to
PageContext).
Index: Generator.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Gen
erator.java,v
+out.printil(javax.servlet.jsp.tagext.BodyContent _bc =
pageContext.pushBody(););
+out.printil(_bc.clear(););
+out.printil(out = _bc;);
Can call to clear() be moved to pushBody()?
Index: PageContextImpl.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/runtime/Page
ContextImpl.java,v
+protected BodyContent[] outs = new BodyContentImpl[0];
Why not start the array with a small fixed size, say 5, to avoid all
these copying.
+protected int depth = -1;
public BodyContent pushBody() {
-JspWriter previous = out;
-writerStack.push(out);
-out = new BodyContentImpl(previous);
-return (BodyContent) out;
+depth++;
+if (depth = outs.length) {
+BodyContent[] newOuts = new BodyContentImpl[depth + 1];
+for (int i = 0; i outs.length; i++) {
+newOuts[i] = outs[i];
+}
+newOuts[depth] = new BodyContentImpl(out);
+outs = newOuts;
+}
+out = outs[depth];
+return outs[depth];
}
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: bean with jsp
You should try to get answers to questions like this on tmcat-users alias.
You'll need to put whatever you import in a package. This is a new
in JDK1.4.
Date: Wed, 05 Feb 2003 17:39:07 +0530
From: Sachin Chowdhary [EMAIL PROTECTED]
Subject: bean with jsp
To: [EMAIL PROTECTED]
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
X-OriginalArrivalTime: 05 Feb 2003 12:09:09.0271 (UTC)
FILETIME=[63397A70:01C2CD0F]
I am trying to use a class by using useBean tag in jsp but i am not able to
do it so remove all coding and just using import class name syntax but still
i am not able to do that on tomcat4.1.18 .so what i am doing wrong
can you suggest me
C:\Program Files\Apache Group\Tomcat 4.1\webapps\examples\jsp
%@ page import=MyClass %
html
body
Meet a Bean!
/body
/html
//MyClass.java
C:\Program Files\Apache Group\Tomcat 4.1\webapps\examples\WEB-INF\classes
public class MyClass
{
public String val;
}
HTTP Status 500 -
type Exception report
message
description The server encountered an internal error () that prevented it
from fulfilling this request.
exception
org.apache.jasper.JasperException: Unable to compile class for JSP
An error occurred at line: -1 in the jsp file: null
Generated servlet error:
[javac] Compiling 1 source file
C:\Program Files\Apache Group\Tomcat
4.1\work\Standalone\localhost\examples\jsp\MyJsp_jsp.java:7: '.' expected
import MyClass;
^
1 error
-
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]
[TC5] Time to make a release?
There has been inquiries about a Tomcat 5 release, both in and out of the mailing list. I usually direct them to our nightly builds, but there is no links from the jakarta page, and they are not always available. I think it's time that we make a release, to make it easier for people to try it out. I know there are a lot of work still going on, and a lot need to be done to make it into a stable release. I am thinking about an alpha release. Now that JSP 2.0 PFD2 has been published, (http://jcp.org/aboutJava/communityprocess/first/jsr152/index2.html) and the jasper implementation has been complete, we need a release for people to try it out. Comment? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: TC 5.0 nightly builds
No matter how easy the build is, it is still not as easy as downloading a binary from the nightly build area. Just tell someone who haven;t done a build before to do it now and watch her cringe! Sue' point is that TC5 nightly build has failed for a week now and should be fixed. It's important that we have a current nightly build for TC5, especially since we don't have a release for TC5 (hint! hint :) ). Date: Tue, 11 Feb 2003 16:49:20 -0500 From: Jeanfrancois Arcand [EMAIL PROTECTED] Subject: Re: TC 5.0 nightly builds To: Tomcat Developers List [EMAIL PROTECTED] Hi, an easy way to build tomcat 5 is to: cvs -d bla bla checkout jakarta-tomcat-5 cd jakarta-tomcat-5 ant download //download all dependencies (including common-el.jar) ant checkout //jakarta-servletapi-5, jakarta-tomcat-catalina, jakarta-tomcat-connectors, jakarta-tomcat-jasper ant dist Et hop :-) -- Jeanfrancois Brian Millett wrote: On Tue, 2003-02-11 at 11:34, Sue Spielman wrote: Is there an ETA when the nightly builds of TC 5.0 will return? It has not been building since 2/5. Thanks. It will build if you go and get a nightly binary build of commons-el. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0.1] Tagging today
Date: Tue, 18 Feb 2003 21:46:54 +0100 From: Remy Maucherat [EMAIL PROTECTED] Subject: Re: [5.0.1] Tagging today To: Tomcat Developers List [EMAIL PROTECTED] Costin Manolache wrote: Remy Maucherat wrote: Costin Manolache wrote: Remy Maucherat wrote: Jeanfrancois Arcand wrote: Are you able to build it? The nightly build failled with the following (see below). I will look at the failure latter this afternoon... It's a hint that there are urgent bugs to fix in either JspC or Jasper, which make precompilation fail (read my commit massage to see the full story) ;-) Well, we can't release a milestone with both gump and normal build failing. At this point disabling the precompilation seems the best short-term workaround, but I think we should rather wait with the milestone until the fix is available. That's reasonable. +1 for fixing the bugs (I tried a bit and failed). +1 for fixing the bug too - but I don't know how :-) It seems to be introduced by one of the recent changes - I had no problem compiling the admin few weeks ago. We either roll back the change or find another way. The bug happens in the jsp-examples precompilation (which is supposed to work also, right ?). One of the tag examples apparently causes problems. The strange thing is the error hapeened with source.jsp, which is not one of the exmaples. Do you guys know what it's for? I also don't believe jsp-examples has been successful compiled with JSPC before. I know haven't tried that with JSP2.0 examples. With automatic compiling of the tag files, I won't be surprise if there are problems. :) One thing should be clear - precompiled jsps should be included with tomcat5 and we should strongly recommend ( and support ) this mode for production sites. For development it is normal to compile the page, but doing the compilation on a production server is really bad idea. +1. +1 from me too. However, is Jspc good enough now? Are there areas that need to be fixed? We should not make this a requirement for tomcat5 and recommand such a practice until it is good enough. For now we should just turn off precompilation of the examples until the problem is identified and fixed. 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: cvs commit:jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compilerTagFileProcessor.java
The fix looks OK, except that you still need to put the call to
incTripCount in a synchronized block. Of course that won't
be necessary for JSPC.
There may better solutions to this problem, and I'll look into that.
I'll also make sure that there won't be problems using jspc on tag
files.
Date: Wed, 19 Feb 2003 07:03:46 +
From: [EMAIL PROTECTED]
Subject: cvs commit:
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler
TagFileProcessor.java
To: [EMAIL PROTECTED]
billbarker2003/02/18 23:03:45
Modified:jasper2/src/share/org/apache/jasper
JspCompilationContext.java
jasper2/src/share/org/apache/jasper/compiler
TagFileProcessor.java
Log:
Fix for most of the pre-compile problems with TC-5.
The basic problem is that with Jspc, there is no 'RuntimeContext'. I've
patched around the worst parts of it, but I'm the first to admit that I don't
know Jasper down to this sort of level.
Jan, Kin-Man, please review (and feel free to -1 if I've broken something).
Revision ChangesPath
1.32 +5 -3
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/JspCompilationContext.
java
Index: JspCompilationContext.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/JspCompilati
onContext.java,v
retrieving revision 1.31
retrieving revision 1.32
diff -u -r1.31 -r1.32
--- JspCompilationContext.java 12 Feb 2003 16:37:11 - 1.31
+++ JspCompilationContext.java 19 Feb 2003 07:03:44 - 1.32
@@ -201,6 +201,8 @@
public ClassLoader getClassLoader() {
if( loader != null )
return loader;
+ if( rctxt == null)
+ return getClass().getClassLoader();
return rctxt.getParentClassLoader();
}
1.40 +62 -49
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/TagFileProces
sor.java
Index: TagFileProcessor.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Tag
FileProcessor.java,v
retrieving revision 1.39
retrieving revision 1.40
diff -u -r1.39 -r1.40
--- TagFileProcessor.java 5 Feb 2003 23:35:21 - 1.39
+++ TagFileProcessor.java 19 Feb 2003 07:03:45 - 1.40
@@ -412,60 +412,73 @@
JspCompilationContext ctxt = compiler.getCompilationContext();
JspRuntimeContext rctxt = ctxt.getRuntimeContext();
-JspServletWrapper wrapper =
+ JspServletWrapper wrapper = null;
+ if( rctxt != null ) {
+ wrapper =
(JspServletWrapper) rctxt.getWrapper(tagFilePath);
- synchronized(rctxt) {
- if (wrapper == null) {
- wrapper = new JspServletWrapper(ctxt.getServletContext(),
- ctxt.getOptions(),
- tagFilePath,
- tagInfo,
- ctxt.getRuntimeContext(),
- (JarFile)
ctxt.getTagFileJars().get(tagFilePath));
- rctxt.addWrapper(tagFilePath,wrapper);
+ synchronized(rctxt) {
+ if (wrapper == null) {
+ wrapper = new JspServletWrapper(ctxt.getServletContext(),
+ ctxt.getOptions(),
+ tagFilePath,
+ tagInfo,
+ ctxt.getRuntimeContext(),
+ (JarFile)
ctxt.getTagFileJars().get(tagFilePath));
+ rctxt.addWrapper(tagFilePath,wrapper);
+ }
}
+ } else {
+ wrapper = new JspServletWrapper(ctxt.getServletContext(),
+ ctxt.getOptions(),
+ tagFilePath,
+ tagInfo,
+ ctxt.getRuntimeContext(),
+
(JarFile)ctxt.getTagFileJars().get(tagFilePath)
+ );
+ }
+
- Class tagClazz;
- int tripCount = wrapper.incTripCount();
- try {
- if (tripCount 0) {
- // When tripCount is greater than zero, a circular
- // dependency exists. The circularily dependant tag
- // file is compiled in prototype mode, to avoid infinite
- // recursion.
+ Class
Re: [5.0.1] Tagging today
Date: Fri, 21 Feb 2003 19:16:46 +0100 From: Remy Maucherat [EMAIL PROTECTED] Subject: Re: [5.0.1] Tagging today To: Tomcat Developers List [EMAIL PROTECTED] Costin Manolache wrote: Kin-Man Chung wrote: I also don't believe jsp-examples has been successful compiled with JSPC before. I know haven't tried that with JSP2.0 examples. With automatic compiling of the tag files, I won't be surprise if there are problems. :) It doesn't matter what it's for - if it is valid JSP it should compile with jspc the same as with jspservlet :-). If it's not valid - it should be removed... I tried to look into the issue, but it's quite complex :-( I have just committed a fix for using JSPC to compile JSP pages that uses tag files. The complication comes from the need to compile tag files into class objects before a JSP page that references them can be compiled. I don't know a better strategy for precompiling an application would be to first compile all the tag files first, then compile the JSP pages after that. The added complication is that a tag file may use other tag files, or even be circularly dependent. I don't like that new spec feature, overall. Same for the ability to put the TLD in random places. It's supposed to help page authors that are not programmers. But if a seasoned programmer find tag files hard to use, it's not a good sign. It seems the new spec revisions mean more complex + more bloated :-( This is quite disappointing ... Isn't that always true? :-) You need to add new features but cannot remove old ones. 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: [4.1.21] Stability rating
The patch you mentioned in 14302 was actually applied to TC5. Date: Fri, 28 Feb 2003 12:07:21 -0800 From: Hans Bergsten [EMAIL PROTECTED] Subject: Re: [4.1.21] Stability rating To: Tomcat Developers List [EMAIL PROTECTED] Remy Maucherat wrote: ballot [X] Alpha [ ] Beta [ ] Stable (GA) /ballot The TagLibraryInfoImpl patch attached to bug 14302 is still not applied, so JSPC fails with an NPE for any web app that contains a tag library packaged as a JAR file (with the TLD in the JAR file). Other than that, all my tests works okay. Hans -- Hans Bergsten[EMAIL PROTECTED] Gefion Software http://www.gefionsoftware.com/ Author of O'Reilly's JavaServer Pages, covering JSP 1.2 and JSTL 1.0 Details athttp://TheJSPBook.com/ - 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: [5] EL parsing eats extra character after '?'
Date: Fri, 30 May 2003 13:47:01 -0400
From: Tim Funk [EMAIL PROTECTED]
Subject: [5] EL parsing eats extra character after '?'
To: Tomcat Developers List [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Attached below is a message from tomcat-user. I don't know it this is a valid
issue or not. If its not, it has great FAQ potential.
Argh, this is a bug! JSP 2.0 now recognizes ${...} as an EL expression,
so there are some special handling for $ in the parser. It got this
wrong, apparently.
I'll commit a fix to this as soon as I send this mail out. Note that
the workaound to this problem is to write
\$jsp:getProperty name=login property=username/
instead. Here, \$ is an escape for $. This is new in JSP 2.0.
Note also that this can now be written as
\$${login.username}
taking advantage of EL in tc 5.
If it is a problem, could it be caused by the following the snippet below? It
looks like any custom tag would be ignored if preceded by a $. This seems to
be the behavior I saw when I put $ in front of the hello world tag in
/jsp-examples/jsp2/tagfiles/hello.jsp.
In org.apache.jasper.compiler.Parser.parseXMLTemplateText()
lines 1502, 1506
if (ch != '{') {
ttext.write('$');
ttext.write(ch);
continue;
}
This would not work, since parseXMLTemplateText deals only with
text in the body of jsp:text element.
I really don't know much about Jasper, and was just snooping.
Well, this is a good time to do that, now that Jasper in TC5 has
stablized. Ping me if you need help. :)
-Kin-man
-Tim
Original Message
Subject: Tomcat 5.0.2 Bug
Date: Fri, 30 May 2003 06:36:04 -0700 (PDT)
From: Ed Smith [EMAIL PROTECTED]
Reply-To: Tomcat Users List [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
I think there is a bug in Tomcat 5.0.2 (at least under
Windows XP) dealing with placing a $ before (at least
some) tags.
Consider the following JSP:
jsp:useBean id=login class=LoginBean
scope=session/
jsp:setProperty name=login property=username
value=foo/
html
body
$jsp:getProperty name=login
property=username/
/body
/html
In Tomcat 4.1.24, this generates the following HTML
(as expected)
html
body
$foo
/body
/html
In Tomcat 5.0.2, it generates
html
body
$jsp:getProperty name=login
property=username/
/body
/html
The jsp taglib does not get processed in
5.0.2. Note that if I add a space after the $, it
works in 5.0.2
Changing to
$ jsp:getProperty name=login property=username/
gets the following HTML
html
body
$ foo
/body
/html
Am I missing something? I didnĀt find the problem in
either the bugs database or the mailing list archives.
-
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: jsp:include
Can you reproduce your problem with Tomcat 5? If so, you may get it fixed faster if you post it on bugzilla. When you do, make sure to include a test case (a war file would be great). Not sure I understand what the problem is. Also not sure what jsp:include has to anything to do with your problem. You cannot find a class that is related to jsp:include because there isn't one. jsp:include eventually invokes RequestDispatcher.include in the generated servlet code. See org.apache.jasper.runtime.JspRuntimeLibrary.include() for more details. Date: Tue, 24 Jun 2003 15:45:39 -0500 From: Reshat Sabiq [EMAIL PROTECTED] Subject: jsp:include To: [EMAIL PROTECTED] Hi, There's a bug in J2EE 1.4 RI Beta 2 that prevents me from using a custom tag: instanceof operator treats TagSupport subclass as SimpleTagSupport instance. This leaves me only one appropriate option: subclass the class that implements jsp:include tag, and overwrite a method in it. I'd appreciate a pointer as to what class implements that tag. I've been searching through taglibs and tomcat-5 nightly builds, and have not found a single class that is related to jsp:include. Thank you in advance. P.S. Yes, i will be reporting the bug on sun's website. But i need to work around at this time... -- Sincerely, Reshat. --- If you see my certificate with this message, you should be able to send me encrypted e-mail. Please consult your e-mail client for details if you would like to do that. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[VOTE] Jan Luehe
I'd like to nominate Jan Luehe as a committer to tomcat. Jan is currently a commiter for Jakarta taglib project, and has been active in implementing JSTL, the standard tag library. Jan was involved with jasper 2 from the beginning, and has contributed to writing a number of important modules in jasper 2. He has submitted a number of high quality patches recently, of which the tag pooling/reuse is an examples. Jan plans to contribute more to increase the performance of jsp pages, especially those with tag invokations. His knowledge in JSTL would make him an invaluable addition to the tomcat development community. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit:jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper JspC.java
costin 2002/06/14 13:43:05 Log: Second stage of braking jasper2. You think jasper 2 is going too fast? :-) Otherwise +1 on the changes. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit:jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compilerCompiler.java
costin 2002/06/14 13:44:37 Modified:jasper2/src/share/org/apache/jasper/compiler Compiler.java Log: Split the compile() method in generateJava() and generateClass() - JspC only generates java, the compile is a separate step. Why not have an option to include javac compilation in JspC? There has been requests for this functionality. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Jasper2: serious problem with tag declarations
Date: Tue, 18 Jun 2002 11:04:10 +0100
From: [EMAIL PROTECTED]
Subject: RE: Jasper2: serious problem with tag declarations
To: [EMAIL PROTECTED]
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft Exchange V6.0.5762.3
Content-transfer-encoding: quoted-printable
Content-class: urn:content-classes:message
Delivered-to: mailing list [EMAIL PROTECTED]
Thread-topic: Jasper2: serious problem with tag declarations
Thread-index: AcIWizWxrE/eTDHgQNOcNern1B02QQAIq6BA
Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
X-Antivirus: nagoya (v4198 created Apr 24 2002)
X-WDR-Disclaimer: Version $Revision: 1.15 $
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
X-OriginalArrivalTime: 18 Jun 2002 10:04:11.0284 (UTC)
FILETIME=[7E3D7540:01C216AF]
The scope of scripting variables from tags is specified in the Tag. From the
1.1 spec:
The defined values for scope are:
Ā· NESTED, if the scripting variable is available between the start tag and the
end tag of the
action that defines it.
Ā· AT_BEGIN, if the scripting variable is available from the start tag of the
action that
defines it until the end of the page.
Ā· AT_END, if the scripting variable is available after the end tag of the
action that defines
it until the end of the page.
The scope value for a variable implies what methods may affect its value...
So while declaring two id's the same is an error IMO, the specific tag
logic:iterate should probably be NESTED rather than AT_BEGIN (which is what's
happening).
Checking the struts code (org.apache.struts.taglib.logic.IterateTei), it is
indeed declared as NESTED. Looks like a Jasper 2 bug then. Time for a few extra
{}'s?
Having extra {}'s is not going to work, because it's not legal java to
have variables of the same name in a method, even if one is in the block
nested with another block containing the other.
There was a problem with scripting variables when a tag is nested in
the same tag, because of the above problem. But that has been fixed
recently in jasper2. If costin's page works in old jasper, but not
in jasper2, then it must be something else.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: 18 June 2002 06:44
To: Tomcat Developers List; Kin-Man Chung
Subject: Re: Jasper2: serious problem with tag declarations
On Mon, 17 Jun 2002, Kin-Man Chung wrote:
Costin,
I am not aware that id attribute is handled differently in a tag.
Can you give a test case for this? I can look into it more. Thanks.
I'll try to extract a test case.
There is nothing special about 'id' - just 2 consecutive struts
logic:iterate id='foo' . This generates a variable 'foo'
( via TLD/TagInfo/etc ), and the problem is that the variable foo is
declared twice ( there are 2 'Object foo;' in the same scope ).
I'm not very familiar with struts ( but you may find some
experts on this list :-), but unless I'm doing something very
stupid in the page, this issue may be serious.
Costin
- Kin-man
Date: Mon, 17 Jun 2002 10:41:07 -0700 (PDT)
From: [EMAIL PROTECTED]
Subject: Jasper2: serious problem with tag declarations
X-X-Sender: [EMAIL PROTECTED]
To: List Tomcat-Dev [EMAIL PROTECTED]
MIME-version: 1.0
Delivered-to: mailing list [EMAIL PROTECTED]
Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
X-Antivirus: nagoya (v4198 created Apr 24 2002)
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N
X-Authentication-warning: costinm.sfo.covalent.net: costin owned process
doing
-bs
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
I see some errors, not sure yet if it's an error in the taglibs or
jasper but seems serious. ( the taglibs are from struts ).
There are few logic:iterate id=foo tags in the page, using the
same id, and the generated code has:
Object foo;
Object foo;
...
That obviously doesn't compile.
I don't know too much about struts, but I suppose it is valid to use
the same value in 2 tag attributes, couldn't find any reference on
the contrary in the spec.
It workes fine with older jasper.
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]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto
Re: Jasper2: serious problem with tag declarations
Costin,
I'm a bit worried here - most of the stuff is pretty basic and
common use of tags. Watchdog and the test suite was supposed
to detect that withou any problems.
Use of scripting varibles in nested tag never work before, so obviously
no body uses it much. I think the whole scripting variable in JSP1.2 is
poorly designed, and not well understood.
I am also surprised that how much watchdog *does not* test!
I'll vote for 'alpha' status for the next build,
and I hope more people will check their apps against it -
I like the changes that are going on, but we need a bit
more testing.
How do we deal with nested tags of different type ? I don't have
a test case, but I assume someone may have a NESTED tag
'foo' in 2 different tags, with different declared types ( String and
Integer ). The current generator seems to not create { },
and I'm not sure how this will work.
( no test case - but I'm sure you can find such tags )
That would not work, and would never be made to work, not only for
nested case, but also for non-nested tags with AT_BEGIN scopes.
I tend to think this falls into the user's reponsibility if she uses
the same variable name for two different types, somewhat analogous to
declaring two variables of the same name two different types in Java.
Hopefully, there won't be a need for scripting variables anymore when
expression language becomes available in JSP2.0.
-Kin-man
Costin
On Fri, 21 Jun 2002, Jan Luehe wrote:
Costin,
If those variable declaration problems are fixed, I'll release a
new
4.1.6 milestone as soon as I can fix the JNDI problems.
Not yet...
I attached the failed jsp.
Costin
[...]
%@ page language=java %
%@ taglib uri=/WEB-INF/struts-logic.tld prefix=logic %
logic:iterate id=a name=foo property=bar
/logic:iterate
logic:present name=b
logic:iterate id=a name=foo property=bar
/logic:iterate
/logic:present
last and final attempt! :)
The attached patch should fix the last issue you brought up.
Since I am still waiting for my commit privileges, Kin-Man
has again volunteered to apply the patch. Thanks Kin-Man!
Jan
--
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: Jasper2: serious problem with tag declarations
Costin,
On Fri, 21 Jun 2002, Kin-Man Chung wrote:
Use of scripting varibles in nested tag never work before, so obviously
no body uses it much. I think the whole scripting variable in JSP1.2 is
poorly designed, and not well understood.
The failures are from an app that worked perfectly fine with
jasper1, and with jasper2 ( up to 4.1.4 ).
And IMHO are very elementary use cases - 2 iterates and one
condition is not that infrequent.
jasper1 and old jasper2 implements scripting variables by declaring them
when a tag handler is instantiated, inside a block of its own, like
{
String x; // variable x defined here
...
}
This implementation has 2 problems.
1) Nested tags with same variable does not work
mytag:foo
mytag:foo
/mytag:foo
/mytag:foo
because you cannot have two varibles of the same name in Java, even if
they are in blocks nested within one another.
2) The variables are out of scope when the tag ends, but for variables
with AT_BEGIN scope, spec says they should be accessable until the
end of the page.
How do we deal with nested tags of different type ? I don't have
a test case, but I assume someone may have a NESTED tag
'foo' in 2 different tags, with different declared types ( String and
Integer ). The current generator seems to not create { },
and I'm not sure how this will work.
( no test case - but I'm sure you can find such tags )
That would not work, and would never be made to work, not only for
nested case, but also for non-nested tags with AT_BEGIN scopes.
I tend to think this falls into the user's reponsibility if she uses
the same variable name for two different types, somewhat analogous to
declaring two variables of the same name two different types in Java.
I'm lost here - wasn't NESTED supposed to define a lexical scoping ?
I don't see why this wouldn't work - are you saying it doesn't
work with jasper2, it didn't worked with jasper1, or is not
required by the spec ?
You cannot have
{
String x;
{
String x;
}
}
in Java, so we are implementing scripting variables with nested scopes as
{
String x;
{
String temp = x;
...
}
x = temp;
}
You can see why we'll have problems if two variables nesting with one
anothers have the same name but different types.
Hopefully, there won't be a need for scripting variables anymore when
expression language becomes available in JSP2.0.
:-)
Unfortunately JSP1.x will be around for a while, and jasper must support
it.
Costin
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Jasper2: serious problem with tag declarations
My problem is that code that worked with jasper1 no longer works with jasper2. And I believe the use case is valid and within the spec, and quite common. The latest failure is just 2 iterate tags and a condition tag - I think it should work. Costin With the Jan's patch last Friday, jasper 2 should handle those cases that used to work for japser1, as well as those those that cannot be handled by jasper1. If this is not the case, please let me know. - Kin-man -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Jasper2: serious problem with tag declarations
- in the same case, the 'a' variable is declared at the top of the file, even if it is AT_END. That brakes previous iterate that used the 'a' id. I believe this is a bug. According to the spec, the scope of an AT_END variable spans from the end element of the tag exposing it to the end of the page. The previous jasper did not implement this correctly: If the tag exposing the AT_END variable was nested, the previous jasper would declare the variable at its nesting level, limiting its visibility. I think this was in violation of the spec. However the current jasper exposes it from the beginning of the service() method - which is also in violation of the spec. ( i.e. AT_END is before AT_BEGIN and anything else ). Costin That's true, but the value of those variables are still synchronized with the corresponding pageContext attributes at the locations specified by the spec, so using these variables before they are synchronized is meaningless. The spec as is today really cannot be implemented correctly in Java. What we are doing is let pages that conform to the spec (e.g. referencing an AT_END variable after end of tag) be compiled and run correctly, but does not prevent people from writing page that is not spec conformant (e.g. referencing an AT_END variables in the body). -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] Apache Tomcat 5.0 Proposal
+1. I'll populate jasper2 and servlet-api with initial changes for JSP2.0 support. Date: Tue, 02 Jul 2002 16:57:20 -0700 From: Remy Maucherat [EMAIL PROTECTED] Subject: [VOTE] Apache Tomcat 5.0 Proposal To: Tomcat Developers List [EMAIL PROTECTED] After trying to address the concerns raised by the proposal draft, I would like to call for a vote on it, now that the discussions have died down. ballot [ ] +1 I support the proposal, and will help implement it [ ] +0 I support the proposal [ ] -0 I do not support the proposal [ ] -1 I am against the proposal being implemented, because: /ballot The vote will run for one full week until July 9th. Users and other contributors may vote, but only committers have binding votes. Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [5.0] [VOTE] New branches and repositories
ballot A) Servlet 2.4 JSP 2.0 API 1. [X] Use new jakarta-servletapi-5 2. [ ] Use the HEAD of jakarta-servletapi 3. [ ] Other: B) Catalina 2.0 1. [X] Use new jakarta-tomcat-catalina 2. [ ] Use new jakarta-tomcat-5.0 3. [ ] Use the HEAD of jakarta-tomcat-4.0 4. [ ] Other: C) Coyote 2.0 1. [ ] Yes, use the HEAD of jakarta-tomcat-connectors 2. [ ] No, use: D) Tomcat 5.0 1. [X] Use new jakarta-tomcat-5.0 2. [ ] Use the HEAD of jakarta-tomcat-4.0 3. [ ] Use the HEAD of jakarta-tomcat 4. [ ] Other: E) Jasper 2.0 1. [X] Yes, use the HEAD of jakarta-tomcat-jasper 2. [ ] No, use: /ballot -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: $ in JSP names
I totally agree that the use of $ in a file name is a pain in the neck. In fact, I don't see the need for appending a $jsp at all. Currently we have the following mapping: jsp file name: foo.jsp class name: foo$jsp servelt file name: foo$jsp.java class file name: foo$jsp.class I think it'd be perfectly OK to use the following mapping: jsp file name: foo.jsp class name: foo servelt file name: foo.java class file name: foo.class Date: Fri, 12 Jul 2002 14:55:01 -0700 (PDT) From: [EMAIL PROTECTED] Subject: $ in JSP names X-X-Sender: [EMAIL PROTECTED] To: List Tomcat-Dev [EMAIL PROTECTED] X-Authentication-warning: costinm.sfo.covalent.net: costin owned process doing -bs I just upgraded to jikes1.16, and I get one warning for each JSP file I compile: Lexical: The use of $ in an identifier, while legal, is strongly discouraged, since it can conflict with compiler-generated names. If you are trying to access a nested type, use . instead of $. In addition, it is painfull to look at the source from shell ( need to do emacs page\$jsp.jsp ). Would it be possible to use another delimiter in the generated name ? The change is trivial. 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: $ in JSP names
I think you and Craig are both right. So how about using a _ instead of a $? Date: Mon, 15 Jul 2002 12:48:18 -0700 From: Arvind Srinivasan [EMAIL PROTECTED] Subject: Re: $ in JSP names To: Tomcat Developers List [EMAIL PROTECTED] Cc: Kin-Man Chung [EMAIL PROTECTED] Content-transfer-encoding: 7BIT Craig R. McClanahan wrote: On Mon, 15 Jul 2002, Kin-Man Chung wrote: Date: Mon, 15 Jul 2002 11:55:15 -0700 (PDT) From: Kin-Man Chung [EMAIL PROTECTED] Reply-To: Tomcat Developers List [EMAIL PROTECTED], Kin-Man Chung [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: $ in JSP names I totally agree that the use of $ in a file name is a pain in the neck. In fact, I don't see the need for appending a $jsp at all. Currently we have the following mapping: jsp file name: foo.jsp class name: foo$jsp servelt file name: foo$jsp.java class file name: foo$jsp.class I think it'd be perfectly OK to use the following mapping: jsp file name: foo.jsp class name: foo servelt file name: foo.java class file name: foo.class I thought the reason for appending something ($jsp or _jsp) was to prevent errors in the generated java files for jsp filenames that use one of java's keywords - default.jsp or new.jsp. -Arvind -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit:jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compilerGenerator.java
Remy, No they don't: they are bug fixes for JSP2.0 stuff. I'll make sure bug fixes that apply to both branches get in both branches. Don't worry! :-) - Kin-man Date: Wed, 17 Jul 2002 00:43:53 +0200 From: Remy Maucherat [EMAIL PROTECTED] Subject: Re: cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler Generator.java To: Tomcat Developers List [EMAIL PROTECTED] Content-transfer-encoding: 7bit [EMAIL PROTECTED] wrote: luehe 2002/07/16 15:39:20 Modified:jasper2/src/share/org/apache/jasper/compiler Generator.java Log: Fixed infinite loop in fragment generation for jsp:body. BTW, those patches probably need to be also applied to the 4.1 branch. 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]
RE: Missed vote
I am sympathetic to Jon's view on separating servlet and JSP API and repositories. One result of the separation would make it likely that package names for JSP 2.0 API may change. JSP2.0 is now in public review, so it may be important to raise this issue before the door is closed. Until the JSP 2.0 spec is changed, it make less sense for us to have two separate repos. (It just make more sense to put javax.servlet.jsp.tagext.TagInfo with javax.servlet classes). Date: Wed, 17 Jul 2002 20:28:43 +0200 From: Paulo Gaspar [EMAIL PROTECTED] Subject: RE: Missed vote To: Tomcat Developers List [EMAIL PROTECTED] X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600. Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal For what is worth, I think Jon is 100% right on this one. And he was cristal clear about the reasons too. Regards, Paulo -Original Message- From: Jon Scott Stevens [mailto:[EMAIL PROTECTED]] Sent: Wednesday, July 17, 2002 12:43 AM To: tomcat-dev Subject: Re: Missed vote on 7/16/02 1:14 PM, Craig R. McClanahan [EMAIL PROTECTED] wrote: What's so painful about a ten-line build.xml target that creates a separate JAR file with just the javax.servlet and javax.servlet.http API classes, if that's what you need? Sharing a CVS repository has little or nothing to do with how many distributable outputs you create. On the other hand, having both servlet and JSP APIs in a single JAR file is quite useful to a very large number of existing Tomcat (and other container) users, so it should be available also. Craig I used to say the same thing about Turbine and Torque. You could use Torque without using any of the Turbine code...yet people refused to use Torque because it was packaged in the same jar file as Turbine. I also think that keeping two different API's in the same .jar file is a terrible idea. Think about all the issues we have/had with the XML api's. The Servlet API is also on a different release cycle than the JSP API. Also, having things in the same repo makes it to easy to create dependencies between the two API's...that is why the JSR's were split as well. As Pier said, 2 API's, 2 JSR's, 2 CVS repo's. Consider this my strong -1. -jon -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- 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: cvs commit:jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasperJspCompilationContext.java
Date: Thu, 18 Jul 2002 14:15:16 -0400
From: Tim Funk [EMAIL PROTECTED]
Subject: Re: cvs commit:
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper
JspCompilationContext.java
To: Tomcat Developers List [EMAIL PROTECTED]
Content-transfer-encoding: 7bit
Yeah! $ is replaced by _ when JSP's are converted to java files.
Question:
When someone upgrades to this release, would it be advisable for the
user to eliminate the work directory (or clean it) since an older
compiled JSP now has the wrong name?
Yes. It'd be advisable to do so for any new release, anyways.
Or warn them that every JSP will be recompiled?
By all means. Or do you think we should give the warning in the release
note?
[EMAIL PROTECTED] wrote:
kinman 2002/07/18 10:57:27
Modified:jasper2/src/share/org/apache/jasper Tag: tomcat_4_branch
JspCompilationContext.java
Log:
- use _ instead of $ to generate file and class names for jsp servlets.
Revision ChangesPath
No revision
No revision
1.6.2.1 +6 -6
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/JspCompilationContext.
java
Index: JspCompilationContext.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/JspCompilati
onContext.java,v
retrieving revision 1.6
retrieving revision 1.6.2.1
diff -u -r1.6 -r1.6.2.1
--- JspCompilationContext.java20 Jun 2002 22:33:57 - 1.6
+++ JspCompilationContext.java18 Jul 2002 17:57:27 - 1.6.2.1
@@ -266,15 +266,15 @@
new StringBuffer(jspUri.length() - iSep);
if (!Character.isJavaIdentifierStart(jspUri.charAt(iSep))) {
// If the first char is not a legal Java letter or digit,
- // prepend a '$'.
- modifiedClassName.append('$');
+ // prepend a '_'.
+ modifiedClassName.append('_');
}
for (int i = iSep; i iEnd; i++) {
char ch = jspUri.charAt(i);
if (Character.isLetterOrDigit(ch)) {
modifiedClassName.append(ch);
} else if (ch == '.') {
-modifiedClassName.append('$');
+modifiedClassName.append('_');
} else {
modifiedClassName.append(mangleChar(ch));
}
--
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: javax.servlet.jsp.el.ExpressionEvaluator ????
The head branch of jasper2 is meant to be part of Jakarta-tomcat-5, which in the middle of being set up. It might be a while before tomcat 5 can be built. You should check out the tomcat_4_branch of jasper2 for your build. If you really want to build Jakarta-tomcat-4 with the head branch of jasper2 with, just to try out JSP2.0 features, then you should follow the instructions in BUILDING.txt in jasper2. Date: Thu, 25 Jul 2002 14:45:07 -0500 From: Brian Millett [EMAIL PROTECTED] Subject: javax.servlet.jsp.el.ExpressionEvaluator To: Tomcat Developers List [EMAIL PROTECTED] Content-transfer-encoding: 7bit I am trying to compile the latest 7/25 cvs co of Jakarta-tomcat-4 and I have ran into a problems with jasper2. [javac] /home/bpm/compile_area/cvs_jakarta/jakarta-tomcat-jasper/jasper2/src/share/org/a pache/jasper/compiler/JspUtil.java:90: package javax.servlet.jsp.el does not exist [javac] import javax.servlet.jsp.el.ExpressionEvaluator; [javac] ^ I have no idea where this file might be located. It is not part of the commons, commons-sandbox, taglibs, struts, velocity, etc. What is it and why was code committed to CVS that references files that do not exist? Thanks. -- Brian Millett Enterprise Consulting Group Shifts in paradigms (314) 205-9030 often cause nose bleeds. [EMAIL PROTECTED] Greg Glenn -- 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: [4.1.9] New test milestone released
There is also this feature/bug in jasper2 regarding the scope of scripting variables that costin had objected to. The clarifications from JSP spec lead inidcates that costin was right. We should have a fix this week and that should go into 4.1.10. - Kin-man Date: Sat, 10 Aug 2002 09:54:02 -0700 (PDT) From: [EMAIL PROTECTED] Subject: Re: [4.1.9] New test milestone released X-X-Sender: [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] X-Authentication-warning: costinm.sfo.covalent.net: costin owned process doing -bs Remy, Let's try to make 4.1.10 the 'stable' release ( and consider 4.1.9 as the 'release candidate ). I cleaned up some of the jk messages and I want to do some more watchdog tests with apache/jk. If everyone agree, I think we should also tag jk2 as 'jk2.0beta' and jk1.2.0 release, even if we don't distribute a standalone package. Costin On Sat, 10 Aug 2002, Remy Maucherat wrote: A new test milestone of Tomcat 4.1 has just been released. Downloads: http://jakarta.apache.org/builds/jakarta-tomcat-4.0/test/v4.1.9/ Significant changes over 4.1.8 Beta include: - Jasper 2 bugfixes - Catalina classloader bugfixes - Coyote HTTP/1.1 fixes - Updated commons-dbcp connection pool The list of changes is available in the release notes. 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] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit:jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/servletJspServletWrapper.java
Date: Wed, 28 Aug 2002 16:41:16 -0700 (PDT) From: Craig R. McClanahan [EMAIL PROTECTED] Subject: Re: cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/servlet JspServletWrapper.java To: Tomcat Developers List [EMAIL PROTECTED] On 28 Aug 2002 [EMAIL PROTECTED] wrote: - Fixed 11485: recompilation of jsp files when TLD is modified. Cool! This change (and wasn't there another recent change to auto-detect changes in files included via %@ include %?) will definitely reduce user confusion. The auto-detect of included files is already working in 4.1.x. I turned that off for tomcat 5, because it was causing problems with auto compilation of tag files. It all works now. I also turn on auto-detection of changes to files that are included with include-prelude and include-coda in jsp-config in JSP2.0, usign the same mechanism. Now if I had this one in 4.1.x ... :-) I could back port the TLD dependency check part to 4.1.x if there are demands for it. Thanks, Craig -- 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: JSP Bug
This is not a bug. Any % that appears in an expression bracketed by % ... % needs to be escaped as %\ (JSP.2.6). Date: Mon, 09 Sep 2002 15:17:04 -0400 From: Stephane Zafirov [EMAIL PROTECTED] Subject: JSP Bug To: [EMAIL PROTECTED] I just wanted to make sure the following bug has been classified. Or maybe it is not a bug, but it looks like one. The following JSP: % String s = %; % is interpreted as: String s = in the java file in the work directory. So it does not compile. Obviously, there are workarrounds. I am just making sure it is known to everyone. Since its pretty simple, my guess is I am the last one to find it. Stephane -- 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: Catalina tester failure on JSP Document Parsing
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/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. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: JSR45
JSR45 support is already in Tomcat 5, which is yet to be released. You can, however, build it from source and try it out yourself. Date: Wed, 18 Sep 2002 16:48:00 +0200 From: Damian Frach [EMAIL PROTECTED] Subject: JSR45 To: [EMAIL PROTECTED] Hi, I am a member of the web app group of the Forte tools. Our group is responsible for the Tomcat integration with the Netbeans/Forte IDE. We are now planning new features for the next Forte release. We have plans for a JSR45 implementation. Can you give me information of your plans in this issue? It will really help us. Thanks, Damian. - Damian Frach Software Engineer, Forte Tools Software Platforms and Products [EMAIL PROTECTED] [EMAIL PROTECTED] Sun Microsystems Czech s.r.o. Evropska 33E 160 00 Prague 6 - Dejvice Tel.: +420 (2) 3300 - 9183 3300 - 9311 Fax.: +420 (2) 3300 - 9299 Mobile: +420 (604) 6277 - 20 Private: Tunelaru 328 Praha 5 - Zbraslav 15600 Tel: +420 (2) 57924924 Polni 10Stepankovice74728 Tel: +420 (653) 6750 - 27 - -- - Damian Frach Software Engineer, Forte Tools Software Platforms and Products [EMAIL PROTECTED] [EMAIL PROTECTED] Sun Microsystems Czech s.r.o. Evropska 33E 160 00 Prague 6 - Dejvice Tel.: +420 (2) 3300 - 9183 3300 - 9311 Fax.: +420 (2) 3300 - 9299 Mobile: +420 (604) 6277 - 20 Private: Tunelaru 328 Praha 5 - Zbraslav 15600 Tel: +420 (2) 57924924 Polni 10Stepankovice74728 Tel: +420 (653) 6750 - 27 - -- 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: [VOTE] [5.0] Milestones
+1 Date: Sat, 28 Sep 2002 16:12:06 +0200 From: Remy Maucherat [EMAIL PROTECTED] Subject: [VOTE] [5.0] Milestones To: Tomcat Developers List [EMAIL PROTECTED] Hi, Now that the first stable releases of Tomcat 4.1 are out (and according to reports, of good overall quality), it could be appropriate to start releasing 5.0.x milestones. It should be pointed out that 5.0.x is still far from being feature complete (esp the configuration code needs to be unified if possible, and some optimizations are needed), so the milestones should be considered alpha or pre alpha until further notice. ballot [ ] +1 Yes, start releasing milestones [ ] -1 No, because: /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]
Re: JSP Compilation Issues (Multiple Domains)
If you are using JDK javac for compiling the servlet generated by the JSP compiler, then you probably ran into the problem that the javac not being thread-safe. In Tomcat 5 the javac compilation is synchronized, so that the compilation is serialized. Guess that fix is not ported to 4.1.5. :-( I always assume that JSP pages would be deployed precompiled, and simultaneous compilation under development mode is rare. Maybe my assumption is wrong? Date: Mon, 30 Sep 2002 18:30:48 -0700 From: Joseph Kiok [EMAIL PROTECTED] Subject: JSP Compilation Issues (Multiple Domains) To: [EMAIL PROTECTED] X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600. X-Priority: 3 X-MSMail-priority: Normal Hi All, I'm currently running multiple domains (2 specifically) on top of Apache/Tomcat. It seems that when I hit both domains at the same time (using 2 browser windows), I get a JSP compilation error most (85%) of the time. However, when I reload the page with no JSP code change, it'll compile properly. (Some of the time like 10-15%, it won't recompile until I touch the file manually) Note: It doesn't happen when I only access one domain. PROBLEM SUMMARY: When loading JSPs on multiple domains (hosts) simultaneously, a JSP compile error is generated. SYSTEM COMPONENTS: - Solaris 2.8 - JDK 1.4.0_01 - Tomcat 4.1.12 - Apache 1.3.20 SOLUTIONS TRIED (FAILED): - Configured different workers for each domains (hosts) as recommended in the tomcat mod_jk document. - Downloaded the source of tomcat and recompiled everything on our environment. Any help would be appreciated. Thanks. Best regards, Joseph Kiok -- 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]
Help! Tomcat problem
I got the following exception when I run TC5. I am using xerces-2_0_1. I tried disable xmlValidation, but still have the problem. catalina.sh run Using CATALINA_BASE: /home/kchung/tc/jakarta-tomcat-5/build Using CATALINA_HOME: /home/kchung/tc/jakarta-tomcat-5/build Using CATALINA_TMPDIR: /home/kchung/tc/jakarta-tomcat-5/build/temp Using JAVA_HOME: /tomc/j2sdk1.4.0/ Oct 8, 2002 7:17:01 PM org.apache.commons.modeler.Registry loadRegistry INFO: Loading registry information Oct 8, 2002 7:17:01 PM org.apache.commons.modeler.Registry getRegistry INFO: Creating new Registry instance Oct 8, 2002 7:17:03 PM org.apache.commons.modeler.Registry getServer INFO: Creating MBeanServer Oct 8, 2002 7:17:06 PM org.apache.coyote.http11.Http11Protocol init INFO: Initializing Coyote HTTP/1.1 on port 8080 Starting service Tomcat-Standalone Apache Tomcat/5.0 Oct 8, 2002 7:17:08 PM org.apache.catalina.loader.WebappLoader start INFO: Reloading checks are enabled for this Context java.lang.NullPointerException at org.apache.catalina.startup.ContextConfig.registerLocalSchema(ContextConfig.java :740) at org.apache.catalina.startup.ContextConfig.createWebDigester(ContextConfig.java:5 93) at org.apache.catalina.startup.ContextConfig.defaultConfig(ContextConfig.java:628) at org.apache.catalina.startup.ContextConfig.start(ContextConfig.java:774) at org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:260) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.ja va:166) at org.apache.catalina.core.StandardContext.start(StandardContext.java:3718) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1188) at org.apache.catalina.core.StandardHost.start(StandardHost.java:791) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1188) at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:347) at org.apache.catalina.core.StandardService.start(StandardService.java:497) at org.apache.catalina.core.StandardServer.start(StandardServer.java:2290) at org.apache.catalina.startup.Catalina.start(Catalina.java:516) at org.apache.catalina.startup.Catalina.execute(Catalina.java:402) at org.apache.catalina.startup.Catalina.process(Catalina.java:180) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.jav a:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:202) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
costin: fix reverted
costin,
This fix seems to break errorPage handling in JSP, causing the errorPage
example to fail, and a couple of JSP watchdog tests too. I have reverted
your fix.
I have not reverted the tomcat_4_branch.
Date: Thu, 24 Oct 2002 19:18:55 +
From: [EMAIL PROTECTED]
Subject: cvs commit:
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/runtime
PageContextImpl.java
To: [EMAIL PROTECTED]
costin 2002/10/24 12:18:55
Modified:jasper2/src/share/org/apache/jasper/runtime
PageContextImpl.java
Log:
Change the 'flush' to just a 'flushBuffer'.
This allows the container to deal with flushing the buffer (
wich is done automatically if the servlet doesn't explicitely
flush()/close() ). The container can attach the Content-Length
header which is usefull in many cases.
Revision ChangesPath
1.27 +11 -6
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/runtime/PageContextImp
l.java
Index: PageContextImpl.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/runtime/Page
ContextImpl.java,v
retrieving revision 1.26
retrieving revision 1.27
diff -u -r1.26 -r1.27
--- PageContextImpl.java4 Oct 2002 19:21:44 - 1.26
+++ PageContextImpl.java24 Oct 2002 19:18:55 - 1.27
@@ -162,7 +162,7 @@
this.bufferSize = bufferSize;
this.autoFlush= autoFlush;
this.request = request;
- this.response = response;
+ this.response = response;
// setup session (if required)
if (request instanceof HttpServletRequest needsSession)
@@ -209,7 +209,12 @@
((JspWriterImpl)out).flushBuffer();
// push it into the including jspWriter
} else {
- out.flush();
+// Old code:
+ //out.flush();
+// Do not flush the buffer even if we're not included (i.e.
+// we are the main page. The servlet will flush it and
close
+// the stream.
+((JspWriterImpl)out).flushBuffer();
}
} catch (IOException ex) {
loghelper.log(Internal error flushing the buffer in release());
@@ -226,7 +231,7 @@
depth = -1;
baseOut.recycle();
session = null;
-
+
attributes.clear();
}
--
To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org
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: costin: fix reverted
X-Trace: main.gmane.org 1036447809 25208 64.84.39.162 (4 Nov 2002 22:10:09
GMT)
Date: Mon, 04 Nov 2002 14:11:32 -0800
From: Costin Manolache [EMAIL PROTECTED]
Subject: Re: costin: fix reverted
To: [EMAIL PROTECTED]
X-Complaints-to: [EMAIL PROTECTED]
NNTP-posting-date: Mon, 4 Nov 2002 22:10:09 + (UTC)
X-Injected-Via-Gmane: http://gmane.org/
NNTP-posting-host: 64.84.39.162
Kin-Man Chung wrote:
costin,
This fix seems to break errorPage handling in JSP, causing the errorPage
example to fail, and a couple of JSP watchdog tests too. I have reverted
your fix.
I have not reverted the tomcat_4_branch.
If it breaks something - tomcat_4_branch should be the first to revert :-)
I reverted tc5 for my own convenience. I didn't revert tomcat_4_branch
becuase I thought that you may want hack more there. :-)
I think the main question is if releasePageContext is required by the
spec to flush() ( i.e. commit the message ) or not.
The spec is not specific about this. So it is up to the implementation. :-)
If it is required - then Content-Length just can't be set by the container
for jsps ( which is not the end of the world :-).
If the spec doesn't require that ( and my reading is that releasePageContext
doc doesn't in any way imply this as a side effect - the flush() is a very
different API ) - then I would say the tests are wrong.
It's not that the tests are wrong, but that your 'fix' renders any JSP
error page not work at all. When an exception occurs, instead of displaying
the error page, it displays the stack trace of the exception! I don't have
anything against not calling flush() in release, but you'll also need to
make sure that it doesn't break this.
Costin
Date: Thu, 24 Oct 2002 19:18:55 +
From: [EMAIL PROTECTED]
Subject: cvs commit:
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/runtime
PageContextImpl.java
To: [EMAIL PROTECTED]
costin 2002/10/24 12:18:55
Modified:jasper2/src/share/org/apache/jasper/runtime
PageContextImpl.java
Log:
Change the 'flush' to just a 'flushBuffer'.
This allows the container to deal with flushing the buffer (
wich is done automatically if the servlet doesn't explicitely
flush()/close() ). The container can attach the Content-Length
header which is usefull in many cases.
Revision ChangesPath
1.27 +11 -6
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/runtime/PageContextImp
l.java
Index: PageContextImpl.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/runtime/Page
ContextImpl.java,v
retrieving revision 1.26
retrieving revision 1.27
diff -u -r1.26 -r1.27
--- PageContextImpl.java 4 Oct 2002 19:21:44 - 1.26
+++ PageContextImpl.java 24 Oct 2002 19:18:55 - 1.27
@@ -162,7 +162,7 @@
this.bufferSize = bufferSize;
this.autoFlush= autoFlush;
this.request = request;
- this.response = response;
+ this.response = response;
// setup session (if required)
if (request instanceof HttpServletRequest needsSession)
@@ -209,7 +209,12 @@
((JspWriterImpl)out).flushBuffer();
// push it into the including jspWriter
} else {
- out.flush();
+// Old code:
+ //out.flush();
+// Do not flush the buffer even if we're not included
(i.e.
+// we are the main page. The servlet will flush it and
close
+// the stream.
+((JspWriterImpl)out).flushBuffer();
}
} catch (IOException ex) {
loghelper.log(Internal error flushing the buffer in release());
@@ -226,7 +231,7 @@
depth = -1;
baseOut.recycle();
session = null;
-
+
attributes.clear();
}
--
To unsubscribe, e-mail:
mailto:tomcat-dev-unsubscribe;jakarta.apache.org 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
--
To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: TagHandlerPool doesn't release Tags on reuse
According to the JSP 1.2 Spec, the release method is not invoked between
tag usages, but is invoked before GC of the tag handler. Therefore
it should not be used to reset the tag handler to its initial state;
you should do that in doStartTag. See p164 and p166.
Date: Mon, 11 Nov 2002 13:32:31 +0100
From: Torsten Fohrer [EMAIL PROTECTED]
Subject: TagHandlerPool doesn't release Tags on reuse
To: '[EMAIL PROTECTED]' [EMAIL PROTECTED]
I have some jsp sites which taglibs. With pooling enabled, some problems
occures.
Samples:
Customer Registration: all fields have the same values???
Sessions Values are used together
After reading the jsp spezifikation and source of the
jasper/runtime/TagHandlerPool, i see that the pool doesn't call release in
his reuse method?
After adding a general release in the reuse methode, which perhaps breaks
the lifecycle of the IterationTag ( see jsp-spec, page 168 ) it's working.
/**
* Adds the given tag handler to this tag handler pool, unless this tag
* handler pool has already reached its capacity, in which case the tag
* handler's release() method is called.
*
* @param handler Tag handler to add to this tag handler pool
*/
public synchronized void reuse(Tag handler) {
// Releasing Tags, see jsp spec 1.2-fcs, page 172
handler.release();
if (current (handlers.length - 1))
handlers[++current] = handler;
}
Torsten Fohrer
**
* DCSI AG* Tel.: +49 7131 155 88-0 *
* Lessingstrasse 17-19 * Fax.: +49 7131 155 88-99 *
* D-74076 Heilbronn * [EMAIL PROTECTED]*
* GERMANY* http://www.dcsi.de*
**
--
To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org
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: TagHandlerPool doesn't release Tags on reuse
Use doStartTag for inits, doEndTag for cleanups. release will be invoked
from destroy.
Date: Mon, 11 Nov 2002 20:34:13 +0100
From: [EMAIL PROTECTED] (Torsten Fohrer)
Subject: Re: TagHandlerPool doesn't release Tags on reuse
X-Sender: [EMAIL PROTECTED]
To: Tomcat Developers List [EMAIL PROTECTED]
Content-disposition: inline
But if i looking into the generated jsp/servlet sources, i see the following:
--- example ---
/* tools:simpleCell */
de.dcsi.util.jsp.taglibs.Validator_SimpleCell
_jspx_th_tools_simpleCell_0 = (de.dcsi.util.jsp.taglibs.Validator_SimpleCell)
_jspx_
tagPool_tools_simpleCell_width_valign_messageName_height_errorName_errorColor.ge
t(de.dcsi.util.jsp.taglibs.Validator_SimpleCell.class);
_jspx_th_tools_simpleCell_0.setPageContext(pageContext);
_jspx_th_tools_simpleCell_0.setParent(null);
_jspx_th_tools_simpleCell_0.setErrorName(messages);
_jspx_th_tools_simpleCell_0.setMessageName(login);
_jspx_th_tools_simpleCell_0.setHeight(30);
_jspx_th_tools_simpleCell_0.setValign(top);
_jspx_th_tools_simpleCell_0.setWidth(14%);
_jspx_th_tools_simpleCell_0.setErrorColor( errorColor );
int _jspx_eval_tools_simpleCell_0 =
_jspx_th_tools_simpleCell_0.doStartTag();
if (_jspx_th_tools_simpleCell_0.doEndTag() ==
javax.servlet.jsp.tagext.Tag.SKIP_PAGE)
return;
example
If i now reset my tag to a initial state in doStartTag() i haven't any
properties set
Who call the release method in reaction of the GC, finalize can't it.
On Monday 11 November 2002 18:44, Kin-Man Chung wrote:
According to the JSP 1.2 Spec, the release method is not invoked between
tag usages, but is invoked before GC of the tag handler. Therefore
it should not be used to reset the tag handler to its initial state;
you should do that in doStartTag. See p164 and p166.
Date: Mon, 11 Nov 2002 13:32:31 +0100
From: Torsten Fohrer [EMAIL PROTECTED]
Subject: TagHandlerPool doesn't release Tags on reuse
To: '[EMAIL PROTECTED]' [EMAIL PROTECTED]
I have some jsp sites which taglibs. With pooling enabled, some problems
occures.
Samples:
Customer Registration: all fields have the same values???
Sessions Values are used together
After reading the jsp spezifikation and source of the
jasper/runtime/TagHandlerPool, i see that the pool doesn't call release
in his reuse method?
After adding a general release in the reuse methode, which perhaps breaks
the lifecycle of the IterationTag ( see jsp-spec, page 168 ) it's
working.
/**
* Adds the given tag handler to this tag handler pool, unless this
tag * handler pool has already reached its capacity, in which case the
tag * handler's release() method is called.
*
* @param handler Tag handler to add to this tag handler pool
*/
public synchronized void reuse(Tag handler) {
// Releasing Tags, see jsp spec 1.2-fcs, page 172
handler.release();
if (current (handlers.length - 1))
handlers[++current] = handler;
}
Torsten Fohrer
**
* DCSI AG* Tel.: +49 7131 155 88-0 *
* Lessingstrasse 17-19 * Fax.: +49 7131 155 88-99 *
* D-74076 Heilbronn * [EMAIL PROTECTED]*
* GERMANY* http://www.dcsi.de*
**
--
To unsubscribe, e-mail:
mailto:tomcat-dev-unsubscribe;jakarta.apache.org 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
--
To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org
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
[Jasper2] framework for tag optimization
I am designing a framework in Jasper for enabling plugins that
work closely with Jasper to generate Java codes instead of calls
to tag handlers. The main idea is to take take JSTL tags, such as
c:forEach var=i begin=1, end=100
${i}
/c:forEach
and generates the Java codes
for (int i = 0; i = 100; i++) {
pageContext.setAttribute(i, String.valueOf(i));
out.print(evaluate(${i}));
}
or even
for (int i = 0; i = 100; i++) {
out.print(i);
}
The design is not to do the actual optimization in Jasper, but to
provide a framework for taglib writers to develop plugins to Jasper
that will do the actual optimization. Eventually, Jasper will be
bundled with 1 or 2 plugins for JSTL, as test cases for the framework
and as examples for writing the plugins.
The plugins are specified in a xml file:
tag-plugins
tag-plugin
tag-classthe name of the tag class/tag-class
plugin-classthe name of the pkugin class/plugin-class
/tag-plugin
tag-plugins
There are currently 3 interfaces:
TagPluginFactory
Used for creating a TagPlugin.
TagPlugin
Created at code generation time for a specific tag invokation. Used
by Jasper to generate java codes.
TagPlugContext
Created by Japser and used by the plugin to query properties of
the current tag, and to use resources in Jasper.
This work is at the very early stage of the design, and is purely
experimental. I'll be checking in sources for this work, and they
should not affect the other part of Jasper, when plugins are not
turned on.
I welcome comments and suggestions.
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Jasper 2 Synchronized JSP compiles
Performance-wise, wouldn't doing javac compilation in another process be much worse than synchronized javac, at least for systems with small number of processors? It would nice if we can have some numbers for comparision. I know javac used to have memory leak, but is it still true for modern compilers, such as the one in JDK 1.4.0? BTW, I am +1 on the proposal. Date: Wed, 04 Dec 2002 09:04:35 -0600 From: Glenn Nielsen [EMAIL PROTECTED] Subject: Jasper 2 Synchronized JSP compiles To: [EMAIL PROTECTED] I have some ideas on how invoking the javac compiler for compiling JSP pages can be improved. Currently Jasper 2 uses ant to do compiles from within Tomcat which are synchronized. There are currently several problems. 1. The known javac memory leak. 2. JSP page compiles are synchronized. 3. Jikes currently can't be configured for windows because the windows build of jikes doesn't support -encoding. 4. We may be getting some bug reports related to this problem noted in the Ant documentation for the javac task: Windows Note:When the modern compiler is used in unforked mode on Windows, it locks up the files present in the classpath of the javac task, and does not release them. The side effect of this is that you will not be able to delete or move those files later on in the build. The workaround is to fork when invoking the compiler. Recommendation: Change Jasper 2 so that it tells ant to fork the javac compile. This should remove the need to synchronize the compiles. It will also move java compilation outside of the JVM process Tomcat is running in saving JVM heap memory and reducing GC overhead from objects created for JSP compiles. This could be done by just adding another parameter called fork to the JspServlet paramters. If fork=true ant forks the javac compile and no synchronization is done. The default for fork would be false. Comments? Regards, Glenn -- 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: [newbie] where do I get TagFileInfo, etc.?
It's in jakarta-servletapi-4, which IS mentioned in BUILDING_txt. Make sure that you have servlet.home defined correctly in build.properties. Date: Wed, 04 Dec 2002 17:39:25 -0800 From: Michael [EMAIL PROTECTED] Subject: [newbie] where do I get TagFileInfo, etc.? To: [EMAIL PROTECTED] I'm trying to build jakarta-tomcat-4.0, but it wanted jakarta-tomcat-jasper (not mentioned in BUILDING.txt). I checked that out, but it's build fails with undefined symbols. Where can I find these? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [newbie] where do I get TagFileInfo, etc.?
Sorry for not responding earlier. When checking out files from jakarta-tomcat-jasper, make sure to use the tag tomcat_4_branch. The head branch is an implementation of JSP 2.0, and is used for building TC5.0. Good luck! Date: Sat, 07 Dec 2002 14:57:24 -0800 From: Michael [EMAIL PROTECTED] Subject: Re: [newbie] where do I get TagFileInfo, etc.? To: Tomcat Developers List [EMAIL PROTECTED] Kin-Man Chung wrote: It's in jakarta-servletapi-4, which IS mentioned in BUILDING_txt. Make sure that you have servlet.home defined correctly in build.properties. I'm trying to build jakarta-tomcat-4.0, but it wanted jakarta-tomcat-jasper (not mentioned in BUILDING.txt). I checked that out, but it's build fails with undefined symbols. Where can I find these? I was relying on Debian's libservlet2.3-java package. But it's not in jakarta-servletapi-4, either. I built that, and pointed jakarta-tomcat-4.0/build.properties to it, but get the same errors. I grepped the tree, too, and couldn't find 'package.*javax\.servlet\.jsp\.el', for example. So far, I've got the CVS from jakarta-servletapi-4 jakarta-tomcat-connectors jakarta-tomcat-4.0 jakarta-tomcat-jasper Thanks. -- 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: cvs commit:jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper JspC.java
See below. Date: Wed, 22 Jan 2003 19:03:08 +0100 From: Remy Maucherat [EMAIL PROTECTED] Subject: Re: cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper JspC.java To: Tomcat Developers List [EMAIL PROTECTED] Costin Manolache wrote: Remy Maucherat wrote: Then why not default to the context path ? Can you give examples ? It's very hard to determine the context path from JSPC IMO. I think the naming conventions for the generated servlets should be settled down, documented - and treated as APIs ( i.e. no change unless absolutely needed ). Ok, but in the meantime, we must not allow non packaged classes. When I wrote my patch, I also felt that a default package prefix was a good idea, but I dropped it in the end due to the package/directory structure mismatch. If it's really important to, you should also make sure the class files are generated in a directory structure that starts with org/apache/jsp/ I was wondering about that, actually, and thought this was inconsistent. JSPC does generate the right package directory structure. I think JspServlet should do the same - if it doesn't already. Well, I don't think we care. JspServlet generates in the workdir, and uses one CL per page. So packaging is not relevant IMO. OTOH, JSPC may generate the classes in /WEB-INF/classes, so we would need to create the full package structure. I'd like to point out that you admin precompilation example does include an extra admin subfolder in the output directory path. Remy Well, there is one case that generating the classes with the same package name would cause problem, and that is when you have two JSP pages with the same file name (but in different directories). Still not a problem in class loading, since the class files are placed in different directories, but you cannot debug them anymore since you cannot identify the classes by name - they have the same name. Anyone knows why it was done this way? -- 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]
