Comments inline.
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.
Indeed. Assuming we can design a useful i18n extension to sfl4j, I would like it
to ship within the slf4j distribution.
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)
Using resource bundles for localization make sense. I am unsure whether the
resource bundle should be related to a logger's name but we can come back to
this later.
- the ability to log an enum value (rather than using a static to hold
the message/key)
Using emums? Interesting. How could enums be used instead of String as enum is
not a specific type in itself (in the same way as class is not a type in itself).
What do you mean by static? Perhaps you meant to say String instead of static?
- 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 mentioned that his requirement was to be able to change the level of a
logging statement without needing to recompile his application. I don't see how
annotations help in this case since they also need to be recompiled.
Markers allow for a cleaner way of filtering out messages. Changing the level is
unnecessary. For example, if all logging events of level ERROR trigger an alarm,
and if a certain ERROR event should not trigger an alarm, you can mark that
particular event with the "NO_ALARM" marker.
Instead of debating the requirements, how about code that embodies your vision
of the API (assuming everything was possible)?
For example, here is a vision of the i18n API:
LoggerContext lc = (LoggerContext) LoggerFactory.getILoggerFactory();
lc.addResourceBundle( aResourceBundle);
Logger loggerA = LoggerFactory.getLogger("A");
Logger loggerB = LoggerFactory.getLogger("B");
// replace key_0 with its corresponding value in aResourceBundle
loggerA.info("key_0");
// same as before, but also insert the value of "param" as specified in
// the message
loggerB.info("key_1", param);
The above is just an *example* of what I mean by "vision" of the API.
You can go a step further an implement something. You may wish to fork SLF4J on
git. The url is http://github.com/ceki/slf4j/tree/master
(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
Static field of type String? If the field is of type String, it does not matter
whether the variable is an instance variable of a static one. (In a nutshell, I
don't get it.)
By the way, for quicker response time, you can reach me on irc:
irc.freenode.net #slf4j
Cheers,
--
Ceki Gülcü
Logback: The reliable, generic, fast and flexible logging framework for Java.
http://logback.qos.ch
_______________________________________________
dev mailing list
dev@slf4j.org
http://www.slf4j.org/mailman/listinfo/dev
