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 woul
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.
> > 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 s
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
On Apr 15, 2007, at 9:34 PM, Paul Smith wrote:
I definitely think that most of log4j2 should be POJOs (plain old
java objects). If we need to have an overarching component
framework like log4j 1.3 had with its Component, Scheduler and the
like, then we should not reinvent the wheel. Ho
I definitely think that most of log4j2 should be POJOs (plain old
java objects). If we need to have an overarching component
framework like log4j 1.3 had with its Component, Scheduler and the
like, then we should not reinvent the wheel. However, I don't want
to prejudge that we need one
On Apr 14, 2007, at 2:57 AM, Paul Smith wrote:
I was thinking that org.apache.logging would be the base package
for new stuff. org.apache.logging.log4j would be the home for a
(at least mostly) source code compatible API. Other stuff that
works with both the log4j API and the java.util
I was thinking that org.apache.logging would be the base package
for new stuff. org.apache.logging.log4j would be the home for a
(at least mostly) source code compatible API. Other stuff that
works with both the log4j API and the java.util.logging API might
be in org.apache.logging.appe
On Apr 13, 2007, at 4:59 PM, Paul Smith wrote:
On 14/04/2007, at 1:11 AM, Curt Arnold wrote:
I've been thinking that it might be good to repackage the log4j
1.3 PatternLayout so that it can be used in conjunction with
existing versions of log4j 1.2.x. The process that I'd see is:
1. Fi
First though, should we sit back ever so slightly and document up
some overarching goals/principles we wish to follow for log4j2 as
well as a general overall high level design, and plan of attack?
Sort of a 'vision' statement?
I'm starting to put together a 'compelling reasons to adopt
On 14/04/2007, at 1:11 AM, Curt Arnold wrote:
I've been thinking that it might be good to repackage the log4j 1.3
PatternLayout so that it can be used in conjunction with existing
versions of log4j 1.2.x. The process that I'd see is:
1. Fix cosmetic Checkstyle/PMD reported problems for Pa
I've been thinking that it might be good to repackage the log4j 1.3
PatternLayout so that it can be used in conjunction with existing
versions of log4j 1.2.x. The process that I'd see is:
1. Fix cosmetic Checkstyle/PMD reported problems for PatternLayout
and associated classes on log4j/tru
12 matches
Mail list logo
