avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vincent Massol" <vmas...@octo.com>
Subject Re: Logging, LogKit, JDK1.4 Logging ...
Date Wed, 28 Nov 2001 22:28:37 GMT
Following Peter's suggestion and my need to use log4j as the logger for my
components (with ExcaliburComponentManager), I have modified the excalibur
component.* classes to support other loggers. I'm still testing if it works
but your mail on this subject prompted this early response.

Basically I have made almot all the classes implement LogEnabled
(ComponentManager, ComponentHandler and ComponentFactory) and make sure the
manager initializes the log eanbled Logger for the handler and the handler
for the factory so that we have in the factory a valid
org.apache.avalon.framework.Logger object.

The biggest change I have made is in the factory where I have added a
makeLogEnabledLogger() which creates a logger implementation for the
component, based on the type of logger from the factory. Thus, if you
initially write :

manager.enableLogging ( new Log4JLogger(Category.getInstance("....")));

then, the components that implement LogEnabled will get a Log4JLogger.
Writing this, I just realised that I forgot to take into account the case
were the user would not have called enableLogging on
ExcaliburComponentManager. We will simply need to add this case to
makeLogEnabledLogger and default to logkit.

In order to be able to compile even without log4j, I have used reflection to
create a log4j logger. I have not paid attention to performance in this
implementation and it can be improved performance wise. At this point, I
wanted to verify if it would work and wanted to get your feedback.

As I said to Peter, I'm on a production project that has been going on for a
while and which has standardised on log4j and they don't want to change.
However, I'd like to bring in avalon, mainly as a demonstrator of how to
code properly (and so that unit tests can be easily written for components
using mock objects). I have the option of using the modifed component.*
package but I would of course like to benefit from excalibur's modifications
so I would of course prefer if it could be quickly included within the
excalibur codebase. I am willing to help improve this first implementation
if you agree on principle. As you are moving towards neutral Logger anyway,
it seems to be inline with excalibur's future.

Thoughts ?

Note: I have not looked in detail in the excalibur sources so I am not
familiar to any problem my changes could have introduced for existing
components. Is there a full unit tests suite that I could run and where can
I find the requirements/instructions for running it (link with environment,
...) ? Any mock object tests ?

----- Original Message -----
From: "Berin Loritsch" <bloritsch@apache.org>
To: "Avalon Developers List" <avalon-dev@jakarta.apache.org>
Sent: Wednesday, November 28, 2001 1:35 PM
Subject: Re: Logging, LogKit, JDK1.4 Logging ...

> Bachran, Michael wrote:
> > Hi everybody,
> >
> > Unfortunately I missed the invention of the LogEnabled stuff?
> >
> > Currently I am using the Framework along with the
> > (ECM) (Release 4.0). Along with the ECM comes LogKit.
> > As the project started using Log4J I am planning to shift to LogKit now
> > get rid of one of two loggers.
> >
> > I am currently wondering if LogEnabled will simply replace Loggable
> > for abstract classes) and if this has something to do with shifting to
> > compatibility with the upcomming JDK1.4 Logging API.
> > I also want to use the LogKitManagement along with LogKit.
> > At least I would like to know if the interface is stable or I should
> > with shifting till the changes have been applied.
> Rest easy Michael.
> The LogEnabled and Logger interfaces is a straight replacement for the
> Loggable interface.  The difference is that you are now not _tied_ at the
> framework level.  The ExcaliburComponentManager is still LogKit centric,
> and will remain so for a while.
> The interface for the Framework Logger interface is exactly the same as
> the public portion of the LogKit interface.  Our first loyalty is to the
> LogKit package--although we do not want to alienate potential users who
> want to use it.  In the end, you now have a public interface that is
> no matter what Logging package you use.
> --
> "Those who would trade liberty for
>   temporary security deserve neither"
>                  - Benjamin Franklin
> --
> To unsubscribe, e-mail:
> For additional commands, e-mail:

View raw message