Re: [slf4j-dev] slf4j i8ln
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. Ralph 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! Pete ___ dev mailing list dev@slf4j.org http://www.slf4j.org/mailman/listinfo/dev ___ dev mailing list dev@slf4j.org http://www.slf4j.org/mailman/listinfo/dev ___ dev mailing list dev@slf4j.org http://www.slf4j.org/mailman/listinfo/dev
Re: [slf4j-dev] slf4j i8ln
On 19 Aug 2009, at 19:43, Ceki Gulcu wrote:
Pete Muir wrote:
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 would the signature of log.warn() look like? Is the following
legal java?
interface Logger {
void warn(enum e);
}
I don't think it is.
This is valid in Java 5 and above. For example:
public interface Logger {
public enum LogMessages {
WRONG_PASSWORD
}
public static class Test {
public void test() {
Logger logger = new Logger() {
public void warn(Enum? message) {
// No-op, this is a mock
}
};
logger.warn(LogMessages.WRONG_PASSWORD);
}
}
public void warn(Enum? message);
}
Of course, this isn't valid in Java 1.4.
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 :-)
Well, I did not actually mean to hack a complete solution but back
up words with at least some example code. Otherwise, it gets too
abstract for me...
Previously, when I wrote: You may wish to fork SLF4J on git. I
meant to say githib not git.
By the way, the archives for this discussion are available from
http://www.slf4j.org/pipermail/dev/2009-August/date.html
Thus, there is perhaps no need to cc Rodney, Takeshi and David. They
can read the discussion from the archives if they wish to. If they
wish to respond, they can do so after subscribing to the d...@slf4j
mailing list. They can't respond to the mailing list without
subscribing first. When replying, I won't add or remove addressed on
my own initiative.
Good point, they know the discussion is happening now at least. I
removed them from the cc.
___
dev mailing list
dev@slf4j.org
http://www.slf4j.org/mailman/listinfo/dev
Re: [slf4j-dev] slf4j i8ln
To follow up on this, Mark Little pointed me at the Common Logging Framework developed by Arjuna as another way this problem has been addressed in the past. See http://docs.jboss.org/process-guide/en/html/internationalization.html#d0e4183 On 17 Aug 2009, at 18:05, 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! Pete ___ dev mailing list dev@slf4j.org http://www.slf4j.org/mailman/listinfo/dev ___ dev mailing list dev@slf4j.org http://www.slf4j.org/mailman/listinfo/dev
[slf4j-dev] slf4j i8ln
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! Pete ___ dev mailing list dev@slf4j.org http://www.slf4j.org/mailman/listinfo/dev
