+1 Not a high priority for me and I don't see any direct advantages but I have no objections if you do the change like you described.
Dirk Christopher Lenz wrote: > > 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]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
