[slf4j-dev] Review of slf4j

[Niclas Hedhman]

Hi,
I have been thinking some around the proposed SLF4J.


*** getName() method in ULogger interface. ***
This would make it easier to do;
  ULogger child = factory.getLogger( logger.getName() + ".mychild" );


What is getLogger( String domain, String subdomain) supposed to be?
Both the SimpleLoggerFA and the JDK14LoggerFA ignores the subdomain. What is 
the intent here?


Why bother with the Factory Adapters at all??

The specification could say that;

 * Create a factory class named org.slf4j.LoggerFactory that has the 
 * following public structure;
 *
 * public class LoggerFactory
 * {
 *     public static ULogger getLogger( String domain );
 *     public static ULogger getLogger( String domain, String subdomain );
 *     public static ULogger getLogger( Class clazz );
 *     public static ULogger getLogger( Class clazz, String subdomain );
 * }
 * 
I can't see that it makes anyone's life particularly more troublesome, and is 
even more straight forward and not harder to write than a adapter. Only the 
SLF4J's own build system needs a slight change.


Also, is it JDK versions that stops you from using java.text.MessageFormat 
instead of the home-cooked MessageFormatter ?? Or is it performance?


Make the @IMPL@ map to the entire classname. People will want to have its own 
adapters. This is a non-issue if the adapters are scrapped altogether.


For IoC frameworks, the proposal doesn't seem to introduce any more problems 
than Log4J by itself today. The only issue I can see (and don't think there 
is a good solution for) is what to do when there is a mix between good IoC 
citizens and POJOs that does the LoggerFactory.getLogger() directly.
The not so nice solution would be;
  ULogger logger = LoggerFactory.getInstance( this ).getLogger( subdomain );
where the typical behaviour of getInstance() would derive the name from the 
class, and subdomain could be recommended to be null. It is not 'sweet', but 
would allow frameworks a good chance to pass the proper ULogger to the 
requesting object.


Further discussions with my colleagues also revealed that my previous 
statement about no addChildLogger() in the ULogger interface was perhaps not 
wise.
If the addChildLogger is in the ULogger interface, it could be a recommended 
pattern to do;

  public class MyClass
  {
      private MyOtherClass m_other1;
      private MyOtherClass m_other2;

      public MyClass( ULogger logger )
      {
          ULogger child1 = logger.addChildLogger( "other1" );
          m_other1 = new MyOtherClass( child1, 10 );
          ULogger child2 = logger.addChildLogger( "other2" );
          m_other2 = new MyOtherClass( child2, 20 );
      }
  }

in which case the IoC principle is propagated to POJOs, and will greatly help 
in unittesting. And the above is a lot 'sweeter' than going through the 
LoggerFactory for each level. But I do agree that many won't accept this, 
because they think it is troublesome.


For now, this is all I can think of.


Cheers
Niclas