hi, It is possible to assert a write lock on a null resource in order to lock the name .If a resource is automatically versioned , i.e every put request on the resource automatically creates a new version of the resource, then what should be done in the case where a lock-null resource is created first followed by a series of put requests on the same resource .Should the first put request simply update the properties of the lock-null resource to create the initial revision?
thanks, rajkumar -----Original Message----- From: Scott Sanders [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 31, 2002 10:56 AM To: 'Slide Developers List' Subject: RE: [VOTE] Migrate to the Logging Package of Jakarta-Commons I am happy to help you guys if you have any questions. I am a committer over in Commons working on Digester and Logging. > -----Original Message----- > From: Dirk Verbeeck [mailto:[EMAIL PROTECTED]] > Sent: Thursday, January 31, 2002 10:52 AM > To: Slide Developers List > Subject: Re: [VOTE] Migrate to the Logging Package of Jakarta-Commons > > > +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:slide-dev-> [EMAIL PROTECTED]> > > For > additional commands, > e-mail: > > <mailto:[EMAIL PROTECTED]> > > > -- > To unsubscribe, e-mail: > <mailto:slide-dev-> [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]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
