Re: where to plug-in startup/shutdown knowledge for internal tomcat components

[Martin Quinn <ma...@irista.com>]

I have tried to remove myself from this list using the known options - but to no avail. How
can i get off this list.

Casey Lucas wrote:

> Costin,
>
> Thanks for the information, but because I'm still new to the tomcat
> code base, I'm a bit confused.
>
> Maybe it will help if I explain a little more about what I was playing
> around with:
>
> 1. Add a few classes (pooling interfaces/implementation) to jasper.runtime
> package so that rendered jsp's could use them.
>
> 2. Change Jasper to render code to use tag pooling.  This means changes
> to ...jasper.compiler.JspParseEventListener and maybe a couple of
> additional  jasper.compiler.*Generator classes that would render
> tag pooling specific stuff.
>
> Given these assumptions:
>   - org.apache.jasper.runtime.TagHandlerPool is the interface that
>     specifies tag pooling.
>   - org.apache.jasper.runtime.TagHandlerPoolManager is the interface that
>     allows different pooling strategies and gives out TagHandlerPools
>   - poolForTagX will be some better _jspx_... generated name.
>   - "pool name for tagX" will be some unique name (per reuse scope -
>     taking into account attributes, tld, etc.)
>   - TagHandlerX is substituted for the tld specified tag handler
>
> The new rendered code could look something like:
>
> public class _0002ftestdocs_0002fquestions_0002ejspquestions_jsp_4 extends HttpJspBase {
>
>     static {
>     }
>
>     // 2 lines below are new.
>     private TagHandlerPool poolForTag1;
>     private TagHandlerPool poolForTag2;
>
>     public _0002ftestdocs_0002fquestions_0002ejspquestions_jsp_4( ) {
>        // 2 lines below new.  assume that TagHandler1 and TagHandler2 are
>        // tag handler classes (from tld)
>        poolForTag1 = TagHandlerPoolManager.getDefaultManager().
>            getPool("pool name for tag1", TagHandler1.class);
>        poolForTag2 = TagHandlerPoolManager.getDefaultManager().
>            getPool("pool name for tag2", TagHandler2.class);
>     }
>
>     private static boolean _jspx_inited = false;
>
>     public final void _jspx_init() throws JasperException {
>     }
>
>     public void _jspService(HttpServletRequest request, HttpServletResponse  response)
>         throws IOException, ServletException {
>
> ======== end of code ========
>
> Then inside of _jspService, code would be rendered to use the appropriate "poolForTagX"
> object to get/release tag handlers.
>
> So, given all that, I need to control lifetime of TagHandlerPoolManager's
> default instance.  By controlling it, I can have one TagHandlerPoolManager
> instance per web application and when the web application gets unloaded,
> all the Tag.release methods can be called.  Aren't the JspServlet and
> JspInterceptor mechanisms specific to an individual jsp file?  If so,
> I don't think that's what I need because pooling will be for the entire
> web application not a specific JSP.
>
> I was hoping that when the web application (not individual jsp) is
> loaded, unloaded, reloaded I could do the TagHandlerPoolManager initialization
> and cleanup tasks.  Maybe I'm making things too complicated.  Should
> managing the lifetime of a per-web-application object like
> TagHandlerPoolManager be simpler?
>
> Am I off base, with my general strategy?
>
> Also, regarding 3.x and 4.x, I'd like to keep it usable / adaptable
> to all.  We're currently using 3, but will eventually migrate to 4.
>
> thanks.
> -Casey
>
> > -----Original Message-----
> > From: cmanolache@yahoo.com [mailto:cmanolache@yahoo.com]
> > Sent: Friday, March 09, 2001 11:48 AM
> > To: tomcat-dev@jakarta.apache.org
> > Subject: Re: where to plug-in startup/shutdown knowledge for internal
> > tomcat components
> >
> >
> > 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: tomcat-dev-unsubscribe@jakarta.apache.org
> > > For additional commands, email: tomcat-dev-help@jakarta.apache.org
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> > For additional commands, email: tomcat-dev-help@jakarta.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, email: tomcat-dev-help@jakarta.apache.org