At 06:39 AM 8/6/2005, Niclas Hedhman wrote:
On Saturday 06 August 2005 05:02, Joerg Hohwiller wrote:
> Anyways if you make it this way: the syntax with "{}" for me looks like
> you are NOT using java.text.MessageFormat. Why is that? You do not need
> to reinvent the wheel here. But maybe I am missing something.
When I asked about this earlier, I was informed it was due to performance
reasons.
Yes, indeed.
[snip]
The utility method you are suggesting, is in fact a kind of facade, and we
are
in the "Simple Logging Facade for Java" project. The name seems to suggest a
single facade, but I am somewhat inclined to believe that a multi-tier
approach (I think originally suggested by Greg) is probably better.
That means that several interfaces are available, for different needs and the
challenge is about a Factory that can create what I need. I think that a
*culture* of several but simpler interfaces will foster more invention,
adaption and 'cheaper' evolution.
public interface PrimordialLogger
{
boolean isEnabled();
void log( Object[] data );
// effectively the only interface needed, seen from a pure
//computing point of view.
}
public interface TraditionalLogger
{
// Full set according to Ceki's evolutionary path.
// Markers, many method signatures, i.e a heavy interface.
}
public interface SimpleIoCLogger
{
String getName();
String getChildLogger( String childname );
boolean isDebugEnabled();
void debug( String message );
boolean isInfoEnabled();
void info( String message );
boolean isWarningEnabled();
void warn( String message );
void warn( String message, Throwable e );
boolean isErrorEnabled();
void error( String message );
void error( String message, Throwable e );
}
The ILoggerFactory need to be instructed what type to return, so either the
above interfaces need a supertype, or the factory returns a Object (IMHO,
same thing, since cast is unavoidable).
public interface ILoggerFactory
{
Object getLogger( String name, Class type );
// Convenience method;
// return (TraditionalLogger) getLogger( name, TraditionalLogger.class );
TraditionalLogger getLogger( String name );
}
I this train of thought has any bearing, then the next step is to work out an
SPI that is usable, but I'll leave that for later.
This is train of thought is one of the achievements of the discussions
we had so far. IMHO, the quality and depth of those discussions well
went beyond what one commonly encounters in os mailing lists.
A wise researcher once said that when confronted with a hard problem,
identify a more abstract version of the problem and try to solve the
latter. Greg and your approach seems to be aligned with that
philosophy. When you work out a usable API, do not forget where you
discussed it first. :-)
Wishing you a nice weekend,
Cheers
Niclas
--
Ceki Gülcü
The complete log4j manual: http://www.qos.ch/log4j/
_______________________________________________
dev mailing list
[email protected]
http://slf4j.org/mailman/listinfo/dev
