Tag Handler Pooling Clarification

[Casey Lucas <cl...@armassolutions.com>]

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

Re: Tag Handler Pooling Clarification

[William Barker <wb...@wilshire.com>]

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" <cl...@armassolutions.com>
To: "tomcat dev" <to...@jakarta.apache.org>
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: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, email: tomcat-dev-help@jakarta.apache.org
>
>

Re: Tag Handler Pooling Clarification

[Hans Bergsten <ha...@gefionsoftware.com>]

Casey Lucas wrote:
> 
> 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.
> [...]

The JSP 1.1 spec is very confusing in this regard. I suggest you look at
the JSP 1.2 PDF spec before you get going with this. It contains much
improved descriptions, even though it may still not be as clear as it
should.

Basically, you're assumptions are right though: you can only reuse a
tag handler for action elements with the same attribute set. Calling
release() and reinitialize the tag handler for each use is not always
an efficient solution, because the tag handler may do expensive 
initialization in the setter methods. The release() method is intended
to be used by the tag handler to release all its state when it will
no longer be used, i.e. not as a "pool reset" method.

I agree that this whole area is pretty messy and unclear. We had a
looooooong discussion about how to resolve it in the best way within
the JSR-053 group last year. The result of those discussions is reflected
in the JSP 1.2 PDF spec.

Hans
-- 
Hans Bergsten		hans@gefionsoftware.com
Gefion Software		http://www.gefionsoftware.com
Author of JavaServer Pages (O'Reilly), http://TheJSPBook.com