You are viewing a plain text version of this content. The canonical link for it is here.
Posted to taglibs-user@tomcat.apache.org by Hans Bergsten <ha...@gefionsoftware.com> on 2002/10/15 21:38:21 UTC

Re: [dbtags] SOLVED: Strange behavior since switching to Tomcat 4 .1.1 2

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().

Okay, that explains it.

Hans

> 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:hans@gefionsoftware.com] 
> 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:Loren.Halvorson@firepond.com]
>>Sent: Tuesday, October 15, 2002 12:05 PM
>>To: taglibs-user@jakarta.apache.org
>>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: 
>><ma...@jakarta.apache.org>
>>For additional commands, e-mail: 
>><ma...@jakarta.apache.org>
>>
>>--
>>To unsubscribe, e-mail:
> 
> <ma...@jakarta.apache.org>
> 
>>For additional commands, e-mail: 
>><ma...@jakarta.apache.org>
>>
> 

-- 
Hans Bergsten		hans@gefionsoftware.com
Gefion Software		http://www.gefionsoftware.com
JavaServer Pages	http://TheJSPBook.com


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>