You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Casey Lucas <cl...@armassolutions.com> on 2001/03/09 18:36:50 UTC
where to plug-in startup/shutdown knowledge for internal tomcat components
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
Re: where to plug-in startup/shutdown knowledge for internal tomcat
components
Posted by 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
RE: where to plug-in startup/shutdown knowledge for internal tomcat components
Posted by Casey Lucas <cl...@armassolutions.com>.
I pulled src for 3.3 m2 (with jasper.runtime in common dir) and it
all started working.... cool!
Additionally, I have a much better understanding of tomcat's use
of ClassLoaders.
Thanks for the help.
-Casey
> -----Original Message-----
> From: cmanolache@yahoo.com [mailto:cmanolache@yahoo.com]
> Sent: Sunday, March 11, 2001 3:27 AM
> To: tomcat-dev@jakarta.apache.org
> Subject: RE: where to plug-in startup/shutdown knowledge for internal
> tomcat components
>
>
> Hi Casey,
>
> I agree, resolving class loader problems is not easy. But it does have a
> bit of logic :-)
>
> The solution you found ( put everything in common/ ) is ok - that's how
> tomcat worked in 3.2 and before, and still works.
>
> Resolving the problem with a separate class loader for container is a bit
> more difficult - the main benefit is that the container implementation (
> modules and libs that are used - including jaxp ) are separated from the
> web application.
>
> > attempt 1:
> >
> > For each contextInit, TagPoolManagerInterceptor called
> > TagPoolManager.setDefaultManager with a newly created TagPoolManagerImpl,
> > yet when the jsp called TagPoolManager.getDefaultManager, the static
> > reference set in setDefaultManager came back null.
>
> Try to do a println( TagPoolManager.getClassLoader().toString() ) every
> time you use it. You'll see what happens ( 2 different class loaders ).
>
> You can also try to print the parent loader.
>
>
> > Giving up on that, I tried 2:
> >
> > Use no statics, just call Context.setAttribute in the interceptor. In
> > the jsp use Context.getAttribute. The object that comes back is
> > the exact same TagPoolManagerImpl that was put there by the interceptor
> > but if I try to cast it to a TagPoolManager (or TagPoolManagerImpl for
> > that matter), I get a ClassCastException.
>
> Same problem - different class loaders -> different classes :-)
>
> > I was originally trying to follow the model of JspFactory. I modeled my
> > interceptor after the JspInterceptor, but no luck for me. I noticed that
> > sevlet.jar was both in TC_HOME/lib and TC_HOME/lib/common. Maybe that's
>
> That was fixed recently, servlet.jar should be only in common.
>
>
> > why JspFactory works. I jared up the TagPool* classes and stuck them into
> > TC_HOME/lib/common and everything worked. Even though it worked, it didn't
> > seem right putting jasper.runtime.Tag* classes into the common directory.
> > Any help / suggestions would be greatly appreciated.
>
> jasper.runtime is now in common ( we did a number of fixes since M1 ).
> Everything that should be visible to webapps ( and jasper runtime is one
> example - since jsps are using the classes from runtime ) should be in
> common ( i.e. visible in both apps and container ).
>
> Jasper itself ( the compiler ) is in a separate loader.
>
> Think of the container as another application, that happens to provide
> some services to other apps.
>
> The common dir is what all applications are seeing ( including the
> container ). Each app has it's own local jars, providing the local
> functionality. The container provides jsp compilation, configuration,
> and other services that are used by tomcat.
>
> Costin
>
>
> ---------------------------------------------------------------------
> 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
RE: where to plug-in startup/shutdown knowledge for internal tomcat
components
Posted by cm...@yahoo.com.
Hi Casey,
I agree, resolving class loader problems is not easy. But it does have a
bit of logic :-)
The solution you found ( put everything in common/ ) is ok - that's how
tomcat worked in 3.2 and before, and still works.
Resolving the problem with a separate class loader for container is a bit
more difficult - the main benefit is that the container implementation (
modules and libs that are used - including jaxp ) are separated from the
web application.
> attempt 1:
>
> For each contextInit, TagPoolManagerInterceptor called
> TagPoolManager.setDefaultManager with a newly created TagPoolManagerImpl,
> yet when the jsp called TagPoolManager.getDefaultManager, the static
> reference set in setDefaultManager came back null.
Try to do a println( TagPoolManager.getClassLoader().toString() ) every
time you use it. You'll see what happens ( 2 different class loaders ).
You can also try to print the parent loader.
> Giving up on that, I tried 2:
>
> Use no statics, just call Context.setAttribute in the interceptor. In
> the jsp use Context.getAttribute. The object that comes back is
> the exact same TagPoolManagerImpl that was put there by the interceptor
> but if I try to cast it to a TagPoolManager (or TagPoolManagerImpl for
> that matter), I get a ClassCastException.
Same problem - different class loaders -> different classes :-)
> I was originally trying to follow the model of JspFactory. I modeled my
> interceptor after the JspInterceptor, but no luck for me. I noticed that
> sevlet.jar was both in TC_HOME/lib and TC_HOME/lib/common. Maybe that's
That was fixed recently, servlet.jar should be only in common.
> why JspFactory works. I jared up the TagPool* classes and stuck them into
> TC_HOME/lib/common and everything worked. Even though it worked, it didn't
> seem right putting jasper.runtime.Tag* classes into the common directory.
> Any help / suggestions would be greatly appreciated.
jasper.runtime is now in common ( we did a number of fixes since M1 ).
Everything that should be visible to webapps ( and jasper runtime is one
example - since jsps are using the classes from runtime ) should be in
common ( i.e. visible in both apps and container ).
Jasper itself ( the compiler ) is in a separate loader.
Think of the container as another application, that happens to provide
some services to other apps.
The common dir is what all applications are seeing ( including the
container ). Each app has it's own local jars, providing the local
functionality. The container provides jsp compilation, configuration,
and other services that are used by tomcat.
Costin
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, email: tomcat-dev-help@jakarta.apache.org
RE: where to plug-in startup/shutdown knowledge for internal tomcat components
Posted by Casey Lucas <cl...@armassolutions.com>.
Ok, I'm going crazy. I had everything setup like you recommended (at
least I thought I did), but I'm still running into problems.
scenarios:
TagPoolManagerInterceptor is in package org.apache.tomcat.modules.tagpool
TagPoolManager (Impl, etc) are in org.apache.jasper.runtime
attempt 1:
For each contextInit, TagPoolManagerInterceptor called
TagPoolManager.setDefaultManager with a newly created TagPoolManagerImpl,
yet when the jsp called TagPoolManager.getDefaultManager, the static
reference set in setDefaultManager came back null.
Giving up on that, I tried 2:
Use no statics, just call Context.setAttribute in the interceptor. In
the jsp use Context.getAttribute. The object that comes back is
the exact same TagPoolManagerImpl that was put there by the interceptor
but if I try to cast it to a TagPoolManager (or TagPoolManagerImpl for
that matter), I get a ClassCastException.
I was originally trying to follow the model of JspFactory. I modeled my
interceptor after the JspInterceptor, but no luck for me. I noticed that
sevlet.jar was both in TC_HOME/lib and TC_HOME/lib/common. Maybe that's
why JspFactory works. I jared up the TagPool* classes and stuck them into
TC_HOME/lib/common and everything worked. Even though it worked, it didn't
seem right putting jasper.runtime.Tag* classes into the common directory.
Any help / suggestions would be greatly appreciated.
-Casey
> -----Original Message-----
> From: cmanolache@yahoo.com [mailto:cmanolache@yahoo.com]
> Sent: Saturday, March 10, 2001 1:13 AM
> To: tomcat-dev@jakarta.apache.org
> Subject: RE: where to plug-in startup/shutdown knowledge for internal
> tomcat components
>
>
> Hi Casey,
>
> Welcome to the wonderful world of ClassLoading.
>
> The default configuration for 3.3 is to use a separate class loader for
> container ( i.e. tomcat.core, jasper, jaxp ) and web applications.
>
> This resolves a number of problems - like having a different parser in the
> web application.
>
> It also resolves the problem of overriding and fine-control over what is
> seen in the web app, and does enhance the security ( most classes that are
> visible in container are "trusted" ).
>
> But what I love about this is that it forces us to make a clear
> distinction between what is runtime and what is internal to the container.
>
> To answer to your problem: I assume TagPoolManager will be available at
> runtime to jsps. So it should be included in the common runtime, shared by
> both webapps and container.
>
> TagPoolInterceptor is a container extension, so it'll be part of the
> container loader. You shouldn't use static fields in general, but if you
> do keep in mind that "static" refers to the ClassLoader+Class combination
> ( you have one instance of the static field for each class loader ).
>
> BTW, this operating mode ( with multiple loaders ) is the most flexible
> for tomcat. The old mechanism still works ( with the old limitations ),
> but requires some code to enable it ( it's mostly for embeded tomcat ).
>
>
> Costin
>
>
> On Sat, 10 Mar 2001, Casey Lucas wrote:
> >
> > Now, I'm testing the pooling stuff out. I've got a
> > TagPoolManagerInterceptor that listens to contextInit, etc. But my
> > problem is that the static TagPoolManager reference that I initialize
> > in contextInit always ends up null when the jsp runs. I put a print statement
> > in the static initializer of TagPoolManager and I can see that it is
> > being called once when tomcat starts up (and the various contexts are
> > loaded) and a second time when the jsp is run. I assume that there's
> > some class loader stuff going on that I don't understand.
> >
> > I looked at JspFactory because I'm using the same set/getDefault idiom.
> > It some how keeps its static reference that is initilized in contextInit.
> > My code seems to be just like JspFactory, yet my static gets reinitialized
> > to null.
> >
> > Any suggestions?
> >
> > -Casey
> >
> > > -----Original Message-----
> > > From: cmanolache@yahoo.com [mailto:cmanolache@yahoo.com]
> > > Sent: Friday, March 09, 2001 2:29 PM
> > > To: tomcat-dev@jakarta.apache.org
> > > Subject: RE: where to plug-in startup/shutdown knowledge for internal
> > > tomcat components
> > >
> > >
> > > On Fri, 9 Mar 2001, Casey Lucas wrote:
> > >
> > > > 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?
> > >
> > > And you have 2 solutions:
> > > 1. Use tomcat hooks. You can let a tomcat module manager the
> > > TagHandlerPool and you'll get all the notifications you need.
> > > Just implement and TagPoolManagerInterceptor module, implement
> > > the hooks you need ( addContext, contextInit, reload, etc).
> > >
> > > 2. Use some "hacks" in the generated init()/destroy().
> > > For example, in init() you can use a context attribute ( TagPoolManager ),
> > > if not set you'll create it and init, if it's set you just use it.
> > >
> > > > Am I off base, with my general strategy?
> > >
> > > No, it is ok.
> > >
> > > > 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.
> > >
> > > 4.x also have a mechanism to notify you about events - either a 2.3 filter
> > > or use the internal Listener interfaces, and most decent servlet
> > > containers will provide such a mechanism.
> > >
> > > As long as you keep a simple interface to your tag pool, it should be easy
> > > to write the container-specific adapter that will plug it in.
> > >
> > >
> > > Costin
> > >
> > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, email: tomcat-dev-help@jakarta.apache.org
RE: where to plug-in startup/shutdown knowledge for internal tomcat
components
Posted by cm...@yahoo.com.
Hi Casey,
Welcome to the wonderful world of ClassLoading.
The default configuration for 3.3 is to use a separate class loader for
container ( i.e. tomcat.core, jasper, jaxp ) and web applications.
This resolves a number of problems - like having a different parser in the
web application.
It also resolves the problem of overriding and fine-control over what is
seen in the web app, and does enhance the security ( most classes that are
visible in container are "trusted" ).
But what I love about this is that it forces us to make a clear
distinction between what is runtime and what is internal to the container.
To answer to your problem: I assume TagPoolManager will be available at
runtime to jsps. So it should be included in the common runtime, shared by
both webapps and container.
TagPoolInterceptor is a container extension, so it'll be part of the
container loader. You shouldn't use static fields in general, but if you
do keep in mind that "static" refers to the ClassLoader+Class combination
( you have one instance of the static field for each class loader ).
BTW, this operating mode ( with multiple loaders ) is the most flexible
for tomcat. The old mechanism still works ( with the old limitations ),
but requires some code to enable it ( it's mostly for embeded tomcat ).
Costin
On Sat, 10 Mar 2001, Casey Lucas wrote:
>
> Now, I'm testing the pooling stuff out. I've got a
> TagPoolManagerInterceptor that listens to contextInit, etc. But my
> problem is that the static TagPoolManager reference that I initialize
> in contextInit always ends up null when the jsp runs. I put a print statement
> in the static initializer of TagPoolManager and I can see that it is
> being called once when tomcat starts up (and the various contexts are
> loaded) and a second time when the jsp is run. I assume that there's
> some class loader stuff going on that I don't understand.
>
> I looked at JspFactory because I'm using the same set/getDefault idiom.
> It some how keeps its static reference that is initilized in contextInit.
> My code seems to be just like JspFactory, yet my static gets reinitialized
> to null.
>
> Any suggestions?
>
> -Casey
>
> > -----Original Message-----
> > From: cmanolache@yahoo.com [mailto:cmanolache@yahoo.com]
> > Sent: Friday, March 09, 2001 2:29 PM
> > To: tomcat-dev@jakarta.apache.org
> > Subject: RE: where to plug-in startup/shutdown knowledge for internal
> > tomcat components
> >
> >
> > On Fri, 9 Mar 2001, Casey Lucas wrote:
> >
> > > 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?
> >
> > And you have 2 solutions:
> > 1. Use tomcat hooks. You can let a tomcat module manager the
> > TagHandlerPool and you'll get all the notifications you need.
> > Just implement and TagPoolManagerInterceptor module, implement
> > the hooks you need ( addContext, contextInit, reload, etc).
> >
> > 2. Use some "hacks" in the generated init()/destroy().
> > For example, in init() you can use a context attribute ( TagPoolManager ),
> > if not set you'll create it and init, if it's set you just use it.
> >
> > > Am I off base, with my general strategy?
> >
> > No, it is ok.
> >
> > > 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.
> >
> > 4.x also have a mechanism to notify you about events - either a 2.3 filter
> > or use the internal Listener interfaces, and most decent servlet
> > containers will provide such a mechanism.
> >
> > As long as you keep a simple interface to your tag pool, it should be easy
> > to write the container-specific adapter that will plug it in.
> >
> >
> > Costin
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > 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
RE: where to plug-in startup/shutdown knowledge for internal tomcat components
Posted by Casey Lucas <cl...@armassolutions.com>.
Costin.
Thanks for the help and sorry for all the questions. I wasn't familiar
with tomcat hooks and didn't understand the JspInterceptor. But that
was then...
Now, I'm testing the pooling stuff out. I've got a
TagPoolManagerInterceptor that listens to contextInit, etc. But my
problem is that the static TagPoolManager reference that I initialize
in contextInit always ends up null when the jsp runs. I put a print statement
in the static initializer of TagPoolManager and I can see that it is
being called once when tomcat starts up (and the various contexts are
loaded) and a second time when the jsp is run. I assume that there's
some class loader stuff going on that I don't understand.
I looked at JspFactory because I'm using the same set/getDefault idiom.
It some how keeps its static reference that is initilized in contextInit.
My code seems to be just like JspFactory, yet my static gets reinitialized
to null.
Any suggestions?
-Casey
> -----Original Message-----
> From: cmanolache@yahoo.com [mailto:cmanolache@yahoo.com]
> Sent: Friday, March 09, 2001 2:29 PM
> To: tomcat-dev@jakarta.apache.org
> Subject: RE: where to plug-in startup/shutdown knowledge for internal
> tomcat components
>
>
> On Fri, 9 Mar 2001, Casey Lucas wrote:
>
> > 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?
>
> And you have 2 solutions:
> 1. Use tomcat hooks. You can let a tomcat module manager the
> TagHandlerPool and you'll get all the notifications you need.
> Just implement and TagPoolManagerInterceptor module, implement
> the hooks you need ( addContext, contextInit, reload, etc).
>
> 2. Use some "hacks" in the generated init()/destroy().
> For example, in init() you can use a context attribute ( TagPoolManager ),
> if not set you'll create it and init, if it's set you just use it.
>
> > Am I off base, with my general strategy?
>
> No, it is ok.
>
> > 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.
>
> 4.x also have a mechanism to notify you about events - either a 2.3 filter
> or use the internal Listener interfaces, and most decent servlet
> containers will provide such a mechanism.
>
> As long as you keep a simple interface to your tag pool, it should be easy
> to write the container-specific adapter that will plug it in.
>
>
> Costin
>
>
>
>
> ---------------------------------------------------------------------
> 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
RE: where to plug-in startup/shutdown knowledge for internal tomcat
components
Posted by cm...@yahoo.com.
On Fri, 9 Mar 2001, Casey Lucas wrote:
> 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?
And you have 2 solutions:
1. Use tomcat hooks. You can let a tomcat module manager the
TagHandlerPool and you'll get all the notifications you need.
Just implement and TagPoolManagerInterceptor module, implement
the hooks you need ( addContext, contextInit, reload, etc).
2. Use some "hacks" in the generated init()/destroy().
For example, in init() you can use a context attribute ( TagPoolManager ),
if not set you'll create it and init, if it's set you just use it.
> Am I off base, with my general strategy?
No, it is ok.
> 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.
4.x also have a mechanism to notify you about events - either a 2.3 filter
or use the internal Listener interfaces, and most decent servlet
containers will provide such a mechanism.
As long as you keep a simple interface to your tag pool, it should be easy
to write the container-specific adapter that will plug it in.
Costin
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, email: tomcat-dev-help@jakarta.apache.org
RE: where to plug-in startup/shutdown knowledge for internal tomcat components
Posted by Casey Lucas <cl...@armassolutions.com>.
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
Re: where to plug-in startup/shutdown knowledge for internal tomcat
components
Posted by cm...@yahoo.com.
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