OK.
1) So first of all, we have a bug in Jackrabbit's WebDAV:
When you set an XML-typed property, it persists some broken value,
assuming it's a string. This needs to be fixed. If Jackrabbit can't
store a property, the request needs to be rejected.
2) How to decide that: assuming the PROPPATCH request has been parsed
into DOM objects, the right thing to do is to check whether the child
nodes of the property element (not the DAV:prop element) contain element
nodes. In that case, the property type is not plain text, and for now
can not be stored.
Further comments:
> Agree with that. Looking for a better way
See 2). Also, make sure to use namespace-aware DOM methods throughout.
You have to realise there's two issues here:
1. persisting a property that has a string containing XML as a value;
Try
propset someresource xmlProperty
<propValue><subValue>valueOfSubValue1</subValue><subValue>valueOfSubValue2</
subValue></propValue>
in cadaver then do propget; it will look like this:
xmlProperty = [propValue: null]
so any xml string in a prop value is set to the value of [propValue: null];
I'd say this is a bug in jackrabbit or to be more specific in
WebdavRequestImpl.parsePropPatchRequest() irrespective of jackrabbit having
the concept of XML properties.
Yes, that's a bug. See above.
2. after patching WebdavRequestImpl I was able to persist a string
containing xml.
A propget request results in a response looking somewhat like this:
Someresponsestuff .....<propvalue>.....somemoreresponsestuff ONLY for
Now that happens because you have stored the XML as a string. PROPFIND
has no way to decide which is which. It behaves completely correct here.
properties I added. Derived properties like supportedlock were not html
encoded but plain xml
Someresponsestuff .....<lockEntry><lockscope>.... somemoreresponsestuff
This happens in the serialisation.
As I said before; these are computed on the fly, so they really do not
matter here. (And, it's XML, not HTML).
Now what the client makes of this is an entirely different matter; cadaver
does not care, Dav Explorer interprets plain xml as xml and encoded xml as a
plain vanilla string. I don't know who's right but most of our clients use
Dav Explorer so I gotta make it work.
If we make changes, what needs to work is the correct interpretation of
the spec, not what a particular client supports.
If the server allows to PROPPATCH "foo" with
<D:prop xmlns="DAV:"><foo><x/></foo></D:prop>
then the result from PROPFIND needs to be exactly that, not
<D:prop xmlns="DAV:"><foo><x/></foo></D:prop>
Methinks the heart of the matter is that jackrabbit is a bit confused as to
what to do with XML; on the one hand you say it has no concept of xml
properties which is fair enough. On the other hand it quite clearly has when
it comes to derived properties.
Those are special cases.
Sorry bout being a bit unclear in the first post, I just thought the code
said it all;
Hope this clears matters up a bit
Cheers
roland
BR, Julian
