On Tuesday 07 December 2004 05:23, Curt Arnold wrote:
> I'm sure that you could do better with a custom wire-format than the
> current Java default serialization, however I'm not sure that you would
> see any significant advantage over custom serialization. The benefits
> for using Java custom se
We have discussed this before, many moons ago. In order to better support
the various types of Watchdogs I want to implement in v1.3, I want to add
the following method to the Configurator interface:
/**
Use an InputStream as a source for configuration and set up log4j
accordingly.
T
To whom it may satisfy...
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 *no longer* has an issue.
The current state of this project is 'Su
To whom it may satisfy...
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-12 *no longer* has an issue.
The current state of this project is
I've been hinting at this for quite some time but apparently not loud
enough.
The reason there was no serious effort to preserve bw compatibility
between 1.2 and 1.3 is performance improvements scheduled for
1.3. Given that we always transmit LoggingEvent objects on the wire, a
protocol specialized
Hi,
After an incredibly long delay, I got around to implementing an initial version
of this. I just committed it, along with a modified JoranConfigurator to use
it.
I suppose the next step is to enhance the Joran unit tests to use this action.
However, I wasn't sure what the best way is to m
yoavs 2004/12/06 13:07:57
Modified:src/java/org/apache/log4j/joran JoranConfigurator.java
Added: src/java/org/apache/log4j/joran/action
JndiSubstitutionPropertyAction.java
Log:
Initial version of JndiSubstitutionPropertyAction for joran.
Revisio
At 09:20 AM 12/5/2004, Scott Deboy wrote:
I haven't tried sending events from log4j 1.3 to log4j 1.2.8, but I doubt
deserialization would work, without more changes to serialization logic.
In 1.3, LoggingEvent contains a new field:
long sequenceNumber
The 1.2.8 code wouldn't know what to do with
On Monday 06 December 2004 21:59, Shapira, Yoav wrote:
> Hi,
> We should balance the performance aspect versus the requirement for
> serialization compatibility. I think the latter is a nice to have, but
> by no means an essential feature. I think the former is imperative for
> log4j as it is for
Hi,
We should balance the performance aspect versus the requirement for
serialization compatibility. I think the latter is a nice to have, but
by no means an essential feature. I think the former is imperative for
log4j as it is for any logging system. If we can get the serialization
compatibil
10 matches
Mail list logo
