Richard, I am not a great big fan of lots of layers. I would like to use the log API directly, that way I only have to know the *common* log api (which is already a layer) and I know how to use things. It would be a little bit of sugar not to have to call the getMessage() inside every log call, but cut/paste and our unit test that enforces the requirement that we use getMessage() makes this not a problem in my book. I would NOT be in favor of adding another logging layer.
I think getting a message APIs should live in the Message class, not the logging class. Every class has a function... I believe we have something (the JVM?) that enforces the rule that every key have an associate text in the properties file. At least when I add a call without the text, things don't work for me, but what you propose (dumping the key with a warning) sounds reasonable. -- Tom Jordahl Macromedia Server Development -----Original Message----- From: Richard Sitze [mailto:[EMAIL PROTECTED]] Sent: Wednesday, September 18, 2002 12:41 PM To: [EMAIL PROTECTED] Subject: [axis] Messages & Logging : change direction? I'd appreciate more than a silent consent from Tom & Glen :-) Given the changes that are being discussed for Messages, now would be a GREAT time to: - introduce a layer on top of logging that accepts message keys directly: I18NLog - let I18NLog perform translation - expose getMessage() from I18NLog instead of Messages (this is the ONE piece I'm a bit uncomfortable with . . .) for other xlations (exceptions) - if key doesn't map to text, then just dump key (issue debug/warning)? Note that we already pass the Class name (i.e. package name) to LogFactory, and to make Messages aware of the class name we would be doing the same. . . Thoughts? <ras> ******************************************* Richard A. Sitze IBM WebSphere WebServices Development
