I think it may be better to have a derived Date Format class that safely handles mutlithreading issues instead of fixing the code that uses DateFormat.
As a precedent, this is the approach taken by Log4J and Tomcat. Harmeet ----- Original Message ----- From: Peter M. Goldstein To: [EMAIL PROTECTED] Sent: Friday, June 28, 2002 12:50 PM Subject: Possible Synchronization Issue Hi All, I'm a developer new to the James project. In the process of familiarizing myself with the code base I've found what I believe to be a possible synchronization issue in the org.apache.james.util.RFC822Date, org.apache.james.util.RFC822DateFormat, and org.apache.james.nntpserver.NNTPHandler classes. Basically the issue centers on the fact that the format and parse methods of the java.text.SimpleDateFormat are not thread-safe (they reference a common internal Calendar instance) and so can only be called in a multi-threaded context inside an appropriate synchronized block. Each of these James classes contains one or more static SimpleDateFormats that are referenced by a number of instances in an unsynchronized fashion. Attached are CVS diffs that resolve this problem - by wrapping the format and parse calls in appropriate synchronized blocks. I'm not sure what the process is for a contributor to submit a patch. I'd also like to get someone more familiar with the James source code to review these changes. So I'm sending this to the james-dev distribution list. If this is not the correct procedure, please let me know. Thanks. --Peter -- 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]>
