> > 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. > > Problem is: changing excalibur will probably affect quite some > > projects. Unfortunately AbstractLoggable and AbstractLogEnabled > > both have a getLogger() method but return a different class. > > So we cannot have a AbstractLogEnabledLoggable to make an easy > > transition. > > > > So I fear we would need a wrapper class for all public components. > > > What is in the works is a complete reimplementation of the Component > system. There will be a Container object that takes on the job of > containing the Components, and it takes on the job of exposing the > Components through the ComponentManager/Selector hierarchy. It also > takes care of the Configuration of the system. I haven't gotten that > far yet (I have an old Cocoon based system to make current)--but that > is the direction I am headed. [snip] ...sounds cool - do you propose to wait migrating to LogEnabled 'til the rewriting is finished? -- Torsten -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
