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