> From which code base are you migrating? 1.0.x? 2.0 Beta. We've experienced 3 issues so far - the one you've just helped me with + http://www.mail-archive.com/[EMAIL PROTECTED]/msg06556.html http://www.mail-archive.com/[EMAIL PROTECTED]/msg06508.html
None of them is a big deal, of course. However, we've just started testing and if it's a general trend we should probably go with 2.0 Release. >From the other hand, I'd really like to use this new event framework. Well, probably we could postpone this migration until 2.1 Beta or even RC is released. Hope it really happens in early August as you've mentioned in the developer mailing list. Yours sincerely, Andrey. > > Oliver > > Andrey Shulinsky wrote: > > 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] > > > > > > > --------------------------------------------------------------------- > 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]
