tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Felipe Schnack <>
Subject Re: more about custam tag life cycle
Date Mon, 03 Feb 2003 19:11:51 GMT
  I'm curious, how you get a PageContext when the container doesn't call
setPageContext? Which container have this behavior?
  I don't see a reason why we should have pool-specific method for tag
property cleaning. doFinally method is intended for tag cleaning...
Probably when created it was intended for cleaning resources like
database connections, etc but I don't see any reason to create yet
another method just for tag reuse

On Mon, 2003-02-03 at 17:00, Will Hartung wrote:
> > From: "Felipe Schnack" <>
> > Sent: Monday, February 03, 2003 10:12 AM
> > Subject: RE: more about custam tag life cycle
> > This makes me feel muuuuuch better :-)
> On Mon, 2003-02-03 at 16:09, Tim Moore wrote:
> > This is NOT true, AFAIK.  The same tag instance can be used multiple times
> *sequentially*
> > but not *concurrently*.  Check out the lifecycle state diagram in the JSP
> spec.
> The way to look at it is simply that the generated code is going to use a
> tag pool for each distinct class of tags. Unfortunately, there is no
> specific action that tells the tag it is being pulled from or being put back
> from the pool.
> All tags follow the basic lifecycle of simpy
> constuctor
> setPageContext
> doStartTag
> doEndTag
> In the pooled environment, it's:
> constructor
> setPageContext
> doStartTag
> doEndTag
> doStartTag
> doEndTag
> etc.
> (I've seen some containers, I thinik Tomcat is one, that call setPageContext
> on each tag, but I've seen others that do not, so setPageContext is not a
> reliable method to reset the tag properties).
> If the tag implments the TryCatchFinally interface, then a doFinally is
> called after the doEndTag.
> What's is non-obvious is that the doEndTag and doFinally are supposed to
> assume the role of cleaning the tag up for reuse.
> I particularly like this quote from the spec:
> "The particular code shown below assumes there is some pool of tag handlers
> that are managed (details not described, although pool managing is simpler
> when
> there are no optional attributes),"
> This entire problem, at least as I've encountered it, revolves around not
> only optional, but also contradictory tags (i.e. it's okay to specify
> paramter a, b, or c, but no combination in the same tag).
> And like I said earlier, it would be nice if there were a pool interface
> added to the lifecycle to clean up the tag processing to make optional
> properties more portable and easier to write for.
> Regards,
> Will Hartung
> (
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

Felipe Schnack
Analista de Sistemas
Cel.: (51)91287530
Linux Counter #281893

Centro Universitário Ritter dos Reis
Fone/Fax.: (51)32303341

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message