> - The logging interface DO NOT take a single argument of message. In
> fact, it uses a selection of multiple arguments. So the
> logging call is
> basically with the bundle name, message ID and the arguments. In fact,
> this is more efficient, it is because we don't spend time on
> packing up
> the message with its argument and log the message with a log level.
> Meanwhile the parent category has a lower log level.
I'd imagine this isn't more efficient because you have more stuff kicking
about in each method call. In fact, the log4j logging methods take either
an object (which is later toString()'d) or an object and a throwable. I've
found this completely adequate so far.
I think including the bundle name and message ID (not sure exactly what
these are) in each call to the logger would get tedious for a programmer.
I just use _logClass, a category corresponding to the class I'm currently
in. This works fine and I can filter the output in a hierachical manner
later. All my logging output looks like this:
_logClass.debug("Parsing input parameters");
_logClass.warn("Invalid value for 'foo' parameter: " + fooParam);
_logClass.warn("Caught unexpected exception", e);
> - We separate the format of logging and localisation from the actual
> log file. The actual log file is in some internal format (such as XML).
You're claiming efficiency and then storing the log in XML? I really like
XML and think that the approach has merit, but efficient it ain't. ;-)
As for native language stuff, our code is written by English speaking staff,
and all of our foreign offices speak english to some extent too. Surely
the cost of translating your log messages is prohibitive? How does it work?
Are all log messages retrieved from a string bundle?
> - With log messages stored in raw format, the logging time
> can be stored as the number of milli secs instead.
If you use the JDBC appender you can throw log messages into a database
and use SQL queries to find, sort and display messages.
> - The log level value should be in bitset, ie, 1, 2, 4, 8, 16, etc,
> etc, such that we can filter log messages in either threshold or
> bitset manners. Not just threshold.
We use ERROR, WARN, INFO and DEBUG. That's plenty of log levels already,
in my opinion. *grin* I have a different category for each class that
produces log messages. Between the two, I've got more filtering options
than I can handle already.
In short I think Log4j does everything I want it to. If your product does
funky things like native language logging and has a decent UI tool for
viewing log messages, I think those are valuable additions, but I'm not
likely to switch.
Best regards,
Mike.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
