I've committed an initial dump of a rework of the apache-log4j-
pattern-layout project into a log4j 2.0 design experiment. The code
is not currently functional, but does compile.
All the new stuff is in the org.apache.logging and derived packages.
org.apache.log4j.* sources should be identical to the pattern-layout
project and similar to the log4j 1.3 source. Package layout is very
preliminary.
Highlights:
Two-phase pipeline on layouts: an initial value extraction step that
would occur on the same thread as the logging request and a
subsequent render step that could be deferred. The idea is that
asynchronous appenders would be implemented by extracting the data
that would be later rendered and not try to preserve the entire state
of the logging event even if much of it is not used.
Attribute based declaration of thread safety: @Immutable and
@ThreadSafe are used to declare thread-safety. If things are
naturally thread-safe, they should declare it and the configuration
code may optimize based on it. If code needs thread-safety, then it
can check for the presence of the attributes and if not there,
externally synchronize the object (see
o.a.logging.core.impl.SynchronizedLayout for example).
Parameterized layouts: Layouts can be parameterized for different
destination types. The most common would be a Layout<Appendable>
which would be the closest analog to org.apache.log4j.Layout. Other
layouts may be Layout<ByteBuffer> for binary layouts or
Layout<org.xml.sax.ContentHandler> for XML layouts. All the
composting, threading and extracting stuff is generic for layouts
regardless of their destination type.
Opaque context: The context of the logging call is provided by a
distinct context object which is should have value semantics. The
nature of the context beyond that is very open ended. The log4j 1.2
LoggingEvent wrapper exposes the NDC and MDC through the context
object. The j.u.l wrapper doesn't provide a context object.
Advanced logging API's could introduce any fancy thing (per thread,
per connection, per user etc) they would like (they would just need
to add the corresponding layouts that interpret it at the back end).
Context may be constant across a large number of logging requests, so
keeping the context as a distinct value object just seems right.
Localization: I've tried to preserve all the localization
capabilities of j.u.l at hopefully little cost when they are not used.
Object messaging: The message is still a plain Object, not a string.
Stock layouts will likely convert it to a string during the
extraction phase, but you could provide your own layout that does
special handling if it is safe for deferred processing.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
