[logback-dev] RFC 5424 and Structured Data support.

Joern Huxhorn jhuxhorn at googlemail.com
Wed Dec 2 23:48:03 CET 2009


Hi Ceki,

did you have the chance to take a look at my latest SLF4J bug #31 comment, i.e. http://github.com/huxi/slf4j/tree/slf4j-redesign/slf4j-n-api/ ? (I know, I'm probably a nuisance...)

It adds methods like logger.debug(Message message) that would essentially solve issues like that.
For the common appender, such a Message would simply return a formatted String but custom appenders are able to handle an implementation they know however they like.

If you take a look at my branch then please keep in mind that, while being fully (as far as I can tell yet) functional, it's merely meant as a common base for further discussion.
The package names as well as method-names like e.g. getOldLogger() are, of course, just placeholders for whatever they might be called later.

The StructuredDataMessage is also just a placeholder.
I imagine a certain amount of "default" SLF4J-Messages that would be known to all appenders with the ability to add more. Those default messages could be serialized as they are (if they implement Serializable, of course) while messages not contained in the respective package would be serialzed as Strings (or, more specifically, as SimpleMessage instances).

Regards,
Joern.  

On 04.12.2009, at 23:12, Ceki Gülcü wrote:

> Hi Ralph,
> 
> I've looked at the changed you made in relation to RFC 5424. It's
> quite a significant architectural change. The RFC 5424 route is in the
> opposite direction of logback where one creates a new module for each
> new event type. This offers the benefit of type safety but has
> significant overhead from a packaging pov, whereas the 5424 route has
> little packaging overhead but omits type safety.
> 
> The RFC 5424 approach is not to be discarded. However, I don't think
> it's a route we should take at this *immediate* juncture. I propose to
> put it aside for the time being and come back to it, possibly with a
> vengeance, some time later.
> 
> BR
> _______________________________________________
> logback-dev mailing list
> logback-dev at qos.ch
> http://qos.ch/mailman/listinfo/logback-dev



More information about the logback-dev mailing list