Spring Logging Beginner Question

[al0]

Directly from SLF4J homepage "In fact, the binding between SLF4J and a given logging API implementation is performed statically at compile time of each binding."

Sure, it does not mean that you need to rempile your application - but you need to replace slf4j implementation jar with different one. Not a big tragedy, but anyway somewhat less flexible then completely dynamic binding.

Any may notice I do not try to say which of 2 (SLF4J or JCL) is better and should be used. I just say that both have their pro and cons which should be weighed in each case individually. Especially as it is not very complicated migrate back and force, see http://www.slf4j.org/legacy.html#jcl-over-slf4j

Regards,
Oleksandr

explain this please. of course SLF4J does not bind itself to a desired logging system a compilation time but at deployment time. not sure what you mean by compilation time binding but that would be very useless to have to re-compile app to switch logging system...



what flexibility are we giving up?




JCL issues are clear and documented and one of the main reasons for SLF4J existence.

[denis.zhdanov]

No references is required here - JCL gives more flexibility due its nature - as it bind itself to specific logging API dynamically while SLF does it statically, at compilation time. As usually drawbacks are continuation of advantages. SLF win in robustness, especially in complex environments, by giving up some flexibility.
Then everybody may decide for itself what is more important to him.

...

I'm afraid I was not clear enough at the question formulating. It's quite clear that dynamic log system linking gives more flexibility (however, I don't see a real-world situation when dynamic logging implementation discovery is more preferable than the static linking).

I posted the link to the description of exact problems that may occur during JCL usage. You said that 'latest version of JCL work good enough in most situation (many of mentioned class-loading problems are addressed in them)'. I don't see a possibility to have a protection for the mentioned problems on a framework level due to dynamic framework nature. So, are there any references about that?

[al0]

If I remember properly, along with dynamic discovery you may specify which system to use via configuration settings.
And as for problems - even link that you posted contatins remarks like "this problem is fixed in 1.0.4" and "that is fixed in 1.0.5". And well you may take a look on JCL release notes for versions 1.1 and 1.1.1 as well as at following link http://wiki.apache.org/commons/Commons_Logging_FUD

Regards,
Oleksandr

I'm afraid I was not clear enough at the question formulating. It's quite clear that dynamic log system linking gives more flexibility (however, I don't see a real-world situation when dynamic logging implementation discovery is more preferable than the static linking).

I posted the link to the description of exact problems that may occur during JCL usage. You said that 'latest version of JCL work good enough in most situation (many of mentioned class-loading problems are addressed in them)'. I don't see a possibility to have a protection for the mentioned problems on a framework level due to dynamic framework nature. So, are there any references about that?

[denis.zhdanov]

And as for problems - even link that you posted contatins remarks like "this problem is fixed in 1.0.4" and "that is fixed in 1.0.5".

There are no such statements at the document I referenced.

And well you may take a look on JCL release notes for versions 1.1 and 1.1.1 as well as at following link http://wiki.apache.org/commons/Commons_Logging_FUD

Regards,
Oleksandr

Rather interesting link, thanks. However, I disagree with the JCL purpose stated there:

If however, like the Jakarta Commons project, you're building a tiny little component that you intend for other developers to embed in their applications and frameworks, and you believe that logging information might be useful to those clients, and you can't be sure what logging framework they're going to want to use, then commons-logging might be useful to you.

That obeys 'tiny module' to reference JCL, hence, obeys module clients to include the JCL binaries to the application distribution. I don't see any benefit in comparison with SLF4J usage then.

[al0]

There are no such statements at the document I referenced.

Sure? One example

This limitation will be addressed in JCL version 1.0.5 ....

Rather interesting link, thanks. However, I disagree with the JCL purpose stated there:

Up to you.

[denis.zhdanov]

Sure? One example

Haven't noticed, my bad