Avalon way (to inject the logger as any other service) is my preferred
approach to logging. I really don't understand why this pattern is not
used by every other logging framework.
In jSPF instead we added our own Logger interface, but I think that this
is not a good solution if everyone start adding new "cloned" interfaces.
We did this because jSPF was not bound to Avalon, so we simply took the
Logger interface from there and used for our purpose (with injection).
I would avoid the "standard" use of static methods inside classes to
lookup the logger (Logger.getLogger / Log.getLogger) and I prefer to
keep dependency injection for the logger service. We could inject
something different from Avalon Logger and then use a wrapper to keep
compatibility with the current components/container.
e.g: refactor our components to expect a Commons-logging logger (like
IMAP classes do) to be injected. We can then use a wrapper (it already
exists in our codebase, because of IMAP stuff, IIRC).
The main "problem" with this solution is the lack of getChildLogger in
commons-logging: we make use of it (not too much, but we do). Joachim
introduced the MyLogFactory interface as a solution to this issue.
Another approach is to avoid the use of getChild by using always
container managed components or using container managed factories when
we need "wired" sub-components.
Stefano
robert burrell donkin ha scritto:
one of the aims of the modularisation is to factor out the container
dependency into the deployment module. function, library and api code
should be container agnostic. this should make the code base more
approachable and allow the development of other container options.
one of the major issues that's going to need to be decided is logging.
ATM JAMES mostly uses AbstractLogEnabled for logging. this introduces
a deep coupling to the avalon framework.
a couple of reasonable options:
* accept that JAMES is coupled to avalon framework through the logging API
* create a lighter JAMES specific replacement for AbstractLogEnabled.
code in non-deployment modules extends that class. code in the
deployment module (whether through byte code enhancement or manual
subclassing) retrofits a logging aspect adapted to the framework.
opinions?
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
