----- Original Message -----
From: "Berin Loritsch" <[EMAIL PROTECTED]>
To: "Avalon Developers List" <avalon-dev@jakarta.apache.org>
Sent: Thursday, November 29, 2001 1:42 PM
Subject: Re: Logging, LogKit, JDK1.4 Logging ...
> Vincent Massol wrote:
>
> <snip/>
>
> > Thoughts ?
> > Thanks
> > -Vincent
> >
> > 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 ?
>
>
> Vincent, what you have done is necessary, and very helpful.
Unfortunately,
> it would break bacwards compatibility for ExcaliburComponentManager. This
> is very unfortunate, and I am still looking for an elegant solution.
I am not sure why. For all components implementing Loggable, there is no
change. For components implementing LogEnabled, there is no change provided
that ExcaliburComponentManager.enableLogging(...) is not called without a
logger other than the LogKit logger. As
ExcaliburComponentManager.enableLogging(...) did not exist before, it would
seem to me it is backward compatible [Note: As I said in my previous email,
there is just a slight change to be made in the makeLogEnabledLogger()
method so that is ExcaliburComponentManager.enableLogging(...) is not
called, the default logger is LogKitLogger].
What am I missing ? :)
> I have
> a feeling that the only elegant solution available to me is to have a
clean
> ComponentManager implementation--that must use a different name than the
> ExcaliburComponentManager. I find this frustrating to say the least, but
> perhaps we can optimize the ComponentManagement implementations with the
> new version--that will be LogEnabled clean. People who have not upgraded
> to the new interface will be stuck with ExcaliburComponentManager (as is
> fitting because that is what they are likely to be using).
>
> The problem with such a clean ComponentManager is that all Components used
> in that system MUST be LogEnabled. There is no method of obtaining a
> LogKit Logger instance from a Framework Logger instance.
no, which is why I had to do an if() and enumerate through a list of
well-known loggers in makeLogEnabledLogger(). I woudln't consider this to be
the final implementation but it allows for using LogKit, Log4J and JDK14 for
now, which is already quite good. WRT getting a logger from the Logger
interface, it is almost there : there is method called
getChildLogger(category). I am not sure what it is there for, but it enables
you to get a logger implementation of the same type as the current logger.
"Unfortunately" the current implementation for Log4JLogger is :
public final Logger getChildLogger( final String name )
{
return new Log4JLogger( Category.getInstance( m_logger.getName() +
"." + name ) );
}
If it were :
public final Logger getChildLogger( final String name )
{
return new Log4JLogger( Category.getInstance( name ) );
}
then it would have been enough ... but then the name of the method is
probably a misnamer : it should be called something like getLogger(final
String category) or something like that.
Maybe we could add a getLogger(final String category) or
getSiblingLogger(final String category) to the Logger interface ?
> One of the design
> strengths--and design weaknesses of the Logger interface is that the
instances
> are opaque. They cannot be simply recast to the originating type. This
is
> good for security and implementation hiding, but it is bad for complex
beasts
> like ComponentManager who have a right and a need to get at the LogKit
Logger
> for legacy Components.
>
> I have been wanting to reimplement the ComponentManager infrastructure in
> excalibur for a while--although I have not figured out how to free my time
> to do it. So far I can only make incremental changes.
yes, that's the problem : reimplementing the full ComponentManager is a bit
of work ...
Thanks
-Vincent
>
>
> --
>
> "Those who would trade liberty for
> temporary security deserve neither"
> - Benjamin Franklin
>
>
> --
> To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>
>
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
