http://bugzilla.slf4j.org/show_bug.cgi?id=31
--- Comment #61 from Joern Huxhorn <jo...@huxhorn.de> 2009-11-15 19:16:48 --- Concerning comment #56 and comment #31: The only downside is the possibility of separate maintenance in case of bug fixes, if necessary and critical enough. We are all in agreement that comment #31 is a good solution of this problem. Concerning comment #59: The only problem I have with XLogger is due to the fact that it *is* a wrapper. Avoiding such an additional wrapper is one of the great features of Logback. I like XLogger but I'd only use it if I required the entry etc. functionality, not always. Concerning my comment #45 and comment #53: My suggestion of defining/discussing a new Logger interface is only partially related to this bug. It was probably a mistake on my side to attach it here and was not meant to be in disagreement with any other suggestion, like XLogger or comment #31. What I tried to accomplish is redesigning SLF4J to support stuff that we can't support right now, due to the fact that we must neither reduce nor extend the original SLF4J logger. Bug #133 is one such issue, something that I would have needed on several occasions, one of which was the bridging of XSLT messages to SLF4J. Being able to retrieve the Threshold of a logger would be nice, too, although I didn't have a situation where I'd needed it. And bug #125, removal of unnecessary methods, is another one of that kind. Last but not least, bug #70, my personal favorite. We could even aim to support all the different kinds of message formattings that were previously requested by various users, e.g. Java-Formatting, StructuredData like Ralph suggested (supporting named placeholders), MDC-related formatting (again, named placeholders that are replaced with MDC values) and so on. This would be possible if we devised something as general as logger.debug(Message message) where Message would be an interface like this: public interface Message { String getFormattedMessage(); Throwable getThrowable(); } where the current implementation would look something like this: public class ParameterizedMessage implements Message { Object[] getParameters() {..} String getMessagePattern() {..} } but with the ability to add new Message types as needed. I'd be highly interested in a discussion about this topic but - as I said - this bug is likely the wrong place for such a discussion... A place to brainstorm about what SLF4J 2.0 could look like would be nice. Cheers, Joern. -- Configure bugmail: http://bugzilla.slf4j.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. _______________________________________________ dev mailing list dev@slf4j.org http://www.slf4j.org/mailman/listinfo/dev