On 08/08/2011 04:56 PM, Elijah Zupancic wrote:
> This could be done by choosing (dynamically or by configuration) the
> logger implementation log4j / commons / slf4j / jul and then loading
> the LoggerFactory into a wrapper class that is then called used by the
> Commons project.
>
> We would then make the logger implementations a compile-time
> dependency only and relay upon the consumer to provide them.
>
> I do realize that this is essentially doing a Facade on top of a
> Facade, but it solves the problem for consumers of the library by
> providing many options.
>
> So, am I crazy?
If I understand you correctly, you would have this dependency chain:
random-commons-project ->
commons-logging-wrapper ->
API like slf4j or logging implementation (at runtime)
Plus commons-logging-wrapper requires compile-time knowledge of all
possible target frameworks, since it is not coding to an API.
Can you explain the advantage over simply coding
random-commons-project against slf4j-api.jar? Then, you have this
dependency chain:
random-commons-project ->
slf4j-api ->
logging implementation (at runtime)
And anyone can create their own slf4j compatible logging
implementation simply by implementing the slf4j api and dropping their
jar into their environment.
Cheers,
Raman
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
