Brian Moseley wrote:
On 4/4/06, Julian Reschke <[EMAIL PROTECTED]> 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.
Brian, thanks for the additional information. I do understand that
there'll be backends that do not offer all the features, and yes, I
think it's absolutely fine to expose these kinds of resources through
WebDAV (witness all the history of discussions on the WebDAV mailing
list :-).
As a newbie to this code, I was trying to understand what I need to do
to configure a system that *does* support custom properties (otherwise
it's pretty pointless to run compliance test suites).
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.
I'm still confused. Is this a limitation of the "simple" server, or one
of the backends?
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.
Thanks for confirming. I guess I'll first submit a bug to Jira, and then
we can think about who's going to fix it.
Best regards, Julian
