tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Casey Lucas" <clu...@armassolutions.com>
Subject RE: where to plug-in startup/shutdown knowledge for internal tomcat components
Date Fri, 09 Mar 2001 20:19:12 GMT

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


Mime
View raw message