You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Kin-Man Chung <Ki...@Eng.Sun.COM> on 2002/11/23 01:57:41 UTC
[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-class>the name of the tag class</tag-class>
<plugin-class>the 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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Jasper2] framework for tag optimization
Posted by Hans Bergsten <ha...@gefionsoftware.com>.
Peter Romianowski wrote:
>>If you think using it for JSTL is okay, why wouldn't it be
>>okay for other tag libraries? The same issues (if they are
>>issues) apply to JSTL, don't they?
>
>
> I thought of it beeing done by the jasper-crew, i.e. being
> part of "stock tomcat", so it could be assured that it is
> working correct.
Well, I hope that it the plugin API would be easy enough to use
to ensure that others than the "jasper crew" can get it right for
other tig libraries ;-)
> The way I understand the proposal is that it *could* be some kind of
> a replacement for a tag-library. So for conformity and interoperability
> a programmer would have to implement the plugin *AND* the taghandler.
> (And I extremely doubt that many will).
I may be wrong, but I don't think the proposal is a replacement. For
instance, the config file makes a reference to the tag handler class
(the <tag-class> element).
> I was involved in a discussion about a "precompile all JSPs in a
> webapp"-functionality (which was wanted by *many* users). I was
> willing to contribute to it, but the developers (Craig himself,
> I think :) said that such a thing would not belong to a reference i
> mplementation of a servlet-container. After he told me so, I agreed
> with him, although I still would like to have this feature. :) So
> that was the reason why I posted my comments.
This was before I rejoined this list, so I can't comment on that
specific proposal (yes, I _could_ look for it in the archives, but
I wont ;-) In general, though, I don't see anything wrong with adding
non-standard features to Tomcat, as long as they are clearly optional
and the behavior defined by the spec still works. In fact, there was
a discussion about this in the Jakarta PMC when Jakarta was formed.
The consensus at the time was that Tomcat has to be spec compliant
(it _is_ the RI, after all), but that there are no restrictions on
additional features.
> As an application developer I would say: "YES! Give me that plugin-
> feature!" since it would improve performance drastically. So, I like
> the idea but I am not sure if such a thing would belong to "stock
> tomcat".
As long as a feature doesn't break spec conformance, it should be fine.
For this specific proposal (assuming my understanding of it is correct),
I don't see any problems.
Hans
--
Hans Bergsten <ha...@gefionsoftware.com>
Gefion Software <http://www.gefionsoftware.com/>
Author of O'Reilly's "JavaServer Pages", covering JSP 1.2 and JSTL 1.0
Details at <http://TheJSPBook.com/>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [4.1.16] New tag ?
Posted by Henri Gomez <hg...@apache.org>.
Mladen Turk wrote:
>
>>-----Original Message-----
>>From: Remy Maucherat
>>
>>It would be good to have updated native connectors at the
>>same time or
>>before.
>>
>
>
> Before, IMO.
>
>
>>I'm posting this to confirm that all the fixes which were
>>needed in JK
>>are in.
>>
>
>
> Think that Henri is preparing a tag this week for JK1.21, and JK2 2.0.2
> is planned to be tagged on Monday, so we could have those and TC in
> sync... amazing ;).
JK 1.2.1 will be tagged tomorrow
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [4.1.16] New tag ?
Posted by Mladen Turk <mt...@mappingsoft.com>.
> -----Original Message-----
> From: Remy Maucherat
>
> It would be good to have updated native connectors at the
> same time or
> before.
>
Before, IMO.
> I'm posting this to confirm that all the fixes which were
> needed in JK
> are in.
>
Think that Henri is preparing a tag this week for JK1.21, and JK2 2.0.2
is planned to be tagged on Monday, so we could have those and TC in
sync... amazing ;).
MT.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
[4.1.16] New tag ?
Posted by Remy Maucherat <re...@apache.org>.
Hi,
Some important fixes went into JK since 4.1.15, some of which were in
the Java side. I plan to abandon the current 4.1.15 alpha and make a new
4.1.16 alpha release of Tomcat, to pick up those changes. This release
looks good on paper, and could be considered for promotion to Beta or
Stable (GA for the purists ;-) ). At the same time, I'll also release a
new 5.0.1 alpha.
It would be good to have updated native connectors at the same time or
before.
I'm posting this to confirm that all the fixes which were needed in JK
are in.
Thanks,
Remy
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [Jasper2] framework for tag optimization
Posted by Peter Lin <tc...@yahoo.com>.
yeah, I had the same discussion with kin-man a while back. the plugin framework kinman is proposing would basically accomplish the same thing for the tags. So I look forward to getting more time to assist in that effort.
peter
"Craig R. McClanahan" <cr...@apache.org> wrote:
On Sun, 24 Nov 2002, Peter Lin wrote:
> Date: Sun, 24 Nov 2002 18:08:00 -0800 (PST)
> From: Peter Lin
> Reply-To: Tomcat Developers List
> To: Tomcat Developers List
> Subject: RE: [Jasper2] framework for tag optimization
>
>
>
> Yeah, I actually use that in some places, but it is a bit harder to read with pages that have a lot of tags. Actually, the whole page is tags with very little HTML and everything that is text is in resource bundles.
>
> Using that syntax doesn't really bother in when used sparsely, but with hunderds of JSP, it gets a bit gruesome as time goes on and pages change.
>
> "Craig R. McClanahan" wrote:
> > One textual approach to minimizing the extra newlines (I would
> > not recommend this -- they don't bother me, but they might bother
> > you):
>
> >
> > ...
> >
> > ...
> >
> > ...
> >
> > Craig
>
> I almost prefer patching JSPC or writing a pre-processor for JSPC than
> use tricks to get around extra "\r\n".
>
You're free to make such a patch in your own version. We can't do that to
the standard version because it would violate the JSP spec to eliminate
any template text (including the newlines).
> peter
Craig
--
To unsubscribe, e-mail:
For additional commands, e-mail:
---------------------------------
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now
RE: [Jasper2] framework for tag optimization
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Sun, 24 Nov 2002, Peter Lin wrote:
> Date: Sun, 24 Nov 2002 18:08:00 -0800 (PST)
> From: Peter Lin <tc...@yahoo.com>
> Reply-To: Tomcat Developers List <to...@jakarta.apache.org>
> To: Tomcat Developers List <to...@jakarta.apache.org>
> Subject: RE: [Jasper2] framework for tag optimization
>
>
>
> Yeah, I actually use that in some places, but it is a bit harder to read with pages that have a lot of tags. Actually, the whole page is tags with very little HTML and everything that is text is in resource bundles.
>
> Using that syntax doesn't really bother in when used sparsely, but with hunderds of JSP, it gets a bit gruesome as time goes on and pages change.
>
> "Craig R. McClanahan" <cr...@apache.org> wrote:
> > One textual approach to minimizing the extra newlines (I would
> > not recommend this -- they don't bother me, but they might bother
> > you):
>
> > <c:choose><c:when>
> > ...
> > </c:when><c:when>
> > ...
> > </c:when><c:otherwise>
> > ...
> > </c:otherwise></c:choose>
> > Craig
>
> I almost prefer patching JSPC or writing a pre-processor for JSPC than
> use tricks to get around extra "\r\n".
>
You're free to make such a patch in your own version. We can't do that to
the standard version because it would violate the JSP spec to eliminate
any template text (including the newlines).
> peter
Craig
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [Jasper2] framework for tag optimization
Posted by Peter Lin <tc...@yahoo.com>.
Yeah, I actually use that in some places, but it is a bit harder to read with pages that have a lot of tags. Actually, the whole page is tags with very little HTML and everything that is text is in resource bundles.
Using that syntax doesn't really bother in when used sparsely, but with hunderds of JSP, it gets a bit gruesome as time goes on and pages change.
"Craig R. McClanahan" <cr...@apache.org> wrote:
> One textual approach to minimizing the extra newlines (I would
> not recommend this -- they don't bother me, but they might bother
> you):
> <c:choose><c:when>
> ...
> </c:when><c:when>
> ...
> </c:when><c:otherwise>
> ...
> </c:otherwise></c:choose>
> Craig
I almost prefer patching JSPC or writing a pre-processor for JSPC than use tricks to get around extra "\r\n".
peter
---------------------------------
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now
RE: [Jasper2] framework for tag optimization
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Sat, 23 Nov 2002, Peter Lin wrote:
> Date: Sat, 23 Nov 2002 20:25:52 -0800 (PST)
> From: Peter Lin <tc...@yahoo.com>
> Reply-To: Tomcat Developers List <to...@jakarta.apache.org>
> To: Tomcat Developers List <to...@jakarta.apache.org>
> Subject: RE: [Jasper2] framework for tag optimization
>
>
>
> I sent the suggestion a while back to the expert group.
> > AFAIK, the and other tags don't actually generate *any* output
> > of their own -- the extra line breaks you are seeing are undoubtedly those
> > you've put in the source JSP page itself.
>
>
> Yes, I was referring to the spaces that are generated by jasper because my original JSP source has:
>
> <c:choose>
The carriage return right here (after <c:choose>) is part of your template
text, and will therefore be rendered to the output. It is *not* rendered
by the <c:choose> tag itself. You can verify this by reviewing the source
code for the JSTL reference implementation (i.e. the "standard" project in
jakarta-taglibs), and you'll see that the tags themselves do not render
anything -- they only decide whether or not to render their bodies.
> <c:when></c:when>
Same here.
> <c:otherwise></c:otherwise>
And here.
> </c:choose>
>
And here.
One textual approach to minimizing the extra newlines (I would not
recommend this -- they don't bother me, but they might bother you):
<c:choose><c:when>
...
</c:when><c:when>
...
</c:when><c:otherwise>
...
</c:otherwise></c:choose>
Craig
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [Jasper2] framework for tag optimization
Posted by Peter Lin <tc...@yahoo.com>.
I sent the suggestion a while back to the expert group.
> AFAIK, the and other tags don't actually generate *any* output
> of their own -- the extra line breaks you are seeing are undoubtedly those
> you've put in the source JSP page itself.
Yes, I was referring to the spaces that are generated by jasper because my original JSP source has:
<c:choose>
<c:when></c:when>
<c:otherwise></c:otherwise>
</c:choose>
> Can't you do this with a standard javax.servlet.Filter, without needing to
> integrate it into a compiler? A custom BodyTag of your own could
> certainly do the job as well.
I've considered it, but again it seems like a band-aid solution. It's a bit wasteful to have the servlet container generate out.print("\r\n") and then to have a filter strip it out. It might not matter for small sites. but if your website gets 1million+ hits a day, it adds up. It matters even more if other parts of your application are heavy weight and the server has to support a high number of concurrent requests. In my hand tweaked tests, it resulted in 10-20% performance improvement. Obviously this could easily be solved by putting <c:choose> statements all in one line, but that makes it a pain to read and debug. The test I ran had 400+ extra "\r\n" in the tag version vs hand tweaked. when the project requirements state you have to generate a complete page of results within 250ms and it takes 200ms to get XML from an app server, every bit helps :)
Most projects/sites do not have these kids of performance requirements, but it would make life easier. I also considered writing a class to parse my JSP before calling JSPC, so that's another approach that wouldn't break spec compliance.
peter
---------------------------------
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now
RE: [Jasper2] framework for tag optimization
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Sat, 23 Nov 2002, Peter Lin wrote:
> Date: Sat, 23 Nov 2002 12:36:50 -0800 (PST)
> From: Peter Lin <tc...@yahoo.com>
> Reply-To: Tomcat Developers List <to...@jakarta.apache.org>
> To: Tomcat Developers List <to...@jakarta.apache.org>
> Subject: RE: [Jasper2] framework for tag optimization
>
>
> So it would seam having a plugin framework wouldn't necessarily break
> conformance. On the otherhand, I would still like to see the expert
> group to seriously consider making plugin framework a standard feature
> of JSP compiler. Beyond performance, there are other good reasons to do
> so.
>
The best place for this feedback would be to the JSP 2.0 expert group
(jsp-spec-feedback@eng.sun.com).
Personally, I'd be surprised if such a suggestion were implemented, since
there is very little in the JSP spec (or most Java specs) about
implementation. In particular, there is no requirement that there even be
such a thing as a JSP page compiler -- an interpreted implementation would
be legal as well.
> For one, JSTL pages generate a lot of out.print("\r\n") when
> <c:choose> statemetns are used.
AFAIK, the <c:choose> and other tags don't actually generate *any* output
of their own -- the extra line breaks you are seeing are undoubtedly those
you've put in the source JSP page itself.
> Rather than have a tag handle the
> body and trim, I would prefer to see a plugin framework that gives
> application developers the ability to strip out extra control linefeeds
> or spaces. For example, some one may want to format their jsp code so it
> is easier to read, but often it breaks HTML formatting. There should be
> an easy way for page developers to write basic filters for jasper that
> allows a plugin to strip tabs and control linefeeds. Not only would this
> reduce the size of the generated page, but it should provide significant
> improvement for pages with lots and lots of tags.
>
Can't you do this with a standard javax.servlet.Filter, without needing to
integrate it into a compiler? A custom BodyTag of your own could
certainly do the job as well.
> peter lin
Craig
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [Jasper2] framework for tag optimization
Posted by Peter Lin <tc...@yahoo.com>.
So it would seam having a plugin framework wouldn't necessarily break conformance. On the otherhand, I would still like to see the expert group to seriously consider making plugin framework a standard feature of JSP compiler. Beyond performance, there are other good reasons to do so.
For one, JSTL pages generate a lot of out.print("\r\n") when <c:choose> statemetns are used. Rather than have a tag handle the body and trim, I would prefer to see a plugin framework that gives application developers the ability to strip out extra control linefeeds or spaces. For example, some one may want to format their jsp code so it is easier to read, but often it breaks HTML formatting. There should be an easy way for page developers to write basic filters for jasper that allows a plugin to strip tabs and control linefeeds. Not only would this reduce the size of the generated page, but it should provide significant improvement for pages with lots and lots of tags.
peter lin
"Craig R. McClanahan" <cr...@apache.org> wrote:Building the pluggability framework pretty much has to be done by the
Jasper developers. Implementing plugins for a particular type of
optimization (such as a JSTL recognizer/optimizer) could be done by Jasper
developers or by anyone else.
The way to ensure correctness of a Jasper+Plugin (of any type) is to
ensure that it still passes the TCKs for the APIs it claims to implement
(JSP x.y of course, and JSTL if we're talking about that particular kind
of a plugin).
There's really two proposals -- a pluggability interface into Jasper's
page compiler, and a specific use of this interface for optimizing the
code generated for JSTL tags. The pluggability would be available to
anyone using Jasper (and, in the past at least, that includes more than a
few J2EE platform vendors). None of this is likely to be done by typical
application developers -- it's much more likely to be container developers
that use it.
On the other hand, I wonder if people running Struts-based apps on Tomcat
would enjoy it if we did a pluggable optimizer for the Struts tags ...
---------------------------------
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now
RE: [Jasper2] framework for tag optimization
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Sat, 23 Nov 2002, Peter Romianowski wrote:
> Date: Sat, 23 Nov 2002 18:05:29 +0100
> From: Peter Romianowski <me...@gmx.de>
> Reply-To: Tomcat Developers List <to...@jakarta.apache.org>
> To: 'Tomcat Developers List' <to...@jakarta.apache.org>
> Subject: RE: [Jasper2] framework for tag optimization
>
> > If you think using it for JSTL is okay, why wouldn't it be
> > okay for other tag libraries? The same issues (if they are
> > issues) apply to JSTL, don't they?
>
> I thought of it beeing done by the jasper-crew, i.e. being
> part of "stock tomcat", so it could be assured that it is
> working correct.
>
Building the pluggability framework pretty much has to be done by the
Jasper developers. Implementing plugins for a particular type of
optimization (such as a JSTL recognizer/optimizer) could be done by Jasper
developers or by anyone else.
The way to ensure correctness of a Jasper+Plugin (of any type) is to
ensure that it still passes the TCKs for the APIs it claims to implement
(JSP x.y of course, and JSTL if we're talking about that particular kind
of a plugin).
> The way I understand the proposal is that it *could* be some kind of
> a replacement for a tag-library. So for conformity and interoperability
> a programmer would have to implement the plugin *AND* the taghandler.
> (And I extremely doubt that many will).
>
There's really two proposals -- a pluggability interface into Jasper's
page compiler, and a specific use of this interface for optimizing the
code generated for JSTL tags. The pluggability would be available to
anyone using Jasper (and, in the past at least, that includes more than a
few J2EE platform vendors). None of this is likely to be done by typical
application developers -- it's much more likely to be container developers
that use it.
On the other hand, I wonder if people running Struts-based apps on Tomcat
would enjoy it if we did a pluggable optimizer for the Struts tags ...
> I was involved in a discussion about a "precompile all JSPs in a
> webapp"-functionality (which was wanted by *many* users). I was
> willing to contribute to it, but the developers (Craig himself,
> I think :) said that such a thing would not belong to a reference i
> mplementation of a servlet-container. After he told me so, I agreed
> with him, although I still would like to have this feature. :) So
> that was the reason why I posted my comments.
>
Tomcat has grown way past the days when it's sole purpose was to be the
basis of the reference implementation (although it's still playing that
role). It has lots of very useful features, and the performance
improvements due to things like Coyote have been quite impressive.
At ApacheCon this last week, Glenn Nielsen (a Tomcat committer) gave a
session on performance tuning Tomcat, and he polled the room on how many
people actually had Tomcat deployed in production environments. Over
three quarters of the people in the room raised their hand.
>From recent discussions about jspc, it's obvious that lots of people would
like to see this capability not only retained, but improved. The best way
to make that happen, IMHO, would be for someone to take the lead in
accumulating design requirements that we can agree to. I don't have time
to do that, but it would seem a natural next step.
> As an application developer I would say: "YES! Give me that plugin-
> feature!" since it would improve performance drastically. So, I like
> the idea but I am not sure if such a thing would belong to "stock
> tomcat".
>
>
> anyway,
> Peter
>
Craig
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [Jasper2] framework for tag optimization
Posted by Peter Romianowski <me...@gmx.de>.
> If you think using it for JSTL is okay, why wouldn't it be
> okay for other tag libraries? The same issues (if they are
> issues) apply to JSTL, don't they?
I thought of it beeing done by the jasper-crew, i.e. being
part of "stock tomcat", so it could be assured that it is
working correct.
The way I understand the proposal is that it *could* be some kind of
a replacement for a tag-library. So for conformity and interoperability
a programmer would have to implement the plugin *AND* the taghandler.
(And I extremely doubt that many will).
I was involved in a discussion about a "precompile all JSPs in a
webapp"-functionality (which was wanted by *many* users). I was
willing to contribute to it, but the developers (Craig himself,
I think :) said that such a thing would not belong to a reference i
mplementation of a servlet-container. After he told me so, I agreed
with him, although I still would like to have this feature. :) So
that was the reason why I posted my comments.
As an application developer I would say: "YES! Give me that plugin-
feature!" since it would improve performance drastically. So, I like
the idea but I am not sure if such a thing would belong to "stock
tomcat".
anyway,
Peter
> Hans
>
> >>-----Original Message-----
> >>From: Peter Lin [mailto:tcw00lfel@yahoo.com]
> >>Sent: Saturday, November 23, 2002 4:59 AM
> >>To: Tomcat Developers List; Kin-Man Chung
> >>Subject: Re: [Jasper2] framework for tag optimization
> >>
> >>
> >>
> >>hey kin-man,
> >>
> >>that sounds great! I was actually thinking along those lines
> >>a while back, but thought it was impracticle because the
> >>project I was working one didn't have enough time to explore
> >>that approach.
> >>
> >>when I was doing performance analysis of jasper1 with jslt
> >>and saw how bad the performance was (due to the nested
> >>try/catch bug), I went through and manually wrote scriplet
> >>code to do the same exact logic. The performance compared to
> >>jasper1 + jstl was tremendous. I had full mockups of a 3
> >>pages written in JSTL and pure scriplet.
> >>
> >>If memory serves me correctly, the difference was 5-8x. the
> >>JSTL version using jasper1 would take 900-1000ms+ to display
> >>15 results. The same exact page using scriplet took about
> >>100-150ms. I would definitely be interested in spending time
> >>on this and assisting. I may have some time opening up next
> >>year, so I hope to start contributing actively :) cross my fingers.
> >>
> >>peter lin
> >>
> >> Kin-Man Chung <Ki...@Eng.Sun.COM> wrote: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
> >>
> >>
> >>${i}
> >>
> >>
> >>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:
> >>
> >>
> >>
> >>the name of the tag class
> >>
> >>the name of the pkugin class
> >>
> >>
> >>
> >>
> >>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:
> >>For additional commands, e-mail:
> >>
> >>
> >>
> >>---------------------------------
> >>Do you Yahoo!?
> >>Yahoo! Mail Plus - Powerful. Affordable. Sign up now
> >>
> >
> >
> >
> > --
> > To unsubscribe, e-mail:
> <mailto:tomcat-dev-> unsubscribe@jakarta.apache.org>
> > For
> additional commands,
> e-mail:
> > <ma...@jakarta.apache.org>
> >
>
> --
> Hans Bergsten <ha...@gefionsoftware.com>
> Gefion Software <http://www.gefionsoftware.com/>
> Author of O'Reilly's "JavaServer Pages", covering JSP 1.2 and JSTL 1.0
> Details at <http://TheJSPBook.com/>
>
>
> --
> To unsubscribe, e-mail:
> <mailto:tomcat-dev-> unsubscribe@jakarta.apache.org>
> For
> additional commands,
> e-mail: <ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Jasper2] framework for tag optimization
Posted by Hans Bergsten <ha...@gefionsoftware.com>.
Peter Romianowski wrote:
> Just a thought: Doesn't this breack the standard conformance
> tomcat is all about?
If I understand the proposal correctly, I don't see that it breaks
standard conformance (I'm in the JSP JRE group, BTW). As long as
it doesn't require extra, non-standard directives or elements in the
JSP files, it's just a proprietary way to get better performance
when using Tomcat. The same JSP files would work fine in any other
JSP container, except that they may run a bit slower.
Another way to look at it. The JSP spec allows a container to do
tricks like this for "well-known tag libraries", such as JSTL. The
proposed feature can be seen as a just way to add other "well-known
libraries", where the knowledge is encoded by the tag library
developer instead of the container developer.
> One could easily be bound to tomcat after
> writing some plugins that break the initial semantics of a tag.
Sure, but then you have done things with the plugin feature that it's
not supposed to be used for. It's no different than relying on
non-standard APIs a container may provide.
> I think there is no way to assure the correctness of a plugin-
> implementation, so it would become impossible to switch to
> another servlet-container. And I saw many improvement-discussion
> on this list, which had been canceled with exact this reason.
Hmm... Testing the app with and without the plugin seems like a
reasonable approach to ensure it's correct. The plugin feature should
only be used to improve performance, not to add behavior.
> But having plugins for standard tags (JSTL) out of the box
> would be great in respect of performance.
If you think using it for JSTL is okay, why wouldn't it be okay for
other tag libraries? The same issues (if they are issues) apply to JSTL,
don't they?
Hans
>>-----Original Message-----
>>From: Peter Lin [mailto:tcw00lfel@yahoo.com]
>>Sent: Saturday, November 23, 2002 4:59 AM
>>To: Tomcat Developers List; Kin-Man Chung
>>Subject: Re: [Jasper2] framework for tag optimization
>>
>>
>>
>>hey kin-man,
>>
>>that sounds great! I was actually thinking along those lines
>>a while back, but thought it was impracticle because the
>>project I was working one didn't have enough time to explore
>>that approach.
>>
>>when I was doing performance analysis of jasper1 with jslt
>>and saw how bad the performance was (due to the nested
>>try/catch bug), I went through and manually wrote scriplet
>>code to do the same exact logic. The performance compared to
>>jasper1 + jstl was tremendous. I had full mockups of a 3
>>pages written in JSTL and pure scriplet.
>>
>>If memory serves me correctly, the difference was 5-8x. the
>>JSTL version using jasper1 would take 900-1000ms+ to display
>>15 results. The same exact page using scriplet took about
>>100-150ms. I would definitely be interested in spending time
>>on this and assisting. I may have some time opening up next
>>year, so I hope to start contributing actively :) cross my fingers.
>>
>>peter lin
>>
>> Kin-Man Chung <Ki...@Eng.Sun.COM> wrote: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
>>
>>
>>${i}
>>
>>
>>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:
>>
>>
>>
>>the name of the tag class
>>
>>the name of the pkugin class
>>
>>
>>
>>
>>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:
>>For additional commands, e-mail:
>>
>>
>>
>>---------------------------------
>>Do you Yahoo!?
>>Yahoo! Mail Plus - Powerful. Affordable. Sign up now
>>
>
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
--
Hans Bergsten <ha...@gefionsoftware.com>
Gefion Software <http://www.gefionsoftware.com/>
Author of O'Reilly's "JavaServer Pages", covering JSP 1.2 and JSTL 1.0
Details at <http://TheJSPBook.com/>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [Jasper2] framework for tag optimization
Posted by Peter Lin <tc...@yahoo.com>.
yeah, it definitely would risk breaking conformance, unless it became an official spec. there is a need for a tag-like markup for designers (non-programmers), but performs better for sites that get million hits a day or more. Most sites wouldn't need it, but for heavy hitters it would save in resources.
peter lin
Peter Romianowski <me...@gmx.de> wrote:Just a thought: Doesn't this breack the standard conformance
tomcat is all about? One could easily be bound to tomcat after
writing some plugins that break the initial semantics of a tag.
I think there is no way to assure the correctness of a plugin-
implementation, so it would become impossible to switch to
another servlet-container. And I saw many improvement-discussion
on this list, which had been canceled with exact this reason.
But having plugins for standard tags (JSTL) out of the box
would be great in respect of performance.
Just my $0.02
Peter
> -----Original Message-----
> From: Peter Lin [mailto:tcw00lfel@yahoo.com]
> Sent: Saturday, November 23, 2002 4:59 AM
> To: Tomcat Developers List; Kin-Man Chung
> Subject: Re: [Jasper2] framework for tag optimization
>
>
>
> hey kin-man,
>
> that sounds great! I was actually thinking along those lines
> a while back, but thought it was impracticle because the
> project I was working one didn't have enough time to explore
> that approach.
>
> when I was doing performance analysis of jasper1 with jslt
> and saw how bad the performance was (due to the nested
> try/catch bug), I went through and manually wrote scriplet
> code to do the same exact logic. The performance compared to
> jasper1 + jstl was tremendous. I had full mockups of a 3
> pages written in JSTL and pure scriplet.
>
> If memory serves me correctly, the difference was 5-8x. the
> JSTL version using jasper1 would take 900-1000ms+ to display
> 15 results. The same exact page using scriplet took about
> 100-150ms. I would definitely be interested in spending time
> on this and assisting. I may have some time opening up next
> year, so I hope to start contributing actively :) cross my fingers.
>
> peter lin
>
> Kin-Man Chung wrote: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
>
>
> ${i}
>
>
> 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:
>
>
>
> the name of the tag class
>
> the name of the pkugin class
>
>
>
>
> 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:
> For additional commands, e-mail:
>
>
>
> ---------------------------------
> Do you Yahoo!?
> Yahoo! Mail Plus - Powerful. Affordable. Sign up now
>
--
To unsubscribe, e-mail:
For additional commands, e-mail:
---------------------------------
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now
RE: [Jasper2] framework for tag optimization
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Sat, 23 Nov 2002, Peter Romianowski wrote:
> Date: Sat, 23 Nov 2002 15:22:15 +0100
> From: Peter Romianowski <me...@gmx.de>
> Reply-To: Tomcat Developers List <to...@jakarta.apache.org>
> To: 'Tomcat Developers List' <to...@jakarta.apache.org>
> Subject: RE: [Jasper2] framework for tag optimization
>
> Just a thought: Doesn't this breack the standard conformance
> tomcat is all about? One could easily be bound to tomcat after
> writing some plugins that break the initial semantics of a tag.
> I think there is no way to assure the correctness of a plugin-
> implementation, so it would become impossible to switch to
> another servlet-container. And I saw many improvement-discussion
> on this list, which had been canceled with exact this reason.
>
There's always been some confusion about the "standard conformance tomcat
is all about" concept.
First, Tomcat itself is *not* the reference implementation of the servlet
and JSP specs. Instead, its code is *used* in the reference
implementation for these specs, and all the other J2EE platform ones --
the J2EE reference implementation.
Until last March, there was no mechanism available to certify yourself as
compliant with only the servlet and JSP specs, without complying with all
of them. As a result of the agreement between Sun and Apache, however, it
is now possible to get just the servlet and JSP TCKs, and test your
servlet/JSP container. It would be possible for Tomcat, or any other
container that only implemented these specs, to certify themselves -- but
they are still not the official RI.
The same thing happens with JSTL -- the JSTL TCK defines the behavior of
(what amounts to) a JSP+JSTL container. If the TCK tests pass, that means
(to the extent validated by the tests) that standards conformance is being
maintained, and portability remains assurred. It'll just run faster :-).
If the TCK tests don't pass, that means that the optimizations being
applied are breaking conformance -- that would be a bug that would need to
be fixed.
Take the specific case of <c:forEach>. What the JSTL spec describes
(Section 6.2) is the *effect* of using this tag in your JSP page:
"repeats its nested body content over a collection of objects, or repeats
it a fixed number of times." It also describes how you configure the
behavior, via the attributes, and how you can optionally expose
LoopTagStatus information inside the body. However, nowhere in the
description is there any mention that <c:forEach> has to actually *be* a
custom tag invoked via the standard tag invocation protocol. This is what
gives a JSP page compiler the freedom to recognize "well known" tag
libraries and do special things. As long as the behavior described in the
spec are faithfully executed, it's perfectly legal for the compiler to
implement this as an appropriate "for" statement instead of as a tag.
Your application will never know the difference.
Of course, an application developer can still do things to mess up the
portability of their apps (like relying on the internal implementation
details of the APIs you use) -- but as long as you use only the public
APIs described in the specs, and the container you are running on passes
the relevant TCKs, you've got some pretty solid assurances of portability.
> But having plugins for standard tags (JSTL) out of the box
> would be great in respect of performance.
>
Yep.
> Just my $0.02
>
> Peter
>
Craig
> > -----Original Message-----
> > From: Peter Lin [mailto:tcw00lfel@yahoo.com]
> > Sent: Saturday, November 23, 2002 4:59 AM
> > To: Tomcat Developers List; Kin-Man Chung
> > Subject: Re: [Jasper2] framework for tag optimization
> >
> >
> >
> > hey kin-man,
> >
> > that sounds great! I was actually thinking along those lines
> > a while back, but thought it was impracticle because the
> > project I was working one didn't have enough time to explore
> > that approach.
> >
> > when I was doing performance analysis of jasper1 with jslt
> > and saw how bad the performance was (due to the nested
> > try/catch bug), I went through and manually wrote scriplet
> > code to do the same exact logic. The performance compared to
> > jasper1 + jstl was tremendous. I had full mockups of a 3
> > pages written in JSTL and pure scriplet.
> >
> > If memory serves me correctly, the difference was 5-8x. the
> > JSTL version using jasper1 would take 900-1000ms+ to display
> > 15 results. The same exact page using scriplet took about
> > 100-150ms. I would definitely be interested in spending time
> > on this and assisting. I may have some time opening up next
> > year, so I hope to start contributing actively :) cross my fingers.
> >
> > peter lin
> >
> > Kin-Man Chung <Ki...@Eng.Sun.COM> wrote: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
> >
> >
> > ${i}
> >
> >
> > 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:
> >
> >
> >
> > the name of the tag class
> >
> > the name of the pkugin class
> >
> >
> >
> >
> > 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:
> > For additional commands, e-mail:
> >
> >
> >
> > ---------------------------------
> > Do you Yahoo!?
> > Yahoo! Mail Plus - Powerful. Affordable. Sign up now
> >
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [Jasper2] framework for tag optimization
Posted by Peter Romianowski <me...@gmx.de>.
Just a thought: Doesn't this breack the standard conformance
tomcat is all about? One could easily be bound to tomcat after
writing some plugins that break the initial semantics of a tag.
I think there is no way to assure the correctness of a plugin-
implementation, so it would become impossible to switch to
another servlet-container. And I saw many improvement-discussion
on this list, which had been canceled with exact this reason.
But having plugins for standard tags (JSTL) out of the box
would be great in respect of performance.
Just my $0.02
Peter
> -----Original Message-----
> From: Peter Lin [mailto:tcw00lfel@yahoo.com]
> Sent: Saturday, November 23, 2002 4:59 AM
> To: Tomcat Developers List; Kin-Man Chung
> Subject: Re: [Jasper2] framework for tag optimization
>
>
>
> hey kin-man,
>
> that sounds great! I was actually thinking along those lines
> a while back, but thought it was impracticle because the
> project I was working one didn't have enough time to explore
> that approach.
>
> when I was doing performance analysis of jasper1 with jslt
> and saw how bad the performance was (due to the nested
> try/catch bug), I went through and manually wrote scriplet
> code to do the same exact logic. The performance compared to
> jasper1 + jstl was tremendous. I had full mockups of a 3
> pages written in JSTL and pure scriplet.
>
> If memory serves me correctly, the difference was 5-8x. the
> JSTL version using jasper1 would take 900-1000ms+ to display
> 15 results. The same exact page using scriplet took about
> 100-150ms. I would definitely be interested in spending time
> on this and assisting. I may have some time opening up next
> year, so I hope to start contributing actively :) cross my fingers.
>
> peter lin
>
> Kin-Man Chung <Ki...@Eng.Sun.COM> wrote: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
>
>
> ${i}
>
>
> 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:
>
>
>
> the name of the tag class
>
> the name of the pkugin class
>
>
>
>
> 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:
> For additional commands, e-mail:
>
>
>
> ---------------------------------
> Do you Yahoo!?
> Yahoo! Mail Plus - Powerful. Affordable. Sign up now
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Jasper2] framework for tag optimization
Posted by Peter Lin <tc...@yahoo.com>.
hey kin-man,
that sounds great! I was actually thinking along those lines a while back, but thought it was impracticle because the project I was working one didn't have enough time to explore that approach.
when I was doing performance analysis of jasper1 with jslt and saw how bad the performance was (due to the nested try/catch bug), I went through and manually wrote scriplet code to do the same exact logic. The performance compared to jasper1 + jstl was tremendous. I had full mockups of a 3 pages written in JSTL and pure scriplet.
If memory serves me correctly, the difference was 5-8x. the JSTL version using jasper1 would take 900-1000ms+ to display 15 results. The same exact page using scriplet took about 100-150ms. I would definitely be interested in spending time on this and assisting. I may have some time opening up next year, so I hope to start contributing actively :)
cross my fingers.
peter lin
Kin-Man Chung <Ki...@Eng.Sun.COM> wrote: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
${i}
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:
the name of the tag class
the name of the pkugin class
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:
For additional commands, e-mail:
---------------------------------
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now