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:[EMAIL PROTECTED] > > 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: > <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > > ------------------------------------------------------------------------------------------------------------------------------------ > Name: trace.txt > trace.txt Type: Plain Text (text/plain) > Encoding: quoted-printable > > > ------------------------------------------------------------------------------------------------------------------------------------ > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- "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]>
