Only comment I can think of after looking at the code is that the sub-
layout elements (logger, priority, messageLayout etc) don't quite
make senses to me as 'layout's. they are really LayoutElements
rather than a complete layout, but given one _might_ want to simply
have a layout of only one element, your approach does mean you could
use a low-level layout. It's just the names of the classes I guess.
Any reason to choose LogRecord as the name of the interface rather
than come up with a distinct name that doesn't use something from the
jul framework? (there's no reason to use log4j LoggingEvent either).
Paul
On 29/04/2007, at 5:45 AM, Curt Arnold wrote:
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]
Paul Smith
Core Engineering Manager
Aconex
The easy way to save time and money on your project
696 Bourke Street, Melbourne,
VIC 3000, Australia
Tel: +61 3 9240 0200 Fax: +61 3 9240 0299
Email: [EMAIL PROTECTED] www.aconex.com
This email and any attachments are intended solely for the addressee.
The contents may be privileged, confidential and/or subject to
copyright or other applicable law. No confidentiality or privilege is
lost by an erroneous transmission. If you have received this e-mail
in error, please let us know by reply e-mail and delete or destroy
this mail and all copies. If you are not the intended recipient of
this message you must not disseminate, copy or take any action in
reliance on it. The sender takes no responsibility for the effect of
this message upon the recipient's computer system.
