I was thinking along the lines of making it simpler to do logging. For
example, right now to add a log message, I would have to
1. initialize
2. getInstance
3. log the message
In the process, I have to specify the Category of the logger and the
messages.properties file .
I was thinking of, what if we could just simply do Logger.info(String
messageKey);
Since David mentioned the i18n inheritance, the Logger could use that
"standardized location" to its advantage.
For example,
Lets say I have a class org/apache/openejb/Dummy.class
I also have a org/apache/openejb/Messages.properties
I also have a org/apache/openejb/util/Logger
The Messages.properties has a key named "key1"
In the Dummy class, lets say I have a method named dumDum() as shown below:
public void dumDum(){
Logger.info("key1");
}
Now here is what the Logger.info method could look like:
// the info method could support varargs too
public static void info(String messageKey){
String callerPackage = getCallerPackage("info");
// now use this package information to grab the messages.properties
file for that package
// extract the key out of it and log the message
}
private static String getCallerPackage(String methodName){
String callerPackage = null;
StackTraceElement[] stackTrace =
Thread.currentThread().getStackTrace();
StackTraceElement caller = null;
for (int i = 0; i < stackTrace.length; i++) {
if(stackTrace[i].getMethodName().equalsIgnoreCase(methodName)
&&
stackTrace[i].getClassName().equals("org.apache.openejb.util.Logger"))
caller = stackTrace[++i];
break;
}
callerPackage = caller.getClassName().substring(0,
caller.getClassName().lastIndexOf("."));
return callerPackage;
}
Since Logger categories also have an inheritance heirarchy, i.e a
logger a.b.c is a child of a.b which is a child of "a" . In a conf
file, I can set the appenders and log level for "a" and "a.b" and
"a.b.c" will inherit from it. So, if i had to lets say change the log
level for a.b , then i can do that through the logging conf file. We
could even provide for adding it to system properties and changing it
from there , this will allow us to change it from the command line
only for that run of the build or test.
How this single instance of Logger will manage Logging using either
java.util.logging or log4j would be a separate issue and can be
discussed later. Right now I want to just throw in this idea as an
immediate benefit from the i18n inheritance heirarchy proposal of
David.
What do you think?
On 6/21/07, David Blevins <[EMAIL PROTECTED]> wrote:
There have been a couple things I thought would be neat additions for
the i18n side of our logging code. Basically, inheritance.
Say you have the following Messages.properties files in the classpath.
A org/apache/openejb/Messages.properties
B org/apache/openejb/core/Messages.properties
C org/apache/openejb/core/stateless/Messages.properties
Then you have a class such as
org.apache.openejb.core.stateless.StatelessContainer (note the package)
If that class referenced a message key "classNotFound" for example,
the i18n code would look for the message first in Messages.properties
C, then B, then A and so on until it found the required message.
This would allow better reuse of messages, more flexibility in where
we put the Message.properties properties files, as well as the added
bonus in that we no longer need to pass in the location of where our
Message.properties file is like we do now -- we'd just use the class'
package name.
The trick would be performance. On that regard we could unroll
upfront and do no backwards walking during actual usage or we could
backwards walk on demand and cache for future lookups. Maybe some
other clever tricks we could do.
Thoughts?
-David
--
Karan Malhi
