Antonio Petrelli wrote:
> However in my experience SLF4J has a big drawback: when used in a
> shared classloader (JBoss Portal anyone?) it is needed to have the
> same stinky old version of SLF4J in all applications during compile
> time, and the library should be excluded from the package.
Hello Antonio,
Since version 1.0 released about 5 years ago, all versions of SLF4J
are compile-time compatible. For example, you can compile code with
slf4j-api version 1.4.3 and run it just fine with any other version of
slf4j-api, including 1.0.x, 1.1.x, 1.2.x, 1.3.x, 1.4.x., 1.5.x and
1.6.x.
On the other hand, the version of slf4j binding that you select at
runtime needs to match the slf4j-api. For example, if you have
slf4j-api-1.6.1.jar on your classpath and you wish to use log4j, then
you need slf4j-log4j12-1.6.1.jar on your class path,
slf4j-log4j12-1.4.3.jar will not work.
HTH,
--
QOS.ch, main sponsor of cal10n, logback and slf4j open source projects,
is looking to hire talented software developers. For further details,
see http://logback.qos.ch/job.html
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
