Hi Mike, Regarding the conditional GET support, is there any reason why you don't rely on the built-in support that we provide for Resource subclasses?
For immutable dates, something strange is that we also override after() in the ImmutableDate and delegate it as well. So everything is processed by the same delegate Date instance... Could you write a simple unit test illustrating the issue and attach it to a new bug report? Best regards, Jerome -----Message d'origine----- De : news [mailto:[EMAIL PROTECTED] De la part de Mike Brzozowski Envoye : mardi 27 mai 2008 21:03 A : [email protected] Objet : Possible bug in DateUtils.ImmutableDate Hi, In trying to implement support for HTTP conditional GET I ran across a bizarre bug which seems to be somehow related to the implementation of ImmutableDate. The scene: lastModified is a java.util.Date (also works if it's a java.sql.Timestamp) corresponding to the last modified date for this resource. final Date clientCopy = request.getConditions().getModifiedSince(); // This represents the "If-Modified-Since" header from the client. /* If this condition is true, the server must send a new copy of the resource (HTTP 200) */ // Both of these calls returns inaccurate results, tested in cases where // lastModified is up to 24 minutes after clientCopy if (clientCopy == null || lastModified.after(clientCopy)) { if (clientCopy == null || !clientCopy.before(lastModified)) { // Both of these calls behave as expected. if (clientCopy == null || lastModified.after(new Date(clientCopy.getTime()))) { if (clientCopy == null || lastModified.getTime() > clientCopy.getTime()) { I'm not really sure what's going on, but manually extracting the epoch timestamp using getTime() (and either comparing the dates as longs or constructing a canonical java.util.Date) fixes the problem. FWIW, java.util.Date.after() uses some sort of bizarre internal structures (fastTime and cdate) to get an epoch time in millis, and doesn't call subclassers' implementations of getTime(). My theory is that ImmutableDates, since they store their real date in a delegate, keep the date of their creation in their internal fields (inherited from java.util.Date). java.util.Date.after() probably reads from this data and not the delegate. A better strategy for ImmutableDate might be to keep the Date data inside the object itself and override all the setXXX functions to throw Exceptions. This maintains functional type inheritance.
