There was a recent discussion on SocketAppender in log4j and log4net on the log4j-dev mailing list:
http://nagoya.apache.org/eyebrowse/ReadMsg?listName=log4j- [EMAIL PROTECTED]&msgNo=8240. One of the suggestions in that thread is that binary compatibility based on the existing log4j serialization is not really important since somebody will eventually design a new serialization, but nobody has started work on that either.



On Dec 22, 2004, at 8:39 AM, Sluis, Minto van der wrote:

Hi its me again,

The extent of the log library begins to dawn on me.
Regrettably, as I understand, the wire protocol for
the SocketAppender in Log4J and Log4cxx are not
compatible (maybe this has something to do with the
subject of my previous mail).

1) Where is this wire protocol described?

Log4j SocketAppender's "wire format" is the default Java Serialization of its org.apache.log4j.spi.LoggingEvent class. The Java Serialization spec is described at http://java.sun.com/j2se/1.5.0/docs/guide/serialization/spec/ protocol.html. The use of default serialization makes log4j's wire format sensitive to class changes and there have been some breaking changes that will cause some log4j 1.2.x message to not be read by a 1.3.x implementation and vice versa. See the previous link for the gory details. If we were going to go done the path of compatibility with the existing log4j implementation, then it would be very desirable to get log4j 1.2.8 and 1.3 compatible with each other.



2) What are the plans for making them compatible?

I'd love for to have it happen, but there is nobody currently working on it and it isn't near the top of my to-do list.



3) How much work would this be?

It is either not very hard or totally impractical.

4) And finally, can I be of service?

The key missing starting point would be someone serializing sample log4j LoggingEvent's to a file stream and analyzing the serialized events using the source code, the serialization spec and a hex editor. It would be great to have a detailed field by field analysis of what log4j currently produces. The analysis would also be useful to log4net in case they want to follow us in making their SocketAppender binary compatible. You'd want to start out with the simpliest LoggingEvent before adding MDC, NDC, LocationInfo and the like. If something in the internal structure is really nasty, we could rework log4j 1.3 to simplify it.


Other possible contributions would be to analyze or address the binary incompatibility between log4j 1.2.x and 1.3.



Reply via email to