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

[Ralph Goers]

On Dec 3, 2009, at 3:26 AM, Joern Huxhorn wrote:

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

Actually, the IETFSyslogLayout and IETFSyslogAppender would be a base part of logback. But these are just new components and obviously wouldn't affect anything new. JMSAppender was modified to accept a layout instead of always sending a serialized 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.
> 
> 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.

I don't think you can actually do that in a single jar but I could be wrong. You'd have to build with source = 1.5 and target = 1.3. I think it would complain about the varargs. In your project your pom.xml specifies source = 1.5 and target = 1.5 so applications trying to use it on <= 1.4 are going to get a wrong version exception. If it did build then that would imply you don't really need the wrapper.


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

I'll try to put this stuff in my branch and see what happens.

Ralph