There was discussion a few years back that was spread across several
mailing lists on localization of logging, see http://article.gmane.org/gmane.comp.jakarta.commons.devel/59103/
for a jumping off place. Searching for "localization" on the
mailing list has two many false hits on Gump messages, searching for
I18N and L7D hit more relevant matches.
Not having looked at your code, my instinct would be to go with a
utility class approach like LogMF and LogSF in the extras companion.
Where the call would end up like:
LogL7D.info(logger, ....)
Will try to review your code over the weekend. Thanks for the
submission.
On Jul 1, 2009, at 2:02 PM, [email protected] wrote:
I've written an enhancement to the localization support the generic
Logger class provides.
A new LocalizedLogger overrides basic log4j logging methods
(trace(), debug(), info(), warn(), error(), fatal()) to use a
localization mechanism. Instead of the actual log messages, keys to
localization log messages can be passed into these logging methods.
Full parameterization is supported. If keys are not found in the
ResourceBundle, they are logged directly, skipping the localization.
Internally, LocalizedLogger simply calls the l7dlog() method that
already exists in Logger. LocalizedLogger is just a convenience
class for applications that don't want to call this special method.
A LocalizationResourceBundle and a LocalizedLoggerFactory classes
are also included. These helper classes provide easy integration
with your application by simply changing the loggerFactory defined
in the log4j configuration to point to this new
LocalizedLoggerFactory.
I've attached an SVN diff that can be applied to log4j trunk.
Thanks,
Manish
<localization.patch>
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
