RE: [Jasper2] framework for tag optimization
On Sat, 23 Nov 2002, Peter Lin wrote: Date: Sat, 23 Nov 2002 20:25:52 -0800 (PST) From: Peter Lin [EMAIL PROTECTED] Reply-To: Tomcat Developers List [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] 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:choosec:when ... /c:whenc:when ... /c:whenc:otherwise ... /c:otherwise/c:choose Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
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 [EMAIL PROTECTED] 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:choosec:when ... /c:whenc:when ... /c:whenc: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
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 [EMAIL PROTECTED] 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:[EMAIL PROTECTED]]
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
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:[EMAIL PROTECTED]]
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 [EMAIL PROTECTED] 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:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
--
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: mailto:[EMAIL
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.
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:[EMAIL PROTECTED]]
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 [EMAIL PROTECTED] 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- [EMAIL PROTECTED]
For
additional commands,
e-mail:
mailto:[EMAIL PROTECTED]
--
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:
mailto:tomcat-dev- [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] framework for tag optimization
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[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: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [Jasper2] framework for tag optimization
On Sat, 23 Nov 2002, Peter Romianowski wrote:
Date: Sat, 23 Nov 2002 15:22:15 +0100
From: Peter Romianowski [EMAIL PROTECTED]
Reply-To: Tomcat Developers List [EMAIL PROTECTED]
To: 'Tomcat Developers List' [EMAIL PROTECTED]
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:[EMAIL PROTECTED]]
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 [EMAIL PROTECTED] 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
RE: [Jasper2] framework for tag optimization
On Sat, 23 Nov 2002, Peter Romianowski wrote: Date: Sat, 23 Nov 2002 18:05:29 +0100 From: Peter Romianowski [EMAIL PROTECTED] Reply-To: Tomcat Developers List [EMAIL PROTECTED] To: 'Tomcat Developers List' [EMAIL PROTECTED] 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: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
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. For one, JSTL pages generate a lot of out.print(\r\n) when lt;c:choosegt; 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 [EMAIL PROTECTED] 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
On Sat, 23 Nov 2002, Peter Lin wrote: Date: Sat, 23 Nov 2002 12:36:50 -0800 (PST) From: Peter Lin [EMAIL PROTECTED] Reply-To: Tomcat Developers List [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] 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 ([EMAIL PROTECTED]). 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 lt;c:choosegt; 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: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
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 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
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 [EMAIL PROTECTED] 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
