On Aug 20, 2009, at 8:22 AM, 近藤 健 wrote:
---
I think there is advantage using enum definition 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.
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.
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".
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.
3. package
EnumMap must create per enum class. so if log id is enum,
they aren't duplication.
You're saying this prevents duplicate message keys? This one is not
something I worry about.
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.
Ralph
_______________________________________________
dev mailing list
dev@slf4j.org
http://www.slf4j.org/mailman/listinfo/dev
