On Apr 16, 2007, at 1:33 AM, Paul Smith wrote:
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.
Otherwise you end up with fairly big features developed in isolation
and then dropped on the community. At that point, it would be pretty
easy to resist suggestions and alternatives since you've already got
it working and it would be hard to change.
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?
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.
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)?
Making a low-cost bridge between log4j 2 and java.util.logging would
require that LoggingEvent be an interface not a concrete class.
However, I think that would be the right decision anyway. At the
point you start interacting with a LoggingEvent, you have a very high
likelihood of actually formatting the event and writing it
somewhere. The performance difference between interface calls and a
concrete class calls should be vanishingly small compared to IO
overhead. On the other hand, you'd want to much more carefully
consider the performance hit of interface calls on Logger.
On Apr 16, 2007, at 2:46 AM, Wyss Patrick wrote:
just a small thought:
as threadsafe programming seems to be a problem for lots of
programmers it would be certainly a good idea to provide some
AppenderSkeleton and SychronizedAppenderSkeleton. actually i even
think the naming should rather be the other way round with
syncronized appenders as 'default' starting point: AppenderSkeleton
and 'UnsychronizedAppenderSkeleton' (obviously i'm not nativ
english speaker ;-) )
I agree that many appenders need synchronized access to a resource
and as much as possible of the common aspects of that behavior should
be provided by the framework.
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.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
