[slf4j-dev] slf4j i8ln

[Pete Muir]

On 19 Aug 2009, at 19:18, Ceki Gulcu wrote:

> 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 like Ralphs suggestion of abstracting this behind a interface and  
providing a default impl based on ResourceBundle.

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

Sorry, I was being loose with my language. I meant using an enumerated  
type such as

enum LogMessages {

    WRONG_PASSWORD, RIGHT_PASSWORD
}

log.warn(WRONG_PASSWORD);

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

I meant a static String like

class LogMessages {

public static final String WRONG_PASSWORD = "com.acme.WrongPassword";
}

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

Yes, I'm also not sure that this is necessary, and it's certainly  
another concern not really relating to i8n IMO.

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

Hehe, sure, I definitely like to understand the requirements properly  
first, but I know others prefer a hack first approach :-)

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

Sounds like a good idea. I'll talk to Takeshi.

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

Yes, it has no practical impact on the implementation of course :-)