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.
_______________________________________________
dev mailing list
[email protected]
http://slf4j.org/mailman/listinfo/dev
