Thanks, Oliver! Looks like there are many subtle but important changes introduced in 2.1 that affect "core" functionality...
> -----Original Message----- > From: Slide Users Mailing List [mailto:[EMAIL PROTECTED] > Sent: Tuesday, July 13, 2004 2:58 PM > To: [EMAIL PROTECTED] > Subject: Re: Locking problem in Slide 2.1 M1 > Importance: Low > > Yes, > > owner must be present. Just set it to the empty string if you > do not want to provide it. > > Oliver > > Andrey Shulinsky wrote: > > > Hi there! > > > > I'm now trying our code with Slide 2.1 M1 and I've just encountered > > the following problem: > > > > When I try to lock a resource (resourceNode, userNode and > actionNode > > all > > exist): > > > > Calendar calendarHelper = > > Calendar.getInstance(); > > calendarHelper.set(Calendar.YEAR, > > > > calendarHelper.get(Calendar.YEAR)+1); > > // Create node lock itself > > NodeLock nodeLock = new NodeLock( > > resourceNode, > > userNode, > > actionNode, > > calendarHelper.getTime() > > /*expiration date*/, > > false /*inheritance*/, > > true /*exclusiveness*/); > > // Create lock > > lockHelper.lock(slideToken, nodeLock); > > namespaceAccessToken.commit(); > > > > I get an exception: > > > > 13 Jul 2004 12:49:16 - > org.apache.slide.transaction.SlideTransaction - > > WARNING - Prepare failure: Resource manager > TxXMLFileDescriptorsStore > > at ../web apps/slide/stores/collaboration/store/metadata > working on > > ../webapps/slide/stores/collaboration/work/metadata Error code > > org.jdom.IllegalDataExceptio > > n: The data "null" is not legal for a JDOM attribute: A > null is not a > legal > > XML value. > > at org.jdom.Attribute.setValue(Attribute.java:483) > > at org.jdom.Attribute.<init>(Attribute.java:229) > > at org.jdom.Attribute.<init>(Attribute.java:252) > > at org.jdom.Element.setAttribute(Element.java:1044) > > at > > > org.apache.slide.store.txfile.AbstractXMLResourceDescriptor.en > codeLocks(Abst > > ractXMLResourceDescriptor.java:696) > > at > > > org.apache.slide.store.txfile.AbstractXMLResourceDescriptor.en > code(AbstractX > > MLResourceDescriptor.java:645) > > at > > > org.apache.slide.store.txfile.AbstractXMLResourceDescriptor.sa > ve(AbstractXML > > ResourceDescriptor.java:616) > > at > > > org.apache.slide.store.txfile.XMLResourceDescriptor.save(XMLRe > sourceDescript > > or.java:112) > > at > > > org.apache.slide.store.txfile.TxXMLFileDescriptorsStore$TxCont > ext.saveDescri > > ptors(TxXMLFileDescriptorsStore.java:547) > > at > > > org.apache.slide.store.txfile.TxXMLFileDescriptorsStore.prepar > e(TxXMLFileDes > > criptorsStore.java:393) > > at > > > org.apache.slide.transaction.SlideTransaction.commit(SlideTran > saction.java:2 > > 52) > > at > > > org.apache.slide.transaction.SlideTransactionManager.commit(Sl > ideTransaction > > Manager.java:187) > > at > > > org.apache.slide.common.NamespaceAccessTokenImpl.commit(Namesp > aceAccessToken > > Impl.java:421) > > > > > > Actually, the exception is thrown by the following line of > > theAbstractXMLResourceDescriptor class: > > > > aElementLock.setAttribute("owner", > aLock.getOwnerInfo()); > > > > Well, does it mean that the owner info must be provided when one > > creates > a > > lock in 2.1? Or is it a bug? As far as I know, WebDAV > requires an "owner" > > element in the LOCK request but doesn't specify the exact format so > > why > not > > use just userNod.getUri() or something like this by default? > > > > Yours sincerely, > > Andrey Shulinsky. > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
