I have a web page that displays two different date/time values. I tried using the datetime format tag to take the long values and convert them to a string format. It works fine the first time in the page, but the second occurrence in the page shows the same date/time value as the first, occurrence, even though the long "parameters" are different. It looks like the format tag is caching this date value after the first request, and is not reading the long "parameter" in the second request.
What servlet container is being used? Do you have a simple example that exhibits this bug? Have you tested this with the latest nightly build of the datetime taglib?
Sorry I didn't give all the details before... Anyway, here they are: Servlet Container: WebLogic Application Server 6.0 with Service Pack 2 Date of Build: I am using the nightly build pull from 07/03/01, but I can bring in the latest build if you think there has been a fix for this. Simple Example: <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <%@ taglib uri="http://jakarta.apache.org/taglibs/datetime-1.0" prefix="dt" %> <HTML> <HEAD> <TITLE> DateTime Format Tag Test </TITLE> </HEAD> <BODY> <P> <dt:format pattern="MM/dd/yyyy hh:mm:ss"> 888888888888 </dt:format> </P> <P> <dt:format pattern="MM/dd/yyyy hh:mm:ss"> 999999999999 </dt:format> </P> </BODY> </HTML> The previous example displays the following output for me: 03/02/1998 08:34:48 03/02/1998 08:34:48 The correct output would be: 03/02/1998 08:34:48 09/08/2001 09:46:39 Do you see anything I am doing wrong? Does this example work for you (in your servlet container)? Thanks for your help! Rob
The example you provided works fine for me in Tomcat. This appears to be a bug in WebLogic where it is reusing the body content for the dt:format tag. Try formatting them this way and see if it helps: <dt:format pattern="MM/dd/yyyy hh:mm:ss">888888888888</dt:format> Also try downloading the latest nigthly build. I have made some changes in the last week to the taglib.
I brought in the latest nightly build (7/13/01) and reformatted the entry the way you suggested (no newlines). Still doesn't work. I'll go ahead and send this in to WebLogic support to let them know they have an apparent bug in their TagHandler. Thanks for your help! Rob
I pulled in the source so that I could put in some print statements and see exactly where the failure was occurring (i.e. print out the BodyContent value to see if the WebLogic Server was caching it). As it turns out, the problem is that after the first invocation of the format tag, the date attribute is being set (by creating a new date object with the long value of the BodyContent field). The next time the tag is called in the JSP page, the value of date is already set, so the tag does not recreate a new Date object with the long value contained in BodyContent, but rather just reuses the date object already created. I looked in the spec (JSP.5.4.2), and it states that once "properly set, these properties are expected to be persistent, so that if the JSP container ascertains that a property has already been set on a given tag handler instance, it need not set it again." It is a little vague about exactly which properties it is talking about (properties in the Tag interface as well as other properties), but even further down it discusses that once release is called, all properties are assumed to be reset to an unspecified value. The execution trace in the life-cycle section (JSP.5.4.7) also seems to indicate reuse of these values between tag invocations (at least on the same JSP page). For whatever reason, it appears that the Tomcat server is resetting this date value to null between invocations, but the WebLogic Server is retaining the value for the date attribute between tag invocations (on the same page). The example in the spec seems to lean toward the WebLogic implementation, but I don't know if the spec is really clear enough to say for sure how this needs to be implemented. In either case, I believe that it will work fine for either implementation if the date field were to be specifically reset to null after the date information was printed out to the JSP page (in the doEndtag() section). Does this sound reasonable to you? Thanks! Rob
Thanks to Rob, the bug was found and fixed and is available in the Version 1.0 Beta 1 release.