hmmm...
i don't know, but in my opinion, we shouldn't call release() at every
doEndTag(), but we should clean, for instance, tag attributes and these
such things. If you clean everything a tag uses in its lifecycle, you're
throwing away most of the advantage of tag reuse
On Tue, 2002-10-15 at 17:32, Halvorson, Loren wrote:
> Hans,
>
> I just had a look at the dbtags source and see why it worked. The release()
> method was already being called manually within most of the doEndTag()
> methods. Unfortunately their release() wasn't doing a complete job because
> it failed to call super.release().
>
> Example from ResultSetTag.java
>
> public int doEndTag() throws JspTagException{
> pageContext.removeAttribute(getId());
> try {
> if (getBodyContent() != null && getPreviousOut() != null) {
> getPreviousOut().write(getBodyContent().getString());
> }
> } catch (IOException e) {
> throw new JspTagException(e.toString());
> } finally {
> try {
> _rset.close();
> }
> catch (SQLException e) {
> // it's not fatal if the result set cannot be closed
> e.printStackTrace();
> }
> }
> * * * * * * * * * * * * * * * * * * *
> // we have to call this guy manually now
> // with the spec clarification
> release();
> * * * * * * * * * * * * * * * * * * *
> return EVAL_PAGE;
> }
>
>
>
>
> -----Original Message-----
> From: Hans Bergsten [mailto:[EMAIL PROTECTED]]
> Sent: Monday, October 14, 2002 2:03 PM
> To: Tag Libraries Users List
> Subject: Re: [dbtags] SOLVED: Strange behavior since switching to Tomcat
> 4.1.1 2
>
>
> Halvorson, Loren wrote:
> > OK I think I have a handle on what is wrong with the dbtags.
> >
> > Almost every tag forgets to call super.release() In their release()
> > method. This doesn't cause any problems if your container doesn't
> > recycle tags.
> >
> > public void release() {
> > super.release(); <--- this needs to be added
> > _position = -1;
> > _attributeName = null;
> > _name = null;
> > _scope = "page";
> > _tag = null;
> > _metaData = null;
> > _locale = null;
> > }
> >
> > Can a taglibs committer just rip through and add super.release() to
> > all of the tag release methods? If there is a formal patch procedure
> > I need to go through instead, let me know.
>
> If the problem is related to tag handler reuse, adding super.release() will
> not fix the problem (even though it may still be a good idea). The
> release() method is only called once, just before the tag handler is no
> longer to be used.
>
> To fix problems related to reuse, you must make sure that per-invokation
> state gets reset for each invocation, typically in the doStart() method. See
> this article for details:
>
> <http://www.onjava.com/pub/a/onjava/2001/11/07/jsp12.html>
>
> Hans
> > -----Original Message-----
> > From: Halvorson, Loren [mailto:[EMAIL PROTECTED]]
> > Sent: Tuesday, October 15, 2002 12:05 PM
> > To: [EMAIL PROTECTED]
> > Subject: [dbtags] Strange behavior since switching to Tomcat 4.1.12
> >
> >
> > We are seeing some strange behavior from dbtags since we switched to
> > Tomcat 4.1.12. I'm pretty sure it's related to the new tag pooling
> > feature of Tomcat. I am wondering if anyone else is having problems.
> >
> > If we have two statements on the same page, where the first one
> > returns rows, but the second does not, the second statement tag prints
> > out the actual text of it's query instead of nothing.
> >
> > For example:
> > <sql:statement id="stmt2" conn="conn">
> > <sql:query>select * from foo/*a query that returns rows*/</sql:query>
> > <sql:resultSet id="rset2">
> > </sql:resultSet>
> > </sql:statement>
> >
> > <sql:statement id="stmt3" conn="conn">
> > <sql:query>select * from bar /*a query that returns NO
> > rows*/</sql:query>
> > <sql:resultSet id="rset3">
> > </sql:resultSet>
> > </sql:statement>
> > Would actually send back to the browser
> >
> > "select * from bar /*a query that returns NO rows*/"
> >
> > Oh I wish we could switch to JSTL (to anticipate the response I know
> > some of you are thinking), but we have the requirement of supporting
> > JSP 1.1 containers too (like WebSphere 4.0). So let's get busy on
> > that JSP 1.1 back-port of JSTL.
> >
> > Thanks
> >
> > --
> > To unsubscribe, e-mail:
> > <mailto:[EMAIL PROTECTED]>
> > For additional commands, e-mail:
> > <mailto:[EMAIL PROTECTED]>
> >
> > --
> > To unsubscribe, e-mail:
> <mailto:[EMAIL PROTECTED]>
> > For additional commands, e-mail:
> > <mailto:[EMAIL PROTECTED]>
> >
>
> --
> Hans Bergsten [EMAIL PROTECTED]
> Gefion Software http://www.gefionsoftware.com
> JavaServer Pages http://TheJSPBook.com
>
>
> --
> To unsubscribe, e-mail:
> <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
> <mailto:[EMAIL PROTECTED]>
>
> --
> To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
>
--
Felipe Schnack
Analista de Sistemas
[EMAIL PROTECTED]
Cel.: (51)91287530
Linux Counter #281893
Faculdade Ritter dos Reis
www.ritterdosreis.br
[EMAIL PROTECTED]
Fone/Fax.: (51)32303328
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>