29.01.2002 15:38:56, "Remy Maucherat" <[EMAIL PROTECTED]> wrote: >> Hi folks, >> >> Now that Jakarta has a super-lightweight logging package in >Jakarta-Commons, >> that is already being used by Tomcat4 and Struts, as well as many other >commons >> components, I propose we migrate to using that package for Slide as well. >> >> The commons-logging package has bindings to JDK1.4 logging, Log4J and >Avalon >> LogKit, and also provides a simple System.out logger like Slide does >currently >> with SimpleLogger. >> >> So in the spirit of code reuse and sharing between Jakarta projects, I >volunteer >> to do a step by step migration of the logging in Slide: First I'll keep >the >> current logging code in place, only deprecating it and adding the commons- >> logging support. As the next step the org.apache.slide.util.logger >package, the >> log4j-wrapper and all references to it will be completely removed and >replaced >> by equivalent commons-logging calls. >> >> All that only applies to the HEAD branch of Slide, of course. >> What do you think ? >> >> +1 from me, obviously. > >Ok, but: >- if this happened only when commons-logging 1.0 was released, that would be >better
Right. I expect that there would be a 1.0 release before slide-2 gets close to release though (whenever the next versions of Beanutils and Digester are released, there will most probably a release of commons-logging too). If we decide in the future to go back using the httpclient component from commons, and possibly other components from commons, there'd probably be a runtime-dependancy on commons-logging anyway. We could consider checking a JAR of commons-logging into our CVS, but seeing that other projects/components directly or indirectly depend on commons-logging, the occurence of frequent API changes breaking the Slide build (as was unfortunately the case with httpclient) seems very unlikely. >- Tomcat 4 doesn't use commons-logging yet, but has dependencies which use >it; there's no plan to migrate to it, except maybe by writing a wrapper, >since it would end up changing the API. Maybe Tomcat 5 will use >commons.logging natively Okay, I misinterpreted the Gump chart then. The same might be true for Struts. >So +1. I would prefer using a wrapper, as I don't think introducing API >changes because of logging is justified. The whole point of commons-logging is to provide a light-weight wrapper around different log-systems. So providing a o.a.s.util.logger.Logger implementation around Log (the equivalent commons-logging interface) does not make much sense to me in the long term. More importantly, there'll be API changes with much more impact to support DeltaV. IMHO, if the API needs to be changed, one should use that "opportunity" to cleanup other stuff in the API. As described, I'd deprecate the old logging API first, but would like to remove it before Slide.next is finally released. For the transition time I'd provide full backwards-compatibility, but "scare" API users with deprecation messages :o). -chris _______________________________________________ /=/ cmlenz at gmx.de -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
