"Craig R. McClanahan" <[EMAIL PROTECTED]> wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > > > On Mon, 3 Feb 2003, Will Hartung wrote: > > > Date: Mon, 3 Feb 2003 11:00:46 -0800 > > From: Will Hartung <[EMAIL PROTECTED]> > > Reply-To: Tomcat Users List <[EMAIL PROTECTED]> > > To: Tomcat Users List <[EMAIL PROTECTED]> > > Subject: Re: more about custam tag life cycle > > > > > 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. > > > > The page will call release() before it is put back in the pool.
Totally and completely false. Please go back and read the JSP Spec. The page will call release() before the tag is released to GC, and for no other reason. > > > 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. > > > > This only helps in a JSP 1.2 container, and comes with at least some > performance price due to the extra try/catch/finally block that the page > compiler has to create. > > > What's is non-obvious is that the doEndTag and doFinally are supposed to > > assume the role of cleaning the tag up for reuse. > > That is not what they are for. > > The purpose of doEndTag() is to finish up whatever processing your tag > does, at the end of the closing tag on the page. You should not be > modifying the attribute values that were set by the page anyway, so there > should be no need to clean up here. > > The purpose of doFinally() is to deal with exceptions that were thrown > within the body of your tag. You really do not want to spend the extra > processor cycles when such exceptions do not occur, or don't matter to > you. > > > > > 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). > > > > There are really two issues here -- tag *pooling* (the container recycles > a previous tag instance instead of creating a new one every time) and tag > *reuse* (the container uses the same instance for more than one tag with > identical attributes). It's entirely legal to have tag reuse even in a > container that does not implement tag pooling, so you have to account for > both possibilities. > > Tag reuse is only allowed when the set of attributes that are used, and > their values, are identical. For example, the following two tags will > *always* use different instances: > > <foo:bar baz="a"/> > <foo:bar baz="b"/> > > because the attribute value is different. Likewise, the following two > tags will *always* use different instances: > > <foo:bar baz="a"/> > <foo:bar bif="a"/> > > because different attribues are used. > > However, the following tag instances *can* be reused (and smart developers > will always program their tags as if they *will* be reused): > > <foo:bar baz="a"/> > <foo:bar baz="a"/> > > If your container does implement tag pooling (in addition to or instead of > tag reuse), it will call release() before returning the instance to the > pool. That makes release() the right place to reset everything to > defaults. > > > 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. > > > > There are two simple rules for writing pooling-safe and reuse-safe tags: > > * Do not modify the instance variables that were > set by your attribute setters in ANY of the > doXxx() methods. > > * If you want to clean up, do so in release(), > which will be called before a tag instance can > be returned to the pool. > > Or, in JSP 2.0, use the new SimpleTag API and dispense with the whole set > of concerns about tag lifecycle (such tag instances cannot be pooled, so > you don't have to worry about it). > > > Regards, > > > > Will Hartung > > ([EMAIL PROTECTED]) > > > > Craig --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
