jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Julian Reschke <julian.resc...@gmx.de>
Subject Re: properties with XML-Values; patch
Date Wed, 20 Feb 2008 09:36:28 GMT
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 .....&lt;propvalue&gt;.....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>&lt;x/&gt;</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

Mime
View raw message