tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Felipe Schnack <feli...@ritterdosreis.br>
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" <felipes@ritterdosreis.br>
> > 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
> (willh@msoft.com)
> 
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
> 
-- 

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

Centro Universitário Ritter dos Reis
http://www.ritterdosreis.br
ritter@ritterdosreis.br
Fone/Fax.: (51)32303341


---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org


Mime
View raw message