On May 19, 2009, at 2:08 AM, Christian Grobmeier wrote:
I haven't looked at this, but I'm guessing that its wire format is
not
compatible with Chainsaw and log4j since they used their easiest
implementation (Java serialization). log4cxx 0.9.7 had its own
wire format,
but it was dependent on the encoding, sizeof(int) and endianess so
you had
to match senders and receivers. In the current log4cxx, I've
mimicked a
valid Java serialization byte sequence and it can interact with
Chainsaw and
other tools that consume log4j serialized events.
Is there any chance to read something somewhere about this?
Some dissection of the wire format appears in https://issues.apache.org/jira/browse/LOGCXX-7
. The file names are the comparison files from the unit tests (https://svn.apache.org/repos/asf/logging/log4j/trunk/tests/witness/serialization
).
The Java serialization spec is here: http://java.sun.com/javase/6/docs/platform/serialization/spec/protocol.html
. That plus the log4j source code defines the wire format that log4j
writes and Chainsaw consumes.
The applicable log4cxx code is:
https://svn.apache.org/repos/asf/logging/log4cxx/trunk/src/main/cpp/objectoutputstream.cpp
https://svn.apache.org/repos/asf/logging/log4cxx/trunk/src/main/cpp/loggingevent.cpp
(the last two methods particularly)
and to a lesser degree:
https://svn.apache.org/repos/asf/logging/log4cxx/trunk/src/main/cpp/socketappenderskeleton.cpp
https://svn.apache.org/repos/asf/logging/log4cxx/trunk/src/main/cpp/socketappender.cpp
log4j and log4cxx both have serialization tests in their unit tests.
I think bringing that
same approach over would likely make LoggerAppenderSocket more
useful. If
there is an existing receiver that depends on the current wire
format, log4j
compatible could be made as an option.
I agree.
However, having the bytesequence defined would help with testing, even
when we don't manage to get a spawned process in PHP (which is a bit
to extreme i would guess). I think a SocketMock would be enough.
Christian
