Hi Casey,
This is a hard question :-)
The main decision you must make is that:
Do you want to use JspServlet or JspInterceptor ?
The first solution ( using Jasper via JspServlet ) is what is used in
tomcat 3.1, 3.2 and 4.0 - and it has the big advantage that the full
Jasper in interfaced using a normal servlet. That means jasper can be used
in any place where a servlet can be used, and integrating it into any
servlet container should be trivial.
The second solution is used in tomcat 3.3 ( JspServlet is still
supported). JspInterceptor is an adapter between tomcat 3.3 internals (
i.e. the hooks provided to tomcat 3.3 modules ) and Jasper's APIs (
Mangler, JspCompiler, etc). It works in the same way as JSPC - where a
command-line interface to jasper is provided, with a lot of options.
This is extremely flexible and gives you full access to all jasper's
features, it allows a number of optimizations ( like avoiding the double
redirection - JspServet->generated servlet), allows treating
jsp-generated servlets as normal servlets ( i.e. absolutely no extra
overhead or difference between a jsp and servlet after the compilation),
and is much cleaner.
It is also possible to adapt jasper ( not as easy as with a servlet ) to
other containers by writing an adapter between Jasper's APIs and the
container's internal APIs.
In any case, remember that Jasper-generated servlets can be used via JspC
- i.e. pre-compiled into servlets, without any jsp-specific code (
JspInterceptor acts like a runtime JspC ). So putting your code into
JspServlet will be a bad choice.
One way is to use tomcat3.3 hooks ( contextInit, reload,
requestMap, pre/postRequest, etc ), and eventually take advantage of the
per/request ( and thread ) and per context storage ( in 3.3, each Thread
has it's own set of Request/Response - so request notes are equivalent
with per thread data ).
The other way is to do tricks in the generated servlet. For example
on init() you can check a context attribute, and if not set you can do the
context initialization and set the attribute. As long as you use
"global" objects, reloading shouldn't affect you. You can use jasper
runtime object to put the common code, so the generated code will remain
small.
Both solutions have advantages - and it's even possible to do a
mix.
My recomandation - just use a SimplePool, implement the "real" code ( tag
pooling ), without worry about how the pool will look like or will be
hooked. After this works, we'll find a solution ( or 2 ) for this issue.
Costin
On Fri, 9 Mar 2001, Casey Lucas wrote:
>
> I'm doing some prototyping for tag pooling in tomcat (based on
> the 3.3 tree.) I'd like to implement tag handler pooling
> per web application. Can someone point me to where I can
> hook into in order to setup the internal pool stuff when
> each web application starts, stop, reloads, etc.?
>
> I need to do things like setup the pooling strategy
> when each web application starts and release all the tag
> handlers when the application shuts down.
>
> Sorry if this is a dumb question, but hopefully someone
> can save me a lot of time.
>
> thanks.
>
> -Casey
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
