[slf4j-dev] Release of SLF4J version 1.6.0-RC0

[Ceki Gülcü]

Hi Joern,

On 24/04/2010 1:55 AM, Joern Huxhorn wrote:
> Hi Ceki,
>
> On 23.04.2010, at 16:18, Ceki Gülcü <ceki at qos.ch> wrote:
>
>> On 23/04/2010 2:14 PM, Joern Huxhorn wrote:
>>> Didn't you change LocationAwareLogger and doesn't that mean that it's
>>> not compatible with the current Logback anymore?
>>> Or is this only relevant for wrappers like jcl-over-slf4j and you
>>> changed all of them already?
>>
>>
>> Right, LocationAwareLogger affects compatibility with logback but so
>> does MessageFormatter changes, actually the latter in a deeper way as
>> it is no longer possible to compute the formatted message lazily in
>> LoggingEvent. I must be computed eagerly in LoggingEvent's constructor.
>>
>
> Are you aware that my ParameterizedMessage supports both #70 and lazy
> initialization?

Yes, but ParameterizedMessage has to be passed as a Message to a logger 
of type org.slf4j.n.Logger. More below.

> This is possible since the placeholders are only counted during
> creation. The actual formatting/placeholder replacement is only
> performed when the formatted message is requested. The formatted message
> is kept so it won't be regenerated in case of further calls.
> It could also be enhanced to perform the toString of the arguments at a
> later time. The Message interface could be extended by an
> prepareForDeferredProcessing() method for that purpose.
>
> I agree with Ralph that this would be a good time to extend the Logger
> interface with Message-aware methods since 1.6 will be incompatible anyway.

Initially, I also thought that 1.6.0 was a good time to integrate your
changes.

Changing the Logger interface breaks compatibility with client code
using SLF4J. Breaking compatibility at this level is different than
breaking compatibility within SLF4J internals. For example, as long as
the end-user places slf4j-api-1.6.0.jar and an appropriate 1.6.0
binding on the class path, things will work fine without needing to
compile client code or dependencies. However, if the logger interface
was changed, then *all* client code (including all dependencies using
SLF4J) would need to be recompiled. There is no comparison in the
impact of changing SLF4J internals and changing client-facing
interfaces such as org.slf4j.Logger.

--
Ceki