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 8:31:11 am
List:org.slf4j.dev

Hi Ralph,

Whether or not resource bundles suck in our opinion, they are the standard approach to this so I believe we can't just dismiss them.

I'm also unsure how, in your approach, a framework would provide i8ln'ized log messages which would be used?

On 17 Aug 2009, at 22:41, Ralph Goers wrote:

My 2 cents.

ResourceBundles suck. Even in Java 1.6 it is difficult to change the implementation and it only works if the application cooperates. The default implementation finds the bundles in the classpath which makes it difficult if you like to store the files outside of the application. Also, since they are loaded on the classpath they aren't automatically reloaded when modified. My organization also has "special" needs when it comes to internationalization - a single application can support thousands of clients each of which may want to override some of the keys in the bundles.

In short, it seems to me to make far more sense to use a separate I18n framework to deal with the actual message text and then just make sure that SLF4J can accept the Locale as a parameter to be passed to the Appender.

Another option along the same lines would be to use the message field as the message key, along with the parameters and pass those to the Appender along with the locale. There again, an I18N framework would deal with the messages.

In short, SLF4J should support I18N but not implement it.

FWIW - I have a need to implement an I18N framework based on Apache Commons Configuration to support the needs I discussed in the first paragraph. I'm considering doing it in the existing I18N project in the Apache Commons Sandbox.

On Aug 17, 2009, at 10:05 AM, 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.

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) - the ability to log an enum value (rather than using a static to hold the message/key) - 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, 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

But I'm sure others have given this more thought than me!