On Mon, Jul 14, 2008 at 9:52 PM, Les Hazlewood <[EMAIL PROTECTED]> wrote:
> On Mon, Jul 14, 2008 at 3:33 PM, Niklas Gustavsson <[EMAIL PROTECTED]> wrote:
>> On Mon, Jul 14, 2008 at 8:57 PM, Les Hazlewood <[EMAIL PROTECTED]> wrote:
>>> Just out of curiosity though, how come you don't seem to mind the
>>> tight-coupling to the SLF4J API as much as I do?  In general,
>>> tight-coupling of _any_ 3rd party API really really irritates me.
>>
>> As a fan of the pure SLF4J approach I see SLF4J as the very extension
>> to the JRE, something that's always around. One would have hoped that
>> JUL would have been just that, but since it's not, SLF4J has had to
>> play that roll. I'm thinking that it will be around in the large
>> majority of cases where JSecurity is used anyways and therefore see a
>> custom logging API as more burden than using SLF4J directly.
>
> I agree with you, but the sad reality is that SLF4J is not embedded
> into the JRE, so therefore I must view it as a proprietary 3rd party
> library.  And as to its ubiquity, I haven't yet needed to use SLF4J in
> any of my most recent projects (and I have a lot of them), nor do any
> of the open source projects I use currently require SLF4J (Spring,
> caching frameworks, etc).

Well, the uber JAR approach proposed earlier in this thread would
indeed take care of just that.

> Now of course, the next version of Hibernate will require it, but not
> too many others - the huge majority of frameworks still require
> Commons Logging. I do feel that this will change over the next year
> though, since SLF4J adoption is occurring quite rapidly - which is why
> SLF4J is my preferred logging API.  JCL will be replaced soon enough
> across the board.

Most projects that I'm familiar with uses jcl-over-slf4j since no one
wants to use JCL these days. If Spring-DM is any indication, Spring
might switch over to SLF4J as well.

/niklas

Reply via email to