Not great feedback I'm afraid - the suggestion of fixing things in
doEndTag sounds fine to me (null or ""), but I'm not deep into the
spec. If it's not an attribute of the tag, and it'll get recreated
anew in doStartTag I don't see any reason to avoid GC having a chance.

Same for the c:forEach, though I've no great itch to hunt down other cases.

Hen

On 3/27/07, Kris Schneider <[EMAIL PROTECTED]> wrote:
On further reflection, perhaps target should be set to "" instead of null
to maintain exception consistency...

Kris Schneider wrote:
> http://issues.apache.org/bugzilla/show_bug.cgi?id=33934
>
> After some thought, here's why I think we can actually set the target
> property to null in doEndTag (or doFinally, if we add it) instead of
> release.
>
> If a request-time value is used (scriptlet expression or EL), then the
> spec requires that the container must reset the property's value between
> all reuses. In other words, setTarget should be called each time the tag
> is (re)used.
>
> If a literal value is used, then the container is not required to reset
> the property's value. First, there's type conversion to deal with.
> However, since the property's type is Object, a new String instance will
> be used. In turn, this will cause doEndTag to throw an exception because
> String does not expose any writable Bean properties.
>
> So, AFAICT, the only way to get a valid value for target is with a
> request-time value.
>
> Feedback?
>
> P.S.
> This is in the context of JSP 2.0 and JSTL 1.1. It may still hold true
> for JSP 1.2 and JSTL 1.0, even for different reasons ;-), but I haven't
> thought much about it...

--
Kris Schneider <mailto:[EMAIL PROTECTED]>
D.O.Tech       <http://www.dotech.com/>

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to