> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Hans
> Bergsten
> Sent: Wednesday, March 07, 2001 9:06 PM
> To: [EMAIL PROTECTED]
> Subject: Re: tag handler pooling ideas
>
>
> Casey Lucas wrote:
> >
> > I am planning on implementing tag handler pooling and would like
> > to throw out a few ideas for feedback:
> >
> > assumptions:
> > - Tag handlers can only be reused if the same set of attributes
> > are used for the tag.
> >
> > - Tag.relese is called only once -- at some point before the
> > handler is garbage collected.
>
> I believe you must add one more restriction on reuse: you can only
> reuse tag handlers that are on the same nesting level. For instance,
> this case requires two tag handler instances even though they have
> the same set of attributes:
>
> <x:tag1 attr1="a" attr2="b">
> <x:tag1 attr1="xyz" attr2="123"/>
> </x:tag1>
>
True. This was an obvious one -- I just didn't mention it.
> > basic idea:
> > My general idea was to have a collection of named pools. Jasper
> > could then render code to use the named pool to obtain handler
> > instances instead of newing them each time.
> >
> > more info:
> > Each tag handler pool would have a name that would include
> > the tag's short name and the set of attributes that were used
> > on the tag.
>
> If by "short name", you mean something that identifies both the
> tag library and the tag, I'm with you. The prefix is not enough.
> The prefix is assigned per page, and you can actually use different
> prefixes for the same library in different pages, so you need
> another unique name for the tag library as such. The same problem
> exists with the taglib uri attribute value. Maybe you can use the
> context-relative path to the TLD; no matter how the TLD is identified
> by the taglib directive's uri attribute, it must always be resolved
> to a path to the TLD, and that must be unique within one app.
>
Right. I wasn't planning on using the prefix. The taglib needs
to be included, but I hadn't given the exact manner much thought. The
TLD path sounds like a good idea.
> > This would give us the correct reuse level. So
> > for the following tags there would be two named pools (after
> > taking into account attributes):
> >
> > <x:tag1 attr1="a" attr2="b"/>
> > <x:tag1 attr1="xyz" attr2="123"/>
> > <x:tag1 attr1="a"/>
> >
> > To eliminate the need to lookup the pool by name each time a
> > tag was needed, pool references could be rendered and initialized
> > (looked up) when the jsp is initialized. Inside the main jsp
> > method (_jspService), the pool references would be used directly.
>
> I'm not sure I follow.
>
Because there will be a collection (HashMap) of pools (Stacks), I don't
want to lookup the correct pool for a handler every time a handler needs
to be used. The overhead of string hash + lookup can be eliminated by
declaring pool instance variables in the rendered jsp. Upon jsp
initialization, the pools could be looked up. Subsequently the pool
references could be used to get handlers when needed. What it boils
down to is a Stack pop (synchronized for this one pool) instead of a
HashMap lookup (synchronized across all tag pools) followed by the pop.
Hopefully that made sense.
-casey
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
