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 > > > > 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]> > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
