<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Aug 20, 2009, at 8:22 AM, 近藤 健 wrote:</div><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><pre style="margin: 0em;">
---

I think there is advantage using enum definition&nbsp;discussed below.

enum has information of package and definition class and field.
Using this feature , I've designed 3 feature.

1. log message definition using enum
For example sample code, it can define enum with log message. so developer don't need to write property file. property file must ensure consistency to log id by hand. enum and annotation do by compiler.
</pre></div></blockquote><div><br></div>This is interesting. Providing the non-internationalized message text along with the key would make it easy to create a non-localized version of a product and then localize it later just by adding files.</div><div><br><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><pre style="margin: 0em;">
2. default property file
 Because enum has class definition, log api is referable declared class of enum.
Log api can load propery file from using declared class name.
for example if enum class name is "example.LogMessages", default propery file is "example/LogMessages.properties".
</pre></div></blockquote><div><br></div>Keep in mind that it isn't a great idea to have the localized files only be able to be loaded via the classloader. Ideally, they should be in a CMS. However, this pattern could still be useful for that. It is handy having the "bundle name" associated with the key.</div><div><br><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><pre style="margin: 0em;">
3. package
 EnumMap must create per enum class. so if log id is enum, they aren't duplication.</pre></div><br></blockquote></div><br><div>You're saying this prevents duplicate message keys? This one is not something I worry about.</div><div><br></div><div>In this approach SLF4J would at least have to be able to serialize the enum and include the relevant parts - the class name, id and message.</div><div><br></div><div>Ralph</div></body></html>