> Original Message from Sun, 4 Nov 2001 22:12:17 0200:> > > Right now the whole Excalibur uses the deprecated Loggable and related > classes all over the place and these seems to be very little support for > LogEnabled. > The i18n package is also extending ExcaliburComponentSelector in some places > (that in turn extends AbstractLoggable) but I would like to port over to the > new API. > I would go in and do the changes to ExcaliburComponentSelector et al myself, > but I'm afraid that I might break something in backward- incompatible way... > So, most probably someone else (Berin probably :-)) will take care of these > issues..? > > Any estimate on how soon that could happen?
I made as many changes as I could. Here is the issue: You CANNOT support Loggable IF the container is LogEnabled. The reason is that there is no way to retrieve the LogKit Logger class from the opaque Framework Logger interface. We _could_ add a method called getLogKitLogger() to the LogKitLogger class. The problem there is what about when you are not using a LogKitLogger in your system? Then there is NO way to get the LogKitLogger (except through LogKitManager). Therefore you HAVE to throw an exception for every Loggable class you have. It was safe to change the DataSource classes to be LogEnabled (at least internally) because that would not break backward compatibility. It was not safe to change the Poolable code because you have to setLogger()--it would break backward compatibility. When we can remove the old interface completely, we can complete the migration. Until then, we can't blanket change to the new API. > > Rgds, > Neeme > > > -- > To unsubscribe, e-mail: > For additional commands, e-mail: > > > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
