Return-Path: Delivered-To: apmail-jakarta-tomcat-user-archive@apache.org Received: (qmail 57521 invoked from network); 3 Feb 2003 14:15:38 -0000 Received: from exchange.sun.com (192.18.33.10) by daedalus.apache.org with SMTP; 3 Feb 2003 14:15:38 -0000 Received: (qmail 12428 invoked by uid 97); 3 Feb 2003 14:17:06 -0000 Delivered-To: qmlist-jakarta-archive-tomcat-user@nagoya.betaversion.org Received: (qmail 12421 invoked from network); 3 Feb 2003 14:17:05 -0000 Received: from daedalus.apache.org (HELO apache.org) (208.185.179.12) by nagoya.betaversion.org with SMTP; 3 Feb 2003 14:17:05 -0000 Received: (qmail 54664 invoked by uid 500); 3 Feb 2003 14:14:36 -0000 Mailing-List: contact tomcat-user-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Tomcat Users List" Reply-To: "Tomcat Users List" Delivered-To: mailing list tomcat-user@jakarta.apache.org Received: (qmail 54636 invoked from network); 3 Feb 2003 14:14:35 -0000 Received: from mail3.panix.com (166.84.1.74) by daedalus.apache.org with SMTP; 3 Feb 2003 14:14:35 -0000 Received: from 216.126.166.102 (03-102.089.popsite.net [216.126.166.102]) by mail3.panix.com (Postfix) with ESMTP id D1D8498637 for ; Mon, 3 Feb 2003 09:14:33 -0500 (EST) Date: Mon, 3 Feb 2003 09:13:47 -0500 From: Gary McGath Subject: Custom tag life cycle To: tomcat-user@jakarta.apache.org X-Priority: 3 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; Charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailer: Mailsmith 1.5.4 (Blindsider) X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N The webapp which I am developing (see http://www.timeczar.com for details) uses a moderately complex custom tag library, and I've found the lifecycle of a TagSupport object to be very confusing. As I understand it, a TagSupport object may (but is not guaranteed to) be reused for subsequent occurrences of the same tag in a JSP. This means that attribute variables can't safely be initialized in the constructor, because they may not get reinitialized for subsequent occurrences of the tag. (Here I'm assuming that setter functions for attributes simply set an instance variable.) After some digging, I found that the recommended way to reset attribute instance varaibles is to use the doEndTag method. This probably doesn't work if a tag is nested within a tag of the same name, but I can live with that. Doing this works fine in Tomcat. However, I recently ported my webapp to Resin and found that it doesn't work there. Here's a cut-back excerpt from my JSP: - The class which implements eventset includes the tag body once for each event in the set. The evtstartdate and evtenddate tags are implemented by a class called DateTag, which extends TagSupport. Under Tomcat, DateTag.setMode and DateTag.SetLength get called once for each tag in each inclusion of the tag body. Under Resin, only two calls (one for each of the date tags) are made to each of setMode and setLength. If I clear the mode and length fields when I call doEndTag, then all occurrences of the date tags except the first take on their default attributes, which is not the behavior I want. Are both Tomcat and Resin within spec in implementing different behaviors here? If so, what is the correct point in the lifecycle to reset attribute values in a TagSupport object? Gary McGath http://www.mcgath.com/ --------------------------------------------------------------------- To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org For additional commands, e-mail: tomcat-user-help@jakarta.apache.org