Joern, I can't help but think having Entry objects that include Level & Marker is a major sticking point with this. I put more thought into Entry objects, and have reached a couple conclusions. First, with the other proposed changes, this feature could be added later without breaking things using a LevelProvidingMessage and corresponding Logger method. Second, one of the major advantages is the ability for an Entry to determine its own Level and Marker. But this comes at a performance cost as the Entry would have to be constructed prior to checking isEnabled.
So, with that, I reworked my branch to have Message objects that more closely resemble those in your branch. (The current Message objects are rudimentary and would need to be updated with the work from your branch.) To recap, this proposal includes: - Much simplified adapter implementation requirements while improving separation of concerns and freedom for future slf4j-api innovation. - Binary and source compatibility with 1.6.x adapters and application code. - Support for new Logger methods including Message objects when using legacy adapters. - No change in the package names for org.slf4j.Logger, LoggerFactory, etc. - Resolves the following: http://bugzilla.slf4j.org/show_bug.cgi?id=245 http://bugzilla.slf4j.org/show_bug.cgi?id=244 http://bugzilla.slf4j.org/show_bug.cgi?id=243 http://bugzilla.slf4j.org/show_bug.cgi?id=242 http://bugzilla.slf4j.org/show_bug.cgi?id=241 http://bugzilla.slf4j.org/show_bug.cgi?id=148 http://bugzilla.slf4j.org/show_bug.cgi?id=31 - Resolves confusion behind the following: http://bugzilla.slf4j.org/show_bug.cgi?id=213 http://bugzilla.slf4j.org/show_bug.cgi?id=240 - Allows easy addition of (if desired): http://bugzilla.slf4j.org/show_bug.cgi?id=133 John _______________________________________________ slf4j-dev mailing list [email protected] http://qos.ch/mailman/listinfo/slf4j-dev
