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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> > Sent: Friday, March 09, 2001 11:48 AM
> > To: [EMAIL PROTECTED]
> > 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: [EMAIL PROTECTED]
> > > For additional commands, email: [EMAIL PROTECTED]
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, email: [EMAIL PROTECTED]
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
begin:vcard
n:Quinn;Martin
tel;pager:888 498 2215
tel;cell:206 890 8780
tel;fax:206 522 1947
tel;work:206 517 6450
x-mozilla-html:FALSE
org:<BR><IMG SRC="http://www.irista.com/logo/irista.gif"><BR><BR><FONT Color=#000080><FONT SIZE=2><B>Bringing Vision to Your Supply Chain</B></FONT><BR>
adr:;;115 NE 100th Street;Seattle;WA;98125;
version:2.1
email;internet:[EMAIL PROTECTED]
title:Director, Product Development
end:vcard
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
