http://bugzilla.slf4j.org/show_bug.cgi?id=31 Ceki Gulcu <listid@qos.ch> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |listid@qos.ch --- Comment #91 from Ceki Gulcu <listid@qos.ch> 2011-09-07 15:57:36 CEST --- Fixing common functionality in an abstract class can alleviate some of the compatibility issues. The idea of reducing adapter implementations to two simple methods is quite brilliant. Nevertheless, Joern makes good points regarding early formatting. Message parameters must reach the logging backend unchanged whenever the backend has the appropriate hooks, e.g. logback. I am guessing that the idea of reducing adapter implementation can still be achieved albeit with different method signatures. Now imagine the following thought experiment. Assume that come up with some code structure which reduces adapter implementations two a handful of methods for all backends. At a later stage, assume we wish to enhance the org.slf4j.Logger interface with new functionality, say support for Joern's Message objects. The aforementioned methods would need to be modified to support Message objects breaking compatibility with existing adapter implementations. I see 3 possibilities to dealing with changes in SLF4J: 0) disallow any meaningful changes to SLF4J 1) allow for breaking compatibility for adapter implementations (as done historically in SLF4J) 2) come up with an abstraction so flexible that it is future proof for the next 10 years. 0 and 1 are doable. 2 requires great foresight. -- Configure bugmail: http://bugzilla.slf4j.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.