jakarta-taglibs-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Strachan <ja...@metastuff.com>
Subject Re: Jasper: SAX preprocessing of XML JSP
Date Thu, 22 Mar 2001 18:49:16 GMT
----- Original Message -----
From: "Craig R. McClanahan" <craigmcc@apache.org>

> > I'm interested in having a configurable (on a per web-app bases for now)
> > XMLFilter object used to preprocess the XML format of JSP before the
> > code gets generated.
> >
> > This mechanism would enable compile time transformation of JSP, for
> > to implement "compile time tags" using XSLT in a similar way to Cocoon's
> > XSP.
> >
> > >From my first looks at the source code it would appear a patch to
> >
> >     org.apache.jasper.compiler.ParseXJspSax
> >
> > would do the trick (in the parse() method).
> >
> I presume that you are only interested in JSP pages that use the XML
> syntax, right?


> If so, this is probably the right place -- you'd want to
> fuss with how Jasper identifies its input source.

Thanks - am hunting through the code now...

> > Does anyone have any warnings or info before I dive in?
> >
> One other consideration is how Jasper checks to see if a page has been
> updated.  Normally it checks the "last modified timestamp" of the xxx.jsp
> file.  You will need to deal with that issue as well, because you don't
> want to regenerate and recompile the page every single time.

I'm hoping to piggy back the same "last modified timestamp" code that gets
used for 'regular' JSP. When a JSP gets recompiled, my little SAX
preprocessing occurs in between Jasper reading the XML JSP file, and the
Java code getting generated. SAX can take care of this using an XMLReader to
preprocess the SAX events before Jasper gets them. So I think its all going
to be OK.... (famous last words ;-)

> Given that, a completely different strategy to consider is to mess with
> how Catalina (the servlet container part of Tomcat 4.0) returns "static"
> resources from the web application.  I have to warn you, though, that this
> is pretty intense going -- we use a JNDI context to hide where the real
> files are (unpacked on disk, directly in the WAR, or somewhere else).

I think I'll give that a miss today ;-)

Thanks for your help Craig.



If you are not the addressee of this confidential e-mail and any 
attachments, please delete it and inform the sender; unauthorised 
redistribution or publication is prohibited. 
Views expressed are those of the author and do not necessarily 
represent those of Citria Limited.

View raw message