Hello, I was looking at the source code of Log4JLogger and it seems to me that it may not be thread safe after deserialization.
The implementation holds a transient variable called logger which is initialized at construction time. There is no synchronized access to the logger variable anywhere in the class. The classes encapsulates all access to the logger variable via the getLogger() method which optionally initializes it if it's null. Since the logger variable is transient, when a Log4JLogger instance is deserialized, the logger variable will be null and thus reinitialized the next time getLogger() is called. If a Log4JLogger instance is held as a static variable in a containing class (a standard commons logging pattern), it would be possible for two threads to call getLogger() at the same time which could lead to a thread unsafe scenario since getLogger() is not synchronized. Even if the underlying log implementation is thread safe (which Log4J is), this class accesses and stores a reference to its returned logger in a thread unsafe way. Unless I'm missing something, it seems this class should protect access to the logger variable if it is to be dynamically created via getLogger() or override the readObject() method so that it's created during deserialization (which I'm assuming would be thread safe as the JVM would release the instance for use until it had been completely deserialized). Chris --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
