OSGi log service (was: [slf4j-dev] Logger.debug(String, Object[])?)

[Curt Arnold]

On Aug 5, 2005, at 12:36 PM, Ceki Gülcü wrote:
>> I think I possibly can agree that it makes sense. I am normally  
>> pro-clarity
>> :o)
>>
>> Interesting to note that 8 new methods here == "not much for a bit of
>> documentation in code", and a single convenience method over at  
>> OSGi folks is
>> a "no no", with the argument that all constrained implementations  
>> will suffer
>> as a result.
>>
>
> I see what you are saying. Maybe the OSGi folks have constrained  
> implementations whereas SLF4J does not have any for the moment. Of  
> course, it will be an entirely different ball game when such  
> implementations start to appear.
>
>

I could not see any previous discussion on OSGi Log Services (http:// 
www.osgi.org) on the mailing list.

Adding a new method to an OSGi interface would mean that existing  
implementations would be broken.  Since the OSGi logging service has  
been released, I think that they are constrained to only introduce  
new interfaces unlike SLF4J where everything is still open to change.

Were you considering providing an SLF4J adapter over the OSGi Log  
Service Specification, or is there already one and I missed it?

If you did so, were you thinking about providing a mechanism to  
associate a ServiceReference with a logger?   
org.osgi.service.log.LogService has basically two flavors of log  
requests

void log(int level, String msg);

and

void log(ServiceReference service, int level, String msg);

With the current definition of org.slf4j.ILoggerFactory.getLogger 
(String name), you would not have a clean way to associate a  
ServiceReference with a logger.  Possibilities might include having  
an OSGi specific interface on the implementation of ILoggerFactory,  
so that an OSGi aware application (which would it would have to be to  
have a ServiceReference) could obtain a Logger associated with the  
ServiceReference, so'd you'd have something like:

class MyClass {
     public void Logger getLogger(ServiceReference ref) {
         ILoggerFactory factory = LoggerFactory.getInstance();
         if (factory instanceof OSGILoggerFactory) {
               return ((OSGILoggerFactory) factory).getLogger(ref);
        }
       return factory.getLogger(ref.toString());
    }
}

 From a quick review of the code, it did not appear that you had a  
clean way of getting the current LoggerFactory to do any capability  
determination, however.

Another approach would be to change the type of the name parameter on  
ILogService.getLogger() from String to Object and allow an  
implementation to  branch depending on the type of object passed.   
However, that would probably introduce way too many gotchas.