--- [EMAIL PROTECTED] wrote:
> >
> > 1) I don't off-hand know of any other generalized
> way to make a portable JSP
> > compiler that can be plugged into any servlet 2.2
> engine other than as a
> > servlet. I'm not sure how that limits us
> feature-wise, other than the fact
> > that it adds a layer of indirection between the
> request on the container and
> > the actual ultimate jsp servlet. A small
> performance price to pay for
> > portability.
>
> The only problem is that the price is much higher
> that that:
>
> - JspServlet must manage the servlet lifecycle - the
> container can no
> longer treat jsp-generate-servlets the same as
> regular servlets
>
This is a limitation of the servlet api and thus the
lack of access to a consistent set of servlet engine
features necessary for full servlet life-cycle
management that can be relied upon. Besides, who said
that the container was guaranteed full-lifecycle
management of ANY servlet? Any servlet could be
created/loaded dynamically and managed by some other
servlet without the container ever knowing about it
(assuming the SecurityManager allowed it, of course
:-).
> - initialization - how can you pass init parameters
> to the jsp ? This is
> one of the worst hacks and source of counteless
> problems ( AFAIK - I
> couldn't find any clean way to do that )
>
How exactly do you solve this with JspInterceptor?
The specification doesn't really seem to cover
init-params for individual JSP pages. The JSP
container has no responsibility to provide
individualized init-params for JSP servlets, only to
invoke jspInit() prior to service(). In the absence
of a specified mechanism, it is the responsibility of
the JSP page author to initialize his page by
implementing the jspInit() method (from which he/she
can optionally load params from whereever he/she sees
fit).
In other words, this is not a limitation of
JspServlet, but rather a limitation of the JSP
specification.
> - class loader problems - again, the JspServlet must
> duplicate and
> override the class loading decisions of the
> container - other problems and
> issues
>
This, again is more a limitation (or too much freedom)
in how servlet containers are implemented.
>
> My point is that the servlet abstraction may not
> provide enough API
> support for what jasper need - in order to make it
> work you have to
> duplicate services that should be ofered by
> containers ( class loading,
> init, reloading, admin, etc ).
>
The glass is half-full as well - because at least with
the servlet api it is _possible_ to implement those
services portably and thus provide a portable JSP
compiler.
And yes, it would be great if the JspServlet didn't
have to implement redundant container services, that
in no way really limits JspServlet's ability to
fullfill all JSP specification features.
And again - what is the alternative? I can't write a
JspInterceptor solution for WebLogic or JRun.
> I don't want to discourage you from doing that - any
> refactoring will help
> and we badly need that. I just want to give you an
> alternate view, based
> on my experience - before you repeat mistakes we've
> already done :-)
>
The mistakes aren't in using a servlet-based approach.
This sort of feature (a plug-in to provid jsp
compilation and loading services to a web server) is
exactly what servlets are for. This in itself in no
way limits what you can do with JSPs because all
features of the JSP spec should be attainable through
a servlet implementation.
This DOES limit the reliance Jasper can have on
value-added container features beyond the servlet API,
but hey, you have to draw the line somewhere.
The way to look at it is that a JspInterceptor-style
solution is a value-added feature of the tomcat
servlet engine. That is a positive. The portability
of JspServlet is also a positive.
Cheers,
Mel
__________________________________________________
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail.
http://personal.mail.yahoo.com/?.refer=text
