Torsten Curdt wrote:
While migrating cocoon to LogEnabled I realized that not even
Excalibur is LogEnabled yet. So question is how to do a smooth
transition? Anyone a migration plan yet? (IMHO there should be
one before deprecating anything)
There is. Current CVS can handle LogEnabled Components--but it would
be backwards incompatible to change the interfaces that
ExcaliburComponentManager implements--especially since it is directly
manipulated by Cocoon and other Containers.
AFAI can see the current ExcaliburComponentManager still extends
AbstractLoggable instead of AbstractLogEnabled. So what about
a wrapper that wrapps around the ExcaliburComponentManager to
have a LogEnabled version of it? Cocoon (or other migrating projects)
can then use the new LogEnabled interface.
When migration is finished we can remove this iterim solution.
In order for this to work, you will need access to a LogKit logger for
legacy components. It is *Impossible* to get a LogKit Logger from an
Avalon Logger wrapper. Really, unless you can come up with a more
elegant solution, I don't think that will work.
Hm... I don't understand where there is the problem.
(dispite the fact that it's ugly ;)
class ExcaliburComponentManager extends AbstractLoggable {
// leave it as is
}
class LogEnabledExcaliburComponentManager extends AbstractLogEnabled
implements ....
or
class LogEnabledExcaliburComponentManager extends ..someclass..
implements LogEnabled, ....
{
final private ExcaliburComponentManager cm;
final private org.apache.avalon.framework.logger.Logger logger;
// wrap/map all methods to the cm
// except enabledLogging()
final public void enabledLogging(org.apache.avalon.framework.logger.Logger
logger) {
if (logger != null) this.logger = logger
}
// except getLogger()
final public org.apache.avalon.framework.logger.Logger getLogger() {
return(logger);
}
}
This way old systems will use the old ExcaliburComponentManager,
new systems the new LogEnabledExcaliburComponentManager. When
everyone has migrated we could make ExcaliburComponentManager extend
AbstractLoggable.
Let me make it a little more plain. Cocoon version 2.0 is now officially
released.
That means that if new users write their own Components that are Loggable, you
won't
be able to give them the Logger class that they need.
class LogEnabledExcaliburComponentManager extends ..someclass..
implements LogEnabled, ....
{
final private ExcaliburComponentManager cm;
final private org.apache.avalon.framework.logger.Logger logger;
// wrap/map all methods to the cm
// except enabledLogging()
final public void enabledLogging(org.apache.avalon.framework.logger.Logger
logger) {
if (logger != null) this.logger = logger
}
// except getLogger()
final public org.apache.avalon.framework.logger.Logger getLogger() {
return(logger);
}
setupComponent( String role, String classname, Configuration
configuration )
{
ComponentHolder holder ComponentHolder.getHolderFor( classname );
holder.enableLogging( getLogger() );
holder.configure( configuration );
m_components.put( role, holder );
}
}
Assuming that all components are LogEnabled, this would work great.
However, as soon
as there is a legacy component involved, the LogEnabled Logger won't work.
How do you propose to get the Logkit Logger from the existing LogEnabled logger
for this
legacy Component that is sharing resources with your system?
Hm... but how do I get a org.apache.avalon.framework.logger.Logger
to enabled logging on LogEnabled components when the old
ExcaliburComponentManager
can only give the org.apache.log.Logger?!
The ExcaliburComponentManager in CVS (both in Cocoon's Excalibur Jar and in
Excalibur's CVS) knows how to handle the LogEnabled components. It is trivial
to wrap a LogKit Logger and hand it to the child component. That work is done
for you!
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
