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" <[EMAIL PROTECTED]> > > 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 > ([EMAIL PROTECTED]) > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > -- Felipe Schnack Analista de Sistemas [EMAIL PROTECTED] Cel.: (51)91287530 Linux Counter #281893 Centro Universitário Ritter dos Reis http://www.ritterdosreis.br [EMAIL PROTECTED] Fone/Fax.: (51)32303341 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
