[slf4j-dev] slf4j i8ln

[Ceki Gulcu]

Comments inline.

Pete Muir wrote:
> Hi,
> 
> As discussed here https://jira.jboss.org/jira/browse/WBRI-290, we would 
> like to switch to slf4j as our logger (it offers a logging facade, 
> supports MDC/NDC and parameter replacement).
> 
> However, as Takeshi highlights here 
> https://jira.jboss.org/jira/browse/WBRI-214, a needed feature is 
> explicit i8n support, and it sounds like Ceki would be happy to accept a 
> contribution for this directly to the slf4j.

Indeed. Assuming we can design a useful i18n extension to sfl4j, I would like it 
to ship within the slf4j distribution.

> Perhaps, to get started, we should discuss the overall design and aims. 
> In the linked issue, Takeshi adds three features in the patch:
> 
> - ability to localize a message by providing a resource bundle, which 
> has the same name as the class using the logger (the declaring class)

Using resource bundles for localization make sense. I am unsure whether the 
resource bundle should be related to a logger's name but we can come back to 
this later.

> - the ability to log an enum value (rather than using a static to hold 
> the message/key)

Using emums? Interesting. How could enums be used instead of String as enum is 
not a specific type in itself (in the same way as class is not a type in itself).

What do you mean by static? Perhaps you meant to say String instead of static?

> - the ability to associate the level at which to log with the message 
> with the enum (via an annotation) rather than in the call from the 
> declaring class

Takeshi mentioned that his requirement was to be able to change the level of a 
logging statement without needing to recompile his application. I don't see how 
annotations help in this case since they also need to be recompiled.

Markers allow for a cleaner way of filtering out messages. Changing the level is 
unnecessary. For example, if all logging events of level ERROR trigger an alarm, 
and if a certain ERROR event should not trigger an alarm, you can mark that 
particular event with the "NO_ALARM" marker.

Instead of debating the requirements, how about code that embodies your vision 
of the API (assuming everything was possible)?

For example, here is a vision of the i18n API:

   LoggerContext lc = (LoggerContext) LoggerFactory.getILoggerFactory();
   lc.addResourceBundle( aResourceBundle);

   Logger loggerA =  LoggerFactory.getLogger("A");
   Logger loggerB =  LoggerFactory.getLogger("B");

   // replace key_0 with its corresponding value in aResourceBundle
   loggerA.info("key_0");

   // same as before, but also insert the value of "param" as specified in
   // the message
   loggerB.info("key_1", param);

The above is just an *example* of what I mean by "vision" of the API.

You can go a step further an implement something. You may wish to fork SLF4J on 
git. The url is http://github.com/ceki/slf4j/tree/master

> (Takeshi, correct me if this is incorrect). I think we can probably 
> separate these features out when discussing.
> 
> I think we would also need:
> 
> - ability to specify the resource bundle to use when getting the logger
> - ability to use statics fields or just a string id embedded in call to 
> logger

Static field of type String? If the field is of type String, it does not matter 
whether the variable is an instance variable of a static one. (In a nutshell, I 
don't get it.)

By the way, for quicker response time, you can reach me on irc: 
irc.freenode.net #slf4j

Cheers,

-- 
Ceki Gülcü
Logback: The reliable, generic, fast and flexible logging framework for Java.
http://logback.qos.ch