my use of the phrase "optionally post-processed into servlets" was
touching upon the fact that it is possible for some deployments to
deliver pre-compiled jsp's (ala servlet classes) which will require no
page compiliation upon the destination system. that's all.
i see jsp's as a great developer tool but in practice i doubt many
mid to large sized sites will regularly edit source jsp files by hand.
this activity will likely occur during the proto, development and
testing cycles but not in the production cycle where i expect the
page pre-compile feature to be well appreciated.
further on this topic, tomcat@jakarta (http://jakarta.apache.org)
supports, at some level, a servlet and jsp "load-on-startup" which
effectively routes a dummy request/response to the jsp pages to
trigger a compiliation if required. the net effect is that the page
is all ready translated before the first "real" external request. that
said, i still expect the pre-compile feature to be used in production
by big sites.
hope this helps,
- james
"Craig R. McClanahan" wrote:
> "Frank D. Greco" wrote:
>
> > At 02:50 PM 11/9/99 -0800, James Todd wrote:
> > >jsp's are optionally post-processed into servlets after which
> > >all subsequent executions offer all the benifits of a servlet ...
> > >cuz it *is* a servlet.
> >
> > "Optionally"? hmmmm... does the JSP spec say that JSP's
> > *must* be post-processed into servlets, or is it up to
> > the JSP implementor?
>
> Among many other places, see section 3.2 of the JSP 1.1pr2 specification:
>
> "The JSP page implementation class will implement
> Servlet and the Servlet protocol will be used to
> deliver requests to the class."
>
> so it's not optional. The 1.0 spec wasn't quite so clear cut as this.
>
> > After all, the spec does allow other
> > source languages, which implies a Java servlet might
> > not be generated.
> >
>
> Support for different scripting languages doesn't have a lot to do with the
> characteristics of the generated page. For example, if you wanted to
> implement a JSP container for language "foo", here's at least a couple of
> approaches you could take:
>
> * Translate all scriptlets written in "foo" into their corresponding
> Java equivalents, and embed them in the generated class.
>
> * Leave the scriptlets in language "foo", and call a "foo"
> interpreter at runtime (embedded in the JSP container)
> to execute the desired logic.
>
> >
> > Frank G.
>
> Craig McClanahan
>
> ___________________________________________________________________________
> To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
> of the message "signoff SERVLET-INTEREST".
>
> Archives: http://archives.java.sun.com/archives/servlet-interest.html
> Resources: http://java.sun.com/products/servlet/external-resources.html
> LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".
Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
