rev 293331: latest changes in contrib jcr-server (summary)

[Angela Schreiber <an...@day.com>]

hi

with revision 293331 the following issues have been
addressed within the jcr-server contribution:


1) JCR 184 - Simple Webdav: jcr-encoding for resource names
------------------------------------------------------------

as stated in the jira issue, i could not find an
satifying way to introduce an encoding of uris
containing characters invalid in jcr.

nevertheless i modified the code in order to have separate
usage of dav 'resourcepath' and jcr 'itempath' throughout
the project. in addition DavResourceLocator provides a method 
getJcrPath(). a new locator can be created from a jcr item path
using an additional method with the factory.


2) JCR-193 - MultiStatus response for PROPPATCH
------------------------------------------------------------

modification in DavResource interface. alterProperties
now returns a MultiStatusResponse instead of void.
adjusted implementations and AbstractWebdavServlet
accordingly.

note: PROPPATCH now always returns a MultiStatus response
(except for bad requests). it's a known issue with 'litmus'
that it does not properly recognizes errors within the 217
response. if it turns out to be a problem with other clients,
this could easily be changed (returning an error status).


3) JCR-216 - hrefs in dav responses should be url-escaped
------------------------------------------------------------

DavResourceLocator.getHref() must return a properly
escaped string > adjusted implementations and javadoc.

for consistency reasons the resource path is not unescaped
in the webdav request any more. however, the factory takes
care of this, when building a new locator from a href.


4) JCR-203 - set jcr:encoding when importing files
------------------------------------------------------------

according to patch provided by brian


5) 0000 - simple: 'resource-filter' -> 'resource-config'
------------------------------------------------------------

the optional resource-filter parameter for the simple-server
been replaced by 'resource-config'. the filter definitions
are now part of this configuration. in addition the config
allows to define which nodetypes represent collections
(or noncollections respectively). consequently the hard-
coded distinction in DavResourceImpl has been removed.


6) Various fixes in simple-server
------------------------------------------------------------

- missing return value in simple/LocatorFactoryImpl
- dealing with default namespace present in PROPPATCH body
- remove usage of item.getName() for the displayname. tests
   revealed that this caused problems if same-name-siblings
   are present.
- avoid invalid dav-property names (ISO9075-encoding/decoding
   of jcr-properties that are reflected as dav properties).
- if underlaying node is not mix:lockable, make an attempt
   to add this mixin-type (thus, use jcr locks whenever possible)
- locktokens present in the header where not added/removed
   to/from the session.
- remove usage of DavResourceImpl instead of interface inside
   NodeResource.java
- remove double Cache-Control, Pragma header (SimpleWebdavServlet)


7) Various fixes in jcr-server
------------------------------------------------------------

- protection of jcr-defined properties that cannot be
   altered by PROPPATCH.
- include list of resources that could not be merged into
   the MERGE response.


8) Various fixes
------------------------------------------------------------

- WebdavRequestImpl: missing check for null in getStrongETag
- WebdavResponse: improve method naming
- AbstractWebdavServlet: removed todo within lock related to
   strong etags and adjust code.
- javadoc issues


regards
angela

Re: rev 293331: latest changes in contrib jcr-server (summary)

[Brian Moseley <bc...@osafoundation.org>]

Angela Schreiber wrote:

> what kind of specifics do you expect? examples? i thought the 
> explanation was pretty straight. the de/encoding is present on
> the dav layer only and you will not be able to resolve ambiguities
> that this level if your repository is not only accessible via
> webdav. am i missing something?

no, you aren't missing anything. i misunderstood your comments and 
thought you were talking about something more than/in addition to the 
above, which was quite clear from the beginning of the conversation. thanks.

> btw: you cannot encode the [] that mark an index of a same name
> sibling node. those are part of the item path. however, creating an
> item with a trailing index in the name is invalid. so you would need
> a more sofisticated parsing.

i don't think this matters to me in terms of webdav. since i can't have 
same named webdav resources, i'll never have sibling nodes or the need 
to access a node with an indexed path.

Re: rev 293331: latest changes in contrib jcr-server (summary)

[Angela Schreiber <an...@day.com>]

hi brian

> sure, and i like the compromise you came up with. i'm perfectly willing 
> to implement my own encoding scheme with the hook you've given me. i'm 
> just wondering if you can give specific reasons for your unease with 
> regard to hex-escaping ' and " and [ and ] and so forth.

what kind of specifics do you expect? examples? i thought the 
explanation was pretty straight. the de/encoding is present on
the dav layer only and you will not be able to resolve ambiguities
that this level if your repository is not only accessible via
webdav. am i missing something?

btw: you cannot encode the [] that mark an index of a same name
sibling node. those are part of the item path. however, creating an
item with a trailing index in the name is invalid. so you would need
a more sofisticated parsing.

regards
angela

Re: rev 293331: latest changes in contrib jcr-server (summary)

[Brian Moseley <bc...@osafoundation.org>]

Angela Schreiber wrote:

> actually, i already summarized my expectations and considerations
> in the jira issue (184) and explained why i came to the conclusion,
> that an extra jcr-encoding should not be part of the code provided 
> within jackrabbit.

right, you mentioned potential inconsistencies and being 
uncomfortable with certain things, but you didn't really go 
into specifics.

> i'm aware that some points are not relevant for your application,
> but for me they are and i would feel uneasy with any of the
> variants i considered so far.

sure, and i like the compromise you came up with. i'm 
perfectly willing to implement my own encoding scheme with 
the hook you've given me. i'm just wondering if you can give 
specific reasons for your unease with regard to hex-escaping 
' and " and [ and ] and so forth.

Re: rev 293331: latest changes in contrib jcr-server (summary)

[Angela Schreiber <an...@day.com>]

hi brian

> it looks like neither the simple nor jcr servers have implemented any 
> escaping - you've just provided the interface for us to provide our own. 
> is that right?

exactly.

> can you discuss why you don't think a simple hex-escaping of reserved 
> characters is not sufficient for an implementation of getJcrPath()?

actually, i already summarized my expectations and considerations
in the jira issue (184) and explained why i came to the conclusion,
that an extra jcr-encoding should not be part of the code provided 
within jackrabbit.
i'm aware that some points are not relevant for your application,
but for me they are and i would feel uneasy with any of the
variants i considered so far.
if someone comes up with a satifying solution... even better,
the issue 184 is still open.

kind regards
angela

Re: rev 293331: latest changes in contrib jcr-server (summary)

[Brian Moseley <bc...@osafoundation.org>]

Angela Schreiber wrote:

> with revision 293331 the following issues have been
> addressed within the jcr-server contribution:

angela, thanks for all this. great stuff, very helpful.

> 1) JCR 184 - Simple Webdav: jcr-encoding for resource names
> ------------------------------------------------------------
> 
> as stated in the jira issue, i could not find an
> satifying way to introduce an encoding of uris
> containing characters invalid in jcr.
> 
> nevertheless i modified the code in order to have separate
> usage of dav 'resourcepath' and jcr 'itempath' throughout
> the project. in addition DavResourceLocator provides a method 
> getJcrPath(). a new locator can be created from a jcr item path
> using an additional method with the factory.

it looks like neither the simple nor jcr servers have implemented any 
escaping - you've just provided the interface for us to provide our own. 
is that right?

can you discuss why you don't think a simple hex-escaping of reserved 
characters is not sufficient for an implementation of getJcrPath()?