| From | Sent On | Attachments |
|---|---|---|
| Pete Muir | Aug 17, 2009 10:04 am | |
| Ralph Goers | Aug 17, 2009 2:40 pm | |
| Pete Muir | Aug 18, 2009 6:37 am | |
| Ralph Goers | Aug 18, 2009 7:10 am | |
| 近藤 健 | Aug 18, 2009 9:59 am | |
| Pete Muir | Aug 19, 2009 8:30 am | |
| Ralph Goers | Aug 19, 2009 9:15 am | |
| Ceki Gulcu | Aug 19, 2009 11:17 am | |
| Pete Muir | Aug 19, 2009 11:20 am | |
| Pete Muir | Aug 19, 2009 11:29 am | |
| Ceki Gulcu | Aug 19, 2009 11:42 am | |
| Pete Muir | Aug 19, 2009 11:50 am | |
| Ceki Gulcu | Aug 19, 2009 12:38 pm | |
| Ralph Goers | Aug 19, 2009 1:42 pm | |
| Ceki Gulcu | Aug 19, 2009 1:57 pm | |
| Ceki Gulcu | Aug 19, 2009 2:14 pm | |
| Ralph Goers | Aug 19, 2009 2:20 pm | |
| Ralph Goers | Aug 19, 2009 2:31 pm | |
| Ceki Gulcu | Aug 19, 2009 2:40 pm | |
| 近藤 健 | Aug 20, 2009 8:21 am | |
| Ralph Goers | Aug 20, 2009 8:35 am | |
| Takeshi Kondo | Aug 20, 2009 10:06 am | |
| ralp...@dslextreme.com | Aug 20, 2009 10:20 am | |
| Ceki Gulcu | Aug 20, 2009 1:58 pm | |
| Ceki Gulcu | Aug 20, 2009 2:05 pm | |
| Takeshi Kondo | Aug 21, 2009 10:27 pm | |
| Takeshi Kondo | Aug 22, 2009 10:31 pm | .jar, .jar |
| Ralph Goers | Aug 23, 2009 8:20 am | |
| Takeshi Kondo | Aug 23, 2009 8:40 am | |
| Ceki Gulcu | Aug 23, 2009 10:38 am | |
| Takeshi Kondo | Aug 23, 2009 4:58 pm | |
| Ralph Goers | Aug 23, 2009 9:55 pm | |
| Ceki Gulcu | Aug 24, 2009 6:14 am | |
| Takeshi Kondo | Aug 24, 2009 10:02 am | |
| Ceki Gulcu | Aug 24, 2009 10:22 am | |
| Takeshi Kondo | Aug 24, 2009 11:05 am | |
| Ceki Gulcu | Aug 24, 2009 11:26 am | |
| Takeshi Kondo | Aug 24, 2009 12:36 pm | |
| Ceki Gulcu | Aug 24, 2009 12:56 pm | |
| Takeshi Kondo | Aug 24, 2009 1:15 pm | |
| Ceki Gulcu | Aug 24, 2009 1:24 pm | |
| Ralph Goers | Aug 24, 2009 1:32 pm | |
| Takeshi Kondo | Aug 24, 2009 2:02 pm | |
| Ceki Gulcu | Aug 25, 2009 1:31 am |
| Subject: | Re: [slf4j-dev] slf4j i8ln | |
|---|---|---|
| From: | Takeshi Kondo (take...@gmail.com) | |
| Date: | Aug 21, 2009 10:27:55 pm | |
| List: | org.slf4j.dev | |
If I followed you, the idea is to encode the resource bundle *keys* within enums. You still need to check the consistency of the resource bundle keys, including copies found in various language variations so that they match the enums. I can see how this would be useful if the IDE somehow knew about the the resource bundle keys and the enums and cross checked things. Without tooling support, one would still need to manually match the enum keys with those found in resource bundle. I still don't see the gain with enums. What am I missing?
You don't understand my idea a little. My idea is to use enums as log message id. The resource bundle keys is one of ways binding enums to log messages. Of cause, we need to check the consistency of the resource bundle keys.
public class enum LogMessages{ @Debug("debug log message") TEST0001 }
Log level annotation is one of ways. This is type safe.
If we follow up type safe, there is my thinking idea.
---- Binding enums to log messages by coding
---- public class JapanLogMessages implements LocalizedMessage<LogMessages>{ // return target locale public Locale locale() { return Locale.JAPAN; // target local } // return message bound log message id. public String toMessage(LogMessages logId){ switch (logId){ case TEST0001: // log message id return "japanene log message"; // return localized message } return null; } }
---- Switch case is type safe. In development, enums is useful because it is type safe.
I think enums have application possibility.
_______________________________________________ dev mailing list de...@slf4j.org http://www.slf4j.org/mailman/listinfo/dev






.jar, .jar