On Feb 24, 2005, at 7:25 PM, Paul Smith wrote:
Ahhh, I thought I'd forget something. Hi infrastructure, is it
possible for us to please have '[EMAIL PROTECTED]'
configured to go to the log4j-dev list?
Done.
Roy
-
To unsubs
Curt and Ceki,
Curt Arnold apache.org> writes:
>
> Actually, looking at the Gump messages in the Hivemind mailing list
> suggest that the problem was all along the lack of an activateOptions
> call before adding an appender and was never the addition of
> isClosed(), isActive() and activa
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at [EMAIL PROTECTED]
Project logging-log4j-chainsaw has an issue affecting its community integration.
This iss
At 09:41 AM 2/25/2005, Knut Wannheden wrote:
Curt and Ceki,
Curt Arnold apache.org> writes:
>
> Actually, looking at the Gump messages in the Hivemind mailing list
> suggest that the problem was all along the lack of an activateOptions
> call before adding an appender and was never the addition of
ceki2005/02/25 05:42:42
Modified:src/java/org/apache/log4j AppenderSkeleton.java
Appender.java
Log:
We already have a strategy ensuring backward compatibility, no need to make
things even more complicated.
Revision ChangesPath
1.39 +13 -3
ceki2005/02/25 05:44:37
Modified:src/java/org/apache/log4j WriterAppender.java
AsyncAppender.java
src/java/org/apache/log4j/varia ListModelAppender.java
ListAppender.java NullAppender.java
src/java/org/apac
ceki2005/02/25 05:45:22
Modified:tests/src/java/org/apache/log4j WriterAppenderTest.java
FileAppenderTest.java ConsoleAppenderTest.java
VectorAppender.java AbstractAppenderTest.java
tests/src/java/org/apache/log4j/perform
ceki2005/02/25 05:46:02
Modified:testsbuild.xml
tests/integration/src/java TestAppender.java
Log:
We already have a strategy ensuring backward compatibility, no need to make
things even more complicated.
Revision ChangesPath
1.101 +191 -192 lo
ceki2005/02/25 05:49:00
Modified:src/java/org/apache/log4j Hierarchy.java
Log:
Reducing verbosity.
Revision ChangesPath
1.62 +2 -2 logging-log4j/src/java/org/apache/log4j/Hierarchy.java
Index: Hierarchy.java
===
Curt,
I'd like to keep things simple and stupid. Imagining and implementing
solutions for problems that do not exist makes the code hard to maintain.
We already have a strategy for preserving backward compatibility which is
both extremely simple and robust. More sophisticated solutions need to b
I saw these LogLog calls when looking into some of the deprecated warnings
during compile. Is there a reason LogLog is still being used here?
-Mark
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Sent: Friday, February 25, 2005 5:49 AM
> To: [EMAIL PROTECTED]
>
I'd like to see a June release as well, but this seems like a big list of
items, plus the other items mentioned by Curt and Elias. Some of the tests
and performance issues could be looked at during the beta period. Still
feels a bit ambitious.
But, working backwards, when do we want to target th
On Feb 25, 2005, at 7:59 AM, Ceki Gülcü wrote:
Curt,
I'd like to keep things simple and stupid. Imagining and implementing
solutions for problems that do not exist makes the code hard to
maintain. We already have a strategy for preserving backward
compatibility which is both extremely simple and
Curt,
While I appreciate your efforts in resolving the Gump failure with the
Hivemind tests, what we have currently works just fine and is quite simple
to understand. Could we please move on?
At 08:03 PM 2/25/2005, Curt Arnold wrote:
Seems we have found ourselves in a revert war.
I really think
On Feb 25, 2005, at 1:22 PM, Ceki Gülcü wrote:
Curt,
While I appreciate your efforts in resolving the Gump failure with the
Hivemind tests, what we have currently works just fine and is quite
simple to understand. Could we please move on?
I can't stress how strongly that I believe these changes
On Feb 25, 2005, at 1:03 PM, Curt Arnold wrote:
This would result in a call to AppenderSkeleton.activate() and a call
to AppenderSkeleton.activateOptions() since activateOptions would
invoke the custom appenders activation code. If code wants to work
properly with existing custom appenders, the
Folks already know how I feel about the subject:
We should try to maintain backward compatibility and give up when it causes too
much pain.
This problem has been discussed (rehashed) numerous times.
Can we come to agreement, for the benefit of log4j users who for various
reasons must use old v
At 09:48 PM 2/25/2005, Curt Arnold wrote:
I can't stress how strongly that I believe these changes are bad and will
unnecessarily cause some users of 1.2 to stay with log4j 1.2 or encounter
broken behavior during the migration. I was disappointed that such
significant changes were initially com
On Feb 25, 2005, at 3:22 PM, Ceki Gülcü wrote:
At 09:48 PM 2/25/2005, Curt Arnold wrote:
I can't stress how strongly that I believe these changes are bad and
will unnecessarily cause some users of 1.2 to stay with log4j 1.2 or
encounter broken behavior during the migration. I was disappointed
t
On Fri, 25 Feb 2005 22:22:19 +0100 Ceki Gülcü <[EMAIL PROTECTED]> wrote:
> I understand. OK, to summarize:
>
> 1) The changes are compile-time backward compatible -- existing appenders
> will compile just fine without change against 1.2 as well as 1.3.
>
> 2) The changes only affect programmatic c
Appender the interface is the contract for all Appenders,
AppenderSkeleton just happens to provide some decent plumbing and
support in an effort to make it easy to write a custom appender.
Anywhere within log4j we should think Appender, and forget about the
existence of AppenderSkeleton. Chang
On Feb 25, 2005, at 6:57 PM, Paul Smith wrote:
Appender the interface is the contract for all Appenders,
AppenderSkeleton just happens to provide some decent plumbing and
support in an effort to make it easy to write a custom appender.
Anywhere within log4j we should think Appender, and forget a
Ok. I've got the gump module out and now at least understand a bit more
about gump.
The reason I think this failed is because the current Chainsaw build
expects a set of jars to be available as part of the compile classpath.
I see that the gump descriptor has logging-log4j and commons-vfs, but
I would love this feature. I like the way Eclipse allows you to do
this. Copied from the Java->Appearance tab of Eclipse preferences:
"Compression pattern (e.g givin a package name 'org.eclipse.jdt' pattern
'.' will compress it to '..jdt' '0' to 'jdt', '1~' to 'o~.e~jdt')"
We should probably
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at [EMAIL PROTECTED]
Project logging-log4j-chainsaw has an issue affecting its community integration.
This iss
On Feb 25, 2005, at 9:42 PM, Paul Smith wrote:
I would love this feature. I like the way Eclipse allows you to do
this. Copied from the Java->Appearance tab of Eclipse preferences:
"Compression pattern (e.g givin a package name 'org.eclipse.jdt'
pattern '.' will compress it to '..jdt' '0' to '
I'm not sure if we are looking at the same run since the Gump message
seemed to arrive about an hour after your message.
Looking at
http://brutus.apache.org/gump/public/logging-chainsaw/logging-log4j-
chainsaw/gump_work/build_logging-chainsaw_logging-log4j-chainsaw.html
I added commons-vfs t
log4j-core jar doesn't have the socket classes. the log4j-optional jar needs
added to the classpath.
also need log4j-oro and log4j-xml in the classpath as well.
Thanks for the help, Curt
Scott
-Original Message-
From: Curt Arnold [mailto:[EMAIL PROTECTED]
Sent: Fri 2/25/2005 11:1
28 matches
Mail list logo
