I think that use fits within the description of project sandboxes
in the Apache Labs bylaws (http://labs.apache.org/bylaws.html). I
think it is highly beneficial that even the exploratory code is
done in public view, false starts and all.
Yes, I see what you're saying, commit to svn for public consumption,
but that might not actually be the 'working' trunk of log4j20. One
might commit to some off-trunk _dev branch to show progress and for
review, and then merge back into the mainline once finalized. If the
changeset is small, I'm personally happy to review patches (we do
this all the time at Aconex with pre-checkin reviews), but given
we're so locationally disparate a combination of the svn spam plus
the raw code checked into a review branch is a good idea I think.
For the initial work around layouts, I'm believe that layouts
should not depend on any external synchronization and should have
no or minimal need for internal synchronization. The configuration
classes around appenders would require synchronization, but the
actual working appender classes should not depend on any external
synchronization. Many classes of appenders will need to be
synchronized at some point on a shared resource (a file for
example), but the framework should allow fully concurrent appenders
(for example, an appender that simply discards messages should not
require any synchronization).
So, we'd need to document that Appender & Layout 3rd party developers
would need to design for thread-safety? That log4j2 would not
guarantee thread-safety on the call to the layout/appender?
The java.util.logging API has been part of the JDK since 1.4.
log4j 1.2 offers a much richer set of appenders, layouts and
configuration options than available for java.util.logging. I
think it would be desirable that log4j 2 be designed so that it
is trivial to use the log4j 2 appender set with the
java.util.logging API for the users who are satisfied with that
API. Current approaches to bridge the log4j and
java.util.logging world require constructing a new
o.a.l.spi.LoggingEvent from info extracted from a
java.util.logging.LogRecord. I'd hope the log4j 2.0 design could
accomplish the same goal without having to do the brute-force
copying.
That is quite a worthy goal, but only time will tell how practical
that might be. I'm not sure we should restrict the design of
anything to accommodate this, but certainly have it in the back of
our minds.
It is pretty high on my list of design goals. I think it is
achievable but will give it up if it proves untenable, but I hate
to be beaten by a problem.
In the scheme of things though, a simplified/rock solid design should
probably win over complex design to accommodate edge-case features
that can be worked around. If we decide that LoggingEvent becomes an
interface, then creating a delegate anonymous class wrapper of
LogRecord becomes a trivial case with minimal overhead (cost of
method call)?
Paul
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
