james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Peter M. Goldstein" <peter_m_goldst...@yahoo.com>
Subject RE: Possible Synchronization Issue
Date Tue, 02 Jul 2002 05:56:21 GMT

Harmeet,

While I don't necessarily disagree with the notion behind the suggested
approach, I can't find the precedents you reference.  I'm especially
confused because, as I understood it, the declaration of a number of
methods in SimpleDateFormat and DateFormat as either final or private
makes the inheritance you describe difficult to pull off.

The Log4J helper classes (package org.apache.log4j.helpers)
ISO8601DateFormat, RelativeTimeDateFormat, and AbsoluteTimeDateFormat
all fail to implement an appropriate parse method.  As we use parse in
the James code base (specifically the NNTPHandler class), these classes
do not meet the requirements for use in James.

Examination of the Tomcat 4.0 source base reveals extensive use of
java.text.SimpleDateFormat with in-situ locking (or lack thereof).
There are a number of classes that appear to do some form or another of
DateFormat functionality, mostly via unsynchronized delegation to
composite SimpleDateFormat objects.  These include use of the
org.apache.catalina.util.DateTool class (essentially a repository for a
set of commonly used SimpleDateFormat objects).  The notable exception
is the org.apache.catalina.util.FastHttpDateFormat class, which has
internal synchronization of a composed SimpleDateFormat object.  This
class doesn't expose the full capabilities of the internalized
SimpleDateFormat object (which is not a problem), nor the signature
(which is not a problem).  But it doesn't extend DateFormat (which is
not a problem).  Of all these, the one that comes closest to what you
describe is FastHttpDateFormat although it doesn't inherit from
java.text.DateFormat.  Please let me know if I've missed something,
because I'm not really familiar with the Tomcat source base.

As I see it, the notion behind your suggestion is correct - we don't
want the clients of the date format classes to have to worry about
synchronization.  Let me make a specific counter suggestion that I think
will address your concerns.

1. Introduce a new interface org.apache.james.util.SimplifiedDateFormat
that lays out the basic methods we want from a date formatting class.
These methods will be a subset of the methods of the DateFormat class.
This interface is attached.

2. Introduce several classes that implement this interface.  These
classes will not inherit from java.text.DateFormat.  These classes
include a SynchronizedDateFormat, which wraps an internal DateFormat in
synchronized blocks.  Other classes include RFC2980DateFormat,
RFC977DateFormat, and a modified version of RFC822DateFormat.  All of
these classes are thread safe.  They are attached.  The first two are
designed to handle the date formats associate with NNTP and described in
RFC 2980 and RFC 977 respectively.  The RFC822DateFormat also includes
the previously present static method toString(Date d) to preserve
backwards compatibility.

3. Change RFC822Date so it delegates to RFC822DateFormat for its format
method.  In truth RFC822Date isn't a great idea.  The only place we use
it in the code is to generate a string representing 'now' in the
appropriate format.  This is just syntactic sugar for
RFC822DateFormat.toString(new Date()) and as such is somewhat
superfluous.  So we deprecate the class, but leave it intact.  This
approach ensures that anyone using this class in mailets and what not is
left with correctly functioning code.  That diff is attached.

4. Replace references to RFC822Date in the assorted classes (there are
three references) with RFC822DateFormat.toString(new Date()) as
described above.  Those diffs (NotifyPostmaster.java.diff,
NotifyPostmaster.java.diff, Redirect.java.diff) are attached.

5. The NNTPHandler should be altered to contain an instance of each of
RFC977DateFormat and RFC2980DateFormat in preference to the current use
of composed SimpleDateFormat objects.  A diff for NNTPHandler is
attached.

6. Change org.apache.james.core.MimeMessageWrapper to use
RFC822DateFormat instead of a synchronized wrapped
javax.mail.internet.MailDateFormat.  This unifies the code.  The
relevant diff is attached.

This is a complete set of changes that fully resolve the thread safety
issues without requiring client classes to implement their own
synchronized blocks.  Your thoughts?

Note that I altered the RFC822DateFormat class (and hence the RFC822Date
class) so that it uses the javax.mail.internet.MailDateFormat class for
formatting.  Comments in this source file indicated a reluctance on the
part of previous authors to do this, but this made little sense to me as
the core classes were employing the MailDateFormat class. 

--Peter



Mime
View raw message