On 19 Aug 2009, at 19:18, Ceki Gulcu wrote:
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 like Ralphs suggestion of abstracting this behind a interface and
providing a default impl based on ResourceBundle.
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).
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 do you mean by static? Perhaps you meant to say String instead
of static?
I meant a static String like
class LogMessages {
public static final String WRONG_PASSWORD = "com.acme.WrongPassword";
}
- 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.
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 :-)
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
Sounds like a good idea. I'll talk to Takeshi.
(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.)
Yes, it has no practical impact on the implementation of course :-)
_______________________________________________
dev mailing list
dev@slf4j.org
http://www.slf4j.org/mailman/listinfo/dev
