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

John E. Conlon jconlon at verticon.com
Fri Feb 16 23:05:59 CET 2007


Your right, neither do I want to increase the number of classes in the 
org.slf4j packages.  But we are basically doing the same kind of thing 
with the second approach as well - exposing our selves to greater 
coupling by clients.  By exporting the org.slf4j.spi package we are 
exporting what was once a private package and all classes in it, on to 
the OSGi package matrix. 


Right now we are in a very good position regarding client coupling to us 
and dependencies we have on other third party jars.  Although we are 
still using split packages to deliver our Logger service but now for 
1.5.0 we do the 'package join' at maven build time versus before we had 
our clients do it on the classpath.

If I review what we want with this fix, it is to give to our adapters a 
common functionality for providing location awareness.  (Am I right?)  
IMO a better way to do this is to create a new utilities package with 
this interface in it, that way we can offer it for inclusion in our 
bindings projects along with the private binding packages 
org.slf4j.impl, org.slf4j.spi, org.slf4j.helpers.  These binding bundles 
would then offer both org.slf4j and something like a org.slf4j.utilities 
to clients and adapter bundles.  Clients bundles would not see this 
package, and adapter bundles would import both from the binding bundles. 
  That's the  theory at least. 

WDYT?
John

Ceki Gülcü wrote:
> I believe it was my bad. I introduced a new dependency without
> thinking about the consequences at the OSGi level. My apologies for
> the inconvenience.
>
> There are two possible solutions:
>
> 1) move the LocationAwareLogger interface from org.slf4j.spi to org.slf4j.
> 2) export the org.slf4j.spi package
>
> I have a slight preference for the second option. Moving
> LocationAwareLogger to org.slf4j will put this interface right in front
> of the eyes of our users (increased brain-print) even if it is
> mostly a technical detail.
>
> John, is option two OK with you?
>
>
> At 09:38 PM 2/16/2007, John E. Conlon wrote:
>   
>> Hi Sebastien,
>>
>> I see what is going on, but don't know what to do about it.
>>
>> The build problem is related to the introduction of a new package
>> dependency to
>> the artifact (jar/bundle) created by jcl-over-slf4j.  This change
>> happened at revision 722.
>>
>> The new package dependency is
>>
>> org.slf4j.spi
>>
>> and it is used by the modified SLF4FLogFactory and the new 
>> SLF4JLocationAwareLog.
>>
>> To date we have considered the org.slf4j.spi a private package for use
>> by the bindings projects only, it is never exported by any of our
>> binding bundles and therefore was never intended to be used explicitly
>> so it is never imported by any client bundles.  (OSGi bundles needing
>> logging are only required to import the org.slf4j package. )
>>
>> Even our own clients and jcl-over-slf4j is a client do not import this
>> package and that is why the error during the maven package time.
>>
>> So how to get around the problem?  Revert to previous revision? But what
>> about the fix for location specific logging?
>>
>> John
>>
>>
>> Sebastien Pennec wrote:
>>     
>>> Hello,
>>>
>>> I've had some issues today by building the jcl-over-slf4j module. I get 
>>>       
>> this error:
>>     
>>> [INFO] [bundle:bundle]
>>> [ERROR] Unresolved references to [org.slf4j.spi] by class(es) on the
>>> Bundle-Classpath[Jar:dot]: 
>>>       
>> [org/apache/commons/logging/impl/SLF4FLogFactory.class,
>>     
>>> org/apache/commons/logging/impl/SLF4JLocationAwareLog.class]
>>>
>>> My guess is that it might come from OSGi wiring, but since I'm not too 
>>>       
>> sure, I prefer
>>     
>>> asking :)
>>>
>>> Sébastien
>>>
>>>       
>> _______________________________________________
>> dev mailing list
>> dev at slf4j.org
>> http://www.slf4j.org/mailman/listinfo/dev
>>     
>
>   




More information about the slf4j-dev mailing list