Re: re:tag plugin
For practical purposes, I don't think you'll gain much using plugins for c:set and c:out, since they are relatively simple, and the overheads for invoking the corresponding tag handlers is relatively minor. You'll probably achieve most benefit if you can provide plugins for them that only handle tags with no or empty bodies. If you must, just for academic discussion, you can get to the body content of a tag by generating codes to invoke pushBody() when you enter the body, and popBody() when you leave. - Kin-man On Thu, 2005-08-25 at 21:07, wing lee wrote: Thanks a lot at first :-) By now I think on two occasions the body content should be used. Firstly in the out tag, because some special characters should be converted, so if body content is output, the body content should be filtered. Secondly in the set tag, if the body content is assigned to the variable, the body content should be got at first. That's why I think there should be a method to get the body content. Now in the out tag, I just output the body content without filter. In the set tag, when I have to use the body content, I invoke the method dontUseTagPlugin. I don't know whether doing so is ok. Best regards, Li Jing - DO YOU YAHOO!? 雅虎免费G邮箱－中国第一绝无垃圾邮件骚扰超大邮箱 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: tag plugin
The method generateBody() is meant to continue to generate
codes for body of the tag, as usual. What you want is a method
to generate codes to get the body content, which is certainly
doable, but is not currently available. You are welcome to have
the first crack at extending the plugin framework if you like. It'll
require invoking pushBody(), generateBody(), then popBody() to get the
body content, similar to the codes that are being generated for
fragments. But I don't think you really need it though.
Attributes are much simpler, they are just expressions.
BTW, your English is just fine: no apologies needed. :-)
-Kin-man
On Tue, 2005-08-23 at 02:33, wing lee wrote:
Thanks for all your help.
But I still have questions :-). I know that the body content of the tag is
the runtime entity. I think the value of some attributes is also runtime
entity, if its value can be EL. The method generateAttribute can generate the
code in the generated x_jsp.java file which returns the dynamic value of the
attribute. So I can write such code to get the dynamic value in the
x_jsp.java file:
//in jsp file
c:out value=${xxx}/
//in the tag plugin file
ctxt.generateJavaSource(String s = (String));
ctxt.generateAttribute(value);
ctxt.generateJavaSource(;);
The generated code is:
String s = (String) (Object)
org.apache.jasper.runtime.PageContextImpl.proprietaryEvaluate
(${xxx}, java.lang.Object.class, (PageContext)
_jspx_page_context, null, false);
But if I write such code:(just for example)
//the jsp file
c:out value=asd${xxx}/c:out
//in the tag plugin file
ctxt.generateJavaSource(String s = (String));
ctxt.generateBody();
ctxt.generateJavaSource(;);
the generated code is:
String s = (String) out.write((Object)
org.apache.jasper.runtime.PageContextImpl.proprietaryEvaluate
(${xxx}, java.lang.Object.class, (PageContext)
_jspx_page_context, null, false));
and this code's syntax is wrong.
I think that there should be a method to provide the functionality similar to
the one of the generateAttribute which doesn't output the out.write source
code, so that I can use the body content in the generated file x_jsp.java.
I am not so good at English so perhaps my expression is not very clear. Sorry
about that.
-
DO YOU YAHOO!?
雅虎免费G邮箱－中国第一绝无垃圾邮件骚扰超大邮箱
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: tag plugin
The body content of a tag is a runtime entity, and you cannot
generally get it during compilation time, since it may contain
non-template texts. You need to achieve what you want in another way,
such as the use of JSP fragments.
-Kin-man
On Sat, 2005-08-20 at 00:26, wing lee wrote:
I think it's ok in the if tag. When the following code
ctxt.generateJavaSource(if ( + condV + ){);
ctxt.generateBody();
ctxt.generateJavaSource(});
is executed, the generated code is supposed to be:
if(temp_name_of_condV){
out.write(body_content);
}
the generateBody method not generates the code body_content, but the
out.write(body_content). so I can not write the code to get the value of
the body like following:
String tempName = ctxt.getTemporaryVariable();
ctxt.generateJavaSource(Object +tempName+=);
ctxt.generateBody();
ctxt.generateJavaSource(;);
because the generated code will be like this:
Object temp_name = out.write(body_content);
not this:
Object temp_name = body_content;
so this is what confuses me.
Remy Maucherat [EMAIL PROTECTED] 写道：
wing lee wrote:
I've tried the generateBody method, but it just generate such code
write.out(body content), don't return the value of the body content.
That's odd: it's supposed to continue evaluation and code generation for
the body, not consider nested stuff as static text. There's a good
example with the if tag plugin (although, as I said, I didn't test it
at all, so maybe it's broken).
public final class If implements TagPlugin {
public void doTag(TagPluginContext ctxt) {
String condV = ctxt.getTemporaryVariableName();
ctxt.generateJavaSource(boolean + condV + =);
ctxt.generateAttribute(test);
ctxt.generateJavaSource(;);
if (ctxt.isAttributeSpecified(var)) {
String scope = PageContext.PAGE_SCOPE;
if (ctxt.isAttributeSpecified(scope)) {
String scopeStr = ctxt.getConstantAttribute(scope);
if (request.equals(scopeStr)) {
scope = PageContext.REQUEST_SCOPE;
} else if (session.equals(scopeStr)) {
scope = PageContext.SESSION_SCOPE;
} else if (application.equals(scopeStr)) {
scope = PageContext.APPLICATION_SCOPE;
}
}
ctxt.generateJavaSource(_jspx_page_context.setAttribute();
ctxt.generateAttribute(var);
ctxt.generateJavaSource(, new Boolean( + condV + ), + scope +
););
}
ctxt.generateJavaSource(if ( + condV + ){);
ctxt.generateBody();
ctxt.generateJavaSource(});
}
}
Rémy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
DO YOU YAHOO!?
雅虎免费G邮箱－中国第一绝无垃圾邮件骚扰超大邮箱
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: New TLP draft
It appears that my name (Kin-man Chung [EMAIL PROTECTED]) has been dropped from the PMC. Hope this is not intentional. :-) On Wed, 2005-04-06 at 05:15, Remy Maucherat wrote: Hi, Here's a new draft with the necessary updates. I suppose this needs to be sent to the PMC for approval. If this draft is ok, I will send it there. Then there are infrastructure taks: - renaming mailing lists - moving CVS - new DNS and virtual host To summarize things: - I will be the proposed first PMC chair - PMC chairs will serve for one year, and cannot serve consecutive one year terms (shouldn't this be put in the resolution text ? - if so, please help writing it, as I can't write ASF resolution compliant language) - although the ASF infrastructure is quite aggressive in pushing Subversion, I find it harder to work with than CVS at the moment (including crucial - for me - revision graphs, and better tool support); as a result, I think I would prefer keeping CVS for the time being - feel free to take any further actions to update the PMC list (as proposed by Costin) Rmy --- Draft TLP resolution --- X. Establish the Apache Tomcat Project WHEREAS, the Board of Directors deems it to be in the best interests of the Foundation and consistent with the Foundation's purpose to establish a Project Management Committee charged with the creation and maintenance of open-source software related to the implementation of the Java Servlet and Java Server Pages specifications, for distribution at no charge to the public. NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee (PMC), to be known as the Apache Tomcat PMC, be and hereby is established pursuant to Bylaws of the Foundation; and be it further RESOLVED, that the Apache Tomcat PMC be and hereby is responsible for the creation and maintenance of software related to creation and maintenance of open-source software related to the implementation of the Java Servlet and Java Server Pages specifications based on software licensed to the Foundation; and be it further RESOLVED, that the office of Vice President, Apache Tomcat be and hereby is created, the person holding such office to serve at the direction of the Board of Directors as the chair of the Apache Tomcat PMC, and to have primary responsibility for management of the projects within the scope of responsibility of the Apache Tomcat PMC; and be it further RESOLVED, that the persons listed immediately below be and hereby are appointed to serve as the initial members of the Apache Tomcat PMC: Jean-Francois Arcand ([EMAIL PROTECTED]) Bill Barker ([EMAIL PROTECTED]) Ian Darwin ([EMAIL PROTECTED]) Jean-Frederic Clere ([EMAIL PROTECTED]) Tim Funk ([EMAIL PROTECTED]) Henri Gomez ([EMAIL PROTECTED]) Filip Hanik ([EMAIL PROTECTED]) Larry Isaacs ([EMAIL PROTECTED]) Jim Jagielski ([EMAIL PROTECTED]) Jan Luehe ([EMAIL PROTECTED]) Costin Manolache ([EMAIL PROTECTED]) Remy Maucherat ([EMAIL PROTECTED]) Kurt Miller ([EMAIL PROTECTED]) Glenn Nielsen ([EMAIL PROTECTED]) Amy Roh ([EMAIL PROTECTED]) Peter Rossbach ([EMAIL PROTECTED]) Yoav Shapira ([EMAIL PROTECTED]) Mark Thomas ([EMAIL PROTECTED]) Mladen Turk ([EMAIL PROTECTED]) Keith Wannamaker ([EMAIL PROTECTED]) NOW, THEREFORE, BE IT FURTHER RESOLVED, that Remy Maucherat be appointed to the office of Vice President, Apache Tomcat, to serve in accordance with and subject to the direction of the Board of Directors and the Bylaws of the Foundation until death, resignation, retirement, removal or disqualification, or until a successor is appointed; and be it further RESOLVED, that the initial Apache Tomcat PMC be and hereby is tasked with the creation of a set of bylaws intended to encourage open development and increased participation in the Apache Tomcat Project; and be it further RESOLVED, that the initial Apache Tomcat PMC be and hereby is tasked with the migration and rationalization of the Apache Jakarta PMC Tomcat subproject; and be it further RESOLVED, that all responsibility pertaining to the Jakarta Tomcat sub-project and encumbered upon the Apache Jakarta PMC are hereafter discharged. --- End draft TLP resolution --- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED
Re: JSP Compile Hangs
Please file a report on bugzilla. If you also include a test case
(to save me some typing :)), I'll take a look to see where Jasper is
spending its time. Did you said it was in commons-el? That'd be bad.
-Kin-man
On Wed, 2004-10-20 at 00:43, Eric Blenkush wrote:
On Oct 19, 2004, at 10:41 PM, Remy Maucherat wrote:
Eric Blenkush wrote:
Hi,
On Tomcat 5.5.2 I am experiencing very long compile times(and hangs)
for certain JSP pages. The page has an EL expression like this:
${fn:toUpperCase((fn:toUpperCase((fn:toUpperCase((fn:toUpperCase((fn:
toUpperCase((fn:toUpperCase((fn:toUpperCase((fn:toUpperCase((fn:
toUpperCase((fn:toUpperCase((fn:toUpperCase((fn:toUpperCase((fn:
toUpperCase((fn:toUpperCase((fn:toUpperCase((fn:
toUpperCase(('b'}
If you remove the extraneous parenthesis it will compile and execute
very quickly. However, if you add more nested calls to fn:toUpperCase
compiling will again take a very long time. So, this may be related
to the number of nested expressions. This is just a test case
obviously but I am generating JSPs automatically and it is difficult
if not impossible to avoid EL statements with these nested function
calls. Resin can compile and execute these pages very quickly but I
want to stick with Tomcat.
This is crucial to the project I am working on and if someone has an
idea of what is causing this and where to look in the tomcat source I
would appreciate it.
Please don't whine. I hope you have tested this with 5.0.x as well.
If you have a compilation problem specific to the Java compiler, you
obviously should:
- report it to the Eclipse project
- use Ant + javac to compile instead (remove the
jasper-compiler-jdt.jar and put ant.jar at the same spot)
You may want to try to generate efficient code.
Any bug filed about the Eclipse compiler (other than an integration
issue) will be marked as INVALID.
Rmy
The hang is happening when the .java file is being generated from the
.jsp file. I confirmed this by taking the commons-el-1.0 source and
modifying it to parse the same EL statement as given above and it never
completed.
Any helpful comments on where to start looking to fix this are welcome.
Thanks,
Eric
-
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/xmlparser ParserUtils.java UTF8Reader.java
I have no problem getting rid of all those messages, since they are no longer useful. - Kin-man On Fri, 2004-09-17 at 14:23, Amy Roh wrote: [EMAIL PROTECTED] wrote: amyroh 2004/09/17 14:02:34 Modified:jasper2/src/share/org/apache/jasper/compiler SmapUtil.java jasper2/src/share/org/apache/jasper/runtime HttpJspBase.java jasper2/src/share/org/apache/jasper/security SecurityClassLoad.java jasper2/src/share/org/apache/jasper/xmlparser ParserUtils.java UTF8Reader.java Log: More logging changes. You might want to get rid of the if (verbose) and other if (debug_flag_with_funky_name) at the same time :) Yeah, I thought about that. But I didn't want to just get rid of it in case some folks are still using the property. Does anyone object to getting rid of debug/verbose property? Thanks, Amy Rmy - 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: Question on 5.0.23
Which watchdog is it? Can you send me the other part (tld and tag handler)
of it?
If the tag is of a TAGDEPENDENT body type, then its body is should not
be evaluated. It used to be evaluated in XML syntax, which is wrong and
which is what the patch intend to fix. If this is the case, then the
golden file for the watchdog test should be replaced.
-Kin-man
Date: Wed, 05 May 2004 02:26:32 +0200
From: Remy Maucherat [EMAIL PROTECTED]
Subject: Re: Question on 5.0.23
To: Tomcat Developers List [EMAIL PROTECTED]
I have some possible problems with Jasper and XML syntax. One example
from old watchdog:
jsp:root
xmlns:jsp=http://java.sun.com/JSP/Page; version=1.2
xmlns:direct=urn:jsptld:/WEB-INF/tlds/example-taglib.tld
jsp:text![CDATA[html
titlepositiveDirectTldReference/title
body
]]/jsp:text
jsp:text![CDATA[
]]/jsp:text
direct:test toBrowser=true att1=att1
jsp:text![CDATA[
Validated
]]/jsp:text
/direct:test
jsp:text![CDATA[
/body
/html
]]/jsp:text
/jsp:root
Generates for the tag:
do {
out.write(jsp:text);
out.write(\n);
out.write(Validated\n);
out.write(/jsp:text);
out.write('\n');
int evalDoAfterBody = _jspx_th_direct_test_0.doAfterBody();
member = (String) _jspx_page_context.findAttribute(member);
if (evalDoAfterBody !=
javax.servlet.jsp.tagext.BodyTag.EVAL_BODY_AGAIN)
break;
} while (true);
So the tag body is not getting evaluated. I suspect this patch, which
was not yet present in 5.0.22:
kinman 2004/04/16 16:22:30
Modified:jasper2/src/share/org/apache/jasper/compiler
JspDocumentParser.java
Log:
- Fix a bug where a custom tag with tagdependent body type is not
handled correctly in XML syntax. The fix would have been trivial
if not
for the cases where jsp:attribute and/or jsp:body is present.
I'm not too big on tags though, so I don't know for sure if it's even a bug.
(et hop, 5.0.25 ... :/ )
Rémy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 5.0.20 Issue
Your test for bad beans is much weaker than what it is now. For instance,
you do not catch the case where the bean class is abstract.
However, I am sympathetic to your view on this. If I can be convinced that
we have covered all checks that we can do without too much trouble, I'll
fix Jasper.
-Kin-man
Date: Tue, 30 Mar 2004 08:30:05 -0600
From: Jess Holle [EMAIL PROTECTED]
Subject: Re: Tomcat 5.0.20 Issue
To: Tomcat Developers List [EMAIL PROTECTED]
X-OriginalArrivalTime: 30 Mar 2004 14:30:06.0040 (UTC)
FILETIME=[7EEF4580:01C41663]
Kin-Man Chung wrote:
I think your only valid point is the one about the need to make
errorOnUseBeanInvalidClassAttribute be switchable from Jspc main,
but we are not bundling jspc scripts anymore, so I didn't feel there
is a need for it. Anyway, its value can be set with an ant task.
Otherwise, Jasper behaves the same as before when
errorOnUseBeanInvalidClassAttribute is set to false. Well, maybe it
take more time to compile, but that's a compile-time vs. runt-time
tradeoff that all compilers make.
The ideas behind the fix, both in the Jasper and the JSP 2.0 spec, is
to allow the Jasper to generate faster code and to catch as much
errors as possible at compile time. For the embedded compilations, the
comile environment is the same as the runitme (request time) environment,
so there is no problem. For Jspc compilations, you'll just need to make
sure that they are the same, otherwise you'll need to set
errorOnUseBeanInvalidClassAttribute to false there.
I'm not arguing with the overall intent of your change. Rather I
believe that calling the constructor during compilation is wasteful and
improper as the environment *can* differ between compilation and
runtime. Also, the fact that a failure to compile in this fashion
generates a partial Java source means that once a compilation fails due
to an environmental issue it will continue to fail even when the
environment is corrected (e.g. when another server comes back up).
That's certainly not appropriate.
If you have ideas about how to modify Generator that works better, please
submit a patch, and I'll see if it can be incorporated.
I must profess ignorance as to how to submit an official patch (e.g. how
to generate one), but here's a diff with Generator.java version 1.230
from CVS of what I'm suggesting:
22a23
*import java.lang.reflect.Constructor;*
1224c1225,1226
bean.newInstance();
---
// Next line will throw exception if
public no-args constructor cannot be found
*Constructor constructor =
bean.getConstructor( new Class[] {} );
*
Essentially, I'm suggesting we check for the existence of the default
constructor, but don't call it. That takes the same amount of real code
(2 more lines thanks to my import and gratuitous comment) and avoids (1)
actually constructing the bean during compilation and (2) making any
unnecessary assumptions about compilation vs. runtime environmental
conditions.
Applying this diff to Generator.java addresses my issue and I believe is
an overall improvement and better aligned with the JSP specification. I
would greatly appreciate it if this could be incorporated into the
Jasper/Tomcat source stream.
--
Jess Holle
[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 5.0.20 Issue
I think your only valid point is the one about the need to make errorOnUseBeanInvalidClassAttribute be switchable from Jspc main, but we are not bundling jspc scripts anymore, so I didn't feel there is a need for it. Anyway, its value can be set with an ant task. Otherwise, Jasper behaves the same as before when errorOnUseBeanInvalidClassAttribute is set to false. Well, maybe it take more time to compile, but that's a compile-time vs. runt-time tradeoff that all compilers make. The ideas behind the fix, both in the Jasper and the JSP 2.0 spec, is to allow the Jasper to generate faster code and to catch as much errors as possible at compile time. For the embedded compilations, the comile environment is the same as the runitme (request time) environment, so there is no problem. For Jspc compilations, you'll just need to make sure that they are the same, otherwise you'll need to set errorOnUseBeanInvalidClassAttribute to false there. If you have ideas about how to modify Generator that works better, please submit a patch, and I'll see if it can be incorporated. -Kin-man Date: Wed, 24 Mar 2004 09:50:43 -0600 From: Jess Holle [EMAIL PROTECTED] Subject: Tomcat 5.0.20 Issue To: Tomcat Developers List [EMAIL PROTECTED] X-OriginalArrivalTime: 24 Mar 2004 15:50:43.0599 (UTC) FILETIME=[C3DDB1F0:01C411B7] Jess Holle wrote: Works just great in quick testing at least. I'm still waiting for my precompilation script to return to determine whether Jasper still compiles everything it used to (and should have). Unfortunately, Tomcat 5.0.20 cannot compile 6 out our 985 JSP pages (which Tomcat 5.0.19 compiled just fine). The issue can be traced directly to a single entry in the change log: Add some intellignece to the compiler for generating code for useBean action. Generate direct instantiation (use new) when possible, use bean.instantiate when bean name is specified, and for the case of invalid bean class, either issue a translation time error (instead of javac error), or generate codes to throw InstantiationException at runtime, depending on a new compiler switch, errorOnUseBeanInvalidClassAttribute(defaulted to true) (kinman) There are several issues with this change: 1. The new logic assumes that the bean can be directly instantiated /at compile time/ and throws a page compilation error when this is not the case. * There are beans that can be directly instantiated at run time but not at compile time (e.g. upon precompilation). This was the case in all 6 of our failures. [Examples as to when this might occur include requirements for databases being accessible, other servers running, etc, etc, for successful bean instantiation.] * The error occurs in such a way that a partial Java source file is written, so later attempts to recompile the page (when the runtime environment is duplicated) also fail unless the partial Java source file is first deleted. 2. I note the errorOnUseBeanInvalidClassAttribute setting but there are issues here as well: * The default value, true, breaks existing code. * If errorOnUseBeanInvalidClassAttribute is set to false: o Instantiation of some (e.g. session or application scope) beans can be time and/or resource consuming. Besides being an invalid test as to whether a bean can be directly instantiated, instantiating such beans during compilation can be costly. [The combined time for precompiling all pages was longer in 5.0.20 with this behavior in place than when I removed it.] o The new behavior will cause beans to be instantiated via Beans.instantiate() rather than directly instantiated when compile time direct instantiation fails. This leads to a performance degradation whenever a bean has a runtime instantiation dependency. * As best I can tell, errorOnUseBeanInvalidClassAttribute is not accessible from / exposed via JspC main -- which I use from my pre-compilation scripts for various reasons. Due to these issues I have reverted this change in Generator to the 5.0.19 state (leaving the other valuable changes in this class intact). Once I did so all 985 JSP pages compiled -- including the 6 that had previously failed. I would urge that this change be reverted -- either in this release (or an immediate 5.0.21 release) or immediately changed in HEAD for the next release. -- Jess Holle - 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/runtime JspWriterImpl.java
-1. The patch breaks the spec.
According to JSP 2.0 spec, JSP.5.5 (p1-111),
If the page output was unbuffered and anything has been written to
it, an attempt to forward the request will result in an
IllegalStateException.
-Kin-man
Date: Thu, 18 Mar 2004 21:05:17 +
From: [EMAIL PROTECTED]
Subject: cvs commit:
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/runtime
JspWriterImpl.java
To: [EMAIL PROTECTED]
markt 2004/03/18 13:05:17
Modified:jasper2/src/share/org/apache/jasper/runtime
JspWriterImpl.java
Log:
- Fix bug 13499. Remove unnecssary bufferSize check
- Ported from TC4
Revision ChangesPath
1.10 +0 -3
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/runtime/JspWriterImpl.
java
Index: JspWriterImpl.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/runtime/JspW
riterImpl.java,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -r1.9 -r1.10
--- JspWriterImpl.java 17 Mar 2004 19:23:04 - 1.9
+++ JspWriterImpl.java 18 Mar 2004 21:05:17 - 1.10
@@ -139,9 +139,6 @@
* Discard the output buffer.
*/
public final void clear() throws IOException {
-if (bufferSize == 0)
-throw new IllegalStateException(
-getLocalizeMessage(jsp.error.ise_on_clear));
if (flushed)
throw new IOException(
getLocalizeMessage(jsp.error.attempt_to_clear_flushed_buffer));
-
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/runtime JspWriterImpl.java
The action jsp:forward generates a call to PageContextImpl.forward(),
so the patch affects how this action works. The following test
%@ page buffer=none %
jsp:forward page=test.jsp/
used to raise an ISE, now it does not. The test for buffersize might
not be the best way to implement the part of the spec (that was before
my time), but it got the job done. The patch may (and should) break
some TCK tests.
-Kin-man
Date: Thu, 18 Mar 2004 22:23:12 +
From: Mark Thomas [EMAIL PROTECTED]
Subject: RE: cvs commit:
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/runtime
JspWriterImpl.java
To: 'Tomcat Developers List' [EMAIL PROTECTED]
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Thread-index: AcQNM+1cLsjNLxfdTQ2XKdmvPyCgnAAAa/UA
Kin-man,
The original bug report was that Jasper threw an exception on an immediate
pageContext.forward() on an unbuffered page. My reading of the spec is that
this
shouldn't happen. I can't see how this check helps meet the part of the spec
you
quoted.
Am I being stupid and missing the blindingly obvious here?
Mark
-Original Message-
From: Kin-Man Chung [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 18, 2004 9:57 PM
To: [EMAIL PROTECTED]
Subject: Re: cvs commit:
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/runt
ime JspWriterImpl.java
-1. The patch breaks the spec.
According to JSP 2.0 spec, JSP.5.5 (p1-111),
If the page output was unbuffered and anything has been
written to
it, an attempt to forward the request will result in an
IllegalStateException.
-Kin-man
Date: Thu, 18 Mar 2004 21:05:17 +
From: [EMAIL PROTECTED]
Subject: cvs commit:
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/runtime
JspWriterImpl.java
To: [EMAIL PROTECTED]
markt 2004/03/18 13:05:17
Modified:jasper2/src/share/org/apache/jasper/runtime
JspWriterImpl.java
Log:
- Fix bug 13499. Remove unnecssary bufferSize check
- Ported from TC4
Revision ChangesPath
1.10 +0 -3
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/runt
ime/JspWriterImpl.
java
Index: JspWriterImpl.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/j
asper/runtime/JspW
riterImpl.java,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -r1.9 -r1.10
--- JspWriterImpl.java 17 Mar 2004 19:23:04 - 1.9
+++ JspWriterImpl.java 18 Mar 2004 21:05:17 - 1.10
@@ -139,9 +139,6 @@
* Discard the output buffer.
*/
public final void clear() throws IOException {
-if (bufferSize == 0)
-throw new IllegalStateException(
-
getLocalizeMessage(jsp.error.ise_on_clear));
if (flushed)
throw new IOException(
getLocalizeMessage(jsp.error.attempt_to_clear_flushed_buffer));
-
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]
-
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/compiler Generator.java
-1.
Remy, please reread JSP 2.0 spec, p 1-101,1-102. Bullet .2 of the Semantics
section was added to allow for this kind of optimization. Bullet .5 and .6
will be executed ONLY IF the container choose not to issue translation errors.
-Kin-man
Date: Mon, 02 Feb 2004 18:18:01 +
From: [EMAIL PROTECTED]
Subject: cvs commit:
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler
Generator.java
To: [EMAIL PROTECTED]
remm2004/02/02 10:18:01
Modified:jasper2/src/share/org/apache/jasper/compiler Generator.java
Log:
- Revert useBean optimization done by Kin-Man, as it seems to violate the
spec wording (which basically says that an error should occur at runtime
if the class
is not a JavaBean).
- Bug 26507.
Revision ChangesPath
1.217 +31 -35
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Generator.jav
a
Index: Generator.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Gen
erator.java,v
retrieving revision 1.216
retrieving revision 1.217
diff -u -r1.216 -r1.217
--- Generator.java 31 Jan 2004 01:56:28 - 1.216
+++ Generator.java 2 Feb 2004 18:18:00 - 1.217
@@ -1261,41 +1261,37 @@
className =
attributeValue(beanName, false, String.class);
}
-out.printil(try {);
-out.pushIndent();
-out.printin(name);
-out.print( = ();
-out.print(type);
-out.print() java.beans.Beans.instantiate();
-out.print(this.getClass().getClassLoader(), );
-out.print(className);
-out.println(););
-out.popIndent();
-/*
- * Note: Beans.instantiate throws
ClassNotFoundException
- * if the bean class is abstract.
- */
-out.printil(} catch (ClassNotFoundException exc) {);
-out.pushIndent();
-out.printil(
-throw new
InstantiationException(exc.getMessage()););
-out.popIndent();
-out.printil(} catch (Exception exc) {);
-out.pushIndent();
-out.printin(throw new ServletException();
-out.print(\Cannot create bean of class \ + );
-out.print(className);
-out.println(, exc););
-out.popIndent();
-out.printil(}); // close of try
} else {
// Implies klass is not null
-// Generate codes to instantiate the bean class
-out.printin(name);
-out.print( = new );
-out.print(klass);
-out.println((););
+className = quote(klass);
}
+out.printil(try {);
+out.pushIndent();
+out.printin(name);
+out.print( = ();
+out.print(type);
+out.print() java.beans.Beans.instantiate();
+out.print(this.getClass().getClassLoader(), );
+out.print(className);
+out.println(););
+out.popIndent();
+/*
+ * Note: Beans.instantiate throws ClassNotFoundException
+ * if the bean class is abstract.
+ */
+out.printil(} catch (ClassNotFoundException exc) {);
+out.pushIndent();
+out.printil(
+throw new InstantiationException(exc.getMessage()););
+out.popIndent();
+out.printil(} catch (Exception exc) {);
+out.pushIndent();
+out.printin(throw new ServletException();
+out.print(\Cannot create bean of class \ + );
+out.print(className);
+out.println(, exc););
+out.popIndent();
+out.printil(}); // close of try
/*
* Set attribute for bean in the specified scope
*/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands,
Re: cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler Generator.java
Agreed that the spec can be clearer. :-) This has been discussed by the Spec expert group, and bullet .2 was added because some vendors wanted it. I'll check with the spec lead for a clarification. Also agreed that this breaks backward compatibility; but it not really too bad. I think a lot of users would rather have the error at compilation time than at runtime. What can you do with an instantiation error at runtime? If we are really concern about BC, then we can add another compilation option to revert to old behavior. I really don't like another switch, but if it'll make people happy... -Kin-man Date: Mon, 02 Feb 2004 19:41:54 +0100 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] Kin-Man Chung wrote: -1. Remy, please reread JSP 2.0 spec, p 1-101,1-102. Bullet .2 of the Semantics section was added to allow for this kind of optimization. Bullet .5 and .6 will be executed ONLY IF the container choose not to issue translation errors. I cannot really understand what the fragment really means, so I don't know. I had the impression that it implied that the error should be at runtime. I recommend the change is reverted as I did, as many users will likely make the same mistake, since the specification is impossible to understand (if you are right and your change indeed does not break the specification). This will also create compilation errors when upgrading from TC 4 to TC 5. Rémy - 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/compiler Generator.java
Date: Mon, 02 Feb 2004 20:17:29 +0100 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] Kin-Man Chung wrote: Agreed that the spec can be clearer. :-) This has been discussed by the Spec expert group, and bullet .2 was added because some vendors wanted it. I'll check with the spec lead for a clarification. Ok. Also agreed that this breaks backward compatibility; but it not really too bad. I think a lot of users would rather have the error at compilation time than at runtime. What can you do with an instantiation error at runtime? Nothing, but some don't care: they never intended their page to be called without the right attribute in the right scope, so the case where their JavaBean is instantiated never happens. Then EL should be used in this case. If we are really concern about BC, then we can add another compilation option to revert to old behavior. I really don't like another switch, but if it'll make people happy... No new switch, please ;) So we have to decide one or the other. So do you want me to revert the patch ? I'd rather you check with me first before the patch, but since it is already done, let's wait for the spec clarification before we do anything. A revert on a revert would make us look really silly. :-) -Kin-man Rémy - 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: Understanding jakarta-tomcat-4.0 cvs source base / jasper
The source for Jasper in Tomcat 4.1.29 is from j-t-j/jasper2 with Tomcat_4_branch tag. The head branch is for Tomcat 5. A lot of bugs filed against Tomcat 4.1.x has been fixed in Tomcat 5. Unfortunately I don't have cycles to apply the fixes to 4.1.x. It would be great if someone can do that, and I can help and/or anser questions if needed. The branch jakarta-tomcat-4.0/jasper was used for Tomcat 4.0.x releases, and I don't think we are making new releases for Tomcat 4.0.x. -Kin-man Date: Mon, 15 Dec 2003 12:42:30 -0700 From: Jeff Tulley [EMAIL PROTECTED] Subject: Understanding jakarta-tomcat-4.0 cvs source base / jasper To: [EMAIL PROTECTED] Content-disposition: inline Quick question - Does the jasper that ships with Tomcat 4.1.29 come from the source code in jakarta-tomcat-4.0/jasper, or is it from the jakarta-tomcat-jasper CVS module? I am looking at some bugs in Bugzilla against Jasper, where they complain about something in j-t-4.0/jasper/src/(some class), and the bug is fixed in j-t-j/jasper2/src I do not know whether to mark the bug as fixed or investigate further. If the answer turns out that the source code in j-t-4/jasper is NOT being used, what is there against removing it to avoid confusion? Jeff Tulley ([EMAIL PROTECTED]) (801)861-5322 Novell, Inc., The Leading Provider of Net Business Solutions http://www.novell.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: Jasper used for Tomcat 4.0.6
The code for Jasper in 4.0.x is in the module jakarta-tomcat-4.0. Date: Thu, 30 Oct 2003 14:51:13 -0600 From: Ken Sipe [EMAIL PROTECTED] Subject: Jasper used for Tomcat 4.0.6 To: [EMAIL PROTECTED] X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal There are uses with the currect Jasper JspC compiler in the current Tomcat 4.1.x. It works fine in Tomcat 4.0.x. I was looking to see the diff on them and I can't find a label in CVS that maps to code for Tomcat 4.0.x. Could someone explain where the JspC code is for Tomcat 4.0 stuff. It doesn't appear to be under the jasper code base. Although I see tomcat 33 and 4.1 references. Thanks, Ken - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] New builds
Date: Wed, 29 Oct 2003 11:32:58 +0100 From: Remy Maucherat [EMAIL PROTECTED] Subject: [VOTE] New builds To: Tomcat Developers List [EMAIL PROTECTED] ballot Release 4.1.29 as Stable ? [ ] Yes [ ] No /ballot ballot Release 5.0.14 as Beta ? [X] Yes Jasper seems solid. [ ] No /ballot Rémy - 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] IndexOutOfBoundsException from CharChunk
I believe 23805 is unrelated to my problem, and may even be invalid. Mine comes from CharChunk. To refresh the memory, the stack trace is Servlet.service() for servlet jsp threw exception java.lang.IndexOutOfBoundsException at sun.nio.cs.StreamEncoder.write(StreamEncoder.java:132) at java.io.OutputStreamWriter.write(OutputStreamWriter.java:191) at org.apache.tomcat.util.buf.WriteConvertor.write(C2BConverter.java:228 ) at org.apache.tomcat.util.buf.C2BConverter.convert(C2BConverter.java:120 ) at org.apache.coyote.tomcat5.OutputBuffer.realWriteChars(OutputBuffer.ja va:606) at org.apache.tomcat.util.buf.CharChunk.flushBuffer(CharChunk.java:463) at org.apache.coyote.tomcat5.OutputBuffer.flush(OutputBuffer.java:357) at org.apache.coyote.tomcat5.CoyoteWriter.flush(CoyoteWriter.java:117) at org.apache.jasper.runtime.JspWriterImpl.flush(JspWriterImpl.java:203) at org.apache.jasper.runtime.JspRuntimeLibrary.include(JspRuntimeLibrary .java:990) ... In my case, it's not the offset, but end that is too big. It got the value of 16384 when limit is only 8192. I have looked into this more without getting more insight. I use jdb to catch IndexOutOfBoundsException but couldn't figure out what caused end to get this big. Since this happens randomly, I cannot stop a thread and follow its progress. Inserting prints in CharChunk was also not useful, since values for end in threads appear normal until the exception occurs, as if its value were clobbered by a strayed pointer (like in C). The print did show that in some cases, the value for end is 16384 after write(char[]) was invoked, though that didn't cause any exception for some reason. This turns out to be more elusive that it appears. I might have to give this up as another mystery of the universe. :-) -Kin-man Date: Wed, 15 Oct 2003 10:36:01 +0200 From: Remy Maucherat [EMAIL PROTECTED] Subject: Re: [5] IndexOutOfBoundsException from CharChunk To: Tomcat Developers List [EMAIL PROTECTED] Kin-Man Chung wrote: I don't know much about the test; it is one of stress test we have, but it should not affect CharChunk this way, right, even if it has something weird? Like I said, this happens only in this test, and not always reproducible, so I am not surprised that nobody noticed it in 4.1. I thought it might be thread related, but each thread should have its own CharChunk instance, so I can't see how. I look into this more and report back. Bug 23805 could be related to this, and I'm awaiting more details. At least, the offset numbers do match, which is too big a coincidence ;-) 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]
[5] IndexOutOfBoundsException from CharChunk
I am getting a sporadic IndexOutOfBoundsException and it seems to come from
org.apache.tomcat.util.buf.CharChunk.flushBuffer. The trace is
Servlet.service() for servlet jsp threw exception
java.lang.IndexOutOfBoundsException
at sun.nio.cs.StreamEncoder.write(StreamEncoder.java:132)
at java.io.OutputStreamWriter.write(OutputStreamWriter.java:191)
at org.apache.tomcat.util.buf.WriteConvertor.write(C2BConverter.java:228
)
at org.apache.tomcat.util.buf.C2BConverter.convert(C2BConverter.java:120
)
at org.apache.coyote.tomcat5.OutputBuffer.realWriteChars(OutputBuffer.ja
va:606)
at org.apache.tomcat.util.buf.CharChunk.flushBuffer(CharChunk.java:463)
at org.apache.coyote.tomcat5.OutputBuffer.flush(OutputBuffer.java:357)
at org.apache.coyote.tomcat5.CoyoteWriter.flush(CoyoteWriter.java:117)
at org.apache.jasper.runtime.JspWriterImpl.flush(JspWriterImpl.java:203)
at org.apache.jasper.runtime.JspRuntimeLibrary.include(JspRuntimeLibrary
.java:990)
...
In CharChunk,
public void flushBuffer()
throws IOException
{
//assert out!=null
if( out==null ) {
throw new IOException( Buffer overflow, no sink + limit + +
buff.length );
}
out.realWriteChars( buff, start, end - start );
end=start;
}
when realWriteChars is called, the value for start is 0, end is 16384, and
buff.length is 8192, hence the exception.
Does anyone knows how end can go beyond 8192? This only hapeens very
rarely, under heavy load.
-Kin-man
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5] IndexOutOfBoundsException from CharChunk
Date: Wed, 08 Oct 2003 21:22:07 +0200
From: Remy Maucherat [EMAIL PROTECTED]
Subject: Re: [5] IndexOutOfBoundsException from CharChunk
To: Tomcat Developers List [EMAIL PROTECTED]
Kin-Man Chung wrote:
I am getting a sporadic IndexOutOfBoundsException and it seems to come from
org.apache.tomcat.util.buf.CharChunk.flushBuffer. The trace is
Servlet.service() for servlet jsp threw exception
java.lang.IndexOutOfBoundsException
at sun.nio.cs.StreamEncoder.write(StreamEncoder.java:132)
at java.io.OutputStreamWriter.write(OutputStreamWriter.java:191)
at
org.apache.tomcat.util.buf.WriteConvertor.write(C2BConverter.java:228
)
at
org.apache.tomcat.util.buf.C2BConverter.convert(C2BConverter.java:120
)
at
org.apache.coyote.tomcat5.OutputBuffer.realWriteChars(OutputBuffer.ja
va:606)
at
org.apache.tomcat.util.buf.CharChunk.flushBuffer(CharChunk.java:463)
at
org.apache.coyote.tomcat5.OutputBuffer.flush(OutputBuffer.java:357)
at
org.apache.coyote.tomcat5.CoyoteWriter.flush(CoyoteWriter.java:117)
at
org.apache.jasper.runtime.JspWriterImpl.flush(JspWriterImpl.java:203)
at
org.apache.jasper.runtime.JspRuntimeLibrary.include(JspRuntimeLibrary
.java:990)
...
In CharChunk,
public void flushBuffer()
throws IOException
{
//assert out!=null
if( out==null ) {
throw new IOException( Buffer overflow, no sink + limit +
+
buff.length );
}
out.realWriteChars( buff, start, end - start );
end=start;
}
when realWriteChars is called, the value for start is 0, end is 16384, and
buff.length is 8192, hence the exception.
Does anyone knows how end can go beyond 8192? This only hapeens very
rarely, under heavy load.
I don't know. I suppose limit is 8192 also. Are you sure your test is
clean, and without anything weird ? (somehow, I doubt it)
I've changed a bit the algorithm in ByteChunk, and it seems better, but
the CharChunk algorithm is identical in 4.1's ByteChunk and CharChunk.
We would have noticed anything bad, I think.
I don't know much about the test; it is one of stress test we have, but it
should not affect CharChunk this way, right, even if it has something
weird? Like I said, this happens only in this test, and not always
reproducible, so I am not surprised that nobody noticed it in 4.1. I
thought it might be thread related, but each thread should have its own
CharChunk instance, so I can't see how. I look into this more and report
back.
-Kin-man
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: \% not handled right?
This is a bug. I have committed a fix in Tomcat 5. Thanks for reporting. -Kin-man Date: Tue, 23 Sep 2003 07:30:29 -0400 From: Tim Funk [EMAIL PROTECTED] Subject: \% not handled right? To: Tomcat Developers List [EMAIL PROTECTED] Attached is a note from tomcat-user which I think might be a bug in jasper. Summary it you don't want to read it... Take this page: - %=BAR% \%=bar% - It produces: BAR \%=bar% Instead of BAR \bar The spec says to escape % with \% -Tim Original Message Subject: JSP Compilation Problem Date: Tue, 23 Sep 2003 13:23:30 +0300 From: Anatol Pomazau [EMAIL PROTECTED] Reply-To: Tomcat Users List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Hi. I just upgrade tomcat server from 4.1.12 to Tomcat-dev (I get sources from CVS and compile it yesterday) But I have a problem with one jsp. So, such code % String fullname = Anatol Pomazau; % a target=newForm href=\\epmsa007\applForm\new_applicant_form\%=fullname%.doc%=fulln ame%/a Works fine in old version but in new Tomcat generates a target=newForm href=\\epmsa007\applForm\new_applicant_form\%=fullname%.docAnatol Pomazau/a Insead of a target=newForm href=\\epmsa007\applForm\new_applicant_form\Anatol Pomazau.docAnatol Pomazau/a I have looked JSP Spec 2.0 and I have not found any remarks about such quoting. What I do wrong? Please help me. epam EPAM Systems, Minsk, Belarus work: +375 17 210 1662, ext. #1373 icq uin: 138182429 - 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] - 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/compiler Generator.java
Eric,
I forgot about those generated Declartions. It good to have an extra
pair of eyes to keep one honest. Thanks. :)
I have committed a fix for this and the last you reported. Please see if
it works better now. I have noticed that smap now contains lots of
overlaps, because of duplications in the unoptimized smap. I'll leave
to you as an exercise to remove them in smap optimizations :-) Enough
smap for me for the time being.
-Kin-man
Date: Sat, 20 Sep 2003 00:45:21 -0700
From: Eric Carmichael [EMAIL PROTECTED]
Subject: Re: cvs commit:
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler
Generator.java
X-Originating-IP: [64.203.49.21]
To: Tomcat Developers List [EMAIL PROTECTED]
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
X-Priority: 3
X-MSMail-priority: Normal
X-Originating-Email: [EMAIL PROTECTED]
X-OriginalArrivalTime: 20 Sep 2003 07:45:25.0789 (UTC)
FILETIME=[2776FCD0:01C37F4B]
This SMAPs all declaration nodes, including the ones tacked on to the root
node by ELFunctionMapper.java. So for instance the SMAP for
jsp2/el/functions.jsp from the jsp-examples webapp ends with
43,6:120
1,3:10
1,5:13
thus SMAPping
%@ taglib prefix=my
uri=http://jakarta.apache.org/tomcat/jsp2-example-taglib%
to
static private org.apache.jasper.runtime.ProtectedFunctionMapper
_jspx_fnmap_0;
static private org.apache.jasper.runtime.ProtectedFunctionMapper
_jspx_fnmap_1;
and
static {
_jspx_fnmap_0=
org.apache.jasper.runtime.ProtectedFunctionMapper.getMapForFunction(my:reverse
, jsp2.examples.el.Functions.class, reverse, new Class[]
{java.lang.String.class});
_jspx_fnmap_1=
org.apache.jasper.runtime.ProtectedFunctionMapper.getMapForFunction(my:countVow
els, jsp2.examples.el.Functions.class, numVowels, new Class[]
{java.lang.String.class});
}
which is clearly wrong.
Eric
- Original Message -
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Friday, September 19, 2003 4:38 PM
Subject: cvs commit:
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler
Generator.java
kinman 2003/09/19 16:38:09
Modified:jasper2/src/share/org/apache/jasper/compiler Generator.java
Log:
- Make sure scriptlet declarations get properly mapped. This fixes 22833
Revision ChangesPath
1.211 +7 -6
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Generator.jav
a
Index: Generator.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Gen
erator.java,v
retrieving revision 1.210
retrieving revision 1.211
diff -u -r1.210 -r1.211
--- Generator.java 19 Sep 2003 18:30:09 - 1.210
+++ Generator.java 19 Sep 2003 23:38:08 - 1.211
@@ -196,9 +196,7 @@
*/
public void visit(Node.PageDirective n) throws
JasperException {
-if (!getServletInfoGenerated) {
-getServletInfoGenerated = true;
-} else {
+if (getServletInfoGenerated) {
return;
}
@@ -206,6 +204,7 @@
if (info == null)
return;
+getServletInfoGenerated = true;
out.printil(public String getServletInfo() {);
out.pushIndent();
out.printin(return );
@@ -217,8 +216,10 @@
}
public void visit(Node.Declaration n) throws JasperException
{
+n.setBeginJavaLine(out.getJavaLine());
out.printMultiLn(new String(n.getText()));
out.println();
+n.setEndJavaLine(out.getJavaLine());
}
// Custom Tags may contain declarations from tag plugins.
-
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/resources messages.properties
Date: Mon, 15 Sep 2003 22:57:32 -0700
From: Eric Carmichael [EMAIL PROTECTED]
Subject: Re: cvs commit:
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/resources
messages.properties
X-Originating-IP: [64.203.49.21]
To: Tomcat Developers List [EMAIL PROTECTED]
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
X-Priority: 3
X-MSMail-priority: Normal
X-Originating-Email: [EMAIL PROTECTED]
X-OriginalArrivalTime: 16 Sep 2003 05:57:41.0966 (UTC)
FILETIME=[7112DEE0:01C37C17]
But this also shows that tight coupling between Generator and SmapUtil is
flagile and error prone. I think it would be a better design if we
decouple these two modules somehow. We could create additional data
structure that captures the mapping info for template texts, with
Generator
its producer and SmapUtil its comsumer. What do you think? I'll
think about this more.
I thought about this a bit when I was copying the line feed logic from
Generator.java to SmapUtil.java to fix the line mappings for template text
nodes, because I didn't like duplicating code, but I didn't see an
alternative except to move the SMAPping into Generator. How would your
producer/consumer approach differ from that? If a data structure that
captures mapping info is what's needed, we already have SmapStratum
performing that function, so I don't see much difference between having
Generator produce a new mapping info data structure and just having
Generator produce the SMAP directly.
I think keeping an array (in the Template node) of the source line that
corresponds to each of the Java line we generate is probably enough. I'll
commit some codes today and you'll see what I mean.
There are reasons for not doing SMAP generation in Generator. Generator is
already the biggest module in Jasper, and I'd like not to make it any more
complicated. Also, some codes are generated out of order, in buffers that
got appended at the end of generating the main method, so that the mappings
cannot be determined when codes are generated.
SMAP generation is one of the area that does not got enough test and use.
You seem to be one of the few who actually look at it. Are you doing anything
with it?
-Kin-man
BTW, the reason for if (textSize = 3) is for performance optimization.
out.write('\n') should be faster than out.write(\n) so it's OK that
you move into the if (ctxt.getOptions().genStringAsCharArray()) block,
for now; but it should really be applied in all cases. Maybe we can
write all out.write()'s in a single line, so that the mapping is not
changed? Or we can revisit this later.
Yeah, I didn't know if putting if (textSize = 3) outside the if
(ctxt.getOptions().genStringAsCharArray()) block was intentional or not,
which is why I was hesitant to commit my fix. Thanks for clarifying. I
don't have a problem changing the SMAPs as long as we don't break them, so
do whatever you think best on the Generator side, and I'll just try to make
sure to check for SMAP regressions before the next release.
Eric
-
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/resources messages.properties
I know, I know. I plead guilty as charged. :-) Unfortunately, not having a debugger that uses SMP, it is hard to automate SMAP testing. You pretty much has to manually eyeball the files to verify its correctness. I think netbeans is planning to use tomcat 5 for its next major, so we'll expect more use there. -Kin-man Date: Tue, 16 Sep 2003 19:46:19 +0200 From: Remy Maucherat [EMAIL PROTECTED] Subject: Re: cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/resources messages.properties To: Tomcat Developers List [EMAIL PROTECTED] Kin-Man Chung wrote: I think keeping an array (in the Template node) of the source line that corresponds to each of the Java line we generate is probably enough. I'll commit some codes today and you'll see what I mean. There are reasons for not doing SMAP generation in Generator. Generator is already the biggest module in Jasper, and I'd like not to make it any more complicated. Also, some codes are generated out of order, in buffers that got appended at the end of generating the main method, so that the mappings cannot be determined when codes are generated. SMAP generation is one of the area that does not got enough test and use. You seem to be one of the few who actually look at it. Are you doing anything with it? Given the number of bug reports which have been filed against that single feature, I can assert this is not the case. You should rewrite your sentence as SMAP generation is one of the area that does not get enough test and use among Tomcat committers ;-) 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/resources messages.properties
Ah, I forgot about the fix that you did in SmapUtil to improve line mappings
for template texts. Sorry. :-(
But this also shows that tight coupling between Generator and SmapUtil is
flagile and error prone. I think it would be a better design if we
decouple these two modules somehow. We could create additional data
structure that captures the mapping info for template texts, with Generator
its producer and SmapUtil its comsumer. What do you think? I'll
think about this more.
BTW, the reason for if (textSize = 3) is for performance optimization.
out.write('\n') should be faster than out.write(\n) so it's OK that
you move into the if (ctxt.getOptions().genStringAsCharArray()) block,
for now; but it should really be applied in all cases. Maybe we can
write all out.write()'s in a single line, so that the mapping is not
changed? Or we can revisit this later.
-Kin-man
Date: Sun, 14 Sep 2003 21:44:56 -0700
From: Eric Carmichael [EMAIL PROTECTED]
Subject: Re: cvs commit:
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/resources
messages.properties
X-Originating-IP: [64.203.49.21]
To: Tomcat Developers List [EMAIL PROTECTED]
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
X-Priority: 3
X-MSMail-priority: Normal
X-Originating-Email: [EMAIL PROTECTED]
X-OriginalArrivalTime: 15 Sep 2003 04:45:06.0060 (UTC)
FILETIME=[22569CC0:01C37B44]
This change leads to incorrect SMAPs of TemplateText nodes with 3 or fewer
characters, because the if (textSize = 3) logic isn't mirrored in
SmapUtil.java.
Moving the if (textSize = 3) block into the if
(ctxt.getOptions().genStringAsCharArray()) block seems to be a quick way to
fix the problem for genStrAsCharArray=false (which, if
genStrAsCharArray=true is still experimental, is the only case that really
matters), but I haven't followed this thread closely enough to feel
confident committing that change.
Eric
- Original Message -
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Tuesday, September 09, 2003 2:46 PM
Subject: cvs commit:
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/resources
messages.properties
kinman 2003/09/09 14:46:22
Modified:jasper2/src/share/org/apache/jasper
EmbeddedServletOptions.java JspC.java Options.java
jasper2/src/share/org/apache/jasper/compiler Generator.java
jasper2/src/share/org/apache/jasper/resources
messages.properties
Log:
- Add an compilation option to generate writing char arrays instead of
Strings
for template texts.
OK, I'm committing the code experimentally. Please try it out and see
if it improves performance. To turn it on, set the initParam
genStrAsCharArray to true.
Revision ChangesPath
1.6 +28 -3
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/EmbeddedServletOpt
ions.java
Index: EmbeddedServletOptions.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/Embedded
ServletOptions.java,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- EmbeddedServletOptions.java 6 Aug 2003 20:04:05 - 1.5
+++ EmbeddedServletOptions.java 9 Sep 2003 21:46:22 - 1.6
@@ -157,6 +157,11 @@
private boolean isSmapDumped = false;
/**
+ * Are Text strings to be generated as char arrays?
+ */
+private boolean genStringAsCharArray = false;
+
+/**
* I want to see my generated servlets. Which directory are they
* in?
*/
@@ -290,6 +295,13 @@
}
/**
+ * Are Text strings to be generated as char arrays?
+ */
+public boolean genStringAsCharArray() {
+return this.genStringAsCharArray;
+}
+
+/**
* Class ID for use in the plugin tag when the browser is IE.
*/
public String getIeClassId() {
@@ -513,6 +525,19 @@
} else {
if (log.isWarnEnabled()) {
log.warn(Localizer.getMessage(jsp.warning.dumpSmap));
+}
+}
+}
+
+String genCharArray =
config.getInitParameter(genStrAsCharArray);
+if (genCharArray != null) {
+if (genCharArray.equalsIgnoreCase(true)) {
+genStringAsCharArray = true;
+} else if (genCharArray.equalsIgnoreCase(false)) {
+genStringAsCharArray = false;
+} else {
+if (log.isWarnEnabled()) {
+
log.warn(Localizer.getMessage(jsp.warning.genchararray));
}
}
}
1.60 +10 -3
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/JspC.java
Index: JspC.java
Re: cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler Generator.java
Yeah, now I remember; but I didn't pay attention then! :-) Anyway, the print methods handle null String and Object, so we are covered. This is true for outputting expressions in text mode; evaluating attributes with expressions is, however, another matter. BTW, I also think it acceptable to raise NPE. Let's leave print's in until someone else objects! :-) -Kin-man Date: Thu, 11 Sep 2003 08:53:36 +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] [EMAIL PROTECTED] wrote: kinman 2003/09/10 16:11:56 Modified:jasper2/src/share/org/apache/jasper/compiler Generator.java Log: - Use out.print(expr) instead of out.write(String.valueOf(expr)) for outputting expressions in template texts. The problem was when the expression was null, if I remember well the original justification for String.valueOf (of course, it is IMO acceptable to raise a NPE). 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: AW: AW: AW: [5.0] JSP performance ...
Date: Wed, 10 Sep 2003 18:34:40 +0200 From: Remy Maucherat [EMAIL PROTECTED] Subject: Re: AW: AW: AW: [5.0] JSP performance ... To: Tomcat Developers List [EMAIL PROTECTED] Torsten Fohrer wrote: next try Yes, the code is better (IMO) and performs a little better also. However, looking more at my profiler, I think the problem with that benchmark is all the not optimized int - String conversions. Since that's not too useful in the real world (but in that benchmark, it seems extremely important), it is not worth optimizing it right now. BTW, for these, Resin generated out.print((var)), assuming the type of the expression would be correct. I think we went through that and decided not to do that, right ? We did? I think we should also use out.print(var) instead of out.write(String.valueOf(var)). The print methods cover all the types covered by String.valueOf, so there is really no advantage in using out.write's. Using print lets javac resolves the object types at compile time instead of runtime, and should be faster. If there is no objections, I'll go ahead and make the change. - Kin-man I think we would need to define a decent servletJSP bench suite :) (and avoid to rig it) 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: AW: [5.0] JSP performance ...
Date: Tue, 09 Sep 2003 08:59:51 +0200 From: Remy Maucherat [EMAIL PROTECTED] Subject: Re: AW: [5.0] JSP performance ... To: Tomcat Developers List [EMAIL PROTECTED] Kin-Man Chung wrote: I have implemented generating text strings as char arrays, with a compiler option to turn it on and off, and did some timings on the benchmark. Just as I suspected, the benchmark did not show much performance difference, when the option was turned on and then off. Now I am wondering if there is any value in committing my change. :( Well, if it does improve results, it can't hurt, but the two should likely be similar. What did you get in your testing ? I ran your Jsp page with added timings. The difference in the numbers with the option switched on and off is less the time flutuation itself. I think what should be optimized is that there's twice the amount of writes. Looking at the code generated, this situation seems rather common. So the idea would be to do a pass to merge all those TemplateText nodes :) I'll try that next, but don't get your hope up. It may not change much. The profile showed about 75% of the CPU was spent in the JSP service (as usual with the VM profiles, it's probably misleading), and probably some of that time comes from the fact it has to invoke hundreds of methods. Method calls should be cheap. The question is: is writng a String of size 1000 much faster than writing 10 Strings each of size 100? -Kin-man Remy I took a look at o.a.j.runtime.JspWriterImpl and the methods write(String s, int off, int len) and write(char cbuf[], int off, int len) in particualr, and failed to see any performance gain of the 2nd over the first. They are very similar, the only different is that the first uses String.getChars while the second uses System.arraycopy, but those two methods should be on par in terms of performance. That is, I don't see any extra unnecessary copies. Perhasp the culprit is those extra writes? -Kin-man - 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: AW: [5.0] JSP performance ...
This seems easy enough to implement, so I'll look into it. Concatenating texts is also on my list, and it should help a little in this case. - Kin-man Date: Mon, 08 Sep 2003 08:46:32 +0200 From: Torsten Fohrer [EMAIL PROTECTED] Subject: AW: [5.0] JSP performance ... To: 'Tomcat Developers List' [EMAIL PROTECTED] i have patched jasper to use char arrays instead of strings, and it gaves a good performance improvment. It's not perfect, but is works. cu Torsten -Ursprüngliche Nachricht- Von: Remy Maucherat [mailto:[EMAIL PROTECTED] Gesendet: Sonntag, 7. September 2003 15:49 An: Tomcat Developers List Betreff: [5.0] JSP performance ... .. is not as good as it should be. I found a benchmark where TC is currently not too good. The problem occurs when dealing with lots of strings. I'm attaching the benchmark, the code generated by TC, and the code generated by Resin. Resin String handling tricks ends with it making about half the amount of writes, and writing char arrays instead of Strings. I believe this is faster :-D While the benchmark is quite lame, I believe a lot of pages have similar amounts of interleaved static HTML, so optimizing this would give a healthy performance increase. (Note: I did a quick review with a profiler, and all the CPU time is spent in the _jspService method body, using a compiled JSP, so the performance overhead is in the generated code for this particular test) (I found this while looking for optimization ideas) Can we get the same kind of stuff ? Kin-Man, Jan, others ? 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: AW: [5.0] JSP performance ...
I took a look at o.a.j.runtime.JspWriterImpl and the methods write(String s, int off, int len) and write(char cbuf[], int off, int len) in particualr, and failed to see any performance gain of the 2nd over the first. They are very similar, the only different is that the first uses String.getChars while the second uses System.arraycopy, but those two methods should be on par in terms of performance. That is, I don't see any extra unnecessary copies. Perhasp the culprit is those extra writes? -Kin-man Date: Mon, 08 Sep 2003 23:03:19 +0200 From: Remy Maucherat [EMAIL PROTECTED] Subject: Re: AW: [5.0] JSP performance ... To: Tomcat Developers List [EMAIL PROTECTED] Kin-Man Chung wrote: This seems easy enough to implement, so I'll look into it. Concatenating texts is also on my list, and it should help a little in this case. That would be awesome. The test had a *lot* of writes, so this would save hundreds of write invocations (as well as making them faster as it would user char arrays). JSP performance should be really good with that change. 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: AW: [5.0] JSP performance ...
I have implemented generating text strings as char arrays, with a compiler option to turn it on and off, and did some timings on the benchmark. Just as I suspected, the benchmark did not show much performance difference, when the option was turned on and then off. Now I am wondering if there is any value in committing my change. :( -Kin-man Date: Mon, 08 Sep 2003 15:18:34 -0700 (PDT) From: Kin-Man Chung [EMAIL PROTECTED] Subject: Re: AW: [5.0] JSP performance ... To: [EMAIL PROTECTED] Content-MD5: +Y/z1F8l8EXxpI9LL3yPSA== I took a look at o.a.j.runtime.JspWriterImpl and the methods write(String s, int off, int len) and write(char cbuf[], int off, int len) in particualr, and failed to see any performance gain of the 2nd over the first. They are very similar, the only different is that the first uses String.getChars while the second uses System.arraycopy, but those two methods should be on par in terms of performance. That is, I don't see any extra unnecessary copies. Perhasp the culprit is those extra writes? -Kin-man Date: Mon, 08 Sep 2003 23:03:19 +0200 From: Remy Maucherat [EMAIL PROTECTED] Subject: Re: AW: [5.0] JSP performance ... To: Tomcat Developers List [EMAIL PROTECTED] Kin-Man Chung wrote: This seems easy enough to implement, so I'll look into it. Concatenating texts is also on my list, and it should help a little in this case. That would be awesome. The test had a *lot* of writes, so this would save hundreds of write invocations (as well as making them faster as it would user char arrays). JSP performance should be really good with that change. 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0.8] Tag soon
Remy, I discovered there is a jasper bug that causes wrong Java line numbers to be mapped when codes for invoking tag handlers are generated in separate methods. This would completely screw up JSP debugging, and causes javac error messages to be lost if it happens in the generated method. I have a fix for this and plan to commit it. The fix is safe in that it does not affect the generated codes, and I promise to do thorough testing before committing. :-) Kin-man Date: Mon, 18 Aug 2003 18:24:53 +0200 From: Remy Maucherat [EMAIL PROTECTED] Subject: [5.0.8] Tag soon To: Tomcat Developers List [EMAIL PROTECTED] As most (all ?) of the issues uncovered in build 5.0.7 have been fixed or addressed in some way, I plan to tag and release 5.0.8 soon (likely wednesday). Please apply any fixes before then (but please no features addition or refactorings), such as the servlet API updates. Thanks :) (hopefully, we'll have a good quality build this time :) ) 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: JSP include
It eventually invokes request.getRequestDispatcher(bar.jsp).include(). Date: Fri, 08 Aug 2003 11:40:45 +0200 From: Marc Baumgartner [EMAIL PROTECTED] Subject: JSP include To: [EMAIL PROTECTED] Content-disposition: inline Hello all, I want to fix a bug in the JSPReader of the Cocoon-Project. It would be helpfull for me if someone could explain me how the tomcat handles the jsp:include and jsp:forward tag. For example, I have foo.jsp and bar.jsp: titlefoo/title jsp:include page=bar.jsp / titlebar/title phello/p How is the location of the file bar constructed by tomcat? Which methods of HttpServletRequest are used? Thanks in advanced. Regards, Marc - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] New committer: Eric Carmichael
He has my +1 as well. Yan and I need all the help on Jasper! Date: Sun, 10 Aug 2003 18:56:49 +0200 From: Remy Maucherat [EMAIL PROTECTED] Subject: [VOTE] New committer: Eric Carmichael To: Tomcat Developers List [EMAIL PROTECTED] I'd like to nominate Eric Carmichael as a committer on the Tomcat project. Eric has been steadily supplying quality patches to the new Jasper which will implement the JSP 2.0 specification, and has helped fix outstanding bug reports. He plans to continue contributing in the future. He has my +1. 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/compilerJspDocumentParser.java
I don't think this patch is correct. The order that the methods
startPrefixMapping and endPrefixMapping are called is properly nested,
so a stack is appropiate. Take for instance the follow xml fragment
1 foo xmlns:my=mytaglib !-- namespace for my taglib --
2bar xmlns:my=nottaglib/ !-- this namesapce is not a taglib --
3my:doThat/ !-- Is this a taglib invokation? --
4 /foo
The order that those methods will be called is:
At line 1: startPrefixMapping(my, mytaglib)
At line 2: startPrefixMapping(my, nottaglib)
At line 2: endPrefixMapping(my) # for nottaglib
At line 4: endPrefixMapping(my) # for mytaglib
According to your patch, pageInfo.popPrefixMapping() will be called
resulting in Line 3 above not being interpreted as a tag handler
invokation.
This probably does not matter, as I simplify the logic here and remove
the stack altogeterh.
-Kin-man
Date: Sat, 09 Aug 2003 14:55:46 +
From: [EMAIL PROTECTED]
Subject: cvs commit:
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler
JspDocumentParser.java
To: [EMAIL PROTECTED]
remm2003/08/09 07:55:46
Modified:jasper2/src/share/org/apache/jasper/compiler
JspDocumentParser.java
Log:
- pop is called in the same order as push, so using a stack is not correct.
A linked list should be used instead.
Revision ChangesPath
1.63 +9 -10
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/JspDocumentPa
rser.java
Index: JspDocumentParser.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Jsp
DocumentParser.java,v
retrieving revision 1.62
retrieving revision 1.63
diff -u -r1.62 -r1.63
--- JspDocumentParser.java 8 Aug 2003 22:22:09 - 1.62
+++ JspDocumentParser.java 9 Aug 2003 14:55:46 - 1.63
@@ -109,7 +109,7 @@
private boolean isTagFile;
private boolean directivesOnly;
private boolean isTop;
-private Stack prefixMapStack;
+private LinkedList prefixMapLinkedList;
/*
* Constructor
@@ -128,7 +128,7 @@
this.isTagFile = isTagFile;
this.directivesOnly = directivesOnly;
this.isTop = true;
-this.prefixMapStack = new Stack();;
+this.prefixMapLinkedList = new LinkedList();;
}
/*
@@ -560,10 +560,9 @@
if (taglibInfo != null) {
pageInfo.addTaglib(uri, taglibInfo);
pageInfo.pushPrefixMapping(prefix, uri);
-prefixMapStack.push(new Boolean(true));
- }
-else {
-prefixMapStack.push(new Boolean(false));
+prefixMapLinkedList.addLast(new Boolean(true));
+} else {
+prefixMapLinkedList.addLast(new Boolean(false));
}
}
@@ -571,7 +570,7 @@
* Receives notification of the end of a Namespace mapping.
*/
public void endPrefixMapping(String prefix) throws SAXException {
-if (((Boolean)prefixMapStack.pop()).booleanValue()) {
+if (((Boolean) prefixMapLinkedList.removeFirst()).booleanValue()) {
pageInfo.popPrefixMapping(prefix);
}
}
-
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: Please confirm soln: [Bug 22226] Tomcat throws JasperExceptioninstead of NumberFormatException when parameter can't convert to bean property
You are right in that this is not a spec conformant issue and is therefore not a bug. Except for some exceptions, most exceptions are caught and rethrown as JasperExceptions. Making exceptions would just, well, complicate things. :-) -Kin-man Date: Fri, 08 Aug 2003 09:00:30 -0400 From: Tim Funk [EMAIL PROTECTED] Subject: Please confirm soln: [Bug 6] Tomcat throws JasperException instead of NumberFormatException when parameter can't convert to bean property To: Tomcat Developers List [EMAIL PROTECTED] The spec says for jsp:setProperty: A conversion failure leads to an error, whether at translation time or requesttime. From a compliance point of view, it looks like tomcat is OK that is throws a JasperException. But from a user (web developer) point of view, I would think this sucks. But am I correct that this is not a bug? (So I can resolve as invalid) http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6 -Tim - 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]
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 didnt 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: [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.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: 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: 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: 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]
[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: 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]
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]
Re: cvs commit:jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper JspC.java
Date: Wed, 22 Jan 2003 13:20:48 -0600 From: Glenn Nielsen [EMAIL PROTECTED] Subject: Re: cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper JspC.java To: Tomcat Developers List [EMAIL PROTECTED] Kin-Man Chung wrote: 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? I did some refactoring of the JasperClassLoader and the package naming over a year ago. The code for all this in Jasper had been very convoluted and added a great deal of overhead. The refactoring improved runtime JSP performance by 33% and compilation by 25%. If you search the tomcat-dev archives you can find the detailed description of what was changed and why. I am -1 for changing the default package name for JSP pages compiled at runtime from org.apache.jsp to something else until all the implication of doing this are thought through. Agreed. But I don't think changing the package name to one that reflects the directory structure of the jsp files is going to have much performance impact. Jean-Francois mentioned that there are SecurityManager issues related to changing the package name. Yea, I saw. And having an unique package name seems to solve that too. 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: [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: 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]
[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: 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
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
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]
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]
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: 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: 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: 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: 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: [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: 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: 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: 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/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: $ 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: [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: [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: 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: 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
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
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: 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]
[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/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: 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: 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: [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: [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: [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: [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: [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: 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]
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: [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
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: [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: [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]
