Well... I try to explain by telling you how our (non-Phoenix ported)
applications use our Log4j extensions. As I write this description, it
seems to me that it would be very difficult for a logger facade to be able
to support this type of extensions. So, maybe I'll conclude with some
proposals for how I would solve my "problem".
Here's how our apps use our Log4j extensions. We have a class that extends
Logger, call it MyLogger. We've added a couple of new log levels between
info and debug, called verbose and trace. We've also overloaded the fatal,
error, warn, and info methods to hook into our resource bundles and custom
exception hierarchy for internationalization/advanced error handling of some
messages.
We added a MyLogger.init(...) method to our logger, that initializes our
exception handling/internationalization stuff as well as wraps around the
standard Log4J XML configuration initialization. We call this method on our
custom logger once per JVM startup instead of the Log4j DOMConfiguration
method (because it does more than just configure log4j).
For every class that needs a logger, we follow the recommended Log4j
practice of getting a new Logger instance, namely:
private static MyLogger logger = (MyLogger)
MyLogger.getLogger("com.my.company.this.example.MyClass");
And we make calls to as needed to our logger, such as:
Object[] arg = {getAdapterName()};
logger.info("MY_RESOURCE_KEY_0001", arg, null);
or
if (logger.isTraceEnabled())
logger.trace("Entering: " + this.class.getName() + ".init()");
or
if (logger.isDebugEnabled())
logger.debug("{cmi=[" + cmi + "]}");
Now to turn on logging for one of our custom log levels, in the log4j XML
configuration file, you would set the log level as such by referencing the
class name that defines the custom log level extensions:
<level value="verbose#com.my.company.log.MyLevel"/>
where this MyLevel class extends the Log4J Level class to define some custom
log levels. These custom levels are used by the MyLogger class in its
subsequent implementation of the trace(...) and verbose(...) logger methods
and the isTraceEnable() and isVerboseEnabled() methods.
That's pretty much it, and I hope that made sense to you Peter. The more I
think about it, probably what I need to do is somehow be able to execute
MyLogger.init(...) method at Phoenix startup since it only needs to be done
once per JVM. Wherever the log4j XML configuration files are loaded from,
support for knowing custom level extensions should be there. I'm really
suspect that getLogger() from the AbstractLogEnabled framework could really
return me a MyLogger that would have visibility to my custom logger methods,
but maybe you have ideas there. If push comes to shove, then each
class/block could just call the Log4J getLogger() method directly. It lock
my application into using Log4J, but my company really has already made that
decision by investing into extending Log4J and integrating it with our
exception handling processes.
"Peter Donald" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> On Thu, 29 May 2003 01:37 am, Timothy Bennett wrote:
> > Could I extend the Logger abstraction in my Phoenix application, and
> > somehow "inform" Phoenix or the underlying framework about the extention
> > logger abstraction?
>
> How does Log4J ususally handle this? If I can figure this out I may be
able to
> add support it.
>
> --
> Cheers,
>
> Peter Donald
> ----------------------------------------
> Whatever you do will be insignificant,
> but it is very important that you do it.
> --Gandhi
> ----------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
