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