Fwd: [slf4j-dev] Separating API and binding

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Fwd: [slf4j-dev] Separating API and binding

Ceki Gulcu-2

Hello all,

It has been observes that while SLF4J offers abstraction of for
various logging systems through compile-time bindings, it bundles the
SLF4J API and a particular binding in a single jar file. Thus, we
currently have:

slf4j-nop.jar
slf4j-simple.jar
slf4j-jdk14.jar
slf4j-jul.jar

each of which contains a copy of SLF4J API and a corresponding binding.

I think it would be somewhat cleaner to separate the API in its own
jar file. Thus, we would have

slf4j-api.jar (just the API with no particular binding)

slf4j-nop.jar    (only the nop binding, no API)
slf4j-simple.jar (only the simple binding, no API)
slf4j-jdk14.jar (only the jdk14 binding, no API)
slf4j-jul.jar (only the jul binding, no API)

The only down side to this approach is that the user would need to
deploy two jar files instead of one. The upside is a clearer
separation between API and implementation.

Is there any opposition to this approach?

Your comments are most welcome.


--
Ceki Gülcü
http://ceki.blogspot.com/



-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
jetty-discuss mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jetty-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: [slf4j-dev] Separating API and binding

Greg Wilkins-5
Ceki,

I'm kind of neutral as I can see pros and cons both ways.

I like less jars...but I hate class duplication.

cheers


Ceki Gülcü wrote:

> Hello all,
>
> It has been observes that while SLF4J offers abstraction of for
> various logging systems through compile-time bindings, it bundles the
> SLF4J API and a particular binding in a single jar file. Thus, we
> currently have:
>
> slf4j-nop.jar
> slf4j-simple.jar
> slf4j-jdk14.jar
> slf4j-jul.jar
>
> each of which contains a copy of SLF4J API and a corresponding binding.
>
> I think it would be somewhat cleaner to separate the API in its own
> jar file. Thus, we would have
>
> slf4j-api.jar (just the API with no particular binding)
>
> slf4j-nop.jar    (only the nop binding, no API)
> slf4j-simple.jar (only the simple binding, no API)
> slf4j-jdk14.jar (only the jdk14 binding, no API)
> slf4j-jul.jar (only the jul binding, no API)
>
> The only down side to this approach is that the user would need to
> deploy two jar files instead of one. The upside is a clearer
> separation between API and implementation.
>
> Is there any opposition to this approach?
>
> Your comments are most welcome.
>
>


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
jetty-discuss mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/jetty-discuss