jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brian Moseley" <...@osafoundation.org>
Subject Re: Status of jcr-server
Date Tue, 04 Apr 2006 17:22:19 GMT
On 4/4/06, Julian Reschke <julian.reschke@gmx.de> wrote:

> Regarding PROPPATCH: understood. However, I really tried hard but
> couldn't figure out so far how to reconfigure the system so that custom
> properties are allowed? Or does this require a change in the code base?

this is what angela meant when she said the repository implementation
drives the simple server's feature set, not the other way around.

because data is persisted by the simple server as nt:folder and
nt:file nodes, there's no way to store custom properties on a webdav
resource or collection.

in constrast, for cosmo i have defined dav:collection and dav:resource
node types that extend nt:folder and nt:file, adding a dav:displayname
property as well as custom properties.

thus the discussion (which none of us have acted on yet) about
providing a third "back end" for jcr-server that does not limit itself
to node types defined by the jcr spec and which therefore can more
fully implement webdav and its many extensions.

> Yes, there is. Right now, PROPFIND with a broken request body behaves as
> if no body was present. I think that's a bug, and I don't think any
> client relies on that. From an implementation point of view, the generic
> method that gets the DOM of the request body should have a flag
> (indicating whether a request body is required), and it should be
> allowed to throw an exception (when required body not present, or body
> not wellformed). From a debugging point of view, returning the message
> of the XML parser exception in the response body may be useful for
> developers implementing custom clients...

fwiw, i've patched the version of jackrabbit used by cosmo to do
exactly these things. i have not yet had time to migrate that to the
main jackrabbit repository.

View raw message