(It would be nice to get finals taken off methods of the NOP implementation for this release)<br><br><div><span class="gmail_quote">On 2/21/07, <b class="gmail_sendername">Ceki Gülcü</b> <<a href="mailto:listid@qos.ch">
listid@qos.ch</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">John,<br><br>With the recent changes made by Sebastien [1, 2], we no longer have
<br>packages split across modules. Thus,<br><br>slf4j-api<br>exports packages:<br> org.slf4j<br> org.slf4j.spi<br> org.slf4j.helpers<br>imports packages:<br> org.slf4j.impl<br><br>slf4j-BINDING (where BINDING is one of nop, simple, log4j12, etc)
<br>exports packages:<br> org.slf4j.impl<br>imports packages:<br> org.slf4j<br> org.slf4j.spi<br> org.slf4j.helpers<br><br>As things stand currently, I believe that we are close to a release<br>candidate. The remaining question is with respect to OSGi
<br>meta-data. Do we keep using maven-bundle-plugin or not? In particular,<br>does that plug-in support Require-Bundle directives? (I think that<br>Require-Bundle directives would be necessary.)<br><br>Comments/thoughts?<br>
<br>[1] <a href="http://www.slf4j.org/pipermail/dev/2007-February/000818.html">http://www.slf4j.org/pipermail/dev/2007-February/000818.html</a><br>[2] <a href="http://www.slf4j.org/pipermail/dev/2007-February/000874.html">
http://www.slf4j.org/pipermail/dev/2007-February/000874.html</a><br><br><br>At 11:45 PM 2/20/2007, John E. Conlon wrote:<br>>Ceki Gülcü wrote:<br>> > John,<br>> ><br>> > Do you have a suggestion how we could avoid duplication of slf4j-api
<br>> > classes in the various bindings? Can this be done using<br>> maven-bundle-plugin ?<br>> ><br>>At the moment I can think four approaches to removing the duplication of<br>>classes in the bindings that sit on 'Sally's application's classpath.
<br>><br>>1. Keep the packages split across the api and binding projects, continue<br>>to rely on single classloader joining at runtime, and move back to a<br>>Require-Bundle approach for osgi support. We won't need the
<br>>maven-bundle-plugin in the binding projects for this.<br>><br>>2. Remove the split packages by consolidating the packages into the api<br>>and binding jars, and use a 'service implementation' discovery similar
<br>>that suggested by Eric in the "aufgeregt" thread :-) :<br>><br>><a href="http://www.qos.ch/pipermail/logback-user/2007-February/000129.html">http://www.qos.ch/pipermail/logback-user/2007-February/000129.html
</a><br>><br>>We should not depend on a sun impl for this so we would have to provide<br>>our own implementation, Boris has provided an example at:<br>><br>><a href="http://marc.theaimsgroup.com/?l=slf4j-dev&m=117157566417290&w=2">
http://marc.theaimsgroup.com/?l=slf4j-dev&m=117157566417290&w=2</a><br>><br>>While I have not experimented with his code, I do see one area that<br>>would require a change for it to work in an OSGi environment.
<br>><br>> public Object obtainFactory(ClassLoader cl) {<br>> ILoggerFactory ret = null;<br>> InputStream is = cl.getResourceAsStream(SERVICE_ID);<br>><br>>Note: couldn't use a context classloader as it would not find the
<br>>classes in an OSGi runtime. Sun's service api offers similar signatures.<br>><br>>3. Keep split packages and retain current way of combining api and<br>>bindings. Remove OSGi decorations and maven-bundle-plugin from the five
<br>>bindings projects. Create five additional OSGi 'pom' projects that<br>>just wrap the api and bindings to create OSGi binding bundles. These<br>>projects would only have a pom.xml (no code) and the artifacts they
<br>>create would be the same bundles as we are now producing in the binding<br>>projects. All other projects producing native jar/osgi bundles (like<br>>the adapters) would remain unchanged.<br>>(In this case Sally would not use the osgi-xxx-binding bundles.)
<br>><br>>4. Convince Sally to run OSGi ;-)<br>><br>> From an OSGi perspective I would rate them in order of functionality<br>>from higher to lower - 4, 3, 2, 1.<br>><br>>kind regards,<br>>John<br>
><br>><br>><br>> > At 07:52 PM 2/19/2007, Ceki Gülcü wrote:<br>> ><br>> ><br>> >> At 08:25 PM 2/18/2007, John E. Conlon wrote:<br>> >><br>> >><br>> >>>> Assuming Maven 2 is used by all participants, without particular
<br>> >>>> action by Sally, slf4j-api would be packaged in the final<br>> >>>> application along with a user-chosen binding, say slf4j-log4j12. In<br>> >>>> that case, we would have the contents of slf4j-api project duplicated,
<br>> >>>> once in slf4j-api.jar and once in slf4j-log4j12.jar. It would most<br>> >>>> probably work as expected, but I don't think it's good practice to<br>> >>>> have class files duplicated.
<br>> >>>><br>> >>>><br>> >>> I don't like this class duplication either, but AFAIK given the same<br>> >>> classloader this should not matter. The same classloader will load
<br>> >>> which ever it encounters first. (Maybe I will eat these words<br>> latter?) ;-)<br>> >>><br>> >> Hi John,<br>> >><br>> >> The driving premise behind SLF4J is to reduce surprises. I think we
<br>> >> should do things by the book and avoid duplication. Since SLF4J<br>> >> version 1.1, user's have been asked to have two jars, slfl4-api.jar in<br>> >> addition to a binding. In SLF4J
1.3, the general arrangement remains<br>> >> the same, except that slf4j-api is now self-sufficient as a<br>> >> compile-time dependency.<br>> >><br>> >> I quite like this user-story. Alice and Bob expose slf4j-api as a
<br>> >> transitive dependency, while Sally, the end-user, chooses to depend on<br>> >> a binding of her own selection. We respond to Eric Crahen's initial<br>> >> request [1] without fundamentally changing how SLF4J works.
<br>> >><br>> >> I do not wish to hide behind backward-compatibility excuses. We<br>> >> finally have a nice and clear separation between slf4j-api and<br>> >> slf4j-binding. Let's keep it clean and simple even if it costs an
<br>> >> extra jar on the class path.<br>> >><br>> >> [1]<br>> >> <a href="http://www.qos.ch/pipermail/logback-user/2007-February/000129.html">http://www.qos.ch/pipermail/logback-user/2007-February/000129.html
</a><br>> >><br>> >><br>> >><br>> >><br>> >>> a good weekend for you too,<br>> >>> John<br>> >>><br>> >> --<br>> >> Ceki Gülcü<br>> >> Logback: The reliable, generic, fast and flexible logging framework
<br>> for Java.<br>> >> <a href="http://logback.qos.ch">http://logback.qos.ch</a><br>> >><br>> >> _______________________________________________<br>> >> dev mailing list<br>> >>
<a href="mailto:dev@slf4j.org">dev@slf4j.org</a><br>> >> <a href="http://www.slf4j.org/mailman/listinfo/dev">http://www.slf4j.org/mailman/listinfo/dev</a><br>> >><br>> ><br>> ><br>><br>>_______________________________________________
<br>>dev mailing list<br>><a href="mailto:dev@slf4j.org">dev@slf4j.org</a><br>><a href="http://www.slf4j.org/mailman/listinfo/dev">http://www.slf4j.org/mailman/listinfo/dev</a><br><br>--<br>Ceki Gülcü<br>Logback: The reliable, generic, fast and flexible logging framework for Java.
<br><a href="http://logback.qos.ch">http://logback.qos.ch</a><br><br>_______________________________________________<br>dev mailing list<br><a href="mailto:dev@slf4j.org">dev@slf4j.org</a><br><a href="http://www.slf4j.org/mailman/listinfo/dev">
http://www.slf4j.org/mailman/listinfo/dev</a><br></blockquote></div><br><br clear="all"><br>-- <br><br>- Eric