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]>
