You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Berin Loritsch <bl...@apache.org> on 2001/10/31 17:14:33 UTC
Logging change for Avalon Framework
The Avalon folks realized that forcing users of Avalon to use
LogKit was not necessarily a good thing. Several projects want
to use Log4J, and others will want to use JDK 1.4 logging.
You are in luck! The current CVS version of Avalon has a new
interface that abstracts away the implementation of the Logger
you are using. This allows you to keep the same API, and switch
logging implementations whenever you feel like it. One of the
benefits is that your code will never have to be rewritten
again.
The Avalon team has deprecated the method that is LogKit specific,
and introduced a new method that uses the new Logger interface.
There are two wrappers: 1 for LogKit, and 1 for Log4J.
If you have extended AbstractLoggable for your components, there
is nothing else that needs to be done.
However, if you have to handle the Logger class explicitly, then
all you have to do is import the
org.apache.avalon.framework.logger.Logger interface instead.
Several people are deeply in favor of such an API change, even if
it breaks backwards compatibility. We strove to minimize the
impact as much as possible. The new Logger interface matches
the old LogKit Logger interface, and AbstractLoggable automatically
takes care of the transition for you. No method names need to
change.
I would very much like to have some feedback on how much affect
it has on any of your projects before we release the new version
of Framework. I have verified that the change does not affect
Avalon Excalibur at all. Everyone that is responsible for their
projects, I kindly ask that you get a fresh CVS of Avalon Framework,
and test for yourselves. There might be some impact to some of
Cocoon's classes.
Please let me know ASAP. If there are no issues, then I can
get busy preparing a new release of Avalon Framework. If the impact
is much worse than anticipated I need to know. That way I can back
out the changes or add a different Loggable equivalent interface
that uses the new Logger interface.
If all goes well, there should be little to no impact on your
projects.
--
"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 change for Avalon Framework
Posted by Berin Loritsch <bl...@apache.org>.
Berin Loritsch wrote:
>
> > > Please let me know ASAP. If there are no issues, then I can
> > > get busy preparing a new release of Avalon Framework. If the impact
> > > is much worse than anticipated I need to know. That way I can back
> > > out the changes or add a different Loggable equivalent interface
> > > that uses the new Logger interface.
> > >
> > > If all goes well, there should be little to no impact on your
> > > projects.
All did not go well, and the change proved more extensive than I originally
thought. In order to provide what I originally desired, with the least amount
of impact, I deprecated Loggable. The new interface of choice is:
interface org.apache.avalon.framework.logger.LogEnabled
{
void enableLogging( org.apache.avalon.framework.logger.Logger logger );
}
By using the LogEnabled interface, you may use the included adapters for
Log4J, LogKit, or JDK 1.4 logging.
There are some things that I do need to explain regarding the side affects
of using the LogEnabled interface:
1) The Logger you have is Opaque--it cannot be downcast to the originating
logger type. This is a design goal, but if you need to work with Loggable
components in your system, you must use the Loggable interface yourself.
Otherwise there is no way to get the org.apache.log.Logger from the one
supplied to you--nor can you assume that the Logger you have been given
is a LogKit logger (IOW, you can change logging frameworks without touching
the rest of your code).
2) If you are using JDK 1.4 logging, there is no direct mapping between the
priorities we define and what JDK 1.4 defines. We wanted to remain as
consistent as possible, so below is the mapping:
* debug() -> FINE
* info() -> INFO
* warn() -> WARNING
* error() -> SEVERE
* fatalError() -> SEVERE
While it would have been possible to change error() to WARNING, warn()
to INFO, and info to CONFIG, that would have been confusing when you look
at the log files.
3) ExcaliburComponentManager and the Pool implementations must remain Loggable
instead of LogEnabled. It was not possible to upgrade them without breaking
backwards compatibility.
--
"Those who would trade liberty for
temporary security deserve neither"
- Benjamin Franklin
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Logging change for Avalon Framework
Posted by Berin Loritsch <bl...@apache.org>.
Berin Loritsch wrote:
>
> > > Please let me know ASAP. If there are no issues, then I can
> > > get busy preparing a new release of Avalon Framework. If the impact
> > > is much worse than anticipated I need to know. That way I can back
> > > out the changes or add a different Loggable equivalent interface
> > > that uses the new Logger interface.
> > >
> > > If all goes well, there should be little to no impact on your
> > > projects.
All did not go well, and the change proved more extensive than I originally
thought. In order to provide what I originally desired, with the least amount
of impact, I deprecated Loggable. The new interface of choice is:
interface org.apache.avalon.framework.logger.LogEnabled
{
void enableLogging( org.apache.avalon.framework.logger.Logger logger );
}
By using the LogEnabled interface, you may use the included adapters for
Log4J, LogKit, or JDK 1.4 logging.
There are some things that I do need to explain regarding the side affects
of using the LogEnabled interface:
1) The Logger you have is Opaque--it cannot be downcast to the originating
logger type. This is a design goal, but if you need to work with Loggable
components in your system, you must use the Loggable interface yourself.
Otherwise there is no way to get the org.apache.log.Logger from the one
supplied to you--nor can you assume that the Logger you have been given
is a LogKit logger (IOW, you can change logging frameworks without touching
the rest of your code).
2) If you are using JDK 1.4 logging, there is no direct mapping between the
priorities we define and what JDK 1.4 defines. We wanted to remain as
consistent as possible, so below is the mapping:
* debug() -> FINE
* info() -> INFO
* warn() -> WARNING
* error() -> SEVERE
* fatalError() -> SEVERE
While it would have been possible to change error() to WARNING, warn()
to INFO, and info to CONFIG, that would have been confusing when you look
at the log files.
3) ExcaliburComponentManager and the Pool implementations must remain Loggable
instead of LogEnabled. It was not possible to upgrade them without breaking
backwards compatibility.
--
"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 change for Avalon Framework
Posted by Berin Loritsch <bl...@apache.org>.
Stephen McConnell wrote:
>
> Berin:
>
> Have just tried building the current Avalon cvs (without the Log4J jar).
> Even through the build file declares that the Log4J logger source should be
> excluded if log4j is not present, it's still compiled and generating errors
> (because of the absence of the Log4J classes) - I guess its a problem with
> the "available" statement for "log4j.present" - can you confirm.
Try current CVS now. It is working in my environment.
>
> Steve.
>
> > -----Original Message-----
> > From: Berin Loritsch [mailto:bloritsch@apache.org]
> > Sent: Wednesday, 31 October, 2001 17:15
> > To: cocoon-dev@xml.apache.org; avalon-dev@jakarta.apache.org
> > Subject: Logging change for Avalon Framework
> >
> >
> > The Avalon folks realized that forcing users of Avalon to use
> > LogKit was not necessarily a good thing. Several projects want
> > to use Log4J, and others will want to use JDK 1.4 logging.
> >
> > You are in luck! The current CVS version of Avalon has a new
> > interface that abstracts away the implementation of the Logger
> > you are using. This allows you to keep the same API, and switch
> > logging implementations whenever you feel like it. One of the
> > benefits is that your code will never have to be rewritten
> > again.
> >
> > The Avalon team has deprecated the method that is LogKit specific,
> > and introduced a new method that uses the new Logger interface.
> > There are two wrappers: 1 for LogKit, and 1 for Log4J.
> >
> > If you have extended AbstractLoggable for your components, there
> > is nothing else that needs to be done.
> >
> > However, if you have to handle the Logger class explicitly, then
> > all you have to do is import the
> > org.apache.avalon.framework.logger.Logger interface instead.
> >
> > Several people are deeply in favor of such an API change, even if
> > it breaks backwards compatibility. We strove to minimize the
> > impact as much as possible. The new Logger interface matches
> > the old LogKit Logger interface, and AbstractLoggable automatically
> > takes care of the transition for you. No method names need to
> > change.
> >
> > I would very much like to have some feedback on how much affect
> > it has on any of your projects before we release the new version
> > of Framework. I have verified that the change does not affect
> > Avalon Excalibur at all. Everyone that is responsible for their
> > projects, I kindly ask that you get a fresh CVS of Avalon Framework,
> > and test for yourselves. There might be some impact to some of
> > Cocoon's classes.
> >
> > Please let me know ASAP. If there are no issues, then I can
> > get busy preparing a new release of Avalon Framework. If the impact
> > is much worse than anticipated I need to know. That way I can back
> > out the changes or add a different Loggable equivalent interface
> > that uses the new Logger interface.
> >
> > If all goes well, there should be little to no impact on your
> > projects.
> >
> > --
> >
> > "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>
>
> ------------------------------------------------------------------------------------------------------------------------------------
> Name: trace.txt
> trace.txt Type: Plain Text (text/plain)
> Encoding: quoted-printable
>
> ------------------------------------------------------------------------------------------------------------------------------------
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
"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 change for Avalon Framework
Posted by Berin Loritsch <bl...@apache.org>.
Stephen McConnell wrote:
>
> Berin:
>
> Have just tried building the current Avalon cvs (without the Log4J jar).
> Even through the build file declares that the Log4J logger source should be
> excluded if log4j is not present, it's still compiled and generating errors
> (because of the absence of the Log4J classes) - I guess its a problem with
> the "available" statement for "log4j.present" - can you confirm.
This sucks. I am running into the same problem with the JMeter build process.
This may be a case for Ant gurus!
My machine does successfully declare log4j.present, or not.
If you would like me to send you a compiled jar in the interim, let me know.
>
> Steve.
>
> > -----Original Message-----
> > From: Berin Loritsch [mailto:bloritsch@apache.org]
> > Sent: Wednesday, 31 October, 2001 17:15
> > To: cocoon-dev@xml.apache.org; avalon-dev@jakarta.apache.org
> > Subject: Logging change for Avalon Framework
> >
> >
> > The Avalon folks realized that forcing users of Avalon to use
> > LogKit was not necessarily a good thing. Several projects want
> > to use Log4J, and others will want to use JDK 1.4 logging.
> >
> > You are in luck! The current CVS version of Avalon has a new
> > interface that abstracts away the implementation of the Logger
> > you are using. This allows you to keep the same API, and switch
> > logging implementations whenever you feel like it. One of the
> > benefits is that your code will never have to be rewritten
> > again.
> >
> > The Avalon team has deprecated the method that is LogKit specific,
> > and introduced a new method that uses the new Logger interface.
> > There are two wrappers: 1 for LogKit, and 1 for Log4J.
> >
> > If you have extended AbstractLoggable for your components, there
> > is nothing else that needs to be done.
> >
> > However, if you have to handle the Logger class explicitly, then
> > all you have to do is import the
> > org.apache.avalon.framework.logger.Logger interface instead.
> >
> > Several people are deeply in favor of such an API change, even if
> > it breaks backwards compatibility. We strove to minimize the
> > impact as much as possible. The new Logger interface matches
> > the old LogKit Logger interface, and AbstractLoggable automatically
> > takes care of the transition for you. No method names need to
> > change.
> >
> > I would very much like to have some feedback on how much affect
> > it has on any of your projects before we release the new version
> > of Framework. I have verified that the change does not affect
> > Avalon Excalibur at all. Everyone that is responsible for their
> > projects, I kindly ask that you get a fresh CVS of Avalon Framework,
> > and test for yourselves. There might be some impact to some of
> > Cocoon's classes.
> >
> > Please let me know ASAP. If there are no issues, then I can
> > get busy preparing a new release of Avalon Framework. If the impact
> > is much worse than anticipated I need to know. That way I can back
> > out the changes or add a different Loggable equivalent interface
> > that uses the new Logger interface.
> >
> > If all goes well, there should be little to no impact on your
> > projects.
> >
> > --
> >
> > "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>
>
> ------------------------------------------------------------------------------------------------------------------------------------
> Name: trace.txt
> trace.txt Type: Plain Text (text/plain)
> Encoding: quoted-printable
>
> ------------------------------------------------------------------------------------------------------------------------------------
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
"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 change for Avalon Framework
Posted by Stephen McConnell <mc...@osm.net>.
Berin:
Have just tried building the current Avalon cvs (without the Log4J jar).
Even through the build file declares that the Log4J logger source should be
excluded if log4j is not present, it's still compiled and generating errors
(because of the absence of the Log4J classes) - I guess its a problem with
the "available" statement for "log4j.present" - can you confirm.
Steve.
> -----Original Message-----
> From: Berin Loritsch [mailto:bloritsch@apache.org]
> Sent: Wednesday, 31 October, 2001 17:15
> To: cocoon-dev@xml.apache.org; avalon-dev@jakarta.apache.org
> Subject: Logging change for Avalon Framework
>
>
> The Avalon folks realized that forcing users of Avalon to use
> LogKit was not necessarily a good thing. Several projects want
> to use Log4J, and others will want to use JDK 1.4 logging.
>
> You are in luck! The current CVS version of Avalon has a new
> interface that abstracts away the implementation of the Logger
> you are using. This allows you to keep the same API, and switch
> logging implementations whenever you feel like it. One of the
> benefits is that your code will never have to be rewritten
> again.
>
> The Avalon team has deprecated the method that is LogKit specific,
> and introduced a new method that uses the new Logger interface.
> There are two wrappers: 1 for LogKit, and 1 for Log4J.
>
> If you have extended AbstractLoggable for your components, there
> is nothing else that needs to be done.
>
> However, if you have to handle the Logger class explicitly, then
> all you have to do is import the
> org.apache.avalon.framework.logger.Logger interface instead.
>
> Several people are deeply in favor of such an API change, even if
> it breaks backwards compatibility. We strove to minimize the
> impact as much as possible. The new Logger interface matches
> the old LogKit Logger interface, and AbstractLoggable automatically
> takes care of the transition for you. No method names need to
> change.
>
> I would very much like to have some feedback on how much affect
> it has on any of your projects before we release the new version
> of Framework. I have verified that the change does not affect
> Avalon Excalibur at all. Everyone that is responsible for their
> projects, I kindly ask that you get a fresh CVS of Avalon Framework,
> and test for yourselves. There might be some impact to some of
> Cocoon's classes.
>
> Please let me know ASAP. If there are no issues, then I can
> get busy preparing a new release of Avalon Framework. If the impact
> is much worse than anticipated I need to know. That way I can back
> out the changes or add a different Loggable equivalent interface
> that uses the new Logger interface.
>
> If all goes well, there should be little to no impact on your
> projects.
>
> --
>
> "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>