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... and http://github.com/huxi/slf4j/tree/slf4j-redesign/slf4j-n-api-old-integration... 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