> > - 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
> :-).
True, but a container can be smart ( and unload unused
servlets, provide nice monitoring, etc ).
> > - 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?
A JSP is treated the same way as a servlet - it gets a
ServletConfig with the right info from web.xml, etc.
There is no distinction between the way a regular servlet
is treated and a jasper-generated servlet.
> The specification doesn't really seem to cover
> init-params for individual JSP pages. The JSP
???
<servlet><jsp-file>/foo.jsp</jsp-file>
<init-param><name>foo</name>......
AFAIK you should be able to define init params for jsps the same
as you do for servlets ( unless I'm missing something here).
> container has no responsibility to provide
> individualized init-params for JSP servlets, only to
> invoke jspInit() prior to service(). In the absence
I thought it does... Even tought that never worked
very well :-)
> 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.
Almost everything is possible ( in a turing machine :-).
The problem is at what cost, and if that's the best
solution.
> And again - what is the alternative? I can't write a
> JspInterceptor solution for WebLogic or JRun.
Unfortunately that's true - and it's a good reason to
have JspServlet.
But if you have control over the servlet container (
for example using an internal extension mechanism -
like the interceptor in tc3 or valve in tc4 ) it would
be much better to use a rich API that allows full control
over jasper, and lets the container do what it is
supposed to do - manage servlets.
> 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.
I'm still looking for a solution to deal with the init-param
( except for re-parsing web.xml )
I'm not saying it's a mistake to have a servlet-based
approach, but that having a full API and letting the
container manager servlets and jasper do the compilation
could be a better solution.
> 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.
+1
( and to my defense - I did the fixes to allow JspServlet
to be still be used in tomcat 3.3, for people who want
a slower jsp :-)
Mel, what I'm trying to explain is not that JspServlet is bad,
but that we need a refactoring to expose more if Jasper API
and cleanly separate the components - so we can use
JspServlet and interceptors ( or valves ).
A lot of the code in jasper is written with the assumption
that JspServlet is the entry point ( i.e. with workarounds
and hacks for this case ) - and then we have JspC and JspInterceptor that
adds another round of hacks and workarounds.
And it would help a lot to keep this in mind while doing the refactoring -
i.e. to distinguish between what's jasper's core functionality ( convert a
.jsp file to a java file ) and what's a hack and duplication of
container's functionality for JspServlet's use.
For example JspLoader, some of the manglers, some of the JspEngine and
context. If we are going for a refactoring, it would be a good idea to
clean up and fix more than just JspServlet.
Costin
