jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Philip Borlin (JIRA)" <j...@apache.org>
Subject [jira] Commented: (JCR-1917) Report Info appends properties after content
Date Mon, 29 Dec 2008 19:06:44 GMT

    [ https://issues.apache.org/jira/browse/JCR-1917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12659607#action_12659607

Philip Borlin commented on JCR-1917:

First of all thank you very much for the speedy response to the report.

I am testing against bedework (http://www.bedework.org/bedework/) so the debate is whether
the server is broken, but no matter.

I read the section you were talking about three times to make sure I caught all the nuances
and I have a different interpretation.  It seems to me that all they are saying is that if
you see something you can't process just skip it, don't stop processing.  As an example let's
say they change the DTD for calendar-query to:

<!ELEMENT calendar-query (new-feature, (DAV:allprop |
                                    DAV:propname |
                                    DAV:prop)?, filter, timezone?)>

The legacy server receiving this request should skip the new feature but still expect that
the filter element will be after the prop element (if one exists) and is not expected to look
for a prop element after the filter element.

I do have to apologize because the fix I suggested would be a bad idea.  It seems that the
RPI WebDAV server (which bedework builds off of) enforces the ordering of WebDAV requests
based off of the examples in the RFCs even though DTD ordering is not specified.  I would
not want a change to affect other users.  My new proposal is to add two protected methods
that will not change current behavior but will allow a subclass to have access to everything
it needs to override the toXML() method.  The two methods are as follows:

protected Element createElement(Document document) {
    return DomUtil.createElement(document, typeLocalName, typeNamespace);
protected List getContent() {
    return content;

The first line of toXML() could be refactored to:

Element reportElement = createElement(document);

for completeness if desired.

> Report Info appends properties after content
> --------------------------------------------
>                 Key: JCR-1917
>                 URL: https://issues.apache.org/jira/browse/JCR-1917
>             Project: Jackrabbit
>          Issue Type: Bug
>          Components: jackrabbit-webdav
>    Affects Versions: 1.5.0
>         Environment: N/A
>            Reporter: Philip Borlin
> RFC 3253 does not specify any ordering for reports, but RFC 4791 (CalDAV specification
which is built on top of WebDAV) contains DTD sequences that define the order the <prop>
elements occur within a report.
> Examples are from section 9.5:
> <!ELEMENT calendar-query ((DAV:allprop |
>                                     DAV:propname |
>                                     DAV:prop)?, filter, timezone?)>
> and from section 9.10
> <!ELEMENT calendar-multiget ((DAV:allprop |
>                                       DAV:propname |
>                                       DAV:prop)?, DAV:href+)>
> As of 1.5.0 org.apache.jackrabbit.webdav.version.report.ReportInfo the toXML(Document)
method specifically puts the content before the properties.  I request that we reverse the
order and put the properties first before the content.
> This fix should have no impact on WebDAV servers since ordering is not specified and
will allow CalDAV extensions to be built on top of jackrabbit's WebDAV.
> Failing to make this fix makes it impossible to add CalDAV extensions on top of jackrabbit's

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message