atom feed44 messages in org.slf4j.devRe: [slf4j-dev] slf4j i8ln
FromSent OnAttachments
Pete MuirAug 17, 2009 10:05 am 
Ralph GoersAug 17, 2009 2:40 pm 
Pete MuirAug 18, 2009 6:37 am 
Ralph GoersAug 18, 2009 7:10 am 
近藤 健Aug 18, 2009 9:59 am 
Pete MuirAug 19, 2009 8:31 am 
Ralph GoersAug 19, 2009 9:15 am 
Ceki GulcuAug 19, 2009 11:17 am 
Pete MuirAug 19, 2009 11:20 am 
Pete MuirAug 19, 2009 11:29 am 
Ceki GulcuAug 19, 2009 11:42 am 
Pete MuirAug 19, 2009 11:51 am 
Ceki GulcuAug 19, 2009 12:38 pm 
Ralph GoersAug 19, 2009 1:42 pm 
Ceki GulcuAug 19, 2009 1:58 pm 
Ceki GulcuAug 19, 2009 2:15 pm 
Ralph GoersAug 19, 2009 2:21 pm 
Ralph GoersAug 19, 2009 2:31 pm 
Ceki GulcuAug 19, 2009 2:40 pm 
近藤 健Aug 20, 2009 8:22 am 
Ralph GoersAug 20, 2009 8:35 am 
Takeshi KondoAug 20, 2009 10:07 am 
ralp...@dslextreme.comAug 20, 2009 10:20 am 
Ceki GulcuAug 20, 2009 1:58 pm 
Ceki GulcuAug 20, 2009 2:05 pm 
Takeshi KondoAug 21, 2009 10:28 pm 
Takeshi KondoAug 22, 2009 10:32 pm.jar, .jar
Ralph GoersAug 23, 2009 8:21 am 
Takeshi KondoAug 23, 2009 8:40 am 
Ceki GulcuAug 23, 2009 10:38 am 
Takeshi KondoAug 23, 2009 4:59 pm 
Ralph GoersAug 23, 2009 9:56 pm 
Ceki GulcuAug 24, 2009 6:14 am 
Takeshi KondoAug 24, 2009 10:02 am 
Ceki GulcuAug 24, 2009 10:22 am 
Takeshi KondoAug 24, 2009 11:05 am 
Ceki GulcuAug 24, 2009 11:27 am 
Takeshi KondoAug 24, 2009 12:36 pm 
Ceki GulcuAug 24, 2009 12:56 pm 
Takeshi KondoAug 24, 2009 1:15 pm 
Ceki GulcuAug 24, 2009 1:24 pm 
Ralph GoersAug 24, 2009 1:33 pm 
Takeshi KondoAug 24, 2009 2:02 pm 
Ceki GulcuAug 25, 2009 1:32 am 
Subject:Re: [slf4j-dev] slf4j i8ln
From:Pete Muir (pmu@redhat.com)
Date:Aug 19, 2009 11:29:25 am
List:org.slf4j.dev

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