You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by Angela Schreiber <an...@day.com> on 2005/08/09 09:17:46 UTC
jcr-server: latest changes (summary)
hi
the latest commits to the jcr-server cover the following
issues with the 'simple' servlet:
1) ETags (http://issues.apache.org/jira/browse/JCR-174)
-----------------------------------------------------------
discussion:
http://www.mail-archive.com/jackrabbit-dev@incubator.apache.org/msg01505.html
- Calculation of the ETag is removed from NodeResource and
delegated to the Export-Commands
- accordingly the getStrongEtag method on NodeResource does
not make sense and has been removed.
- in addition: if a strong etag is present on a resource
its now used in the evaluation of the IF header (there used
to be a //todo in the WebdavRequestImpl).
2) Proppatch (http://issues.apache.org/jira/browse/JCR-175)
------------------------------------------------------------
discussion:
http://www.mail-archive.com/jackrabbit-dev%40incubator.apache.org/msg01971.html
- Simple-DavResource now exposes jcr-Properties present
on the node that represents the dav-resource.
- Proppatch is forwarded to the corresponding jcr-Properties
instead of throwing Method-Not-Allowed
- namespace prefixes present with jcr-property names
are remapped if they would conflict with any of the
namespaces predefined with the webdav library (basically
the DAV: namespace and the jcr-webdav namespace defined
for the observation and transaction extensions).
3) Resource-Filter
------------------------------------------------------------
- allows to filter resources by namespace and nodetype
(initial version)
- currently respected with PROPFIND and with any write
methods (in order to avoid creation of resources that
will not be visible later on).
- Drawback: the exports-command are not aware of the filter
yet.
> see discussion regarding the command-chains in general
> see also http://issues.apache.org/jira/browse/JCR-165)
regards
angela
Re: PROPPATCH in simple webdav server
Posted by Brian Moseley <bc...@osafoundation.org>.
Angela Schreiber wrote:
> oh, you were misleaded. i intended to say that it's not
> really cool. that's the reason why i don't share it.
heh, too bad. guess i'll stick with cadaver and curl :)
Re: PROPPATCH in simple webdav server
Posted by Angela Schreiber <an...@day.com>.
Brian Moseley wrote:
> Angela Schreiber wrote:
>> i have my own little testclient [...]
> cool! any chance you could make that available?
oh, you were misleaded. i intended to say that it's not
really cool. that's the reason why i don't share it.
regards
angela
Re: PROPPATCH in simple webdav server
Posted by Brian Moseley <bc...@osafoundation.org>.
Angela Schreiber wrote:
> i have my own little testclient, that allows me to
> generate any kind of dav request (also malformated
> request and request for those things we 'invented'
> for the jcr-server)... the reason for this is, that
> i couldn't find a satifying client either. but it's
> very tiny and rather a set of testcases.
cool! any chance you could make that available? being able to generate
arbitrarily malformed requests would be really handy.. currently i do
that by writing xml files and piping them into curl :/
Re: PROPPATCH in simple webdav server
Posted by Angela Schreiber <an...@day.com>.
hi brian
> tho if you don't mind, could you describe how you generate
> webdav requests for testing the server?
i have my own little testclient, that allows me to
generate any kind of dav request (also malformated
request and request for those things we 'invented'
for the jcr-server)... the reason for this is, that
i couldn't find a satifying client either. but it's
very tiny and rather a set of testcases.
means: my tests passed... but of course there
might be something i overlooked ;)
regards
angela
Re: PROPPATCH in simple webdav server
Posted by Brian Moseley <bc...@osafoundation.org>.
Angela Schreiber wrote:
> "Export: In the context of export, the repository may either ignore the
> multi-value property or serialize it as an attribute whose value is an
> XML Schema list type (i.e., a whitespace-delimited list of strings)."
>
> and i had the feeling that no exporting them would be
> the better option.
ok. i was concerned that webdav properties themselves could be
multivalued, and that not allowing multivalued jcr properties would be
problematic there, but i can't find anything in rfc 2518 that says
webdav properties can be multivalued, so i guess it's not an issue.
> anyway: if the PROPPATCH does not work as you would expect,
> please post a JIRA issue and i will certainly look at it as
> soon as possible.
will do. tho if you don't mind, could you describe how you generate
webdav requests for testing the server? i'd like to use the same method
that you do in order to eliminate the possibility that i'm just sending
bad requests to the server. thanks!
Re: PROPPATCH in simple webdav server
Posted by Angela Schreiber <an...@day.com>.
> why are multi-value webdav properties not supported?
i consider display of jcr-properties as dav-properties
through PROPFIND as a sort of 'export' as defined in
jsr170 6.4.2.5 and there it states:
"Export: In the context of export, the repository may either ignore the
multi-value property or serialize it as an attribute whose value is an
XML Schema list type (i.e., a whitespace-delimited list of strings)."
and i had the feeling that no exporting them would be
the better option.
anyway: if the PROPPATCH does not work as you would expect,
please post a JIRA issue and i will certainly look at it as
soon as possible.
regards
angela
PROPPATCH in simple webdav server
Posted by Brian Moseley <bc...@osafoundation.org>.
angela, can you discuss a little bit about how you implemented PROPPATCH
in the simple webdav server and how you tested it? why are multi-value
webdav properties not supported?
i've configured the import-collection chain (called via MKCOL) to add
nodes with the node type "dav:collection", which is defined as such:
NodeTypeName
dav:collection
SuperTypes
nt:folder
IsMixin
false
HasOrderableChildNodes
false
PrimaryItemName
null
PropertyDef
Name *
RequiredType UNDEFINED
DefaultValues null
AutoCreate false
Mandatory false
OnParentVersion COPY
Protected false
Multiple false
PropertyDef
Name *
RequiredType UNDEFINED
DefaultValues null
AutoCreate false
Mandatory false
OnParentVersion COPY
Protected false
Multiple true
the idea is that i should be able to set arbitrary webdav properties
(single- or multi-value) on a webdav collection.
when i use cadaver to mkcol a collection (creating a jcr node of type
dav:collection) and then try to propset an arbitrary property on that
collection (which as i understand it would set a jcr property of the
same name on the dav:collection node), i get a 403 Forbidden error:
dav:/home/> mkcol hi
Creating `hi': succeeded.
dav:/home/> propset hi hi hi
Setting property on `hi': failed:
403 Forbidden
it's not clear to me if i'm using cadaver incorrectly, misunderstanding
the PROPPATCH implementation, or both :) any help you can give would be
much appreciated. thanks!
Re: jcr-server: latest changes (summary)
Posted by Brian Moseley <bc...@osafoundation.org>.
Stefano Mazzocchi wrote:
> Angela, great stuff.
yes indeed. this opens the door for me to implement certain caldav
features. thanks much.
Re: jcr-server: latest changes (summary)
Posted by Stefano Mazzocchi <st...@apache.org>.
Angela Schreiber wrote:
> hi
> the latest commits to the jcr-server cover the following
> issues with the 'simple' servlet:
>
> 1) ETags (http://issues.apache.org/jira/browse/JCR-174)
> -----------------------------------------------------------
>
> discussion:
> http://www.mail-archive.com/jackrabbit-dev@incubator.apache.org/msg01505.html
>
>
> - Calculation of the ETag is removed from NodeResource and
> delegated to the Export-Commands
> - accordingly the getStrongEtag method on NodeResource does
> not make sense and has been removed.
> - in addition: if a strong etag is present on a resource
> its now used in the evaluation of the IF header (there used
> to be a //todo in the WebdavRequestImpl).
>
>
> 2) Proppatch (http://issues.apache.org/jira/browse/JCR-175)
> ------------------------------------------------------------
>
> discussion:
> http://www.mail-archive.com/jackrabbit-dev%40incubator.apache.org/msg01971.html
>
>
> - Simple-DavResource now exposes jcr-Properties present
> on the node that represents the dav-resource.
> - Proppatch is forwarded to the corresponding jcr-Properties
> instead of throwing Method-Not-Allowed
> - namespace prefixes present with jcr-property names
> are remapped if they would conflict with any of the
> namespaces predefined with the webdav library (basically
> the DAV: namespace and the jcr-webdav namespace defined
> for the observation and transaction extensions).
>
>
> 3) Resource-Filter
> ------------------------------------------------------------
>
> - allows to filter resources by namespace and nodetype
> (initial version)
> - currently respected with PROPFIND and with any write
> methods (in order to avoid creation of resources that
> will not be visible later on).
>
> - Drawback: the exports-command are not aware of the filter
> yet.
> > see discussion regarding the command-chains in general
> > see also http://issues.apache.org/jira/browse/JCR-165)
Angela, great stuff.
What is the status of the WebDAV litmus tests at this point?
--
Stefano.