[logback-dev] [Bug 100] Serialization of objectArray in LoggingEvent does not always work

[bugzilla-daemon at pixie.qos.ch]

http://bugzilla.qos.ch/show_bug.cgi?id=100





------- Comment #19 from noreply.ceki at qos.ch  2008-03-22 19:32 -------

While it is true that logging behavior would depend on the underlying
logging system, the changes we are talking about are in the logback
API and only in the logback API. 

So if the user wishes to track a message processed over several
applications distributed over many machines.  It would be interesting
for her to specify parameters such as e.g. server id, application
name, request id, transaction id, user id etc.  The last three
parameters are specific to the request being processed and presumably
should be specified in the logging event as parameters.

It could look as follows:

LogbackEventMap lem = new LogbackEventMap();
lem.put("transactionId", getTransactionId());
lem.put("serverId", getServerId());
lem.put("requestId", getRequestId());
lem.put("userId", getUserId());

org.slf4j.Logger logger = LoggerFactory.getLogger("...");
logger.debug("Started processing message", lem);

The first 5 lines are logback specific while the last 2 lines are just
the SLF4J API. We are taking advantage of a detail in logback's
implementation of the SLF4J API (which is by the way the subject of this
bug).

Thus, logback's implementation of SLF4J logger will carry on the
argumentArray as is. Under certain strict restrictions, the argument
array may even survive serialization unmodified.

Assuming the use case I describe here is not that interesting, then I
think your line of thought is very valid. It brings interesting
simplifications. However, I am inclined to think that the use case is
an important one, and worth tying application code to logback's
implementation. Again, no one is forced to take advantage of
enhancements in logback's implementation of SLF4J's Logger
interface. Moreover, the Logger interface was not modified in any way.

In any case, many thanks for bearing with me on this issue. I
definitely appreciate it.

Given that bugs corrected in the trunk are being reported as
duplicates of previous bug reports, I wish to cut a new release
some time next week.


-- 
Configure bugmail: http://bugzilla.qos.ch/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.