We should definitely document the expectations in the design. In this case, the log4j2 code would demand that appenders be thread- safe. "Java Concurrency in Practice" uses class annotations @Immutable, @ThreadSafe and @NotThreadSafe to allow a class to document its thread-safety. It would be possible to have the configuration code detect that a class does not declare itself to be thread safe and to create a wrapper that synchronizes access to the underlying class in a manner similar to the way that java.util.Collections.synchronizedList wraps a list to add synchronization.
That is nifty. Assume it's @NotThreadSafe if not explicitly declared? This is all the power of using interfaces for things.
The specific class names would likely be different since I'd expect appenders in log4j 2.0 to be build by composition than inheritance (see item 14 of Effective Java). That is instead of having an abstract AppenderSkeleton that almost every appender extends, there'd likely be a final class that handles the threshold and filtering issues of an appender which would take a transport plug- in for the "send to event to the destination" behavior.
I agree with the principle of Composition over inheritance. The downside of using a final-class-type-design means that any more complex extensions to log4j2 require a customization of the log4j code. That's probably ok though if the framework provides extension points that cover the standard use cases.
Paul --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
