[slf4j-dev] Review of slf4j

[Ceki Gülcü]

At 08:20 5/5/2005, Niclas Hedhman wrote:

>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?

The intent is to allow a logger to inherit properties from multiple 
dimensions. Currently, there is a single dimension but there are situations 
where it can be beneficial for a logger to be in two dimensions. The first 
incarnation of log4j had this capability, which was later dropped due to 
performance considerations. IMHO, it's a killer feature, a bit like how 
inheritance in logger trees was a killer feature of log4j.


>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.

In the current code, only a single world needs to be substituted during the 
build process. If LoggerFactory+LoggerFactorAdapter+ImplFA where collapsed 
into LoggerFactory, then the amount of code that would need to be 
substituted at build time would be "large", resulting in a more complicated 
build file.

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

Yes, performance is the reason. The home-cooked MessageFormatter does the 
job quite well already, and there is still room for improvement. 
java.text.MessageFormat is slower because it is a more general tool.

>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.

The current structure imposes that LoggerFactorAdapter implementations be 
located in the org.slf4j.impl package. I believe it to be a minor 
limitation but with the advantage of resulting in simpler build files.
The idea is to propose a very simple cut-and-past recipe for building 
LoggerFactorAdapter implementations. Let me add that initial versions of 
UGLI allowed the whole class name (including the package) to vary.

>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.

I read the above paragraph to be about subdomains. If so, the general 
problem of manufacturing loggers in application frameworks is not affected 
by subdomains. A good solution for manufacturing a logger in a single 
dimension is also likely to be a good solution in 2 dimensions. Similarly, 
a bad solution in 1 dimension is also likely to be a bad solution in 2 
dimensions. Or am I off base?


>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.

How many pojo's are there that take a Logger in their constructor? Phrased 
differently, is it the job of the App framework to provide loggers to the 
objects that it instantiates?

>For now, this is all I can think of.
>
>Cheers
>Niclas
>
>_______________________________________________
>dev mailing list
>dev at slf4j.org
>http://slf4j.org/mailman/listinfo/dev

-- 
Ceki Gülcü

   The complete log4j manual: http://www.qos.ch/log4j/