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

[Joern Huxhorn]

Hi Ralph

On 03.12.2009, at 11:31, Ralph Goers wrote:

> 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?

Well, Logback would, if it's implementing that API, change it's  
LoggingEvent to have a Message instead of pattern+args.
StructuredDataMessage would be just another message. One could argue  
if it should be contained in the set of standard messages (at the  
moment SimpleMessage (just an encapsulation of a String),  
ParameterizedMessage and JavaUtilFormatterMessage) or not.

 From your point of view this wouldn't really matter since you write a  
custom appender anyway, right? Other appenders would simply handle  
your Message type similar to a String.

>
> 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.

Yes, that's true. This is my suggestion about how to proceed  
concerning the Java5 issue in SLF4J.
I think that slf4j-api should stay as it is so that people that still  
depend on <=1.4 are still having the chance to use SLF4J without being  
excluded from future updates/fixes.

Since we must not reduce or enhance the original SLF4J API so neither  
users nor implementors are hurt, I thought it would probably be best  
to simply define an entirely new API without any restrictions  
whatsoever.
So, unfortunately, this can't be added to the current org.slf4j.Logger.

The idea is, that >=1.5 logging frameworks like Logback would  
implement the new API directly, using a wrapper to support the old one.
The opposite is the case for <=1.4 logging frameworks. Those wouldn't  
have explicit support of the new API since it would introduce >=1.5 as  
a requirement. The new API would return a wrapper that'S actually  
using the old Logger.

All work concerning the wrapping is already done in my branch.
See http://github.com/huxi/slf4j/tree/slf4j-redesign/slf4j-n-api-new-integration-test/ 
  and http://github.com/huxi/slf4j/tree/slf4j-redesign/slf4j-n-api-old-integration-test/ 
  for examples.

Another nice thing is the simplicity of new Logger implementations.  
This is quite obvious if you compare the TestLogger implementations of  
the two integration-tests.

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

Thanks,
Joern.

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