My reading of the spec is that after calling Tag.release, the tag handler
could be safely put back into the pool. However calling Tag.release after
doEndTag isn't mandatory. If the compiler is smart enough, it may re-use a
tag without releasing it first if the second invocation uses a super-set of
the first ones attributes. Granted, section 10.3 of the spec forgets to
address this point , but my reading is that it should say:
// loop
}
// put d back to pool
}
----- Original Message -----
From: "Casey Lucas" <[EMAIL PROTECTED]>
To: "tomcat dev" <[EMAIL PROTECTED]>
Sent: Tuesday, March 06, 2001 9:00 AM
Subject: Tag Handler Pooling Clarification
>
> Sorry for the long message, but I'm a bit unclear on some Tag related
> spec details. I need to make sure I have a clear understanding before
> I start thinking about tag handler reuse implementation.
>
>
> My original understanding of Tag.release was that it was always called
after
> a tag handler was used -- after doEndTag. After calling release, the JSP
> container could then put the tag handler back into a pool for reuse. So,
> I was under the impression that a tag handler could be treated simply as
> a pooled resource.
>
> Based on my understanding, all of our code simply set tag handler
attributes
> to their default values in the release method. By doing this we set the
tag
> handler to a "default" or "initialized" state. Subsequently,
setPageContext,
> various setters, etc. could be called and the whole tag use process would
> proceed again.
>
> But, after a more careful reading of the tag sections of the JSP 1.2 spec,
it
> appears that tag reuse can only occur when tags have the same set of
> attributes that are initialized in the JSP. Specifically, in section
10.1.1
> under the "Lifecycle" section, bullet [3] states:
>
> Note that since there are no guarantees on the state of the properties,
> a tag handler that had some optional properties set can only be reused
> if those properties are set to a new (known) value. This means that
> tag handlers can only be reused within the same "Att-Set" (set of
> attributes that have been set).
>
>
> This part of the spec could be interpreted to mean that tag handlers
> should only be reused if they have the same set of attributes. For
example,
> given the following JSP fragment, two different tag1 handlers would
> have to be used (instead of reusing the handler):
>
> <X:tag1 attr1="A" attr2="B"/>
>
> <X:tag1 attr1="A"/>
>
>
> I hope that I'm misunderstanding something. I'd much prefer that the
> JSP container can rely on the handler's release method to reset the
> handler to a known state and simply start the tag process over again
> (setPageContext, setters, etc.) Such an assumption would greatly
> simplify a pooling strategy.
>
> Can anyone provide clarification?
>
> -Casey
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
