--- Jacob Kjome <[EMAIL PROTECTED]> wrote:
>
> Elias,
>
> Are you making sure to apply some of the fixes to
> the 1.2 branch? You mentioned you fixed this on
> the trunk, but it was specifically reported
> against 1.2.xx and is blocking the 1.2.15 release
> tracking issue [1]. I haven't c
--- Curt Arnold <[EMAIL PROTECTED]> wrote:
>
> Many of the dependencies have licenses that prohibit distribution.
Can we simply include those that do allow distribution?
The only one I can think of would be the Sun Java ones. Times are a
changing, though, e.g.
April 19, 2006
> JavaMail is now
I have finally started to code, and I'm not too keen on downloading or
locating the various 10 or so libraries to build Log4j. I propose we simply
copy the appropiate .jar files for building into a "thirdparty" directory and
include all the licenses, etc. This is what many other projects do, I do
Hi,
I would like the user ID eross or eliasross.
I accept the invitation graciously. While I don't really want to be soley
responsible for releasing 1.3, I will do my part to judiciously assist the
project. Hopefully those of you with more experience will be kind enough to
guide me if I do st
--- Thomas Raddatz <[EMAIL PROTECTED]> wrote:
> The first time it hurts. ;-)
>
> Thanks Scott. That was the missing piece of the puzzle.
I haven't taken a look at the patch, but I do know people are more receptive
if the patch is broken into files (to be easily viewed).
As a point of discussio
--- Jacob Kjome <[EMAIL PROTECTED]> wrote:
> Excellent. Have you signed the Contributors License Agreement (CLA)
> found at?...
> http://www.apache.org/licenses
Yes, I believe I have.
Do you Yahoo!?
Ever
--- Jacob Kjome <[EMAIL PROTECTED]> wrote:
> Elias, are you
> volunteering? Users like Kay Abendroth, who has been extremely busy
> the last couple days canvassing Bugzilla reports, may be what we need
> to move things along.
I'm volunteering.
I'd like to 1.3 released within my lifetime :-)
issues you're talking about, do they have patches attached
> in Bugzilla?
>
> Yoav
>
> On 11/12/06, Elias Ross <[EMAIL PROTECTED]> wrote:
> >
> > Perhaps the committers left for a sabbatical, but I was wondering if
> Log4J
> > development is still
Perhaps the committers left for a sabbatical, but I was wondering if Log4J
development is still continuing and who is in charge.
In particular, there are a lot of outstanding bugs and changes I'd like to
get in source control.
The impression I get from reading e-mails from the list is this proje
Hello again!
Thanks for moving my "concurrent" branch over to the trunk.
I've been working on adding more unit tests, these are attached to bug 24159.
I haven't measured code coverage, but coverage should be pretty decent.
I also worked on a RollingFileAppender implementation. To get this to wor
On Thu, 2006-07-13 at 14:09 -0700, Elias Ross wrote:
> This should get you the source.
>
> svn co http://svn.apache.org/repos/asf/logging/sandbox/log4j/concurrent
> log4j-concurrent
>
> I'd like to put out a vote in the next week. I would appreciate your
> help.
On Wed, 2006-07-05 at 14:05 -0700, Elias Ross wrote:
> Does anybody have comments pertaining to the migration itself?
Are there any comments about the migration? Any comments about the
source.
This should get you the source.
svn co http://svn.apache.org/repos/asf/logging/sandbox/lo
On Fri, 2006-06-30 at 22:50 -0500, Curt Arnold wrote:
>
> I'd be very reluctant to change the default value of a significant
> configuration parameter. However, if we were to consider it, I'd
> suggest filing a distinct bug and calling for a separate vote.
>
I will file a separate bug for
On Wed, 2006-07-05 at 09:27 -0700, Chad LaVigne wrote:
> I've attached the source code, a test class and a log4j configuration
> file that utilizes the filter. Please let me know if you have any
> questions or comments.
Just a couple of comments...
It might be nice to call it what it is used fo
This thread is to discuss adding a "concurrent" library to the Log4j
"trunk".
I wrote this library primarily to avoid deadlock situations as explained
in bug 24159. In addition to avoiding deadlock situations, I believe
the bug 33855 explains the reason for wanting to provide a "concurrent"
appe
On Wed, 2006-06-28 at 12:34 -0500, Curt Arnold wrote:
>
>
> Elias, I would appreciate your reviewing bug 33855 and see if it
> should be marked as a dup of 24159. You did submit some patches
> against 24159, but I believe the patches in 33855 obsoleted them.
Actually, it's the other way aro
On Wed, 2006-06-28 at 00:04 -0500, Curt Arnold wrote:
> My personal feeling is that 1.3 is in a no-win situation. Backwards
> compatibility was not rigidly enforced during development. While
> there has been some success reworking the code to be compatible with
> 1.2.x, I do not think that
On Sat, 2006-02-25 at 22:48 -0500, Yoav Shapira wrote:
> And it'd be interesting to see a comparison of your tool to checkstyle
> and PMD, both fairly well-established and good tools for the same
> purpose...
The "findbugs" tool is another possible tool to use and also catches
possible locking and
On Thu, 2006-02-23 at 11:31 -0600, Jess Holle wrote:
> I'd be fine with requiring Java 5 for log4j 1.3 and using the best
> concurrency, etc, utilities it has to offer.
Ah, "concurrency" -- my favorite Log4j word... I can't really see what
Java 5 would provide in terms of better concurrency oth
Thanks for checking in my concurrent library.
There's a bunch of little unrelated changes, you found some already I
noticed.
If you have any questions about the .diff for bug 24159 let me know.
Here are some reasons for some changes:
src/java/org/apache/log4j/FileAppender.java
Setting buffere
On Mon, 2006-02-06 at 13:02 -0600, Curt Arnold wrote:
> On Feb 6, 2006, at 12:40 PM, Mark Womack wrote:
>
> > Yep. Thanks, Curt.
> >
> > So, we had talked about putting Elias' new stuff in the sandbox. Are
> > we still good with that as a start?
> >
> > -Mark
>
> I'm good with it and could take
I've been waiting to contribute some code for Log4j 1.3 and was told to
send a signed a ICLA document. I faxed and later snail-mailed my ICLA
(http://www.apache.org/licenses/icla.txt) but haven't heard back. I e-
mailed [EMAIL PROTECTED] and haven't head back.
Is there a phone number I might ca
On Thu, 2006-01-12 at 12:33 -0800, Scott Deboy wrote:
> I may be in the minority (I'm sure I am), but slf4j's change to
> require logger.debug(string) instead of object may have a performance
> rationale
One thing I like the log4j design, was being able to log non-string
objects. I've used it
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 imp
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 wa
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
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
On Fri, 2005-12-02 at 09:32 -0800, Mark Womack wrote:
> So, I don't remember if anything specific has already been applied to
> 1.3 for the deadlock issue (Elias can speak to that better probably).
Nothing in particular was applied. (I don't have commit access to apply
changes either to effectu
On Thu, 2005-12-01 at 10:22 -0600, Curt Arnold wrote:
>
> I have suggested targeting Java 5 in log4j 2.0. However, I plan on
> experimenting with substantially reducing the scope of locks in
> log4j
> 2.0 instead of just incrementally using new locking features with
> the
> current approach
You really have a user question. Take a look at Logger.forcedLog and
also LoggerFactory.
It does raise the question, why can't LoggerEvent hold an instance of
Thread? (Of course, as part of de/serialization, it would no longer
have it.)
On Tue, 2005-11-29 at 16:21 +0530, George Sebastian wrote
On Mon, 2005-11-28 at 14:07 -0600, Jess Holle wrote:
>
> What is breaking so much source code and many existing binaries really
> buying?
In my opinion, removing "Category" would be just like Sun deciding to
remove "java.util.Emumeration" or some other classes now marked as
"deprecated."
I know
On Fri, 2005-11-04 at 09:19 -0800, Mark Womack wrote:
>
>
> I would much rather get on with 1.3 and do it the right way there.
I'd rather we think of something better for 1.3 than waste time spinning
on this problem for 1.2.
You may be able to change every class in log4j to have more fine gra
For your information: Log4j has the potential to create deadlocks at
the message rendering step. The JBoss team has been working on fixing
this issue.
http://jira.jboss.com/jira/browse/JBAS-2393
Scott Stark is trying two approaches. One is to fix the synchronization
code used in log4j 1.2.12
On Fri, 2005-10-21 at 11:42 +0200, [EMAIL PROTECTED] wrote:
> The attached appender does exactly this job. It caches the last x events
> in memory and passes them to other appenders only in case of an logging
> event of a defined level (e.g. ERROR).
It's a nice idea, but there's some code formatt
On Thu, 2005-08-25 at 23:27 -0500, Curt Arnold wrote:
> +1
>
+1
Incidentally, I do want to see my concurrent patches in 1.3 sometime.
Thanks.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL
On Tue, 2005-07-26 at 09:49 -0700, Mark Palmer wrote:
> My code and needs to be common/lib (i.e. don't want to
> modify the web application war file in any way)
>
> This means log4j needs to be in common/lib as well.
This is more of a user question (and a FAQ really), but here's an idea
I'd lik
On Thu, 2005-07-14 at 17:25 -0500, Curt Arnold wrote:
>
> I agree that it is too potentially disruptive to attempt in 1.2.x.
> I'm not ready to commit to doing it in 1.3, however. log4j currently
> does fairly coarse synchronization which has been raised as an issue
> repeatedly (the whole
On Thu, 2005-05-19 at 13:14 +0200, Endre StÃlsvik wrote:
> Why don't you, as I've asked a dozen times before, ask your user-community
> to vote about this, instead of just bulldozing over them??? The fantastic
> logging-framework that log4j is, isn't really useful IN ITSELF, people use
> it WITHIN
On Tue, 2005-05-17 at 10:02 +1000, Paul Smith wrote:
> 24159 - Deadlock prevention - I appreciate the intent of trying to
> solve this curly one, but it's going to be a tough one to test and
> get right. Just flagging this one has a high risk item.
To fix it requires changes to the AppenderS
On Mon, 2005-05-16 at 09:53 -0700, Mark Womack wrote:
> I figured that a "[VOTE]" message would get folks more interested in
> discussing. :-) Here is proposal #2.
Sounds good. (Sounds like my proposal.)
-
To unsubscribe, e-m
On Wed, 2005-05-11 at 22:05 -0700, Mark Womack wrote:
> 1) Release 1.2.11 with JMS build fix, maybe some other critical fixes
> (action item: determine the other fixes). Timeframe is almost immediate,
> within the next 2 weeks.
Agree.
> 2) Abandon the 1.3 version number, the main branch becom
On Wed, 2005-03-16 at 09:47, Ceki GÃlcà wrote:
> Toly,
>
> Thanks for bringing up this point. You've made quite a convincing
> case.
It appears that java.lang.Throwable is serializable, so even with remote
debugging or logging, it should be included as part of a serialized
ThrowableInformation.
On Fri, 2005-03-04 at 11:28, Harper, Allen (AHARPER) wrote:
> We are heavily multi threaded.
The same thing can happen when log4j is rendering the the log message
and you perform a log event.
Refer to bug 24159, I imagine this is somewhat the same flavor of
deadlock.
I'm working on a concurrent
On Thu, 2005-02-24 at 10:41, Ceki GÃlcà wrote:
> Hi Mark,
>
> I'd like to see log4j released for around June of this year. As such, log4j
> needs to enter into a consolidation and testing phase. There are a number
> of issues that need to be resolved. Here is a non-exhaustive list:
I'd like to
On Mon, 2005-01-31 at 16:27, Curt Arnold wrote:
> and these messages were dispatched to two distinct appenders (possibly
> of different types) and that one instance of Chainsaw was listening to
> both, it could determine that which logging events came from the same
> iteration of the loop.
An
On Mon, 2005-01-31 at 14:53, Curt Arnold wrote:
> So I think that users
> will just have to accept that messages in the log from a multithreaded
> application may appear in a slightly different sequence than the
> requests were made.
Which is sort of the reasoning behind having the appender ge
On Mon, 2005-01-31 at 12:03, Ceki GÃlcà wrote:
> At the time log4j was written there was no readResolve() method.
Here's my patch for it. It will even work for subclasses of Level.
Index: src/java/org/apache/log4j/Level.java
===
RCS
Is there some reason org.apache.log4j.Level is not serializable? The
class java.util.logger.Level is...
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
On Sat, 2005-01-29 at 01:34, Curt Arnold wrote:
> Sorry, A committer who blindly checked in code they hadn't reviewed
> would likely not remain a committer for long. Actually, they would
> more likely get very hostile emails. If anyone in the community is
> just dying to use your patches, the
On Fri, 2005-01-28 at 11:45, Curt Arnold wrote:
> I think that we are all fans of concurrency here. Any hesitancy is due
> to caution or overwork, not interest.
Thanks for taking the time to reply. I don't want to interfere with any
high priority items for the log4j team at this time. Over e-
http://www.gotw.ca/publications/concurrency-ddj.htm
>From the article:
> Concurrency is the next major revolution in how we write software.
> Different experts still have different opinions on whether it will be
> bigger than OO, but that kind of conversation is best left to pundits.
> For techn
I already sent out a few e-mails on working on a concurrent logger and
possibility of performance gains using a different locking strategy. I
have been trying to reconcile if my design change had any impact on
performance. I felt that I wasn't measuring the impact of my changes
correctly.
Have
On Sat, 2005-01-22 at 10:41, Ceki GÃlcà wrote:
> Hi Elias,
>
> I had a cursory look at the code. It looks pretty good.
>
> Although it may be my suggestion to begin with, comparing
...
That's what you asked for from your original...
You can run the other test you want.
Anyway, if you wanted re
On Sat, 2005-01-22 at 04:58, Ceki GÃlcà wrote:
>
> Since what you are doing is not clear, your enthusiasm, although nice to
> see, is hard to share.
Here are the files plus a patch to the pattern layout classes.
(Modifying the layout classes to be thread-safe was a separate step.)
It's still a
Here's another interesting thing I got out of another tool I have that
measures thread contention.
This is comparing the concurrent versus non-concurrent WriterAppender
versions, doing the same test 10 times, each test 5 threads writing 1000
times each: (Code available if curious) (Single proce
On Thu, 2005-01-20 at 10:12, Ceki GÃlcà wrote:
> Elias,
>
> Thank you for your proposal. Would it possible for you to backup your
> proposal with prototype code? I'd be very interested in a comparative
> study between an Appender using the current concurrency model and an
> Appender following your
I am proposing creating a "shadow" package called
org.apache.log4j.concurrent that contains many of the same classes, such
as AppenderSkeleton, FileAppender, etc. but allows multiple threads to
append at the same time. Most of the inspiration for such a project
comes from work done by the java.ut
I would keep log4j.jar as-is (except maybe chainsaw) for easy
compatibility, then create a log4j-core.jar that has no appenders that
depend on third party software and then package these remaining
appenders in log4j-ext.jar (or log4j-smtp, jms, etc.) as you describe
below.
> On Thu, 13 Jan 2005 1
On Thu, 2004-12-30 at 09:49, Ceki GÃlcà wrote:
> Hello Elias,
>
> Currently, the sequence counter is managed per copy of the
> LoggingEvent class. If multiple logging repositories share the same
> log4j.jar file, then they will share the same sequence counter. I
> suppose the
On Thu, 2004-12-30 at 03:03, Ceki GÃlcà wrote:
> You couldn't possibly the sequence counter incremented within
> LoggingEvent to detect dropped messages. First, sequenceCounter is a
> class static variable shared by all LoggingRepositories within a JVM,
> all of which increment the
On Tue, 2004-11-02 at 14:45, Paul Smith wrote:
> Actually, I was thinking along the lines of:
>
>logger.debug("My name is {1}. I am {0} years old", new Object[]{new
> Integer(30}, "Paul"});
I would support both "{}" and "{#}" formats.
In code that I write, I use this sort of construct:
cla
On Thu, 2004-09-23 at 01:59, Ceki GÃlcà wrote:
> Some would say heavy-handed, others would say simple and robust. Given
> the history of this discussion (see bug report 24159), I have a strong
> bias against modifying the existing synchronization code in
> AppenderSkeleton. The problem in 24159 i
On Wed, 2004-09-22 at 16:17, Paul Smith wrote:
> We have the AsyncAppender already, unless ConcurrentAppender does something
> different?
I suppose the main difference would be that you would be appending in
the same thread that you executed the log statement in. Each thread
would be writing to
On Wed, 2004-09-22 at 14:42, Paul Smith wrote:
> This would be worth attaching to a Bugzilla ticket so it can be
> analysed properly without getting lost. If you could write a TestCase
> that shows how the current implementation deadlocks, and how this one
> does not, it will help tremendously.
>
I tried using read-write locks and other techniques, which do indeed
work but are not really backwards compatible, but I think the best
solution I came up with is this: (you can refer to the diffs against CVS
as well)
1. While synchronized, check on the threshold
2. Call getRenderedMessage(), i
On Fri, 2004-09-17 at 11:51, Ceki GÃlcà wrote:
> Do you realize that the main reason for synchronization in doAppend method
> is avoiding simultaneous writes to the same output device? Any write
> operation which is not synchronized (or otherwise protected against
> simultaneous access) is a big
On Fri, 2004-09-17 at 11:35, Elias Ross wrote:
> If this is a concern, you might want to create some sort of semaphore so
> that when an event is being logged, the appender state can't be
> affected. However, as many concurrent events can be logged at the same
> time.
>
In
On Fri, 2004-09-17 at 10:40, Ceki GÃlcà wrote:
> Elias,
>
> How are your changes compatible with log4j 1.3 where layouts write directly
> to the output stream without intermediary String objects?
It would seem the same issue would occur if an appender is locked when a
layout is writing directly
I had a created a way to avoid a deadlock condition when Appender is
holding on to a lock and rendering an object. In some situations,
attempting to log during a toString() causes this. Refer to to Bugzilla
bug:
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24159
To understand why this is
On Thu, 2004-04-15 at 05:27, Robert Pepersack wrote:
> Hi all.
>
> I have an abstract class that has many subclasses. There are several options:
>
> 1. Declare it in the abstract class using the String name of the abstract
> class. For example:
>
> protected static final Logger logger =
+1
Personally, I think the TRACE feature is dubious at best. If it was me
writing for myself, I'd say -1, but if it makes the user base happy and
if log4j is truly user-driven, then let's do it. It's not going to do
much harm for the rest of us who don't need it. (But I would have to
draw the
On Thu, 2004-02-12 at 07:12, zze-ironman LIGNE E ext DvSI/SIReS/GRE
wrote:
> Just modified NDC so as it uses a ThreadLocal as ht instead of a
> Hashtable
> with the threads as keys. This acts functionally equivalent, but no
> longer need for lazy-references removal (lazyRemove method) as
> ThreadL
On Tue, 2004-01-27 at 22:58, Elias Ross wrote:
> Level ALWAYS = new Level(ALWAYS_INT, "INFO", 7);
Okay, looking at the JavaDoc, Level doesn't have a public constructor.
Why not? At first glace it didn't make a whole lot of sense. I then
realized it must have been
On Tue, 2004-01-27 at 18:43, Sheward, Barry wrote:
> Hi,
>
> We use Log4J extensively and find that sometimes we always want to log a message,
> but the message is simply for informational purposes. Using
> Logger/Category.fatal() would potentially frighten users,
You could use a custom Level
74 matches
Mail list logo
