Date: Wed, 05 Sep 2001 14:22:21 -0700 (PDT)
From: Kin-Man Chung [EMAIL PROTECTED]
Subject: [PATH] Tag attributes of type char and short bug
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-MD5: NTIF51okQsoUB2BTXXgn/Q==
This patch fixes 3366
This patch fixes 3174 and 3351. This fix was supplied by the submitter
[EMAIL PROTECTED] This fix looks good.
Index: XmlOutputter.java
===
RCS file:
This patch fixes Bug 3019.
If a tag name includes a '-', the generated var name is not a legal Java
identifier name, causing javac compilation errors. The bug is fixed by
substituting '-' with $1. Similarily, '.' is replaced by $2,
and ':' by $3.
runsocks cvs diff -u TagGeneratorBase.java
This patches fixes Bug 2917. The name of the .java files generated by Jasper
includes the path name, which can be a problem in Windows if the path name
is long. Since the files are placed under the directories indicated by the
path name, there is really no reason to include the pathname with
This patch fixes #3350. In a JSP document, the tags in a XML fragment are
always generated before the characters. The current fix preserves their
orders.
misto% runsocks cvs diff -u ParserXJspSaxHandler.java
Index: ParserXJspSaxHandler.java
This patch fixes #3079
misto% runsocks cvs diff -u Parser.java
Index: Parser.java
===
RCS file:
/home/cvspublic/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/P
arser.java,v
retrieving revision 1.12
diff -u -r1.12
This patch fixes the reopen #3529. Now jspc works for taglib when -webapp is
not specified.
The logic used in JspC.java to get the uri root and base is still very
convoluted and should be a prime target for rewrite, maybe later.
misto% runsocks cvs diff -u JspC.java
Index: JspC.java
PROTECTED]
Subject: Re: [PATCH] Jspc throws NPE when used without -webapp
To: [EMAIL PROTECTED], Kin-Man Chung [EMAIL PROTECTED]
MIME-version: 1.0
X-Spam-Rating: localhost 1.6.2 0/1000/N
Thanks Kin-Man. Can you validate the proposed patch for #3640 as well,
if it is still needed?
Craig
This patch fixes the NPE raised when a jsp:useBean has a non empty body.
However, it does not fix the problem reported in #3740, since I couldn't
reproduce the same bug, though the test now works!
misto% runsocks cvs diff -u Parser.java
Index: Parser.java
This patch fixes #3739.
runsocks cvs diff -u foo.jsp
Index: foo.jsp
===
RCS file:
/home/cvspublic/jakarta-tomcat-4.0/webapps/examples/jsp/simpletag/foo.jsp,v
retrieving revision 1.2
diff -u -r1.2 foo.jsp
--- foo.jsp 2001/09/05
This patch fixes #3707.
misto% runsocks cvs diff -u TagBeginGenerator.java
Index: TagBeginGenerator.java
===
RCS file:
/home/cvspublic/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/T
agBeginGenerator.java,v
Fixes #3617. Patch supplied by [EMAIL PROTECTED]
(Martijn Koster)
Index: Compiler.java
===
RCS file:
/home/cvspublic/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/C
ompiler.java,v
retrieving revision
of the Apache Software Foundation. For more
* information on the Apache Software Foundation, please see
* http://www.apache.org/.
*
*/
package org.apache.jasper;
/**
* Errors generated by the JSP engine. It differs from JasperException in
* that it does not print stack trace.
*
* @author Kin-man
+1
Welcome, Patrick.
Date: Wed, 17 Oct 2001 22:02:13 -0600 (MDT)
From: Christopher Cain [EMAIL PROTECTED]
Subject: [VOTE] New Committer
X-Originating-IP: 216.17.139.153
To: [EMAIL PROTECTED]
MIME-version: 1.0
Content-transfer-encoding: 8BIT
Delivered-to: mailing list [EMAIL PROTECTED]
The problem is actually deeper than is reported in the bug report.
1. We also need a fix for flush(), since invoking flush after close
should also throw IOE.
2. The fixes should also be applied to BodyContentImpl.java, since it's just
another JspWriter.
However, doing all these
1 The Problem
The current JSP compiler (Jasper) in tomcat 4.0 is essentially an one-pass
compiler, with a two stage process. The Jsp page is first parsed, looking
for JSP syntatic elements, and a list of generators for these elements are
produced. At the second stage, these generators are
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4954
Looks like a build environment issue. Want to take a look at this?
Thanks.
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Believe or not, Jasper once mangled the file names in a way similar to what
is in the patch. It was modified in response to a bug (Bugzilla is currently
unavailable, so I can't look up the bug number). The filer complained that
for a file with deeply nested path, the resultant file name is too
-Original Message-
From: Kin-Man Chung [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, December 18, 2001 4:37 PM
To: [EMAIL PROTECTED]
Subject: Re: [PATCH] Bug 5471 - JspC broken when compiling webapps
Believe or not, Jasper once mangled the file names in a way
similar to what
ballot
[X] +1: Make the release
[ ] -1: I'm opposed to the release until the following issues are fixed:
Since 4.0.1, there have been lots of bug fixes. It's time.
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
I am in the process of rewriting much of Jasper, and am using an error
handling mechanism very similar in idea to the one you just proposed.
The new jasper would alos support JSR45, which is an interface for source
mapping. The error handler (and other compiler plugins) can be configured
with a
+1 on both.
Date: Thu, 21 Mar 2002 16:25:50 -0800
From: Remy Maucherat [EMAIL PROTECTED]
Subject: [VOTE] Tomcat 4.0.4 Beta 2 / Coyote 1.0 Beta 4 release
To: Tomcat Developers List [EMAIL PROTECTED]
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.
As I have announced here before, I have been working on rewriting part of
Jasper. There are several goals for the new Jasper:
1. To reorganize/simplify parsing and code generation to make it
more maintainable and yet runs faster.
2. To be used as a basis for reference
:47:12 +0100
From: Ignacio J. Ortega [EMAIL PROTECTED]
Subject: RE: [PLAN] New Jasper
To: 'Tomcat Developers List' [EMAIL PROTECTED], 'Kin-Man Chung'
[EMAIL PROTECTED]
MIME-version: 1.0
X-Priority: 3
Delivered-to: mailing list [EMAIL PROTECTED]
Mailing-List: contact [EMAIL PROTECTED]; run
Mar 06 2002
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N
List-Post: mailto:[EMAIL PROTECTED]
List-Subscribe: mailto:[EMAIL PROTECTED]
List-Unsubscribe: mailto:[EMAIL PROTECTED]
List-Help: mailto:[EMAIL PROTECTED]
List-Id: Tomcat Developers List tomcat-dev.jakarta.apache.org
Kin-Man
On Mon, 25 Mar 2002, Kin-Man Chung wrote:
I have noticed that the current Jasper does a lot of string manipulations
very slowly, e.g. there are unnecessary copying or concatenations, and
the uses of String where StringBuffer should be used. Hopefully I can
avoid all
of custom tags). It is much easier
for a custom parser to just handle them as special cases.
Date: Tue, 26 Mar 2002 08:17:12 -0600
From: Bob Lee [EMAIL PROTECTED]
Subject: Re: [PLAN] New Jasper
To: Tomcat Developers List [EMAIL PROTECTED], 'Kin-Man Chung'
[EMAIL PROTECTED]
MIME-version: 1.0
X
Pulling codes out of iteration tag bodies is very high on my list of
optimizations that I wnat to do. I don't think we can do much about
general scriplets that contain loops, though.
But before we start on jasper optimization work, we'll need benchmarks
and performance analysers. I have learnt
if jasper2 should move in there.
Thanks for the suggestion.
Date: Tue, 26 Mar 2002 15:04:16 +0100
From: Ignacio J. Ortega [EMAIL PROTECTED]
Subject: RE: [PLAN] New Jasper
To: 'Tomcat Developers List' [EMAIL PROTECTED], 'Kin-Man Chung'
[EMAIL PROTECTED]
MIME-version: 1.0
X-Priority: 3
OK, that'd be easier. :) I'll give it a try.
Thanks for the suggestion.
Date: Wed, 27 Mar 2002 14:59:00 -0800 (PST)
From: [EMAIL PROTECTED]
Subject: RE: [PLAN] New Jasper
X-X-Sender: [EMAIL PROTECTED]
To: Tomcat Developers List [EMAIL PROTECTED], Kin-Man Chung
[EMAIL PROTECTED]
MIME
], Kin-Man Chung
[EMAIL PROTECTED]
MIME-version: 1.0
X-Authentication-warning: dyn-181.sfo.covalent.net: costinm owned process
doing -bs
On Wed, 27 Mar 2002, Kin-Man Chung wrote:
Pulling codes out of iteration tag bodies is very high on my list of
optimizations that I wnat to do. I don't
should do?
- kin-man
Date: Wed, 03 Apr 2002 07:29:32 -0500
From: peter lin [EMAIL PROTECTED]
Subject: Jasper2
To: Kin-Man Chung [EMAIL PROTECTED]
MIME-version: 1.0
Content-transfer-encoding: 7bit
X-Accept-Language: en-US
hi kin-man,
I was planning on checking your latest jasper2
Kin-Man,
I have a side question.
I am looking for the documentation /comments on the Jasper compiler(jspc)-I
have
looked through the JspC.java but there are no comment about different
compiler options.
I wondering if you can point me in a right direction.
Thank you.
Leo
Hmm.. you
Good for you, Remy!
Actually, I've already done the optimization for the runtime and it is very
significant for simple pages (see my commits last week); when the page does
run, it does it very fast now. There's no hotspot left in the runtime
(according to OptimizeIt; of course, it won't help
[EMAIL PROTECTED] wrote:
I had problems with the new compiler / runtime environment though (for ex,
the include example doesn't work, and the admin webapp can't compile), so
it's not ready yet.
The include example is wrong in that it includes a page directive
%@ page buffer=5
Remy,
I afraid that this patch won't work, because you are initializing
CustomTag.JspAttrs in the constructor, which is too early.
CustomTag.JspAttrs is currently set in Validator, after tld is consulted
to see if the tag attribute can take a request time expression;
and if so, extracts the
Date: Thu, 04 Apr 2002 11:20:21 -0800
From: Remy Maucherat [EMAIL PROTECTED]
Subject: Re: cvs commit:
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler Node.java
To: Tomcat Developers List [EMAIL PROTECTED]
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE
. 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 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
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
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:
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
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
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
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
-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
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
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:
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).
+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
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
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
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.
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:
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
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
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:
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.
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:
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
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
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
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: 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
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
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
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
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
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]
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
-
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
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
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
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
- 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
+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
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)
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:
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
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:
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
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 _
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
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
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]
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
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
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
+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
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 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:
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:
: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
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
() 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
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
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
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
]
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
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
1 - 100 of 137 matches
Mail list logo
