You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by "Bachran, Michael" <MB...@onebridge.de> on 2001/11/28 13:52:46 UTC
Logging, LogKit, JDK1.4 Logging ...
Hi everybody,
Unfortunately I missed the invention of the LogEnabled stuff?
Currently I am using the Framework along with the ExcaliburComponentManager
(ECM) (Release 4.0). Along with the ECM comes LogKit.
As the project started using Log4J I am planning to shift to LogKit now to
get rid of one of two loggers.
I am currently wondering if LogEnabled will simply replace Loggable (same
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 wait
with shifting till the changes have been applied.
MfG, Michael
Re: Logging, LogKit, JDK1.4 Logging ...
Posted by Vincent Massol <vm...@octo.com>.
----- Original Message -----
From: "Berin Loritsch" <bl...@apache.org>
To: "Avalon Developers List" <av...@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:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Logging, LogKit, JDK1.4 Logging ...
Posted by Berin Loritsch <bl...@apache.org>.
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 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. 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.
--
"Those who would trade liberty for
temporary security deserve neither"
- Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Logging, LogKit, JDK1.4 Logging ...
Posted by Vincent Massol <vm...@octo.com>.
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 ?
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 ?
----- Original Message -----
From: "Berin Loritsch" <bl...@apache.org>
To: "Avalon Developers List" <av...@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
ExcaliburComponentManager
> > (ECM) (Release 4.0). Along with the ECM comes LogKit.
> > As the project started using Log4J I am planning to shift to LogKit now
to
> > get rid of one of two loggers.
> >
> > I am currently wondering if LogEnabled will simply replace Loggable
(same
> > 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
wait
> > 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
Avalon
> LogKit package--although we do not want to alienate potential users who
don't
> want to use it. In the end, you now have a public interface that is
consistent
> no matter what Logging package you use.
>
>
>
>
> --
>
> "Those who would trade liberty for
> temporary security deserve neither"
> - Benjamin Franklin
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
>
Re: Logging, LogKit, JDK1.4 Logging ...
Posted by Berin Loritsch <bl...@apache.org>.
Bachran, Michael wrote:
> Hi everybody,
>
> Unfortunately I missed the invention of the LogEnabled stuff?
>
> Currently I am using the Framework along with the ExcaliburComponentManager
> (ECM) (Release 4.0). Along with the ECM comes LogKit.
> As the project started using Log4J I am planning to shift to LogKit now to
> get rid of one of two loggers.
>
> I am currently wondering if LogEnabled will simply replace Loggable (same
> 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 wait
> 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 Avalon
LogKit package--although we do not want to alienate potential users who don't
want to use it. In the end, you now have a public interface that is consistent
no matter what Logging package you use.
--
"Those who would trade liberty for
temporary security deserve neither"
- Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>