[slf4j-dev] Re: Beta 4 and the new method signatures

[Greg Wilkins]

Ceki,

it's good to participate in a receptive discussion.... even if the end product
is to keep the current API as it is.

Ceki Gülcü wrote:
>> So there is a use for a very simple logger like:
>>
>>  public interface Log
>>  {
>>      boolean isEnabled();
>>      void log( String message );
>>      void log( Throwable throwable );
>>      void log( String message, Throwable throwable );
>>      void log( String format, Object arg );
>>      void log( String format, Object arg1, Object arg2 );
>>  }
>
> All right, the above raises a fundamental question but (in my humble
> opinion) also makes a false assumption. Take for example request
> logs. Do you think any of the methods in interface Log is appropriate
> for requests logs?

I kind of consider that the only true method in this API is
log(String) and the others are just conveniance methods for
effecient formatting.

So I do think that log(String) is appropriate for a request log,
as is isEnabled().     I could even make a case for log(String,Throwable)
if I was to have a request log that did not conform to NCSA format.

I could also live with log(Object) as the fundamental methed,
but slf4j appears to take that approach that logs are for strings not objects.

> As for the second use case, servlet context logs are a degenerate case
> of logging. It's degenerate in the sense that the user cannot specify
> a logger nor a level. Otherwise, as far as I can tell, there is
> nothing special about servlet context logging.

Agreed - but it is still confusing to require a logger with
log levels that are unused by the servlet context logging.

The log level is communicated via the API and then needs to be
ignored when formatting the log.   I have seen applications
pass their own text levels and you see silly things like:

  INFO: WARNING: application failed.


>> ...
> It's indeed workable but is it better? As mentioned previously, I think
> that the simplified Log interface does not solve the extra use cases.
>
> If "info" is a logger, then
>
>   info.log("doing something now");
>
> is not exactly the same as
>
>   logger.info(""doing something now");
>
> While both statements are likely to be allowed to print on the output
> devices, the first statement would leave no clue about the origin of the
> log whereas the second form would print the logger name (hence the class
> name).

I think these are both statements are equivalent.  Neither gives the location
of the source - both only give the scope that the logger was declared in.

It just so happens that by convention the logger.info("something") style
has a logger per class.   There is nothing in the simple Log API that prevents
you having an info logger per class if you feel the need.

Personally I like my debug statements to be very well located (and would
probably appreciate the option of an inefficient file:line location
mechanism).   But I see very little reason to have a tight scope for
errors and warnings (often with a stack trace has the detailed location).
If an info is ambiguous then perhaps it is not actually logging very much
"information"

I still think it is a good question to ask - why does the current API
force the same scope on debug, info, warn and error?
Is it just for simpicity of usage or is there another reason to tie
their scopes together?

> The bottom line is that class scopes logging (for levels INFO, WARN,
> ERROR) yeilds a little more functionality and flexibility at the cost of a
> fatter API.

I disagree that it is more flexible or functional - both have the same
power and can provide the same scoping.

But I think the "fat" API is simpler for the common usage but unwieldy for more
complex use-cases.

And I think the "thin" API is simpler for the complex use-cases but overly
verbose
if you want the class scoping for all log leves.



Hence my suggestion of looking for a way to do both.   The current "fat" API
is perfect for 90% of common usage give or take a few niggles about trace.

But because of it's fatness it is difficult to extend and uncomfortable to
use in some use-cases.    So if there is a layer that we can peal off the "fat"
API and reveal an underlying "thin" API then that can be used for the more
complex use-cases.

So the question is - is there such an underlying "thin" API? and is there
enough need for it to make it worth the complexity of exposing it?

cheers





--
Greg Wilkins <gregw at mortbay.com>


----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.