Adding super.release() solved it for me for both Tomcat 4.1.12 and WebLogic 6.1 SP2. I didn't delve deep into the lifecycle of each tag, but this fix seemed to be exactly what the tags need. So any takers? --Loren
-----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]>
