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]>

Reply via email to