[slf4j-dev] jcl-over-slf4j module not building

[John E. Conlon]

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