logging-log4j-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Endre StĂžlsvik <En...@Stolsvik.com>
Subject RE: java.util.logging interoperability
Date Mon, 23 Feb 2004 18:26:03 GMT
On Mon, 23 Feb 2004, Scott Deboy wrote:

| Endre,
| If you're worried about the added network or xml conversion cost, would
| you be interested in contributing something to improve the situation?

I was just thinking aload, really. I'm afraid I don't have time to
contribute any real code here..

I was thinking about the isDebugEnabled() thing: there should most
probably be some magic there - the entire logging category tree (and the
log-levels of each node) should be sent over the the "logging side", so
that no logging (nor network) would occur if the level on the particular
node wasn't turned on.

That there are impacts -if- the logline must be logged, is understandable
and Okay - it might even "take ages". However, if I turn of logging, the
impact should be close to nil. What I understand from the original mail is
that this isn't true: the impact is 100% (or maybe near "200%"?) on every
log statement?

| One option might be a combination handler/appender which converted
| LogRecords to LoggingEvents, which could then get posted to the Log4J
| framework?

This must surely be much faster than XML'ing the stuff.

 However ..

| Another option might be a handler which serialized LogRecords, and a
| Receiver which converted the LogRecords to LoggingEvents on the receive
| side.

.. the point is that this isn't what I'm concerned about - it is rather
the problem of turning off logging - and what impact it gives then.

| The original reason for contributing receivers which accept
| XML-formatted events via the network (XMLSocketReceiver/UDPReceiver) was
| to provide the ability to accept events generated by non-java
| frameworks: log4perl, log4cxx, log4net, log4php.  The MulticastReceiver
| and MulticastAppender also process XML-formatted events and are pretty
| handy.
| Adding the ability to process util.logging's DTD to was a low-pain way
| to make Log4J's framework (and Chainsaw) accessible to those using
| util.logging.  Supporting util.logging's DTD also allows us to load
| logging files which conform to util.logging's DTD into Chainsaw.

It is certainly interesting, and a very nice feature. However, it might
not be very usable if there is such a extreme impact as I envision, or ..


To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org

View raw message