From which code base are you migrating? 1.0.x?
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]
