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.
On Saturday 06 August 2005 06:07, Curt Arnold wrote:
> I agree that the number of methods and code duplication is
> undesirable. Maybe it would be better to isolate all the formatting
> variants into a single concrete LogFormat class and have the Logger
> interface only supply the most basic of the log methods that the
> actual implementation would need to provide. Something like:
>
> // direct use of org.slf4j.Logger
> logger.debug("Hello, world");
>
> or
>
> LogFormat.debug(logger, "Hello, {}.", location);
>
> which could be implemented:
>
> public static void debug(Logger logger, String format, Object param1) {
> if (logger.isDebugEnabled()) {
> logger.debug(MessageFormat.format(format, param1));
> }
> }
Another neutral observation is that the "format" is only part of the total
format, as additional format information is associated with the "destination"
(Log4J lingo --> Appender).
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.
Cheers
Niclas
_______________________________________________
dev mailing list
[email protected]
http://slf4j.org/mailman/listinfo/dev
