jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Angela Schreiber <anch...@day.com>
Subject Re: wrapping jcr request inside webdav request
Date Mon, 11 Dec 2006 14:31:57 GMT

Kalka, Edyta wrote:
> We are able to browse jackrabbit repository content with the use of
> webdav clients (tested: eclipse site explorer, or dav explorer) but we
> are not able to add/update any new resources - response containes 409
> http error after such attempts (response message: "no definition found
> in parent node's node type for new node: no matching child node
> definition found for...").

this is the exception thrown by jackrabbit if upon Node.addNode
not matching child node definition was found.
in this case you have to make sure, that your webdav call
specifies the nodetype to be used for the new node (see below).

> Therefore I would have the following questions:

> * How should I build webdav request that would be correctly converted to
> jcr request on the server side?

- MKCOL with request body, that will be used to run a importXML
   -> thus it need to be in the xml format defined for the import.
   -> in case of a single addNode, this is simple, see example below [1]
- MKCOL without request body will be translated to n.addNode(String)
- Node.addNode(String, String) has no special translation.

in contrast:
- PUT will always be mapped to Node.setProperty

> * How to define that new resource being created is a resource of given
> custom (mixin) type?

- custom primary type is assigned as described above.
   as specified by jsr170 the primary type cannot be changed later on.

- mixin types:
   mixin types can be added and removed using PROPPATCH on
   the collection representing the target Node.

> * How to pass/set jcr properties withing webdav request?

- Node.setProperty is mapped by a PUT request
- Modifying the value of an existing property can be achieved
   by PROPPATCH on the non-collection resource representing the
   target Property.
   Note, that different custom webdav properties are defined for
   multivalued and single value properties.

further notes:

- we defined, that by default all calls to the jcr-server are
   translated into 'workspace' calls unless the client explicitely
   indicates, that it wants to sent a bundle of transient
   modifications. this is achieved by starting the modifications
   by a LOCK with a custom defined lock-type (-> see
   o.a.j.transaction.TransactionConstants#LOCAL and the
   corresponding entry in the TODO.txt, since the naming is not
   correct). Unpon UNLOCK, the session will be released on
   the server again.

- the reason for this is, that the aim is to keep transient
   modifications on the client and sending calls to the server
   only upon save.

- NOTE: i recently realized, that the server does not
   consistently assert, that this precondition is met. that
   needs to be fixed.


[1] example MKCOL for Node.addNode(String, String) including
     surrounding LOCK/UNLOCK, that indicate the boundaries between
     2 save calls.

---< request lock >-------------------------------------------------

LOCK /jackrabbit/server/default/jcr%3aroot HTTP/1.1
[ headers ]
<?xml version="1.0" encoding="UTF-8"?>
<D:lockinfo xmlns:D="DAV:"><D:lockscope><dcr:local 


---< response >-----------------------------------------------------

HTTP/1.0 200 OK
[ headers ]
Lock-Token: <opaquelocktoken:af768848-3eb0-4172-93d7-45c0282c4c45>

[ response body ]

---< request mkcol >------------------------------------------------

MKCOL /jackrabbit/server/default/jcr%3aroot/testroot/node1 HTTP/1.1
TransactionId: <opaquelocktoken:af768848-3eb0-4172-93d7-45c0282c4c45>
[ headers ]

<?xml version="1.0" encoding="UTF-8"?>
<sv:node xmlns:sv="http://www.jcp.org/jcr/sv/1.0" 
sv:name="node1"><sv:property sv:name="jcr:primaryType" 

---< response mkcol >------------------------------------------------

HTTP/1.0 201 Created
[ headers ]


[ possibly other transient modifications that belong to the same
   'save' call ]

---< request unlock >------------------------------------------------

UNLOCK /jackrabbit/server/default/jcr%3aroot HTTP/1.1
Lock-Token: <opaquelocktoken:af768848-3eb0-4172-93d7-45c0282c4c45>
[ headers ]

<?xml version="1.0" encoding="UTF-8"?><dcr:transactioninfo 

---< response unlock >-----------------------------------------------

HTTP/1.0 204 No Content
[ headers ]

View raw message