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: Status of jcr-server
Date Tue, 04 Apr 2006 17:50:48 GMT
Brian Moseley wrote:
> 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.

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

View raw message