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

[Ralph Goers]

Joern,

I looked at this and I have a question and a concern.

First, I didn't see any code in your logback fork to support the Message. How do you envision that being integrated into the LoggingEvent? 

The concern is that Logger now would require Java 5.  I personally have no problem with a new release train for that but if it means holding off on integrating the things that don't require Java 5 then I'd prefer the vararg support be separated.

Other than that, I think this is a better approach.

Ralph

On Dec 2, 2009, at 2:48 PM, Joern Huxhorn wrote:

> 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
> 
> _______________________________________________
> logback-dev mailing list
> logback-dev at qos.ch
> http://qos.ch/mailman/listinfo/logback-dev