Torsten Curdt wrote:
> I want to upgrade our cocoon components to use LogEnabled
> instead of Loggable. Most of them extend AbstractLoggable,
> so this is no big deal. But some _implement_ Loggable.
>
> Well, I thought "no big deal either". I changed them to
> implement LogEnabled and renamed the setLogger() method
> to enableLogging(). But I had to realize that LogEnabled
> uses a Logger from a different package!!
:) I feel your pain. Among the many improvements in Excalibur,
it is on the list to ease this transition. It would also allow
Cocoon to try out different logging packages *IF* they wanted
to.
> avalon-dev: Can someone please explain why Logger has moved?
> This is giving me some real headaches with the cocoon
> integration - since cocoon still uses Loggable with
> the different Logger.
It has been deprecated--but we will continue to support it
until it is time to remove the functionality.
That being said, there are a lot of people that approached us
saying, "We would love to use Avalon for project X, unfortunately
they only use logging package Y." We thought that was a pretty
sucky reason for not being able to take advantage of a well
defined architecture (what Avalon really affords), so we created
an abstraction layer.
The abstraction layer purposely avoids configuration of the
Loggers, but encourages the propper use of them.
> Having two different Loggers around is a PITA.
:) I know. If you are using the LogEnabled interface, you will
only use the Avalon defined interface. All your children now
have to be LogEnabled (the Logger is opaque, and cannot be
downcast into the original type).
If you are using the Loggable interface, and you want to pass a
logger to a LogEnabled class, simply wrap the logger in a
LogKitLogger class:
class LegacyClass extends AbstractLoggable
{
void method()
{
LogEnabled example = new NewClass();
example.enableLogging( new LogKitLogger( getLogger() ) );
}
}
Again, we are addressing the migration issues in Excalibur.
>
> Should we upgrade cocoon to LogEnabled?
Yes, but you might want to wait until the new Excalibur is
officially released.
> If so...
>
> a) only HEAD
This would be preferred. It allows you to work against a known
implementation. This way, if any surprises crop up due to
unforseen issues (like the ones you are having), users of the
main project that want bug fixes don't have to wait until the
migration is 100% complete.
> b) HEAD and 2.0
I wouldn't.
> --
> Torsten
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
>
> .
>
>
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
