You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-dev@logging.apache.org by Mark Womack <mw...@apache.org> on 2005/12/22 03:21:04 UTC
log4j 1.3 prioritized tasks
I prioritized the task list from the previous thread. Not all of
these are dependent on each other, but I beleive that we should look
at completing the first 2 before seriously tackling anything else.
The last 4 could happen in any order and most likely in parallel.
Documentation will get setup and then be ongoing.
- Restore binary compatibility, restore as much source compatibility as needed
- Locking/threading/synchronization issues
- Packaging changes
- Build changes (Maven2, etc)
- Review internal message logging mechanism, too verbose right now
- Finalize slf4j support: direct or adapter?
- Documentation - update, get community involved
- JoranConfigurator review
- Plugin/PluginRegistery review and implementation
- Watchdog review and implementation
- Expression language review
I still like the idea of monthly releases. What's there is there when
we build. As Jess voiced, I think the goal of the end-of-January
release should at least be the binary compatibility, maybe even the
sync issue if we can manage it.
Overall goal for the release should be middle of the 2006. This
probably means the first beta version sometime in the April/May
timeframe. I've been very wrong about release timeframes for
everything from 1.2 releases to the last estimate for 1.3, so I am
very open to other suggestions and comments here. The goal is to give
the community time to digest the changes while also moving forward.
Comments? Other tasks? Different prioritization?
-Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: log4j 1.3 prioritized tasks
Posted by Mark Womack <mw...@apache.org>.
http://wiki.apache.org/logging-log4j/Log4j13PrioritizedTasks
----- Original Message -----
From: "Yoav Shapira" <yo...@apache.org>
To: "Log4J Developers List" <lo...@logging.apache.org>
Sent: Wednesday, December 21, 2005 6:29 PM
Subject: Re: log4j 1.3 prioritized tasks
Perhaps this prioritized list belongs on a wiki page where we can
jointly edit it, easily refer to it, mark things as done, etc.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: log4j 1.3 prioritized tasks
Posted by Mark Womack <mw...@apache.org>.
I was pretty tired last night, so maybe my reaction as "shameful" was
a little much. But I still believe there is a lot of room for
improvement that needs to be done.
If you look at the documentation we have, there is the short
introduction (which is old and needs some updating; it doesn't even
talk about xml), the javadoc's (which one has to swim through to make
sense of), a bunch of articles (some good, some ok), and Ceki's book.
The only comprehensive documentation we have is Ceki's book, which
folks have to buy. I don't have problem with there being a book, and
I recommend people buy it, as it is a great book. There's even
another book out there from APress (which maybe se should mention on
our pages as well).
But I think that a good open source project should provide a slightly
higher level of organized, up-to-date documentation than we have,
especially for being as mature of a project as we are.
(And I still haven't given up on the build changes, but I won't drag
the rest of the project into that rat hole with me. "I acquiesce to
the demands of the greater good" :-)
-Mark
On 12/22/05, Yoav Shapira <yo...@apache.org> wrote:
> Hola,
>
> > biased view. But I don't agree with the documentation. We REALLY need to
> > do something. I think our current state is pretty shameful.
>
> I only bundled them together because one of the reasons for moving to
> Maven is improved documentation.
>
> > I'd like to
> > get more community involvement, but there hasn't been much reaction. I'd
> > like to set it up and then have it evolve on its own track. I don't
> > consider it a "pure enhancement".
>
> I actually don't think the docs are shameful, or you'd be seeing more
> involvement from the community and more doc RFEs in Bugzilla. No
> documentation is ever perfect, and there is plenty of room for
> improvement of course, but I think log4j's documentation is not bad
> considering its audience of developers/engineers concerned about
> low-level details like logging.
>
> > But the code cleanup and review should come first.
>
> Yeah, for sure.
>
> --
> Yoav Shapira
> System Design and Management Fellow
> MIT Sloan School of Management
> Cambridge, MA, USA
> yoavs@computer.org / www.yoavshapira.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: log4j 1.3 prioritized tasks
Posted by Yoav Shapira <yo...@apache.org>.
Hola,
> biased view. But I don't agree with the documentation. We REALLY need to
> do something. I think our current state is pretty shameful.
I only bundled them together because one of the reasons for moving to
Maven is improved documentation.
> I'd like to
> get more community involvement, but there hasn't been much reaction. I'd
> like to set it up and then have it evolve on its own track. I don't
> consider it a "pure enhancement".
I actually don't think the docs are shameful, or you'd be seeing more
involvement from the community and more doc RFEs in Bugzilla. No
documentation is ever perfect, and there is plenty of room for
improvement of course, but I think log4j's documentation is not bad
considering its audience of developers/engineers concerned about
low-level details like logging.
> But the code cleanup and review should come first.
Yeah, for sure.
--
Yoav Shapira
System Design and Management Fellow
MIT Sloan School of Management
Cambridge, MA, USA
yoavs@computer.org / www.yoavshapira.com
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: log4j 1.3 prioritized tasks
Posted by Mark Womack <mw...@apache.org>.
Well, one can argue that build changes should be deprioritized. I'm the one
that is using it to do the official builds and releases, so I might have a
biased view. But I don't agree with the documentation. We REALLY need to
do something. I think our current state is pretty shameful. I'd like to
get more community involvement, but there hasn't been much reaction. I'd
like to set it up and then have it evolve on its own track. I don't
consider it a "pure enhancement".
But the code cleanup and review should come first.
-Mark
----- Original Message -----
From: "Paul Smith" <ps...@aconex.com>
To: "Log4J Developers List" <lo...@logging.apache.org>
Sent: Wednesday, December 21, 2005 6:32 PM
Subject: Re: log4j 1.3 prioritized tasks
>
> On 22/12/2005, at 1:29 PM, Yoav Shapira wrote:
>
>> Hi,
>> I'm OK with this prioritation except for one thing: build changes
>> should be just about last, or possibly 2nd to last together with
>> documentation, as they are a pure enhancement and not a must-have by
>> any stretch.
>>
>
> +1 build + site work right now, not elegant, a touch messy, but it works.
> 1.3 has dragged on too long lets focus on it.
>
> Paul
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: log4j 1.3 prioritized tasks
Posted by Paul Smith <ps...@aconex.com>.
On 22/12/2005, at 1:29 PM, Yoav Shapira wrote:
> Hi,
> I'm OK with this prioritation except for one thing: build changes
> should be just about last, or possibly 2nd to last together with
> documentation, as they are a pure enhancement and not a must-have by
> any stretch.
>
+1 build + site work right now, not elegant, a touch messy, but it
works. 1.3 has dragged on too long lets focus on it.
Paul
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: log4j 1.3 prioritized tasks
Posted by Yoav Shapira <yo...@apache.org>.
Hi,
I'm OK with this prioritation except for one thing: build changes
should be just about last, or possibly 2nd to last together with
documentation, as they are a pure enhancement and not a must-have by
any stretch.
Perhaps this prioritized list belongs on a wiki page where we can
jointly edit it, easily refer to it, mark things as done, etc.
Yoav
On 12/21/05, Mark Womack <mw...@apache.org> wrote:
> I prioritized the task list from the previous thread. Not all of
> these are dependent on each other, but I beleive that we should look
> at completing the first 2 before seriously tackling anything else.
> The last 4 could happen in any order and most likely in parallel.
> Documentation will get setup and then be ongoing.
>
> - Restore binary compatibility, restore as much source compatibility as needed
> - Locking/threading/synchronization issues
> - Packaging changes
> - Build changes (Maven2, etc)
> - Review internal message logging mechanism, too verbose right now
> - Finalize slf4j support: direct or adapter?
> - Documentation - update, get community involved
> - JoranConfigurator review
> - Plugin/PluginRegistery review and implementation
> - Watchdog review and implementation
> - Expression language review
>
> I still like the idea of monthly releases. What's there is there when
> we build. As Jess voiced, I think the goal of the end-of-January
> release should at least be the binary compatibility, maybe even the
> sync issue if we can manage it.
>
> Overall goal for the release should be middle of the 2006. This
> probably means the first beta version sometime in the April/May
> timeframe. I've been very wrong about release timeframes for
> everything from 1.2 releases to the last estimate for 1.3, so I am
> very open to other suggestions and comments here. The goal is to give
> the community time to digest the changes while also moving forward.
>
> Comments? Other tasks? Different prioritization?
>
> -Mark
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>
>
--
Yoav Shapira
System Design and Management Fellow
MIT Sloan School of Management
Cambridge, MA, USA
yoavs@computer.org / www.yoavshapira.com
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Concurrency (was Re: log4j 1.3 prioritized tasks)
Posted by Mark Womack <mw...@apache.org>.
Elias, you are proposing that there be a new/different set of "concurrent"
appenders? One that do not suffer from the problem that has been
identified?
-Mark
----- Original Message -----
From: "Elias Ross" <er...@m-qube.com>
To: "Log4J Developers List" <lo...@logging.apache.org>
Cc: "Curt Arnold" <ca...@apache.org>
Sent: Friday, December 23, 2005 4:37 PM
Subject: Re: log4j 1.3 prioritized tasks
> On Thu, 2005-12-22 at 00:46 -0600, Curt Arnold wrote:
>
>> I'd prefer to expedite the 2.0 branch and get log4j using a much
>> finer grained locking than maintaining two parallel sets of appenders
>> with different locking characteristics.
>
> I'd be happy to help expedite a 2.0 release, but it seems ever further
> away. And I anticipate (in six months) you'll find yourself in a
> similarly unpleasant situation for 2.0 where people demand application
> binary compatibility.
>
> It's also likely people are going to want both styles of appenders. You
> Joe Java coder might not understand (or want to learn about) read/write
> locking rules.
>
> A good analogy is how the new JDK 1.5 java.util.concurrent.* collection
> classes did not deprecate existing locked collections classes, nor were
> java.util.Vector or java.util.Hashtable considered for removal.
>
> The concurrent library I proposed is around 1000 lines of new
> code/comments to maintain, compared to about 44,000 lines total for the
> existing log4j code base. Frankly, all I would like from the log4j is
> an endorsement and place in svn, I can maintain and deal with the
> implementation details.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: log4j 1.3 prioritized tasks
Posted by Elias Ross <er...@m-qube.com>.
On Mon, 2006-01-09 at 14:47 -0800, Mark Womack wrote:
>
>
> My question before was if you were suggesting a different set of "fine
> grain" classes that co-exist with the current set of classes?
That was my preferred approach. Adding "fine grained" locking to
AppenderSkeleton seems entirely impossible, without requiring users of
it to basically forgo "synchronized" blocks, in favor of a ReadWriteLock
block instead.
I guess you *could* sort of create something like
if (Thread.holdsLock(foo)) {
// use write lock
} else {
// use read lock
}
in the "doAppend" and maintain compatibility, but "holdsLock" seems
little heavy-weight.
As an example of what code changes a user must make, for example, in the
new WriterAppender:
/**
* Close the underlying {@link java.io.Writer}.
*/
protected void closeWriter() {
getWriteLock();
try {
if (this.writer == null)
return;
try {
// before closing we have to output the footer
writeFooter();
this.writer.close();
this.writer = null;
} catch (IOException e) {
getLogger().error("Could not close writer for WriterAppener named "+name, e);
}
} finally {
releaseWriteLock();
}
}
Original version:
/**
* Close the underlying {@link java.io.Writer}.
* */
protected /* synchronized */ void closeWriter() {
if (this.writer != null) {
try {
// before closing we have to output out layout's footer
writeFooter();
this.writer.close();
this.writer = null;
} catch (IOException e) {
getLogger().error("Could not close writer for WriterAppener named "+name, e);
}
}
}
I also decided that "close", which is a common method for users to
override, and created a separate method. Not sure what the consensus on
style is for making things safer for API users, but I prefer to make
methods like this "final":
/**
* Cleans up this appender.
* Marked as <code>final</code> to prevent subclasses from accidentally
* overriding and forgetting to call <code>super.close()</code> or obtain a
* write lock.
* Calls {@link #internalClose} when completed.
* Implementation note: Obtains a write lock before starting close.
* Calling this method more than once does nothing.
*/
public final void close() {
boolean wasClosed;
getWriteLock();
try {
wasClosed = closed.set(true);
} finally {
lock.releaseWriteLock();
}
if (!wasClosed)
internalClose();
}
/**
* Subclasses must implement their own close routines.
* This method is called by the {@link #close} method.
* This is guaranteed to be called only once, even if {@link #close} is
* invoked more than once.
* Note that further locking is not required, as {@link #append} can no
* longer be called.
*/
protected abstract void internalClose();
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: log4j 1.3 prioritized tasks
Posted by Mark Womack <mw...@apache.org>.
Curt is right. Submitting a CLA and resubmitting the code with proper
ASF headers, etc should be sufficient.
See this link, under "Contributor License Agreements":
http://www.apache.org/licenses/
My question before was if you were suggesting a different set of "fine
grain" classes that co-exist with the current set of classes?
-Mark
On 1/9/06, Curt Arnold <ca...@apache.org> wrote:
>
> On Jan 9, 2006, at 10:29 AM, Elias Ross wrote:
>
> > On Fri, 2005-12-23 at 22:22 -0600, Curt Arnold wrote:
> >
> >> I haven't taken a serious look at the code. But if all the IP issues
> >> are addressed and there are no objections, I'd have no problem having
> >> the contribution in the sandbox. If it then progresses to something
> >> that the community wants in a formal log4j release, then all it would
> >> take is a "svn mv" or two to graft in into the log4j source tree.
> >
> >
> > Hi Curt Arnold and Log4j List,
> >
> > Now that I'm back...
> >
> > So, how might I address the IP concerns and release this into "svn"?
> > Please address me privately, if necessary.
>
> I think that the scope of the contribution is substantial enough that
> having a signed Contributor License Agreement (see http://
> www.apache.org/licenses/) should be on file. The CLA contains
> representations that you have rights to contribute the code, etc.
> After that is on file, then resubmit the contribution attached to a
> bug report (since the CLA would not be retroactive to previous
> submissions).
>
> >
> > I also have a list of miscellaneous fixes that "findbugs" (of
> > http://findbugs.sf.net" located. (Mostly unused variables and other
> > cleanup items.) It may be helpful to integrate this tool into the
> > build
> > as well.
>
> The experimental Maven build currently builds a PMD (http://
> pmd.sourceforge.net) report which may have some functional overlap
> with Findbugs. There did seem to be a Findbugs Maven plugin, but I
> haven't investigated whether it was a Maven 1.x or Maven 2.x plugin.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: log4j 1.3 prioritized tasks
Posted by Curt Arnold <ca...@apache.org>.
On Jan 9, 2006, at 10:29 AM, Elias Ross wrote:
> On Fri, 2005-12-23 at 22:22 -0600, Curt Arnold wrote:
>
>> I haven't taken a serious look at the code. But if all the IP issues
>> are addressed and there are no objections, I'd have no problem having
>> the contribution in the sandbox. If it then progresses to something
>> that the community wants in a formal log4j release, then all it would
>> take is a "svn mv" or two to graft in into the log4j source tree.
>
>
> Hi Curt Arnold and Log4j List,
>
> Now that I'm back...
>
> So, how might I address the IP concerns and release this into "svn"?
> Please address me privately, if necessary.
I think that the scope of the contribution is substantial enough that
having a signed Contributor License Agreement (see http://
www.apache.org/licenses/) should be on file. The CLA contains
representations that you have rights to contribute the code, etc.
After that is on file, then resubmit the contribution attached to a
bug report (since the CLA would not be retroactive to previous
submissions).
>
> I also have a list of miscellaneous fixes that "findbugs" (of
> http://findbugs.sf.net" located. (Mostly unused variables and other
> cleanup items.) It may be helpful to integrate this tool into the
> build
> as well.
The experimental Maven build currently builds a PMD (http://
pmd.sourceforge.net) report which may have some functional overlap
with Findbugs. There did seem to be a Findbugs Maven plugin, but I
haven't investigated whether it was a Maven 1.x or Maven 2.x plugin.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: log4j 1.3 prioritized tasks
Posted by Elias Ross <er...@m-qube.com>.
On Fri, 2005-12-23 at 22:22 -0600, Curt Arnold wrote:
> I haven't taken a serious look at the code. But if all the IP issues
> are addressed and there are no objections, I'd have no problem having
> the contribution in the sandbox. If it then progresses to something
> that the community wants in a formal log4j release, then all it would
> take is a "svn mv" or two to graft in into the log4j source tree.
Hi Curt Arnold and Log4j List,
Now that I'm back...
So, how might I address the IP concerns and release this into "svn"?
Please address me privately, if necessary.
I also have a list of miscellaneous fixes that "findbugs" (of
http://findbugs.sf.net" located. (Mostly unused variables and other
cleanup items.) It may be helpful to integrate this tool into the build
as well.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: log4j 1.3 prioritized tasks
Posted by Curt Arnold <ca...@apache.org>.
On Dec 23, 2005, at 6:37 PM, Elias Ross wrote:
> On Thu, 2005-12-22 at 00:46 -0600, Curt Arnold wrote:
>
>> I'd prefer to expedite the 2.0 branch and get log4j using a much
>> finer grained locking than maintaining two parallel sets of appenders
>> with different locking characteristics.
>
> I'd be happy to help expedite a 2.0 release, but it seems ever further
> away. And I anticipate (in six months) you'll find yourself in a
> similarly unpleasant situation for 2.0 where people demand application
> binary compatibility.
However, the big major version change and a namespace change would
clearly signal that there is no intention of being binary
compatible. I would think that we'd want, where reasonable, to
maintain logging statement and configuration compatibility as long as
you simply changed your import statements. It may be possible to
provide a shim that supports some log4j 1.x applications (log4j
users, not extenders) without recompiling by delegating to the log4j
2.0 classes.
>
> It's also likely people are going to want both styles of
> appenders. You
> Joe Java coder might not understand (or want to learn about) read/
> write
> locking rules.
>
> A good analogy is how the new JDK 1.5 java.util.concurrent.*
> collection
> classes did not deprecate existing locked collections classes, nor
> were
> java.util.Vector or java.util.Hashtable considered for removal.
>
> The concurrent library I proposed is around 1000 lines of new
> code/comments to maintain, compared to about 44,000 lines total for
> the
> existing log4j code base. Frankly, all I would like from the log4j is
> an endorsement and place in svn, I can maintain and deal with the
> implementation details.
I haven't taken a serious look at the code. But if all the IP issues
are addressed and there are no objections, I'd have no problem having
the contribution in the sandbox. If it then progresses to something
that the community wants in a formal log4j release, then all it would
take is a "svn mv" or two to graft in into the log4j source tree.
Hope you all have a wonderful Christmas. I'll be off the list for a
few days.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: log4j 1.3 prioritized tasks
Posted by Elias Ross <er...@m-qube.com>.
On Thu, 2005-12-22 at 00:46 -0600, Curt Arnold wrote:
> I'd prefer to expedite the 2.0 branch and get log4j using a much
> finer grained locking than maintaining two parallel sets of appenders
> with different locking characteristics.
I'd be happy to help expedite a 2.0 release, but it seems ever further
away. And I anticipate (in six months) you'll find yourself in a
similarly unpleasant situation for 2.0 where people demand application
binary compatibility.
It's also likely people are going to want both styles of appenders. You
Joe Java coder might not understand (or want to learn about) read/write
locking rules.
A good analogy is how the new JDK 1.5 java.util.concurrent.* collection
classes did not deprecate existing locked collections classes, nor were
java.util.Vector or java.util.Hashtable considered for removal.
The concurrent library I proposed is around 1000 lines of new
code/comments to maintain, compared to about 44,000 lines total for the
existing log4j code base. Frankly, all I would like from the log4j is
an endorsement and place in svn, I can maintain and deal with the
implementation details.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: log4j 1.3 prioritized tasks
Posted by Curt Arnold <ca...@apache.org>.
On Dec 21, 2005, at 11:36 PM, Elias Ross wrote:
> On Wed, 2005-12-21 at 21:09 -0600, Curt Arnold wrote:
>>
>>> - Locking/threading/synchronization issues
>>
>> I think it will be difficult or impossible to safely address the
>> "locks when trying to log during a toString() call" without
>> potentially breaking somebody else. It is an undesirable
>> established
>> limitation of log4j, but it has existed there for a long time.
>
> The problem in 1.3 is in the AppenderSkeleton class. Have you
> examined
> the proposed Appender implementations in bug 24159, which would allow
> users to avoid deadlocks in 1.3 by reconfiguring their class?
>
I'd prefer to expedite the 2.0 branch and get log4j using a much
finer grained locking than maintaining two parallel sets of appenders
with different locking characteristics.
>> Much of
>> the log4j internals aren't thread safe by themselves and depend on
>> the outer
>> synchronization to keep things safe.
>
> Many of the "internals" are public classes which are not really
> internal at all
> and need proper documentation and/or locking.
>
I didn't mean "internals" to mean that they should be off-limits for
review. I'll be the first to say that way too much of log4j is
visible, way too many non-final methods, non-final classes, mutable
fields, protected fields, etc. They do not need proper documentation
and locking, they need to be rewritten to avoid unnecessary locking.
However, that means changes that aren't compatible with a 1.x branch.
> It is irresponsible to not state or establish the contract or
> convention of how
> a library's public classes can (or cannot) used within multiple
> threads. Even
> though, for example, a "Layout" implementation may not be typically
> used outside
> of a locking context or appender, it is not guaranteed or even
> implied this is
> how it will be used.
Most of the active developers came to the party long after the
initial design decisions. Those decisions seemed to be generally
good ones for their time, but reflect the concerns of the JDK 1.1
era. Then it is a question of our priorities, do we spend a lot of
time trying to document the potential problem scenarios in 1.x, spend
a lot of very complex and error-prone work to tweak the 1.x code to
avoid particular scenarios without breaking existing code or do we
rework the 2.0 branch to eliminate those problems.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: log4j 1.3 prioritized tasks
Posted by Elias Ross <er...@m-qube.com>.
On Wed, 2005-12-21 at 21:09 -0600, Curt Arnold wrote:
>
> > - Locking/threading/synchronization issues
>
> I think it will be difficult or impossible to safely address the
> "locks when trying to log during a toString() call" without
> potentially breaking somebody else. It is an undesirable
> established
> limitation of log4j, but it has existed there for a long time.
The problem in 1.3 is in the AppenderSkeleton class. Have you examined
the proposed Appender implementations in bug 24159, which would allow
users to avoid deadlocks in 1.3 by reconfiguring their class?
>>From the bug:
------- Additional Comment #24 From Elias Ross 2005-12-04 03:56
> My unsubstantiated opinion is that the proposed solution would
> break the locking contract so it can't be addressed in a 1.x branch.
Again, the locking contract only exists for AppenderSkeleton.
Note: Although 99.99% of the users use strings or generally Object.toString()
as their output message, there is nothing to prevent users from using any other
custom object as well. For example, I wrote an Appender a while back that would
accept a data structure which contained (essentially) multiple database columns'
worth of data.
Note 2: Log4j would cause deadlocks for JBoss when a user logged an Object
which triggered a class loading operation. This is because JBoss itself uses Log4J.
Note 3: There is a way with 1.3 to have Log4j render "printf"-style messages.
Currently, Log4J converts it to a string before calling "append", though the
string may or may not be actually logged if a filter is present. (My particular
application uses filtering based on MDC values, I would greatly benefit from
*not* rendering complicated data structures or calculated values from
Object.toString().)
An optimization of this behavior would be to create temporary object like this:
class FormattedMessage {
String msg;
Object param[];
public String toString() { /* format here */ }
}
If the call to FormattedMessage.toString() was called when holding a lock on
AppenderSkeleton, it would greatly increase deadlock potential for statements
such as:
Logger.debug("Object stuff: {}", obj);
Where "obj" itself called Logger.
------- Additional Comment #24 From Elias Ross 2005-12-04 03:56
> Another approach would be to use a thread with a timeout to call toString(). If
> the call blocked, then some message like "Message unavailable timeout while
> calling CLASSNAME.toString() " could be created.
I don't know if there would be any way to "undo" a deadlock condition. Perhaps
you could call "Thread.stop" on one of the deadlocked threads. This has
potential to create additional deadlocks.
> Much of
> the log4j internals aren't thread safe by themselves and depend on the outer
> synchronization to keep things safe.
Many of the "internals" are public classes which are not really internal at all
and need proper documentation and/or locking.
It is irresponsible to not state or establish the contract or convention of how
a library's public classes can (or cannot) used within multiple threads. Even
though, for example, a "Layout" implementation may not be typically used outside
of a locking context or appender, it is not guaranteed or even implied this is
how it will be used.
The JDK used to be somewhat haphazard about this, but it's important to state at
least if a class is thread-safe or not thread-safe. It's also important to
state how locking is performed in the thread-safe case (or not necessary due to
design.)
Of course, users generally expect things to work for their multi-threaded
applications. It's usually good to design with this in mind. If
multi-threaded, unlocked use is dangerous, it needs to be spelled out. (Did you
know that if multiple threads modify and access a java.util.HashMap you can
lock-up one thread? If the user reads the JavaDoc they anticipate bad things
might happen without locking.)
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: log4j 1.3 prioritized tasks
Posted by Curt Arnold <ca...@apache.org>.
On Dec 21, 2005, at 8:21 PM, Mark Womack wrote:
> I prioritized the task list from the previous thread. Not all of
> these are dependent on each other, but I beleive that we should look
> at completing the first 2 before seriously tackling anything else.
> The last 4 could happen in any order and most likely in parallel.
> Documentation will get setup and then be ongoing.
>
> - Restore binary compatibility, restore as much source
> compatibility as needed
>
I've started on parts of it. Obviously would be good to have more
hands if we can coordinate/partition the work. May make a stab at
switching the Level/Priority stuff back around over the next two days.
Binary compatibility will require resurrecting the 1.2
RollingFileAppender and DailyRollingFileAppender, the facades over
the o.a.l.rolling.RollingFileAppender would not be compatibility with
any user extensions.
Anybody want to explain what QuietWriter's were and why the
disappeared in the 1.3 branch?
> - Locking/threading/synchronization issues
I think it will be difficult or impossible to safely address the
"locks when trying to log during a toString() call" without
potentially breaking somebody else. It is an undesirable established
limitation of log4j, but it has existed there for a long time.
Probably should be better documented that any object passed as a log
message cannot call log4j as part of its toString call. The problem
should go away with a finer-grained locking in 2.0.
> - Packaging changes
An combined jar file that is a drop in for log4j-1.2.x.jar would be a
nice addition. The auxiliary jars (log4j-db.jar, etc) should have
the version in them.
> - Build changes (Maven2, etc)
> - Review internal message logging mechanism, too verbose right now
That may need to be addressed as part of the restore binary
compatibility.
> - Finalize slf4j support: direct or adapter?
> - Documentation - update, get community involved
> - JoranConfigurator review
> - Plugin/PluginRegistery review and implementation
> - Watchdog review and implementation
> - Expression language review
>
> I still like the idea of monthly releases. What's there is there when
> we build. As Jess voiced, I think the goal of the end-of-January
> release should at least be the binary compatibility, maybe even the
> sync issue if we can manage it.
>
> Overall goal for the release should be middle of the 2006. This
> probably means the first beta version sometime in the April/May
> timeframe. I've been very wrong about release timeframes for
> everything from 1.2 releases to the last estimate for 1.3, so I am
> very open to other suggestions and comments here. The goal is to give
> the community time to digest the changes while also moving forward.
>
> Comments? Other tasks? Different prioritization?
Full API review needs to be completed before calling it a beta.
Systematic code review of changes between 1.2.x and 1.3 would also be
good.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org