Package net.fortuna.ical4j.connector.dav

Class DefaultDavClient

    • Field Summary

      Fields 
      Modifier and Type Field Description
      protected org.apache.http.client.HttpClient httpClient
      The underlying HTTP client.
      protected org.apache.http.client.protocol.HttpClientContext httpClientContext  

    • Method Summary

      All Methods Instance Methods Concrete Methods 
      Modifier and Type Method Description
      List<SupportedFeature> begin​(String bearerAuth)  
      List<SupportedFeature> begin​(String username, char[] password)  
      void copy​(String src, String dest)
      The COPY method creates a duplicate of the source resource identified by the Request-URI, in the destination resource identified by the URI in the Destination header.
      void delete​(String path)
      DELETE is defined in [RFC2616], Section 9.7, to "delete the resource identified by the Request-URI".
      List<Attendee> findPrincipals​(String path, PrincipalPropertySearchInfo info)  
      List<ScheduleResponse> freeBusy​(String path, Calendar query, Organizer organizer)  
      <T> T get​(String path, org.apache.http.client.ResponseHandler<T> handler)
      The semantics of GET are unchanged when applied to a collection, since GET is defined as, "retrieve whatever information (in the form of an entity) is identified by the Request-URI" [RFC2616].
      List<SupportedFeature> getSupportedFeatures()  
      <T> T head​(String path, org.apache.http.client.ResponseHandler<T> handler)  
      void lock​(String path)
      The following sections describe the LOCK method, which is used to take out a lock of any access type and to refresh an existing lock.
      void mkCalendar​(String path, org.apache.jackrabbit.webdav.property.DavPropertySet properties)
      An HTTP request using the MKCALENDAR method creates a new calendar collection resource.
      void mkCol​(String path)
      MKCOL creates a new collection resource at the location specified by the Request-URI.
      void move​(String src, String dest)
      The MOVE operation on a non-collection resource is the logical equivalent of a copy (COPY), followed by consistency maintenance processing, followed by a delete of the source, where all three actions are performed in a single operation.
      void post()
      Since by definition the actual function performed by POST is determined by the server and often depends on the particular resource, the behavior of POST when applied to collections cannot be meaningfully modified because it is largely undefined.
      org.apache.jackrabbit.webdav.property.DavPropertySet propFind​(String path, org.apache.jackrabbit.webdav.property.DavPropertyNameSet propertyNames)
      The PROPFIND method retrieves properties defined on the resource identified by the Request-URI, if the resource does not have any internal members, or on the resource identified by the Request-URI and potentially its member resources, if the resource is a collection that has internal member URLs.
      Map<String,​org.apache.jackrabbit.webdav.property.DavPropertySet> propFindResources​(String path, org.apache.jackrabbit.webdav.property.DavPropertyNameSet propertyNames, ResourceType... resourceTypes)  
      org.apache.jackrabbit.webdav.property.DavPropertySet propFindType​(String path, int type)  
      org.apache.jackrabbit.webdav.MultiStatusResponse propPatch​(String path, List<? extends org.apache.jackrabbit.webdav.property.PropEntry> changeList)
      The PROPPATCH method processes instructions specified in the request body to set and/or remove properties defined on the resource identified by the Request-URI.
      void put​(String path, Calendar calendar, String etag)
      Save calendar data.
      void put​(String path, net.fortuna.ical4j.vcard.VCard card, String etag)
      Save card data.
      Map<String,​org.apache.jackrabbit.webdav.property.DavPropertySet> report​(String path, CalendarQuery query, org.apache.jackrabbit.webdav.version.report.ReportType reportType, org.apache.jackrabbit.webdav.property.DavPropertyNameSet propertyNames)
      The REPORT method (defined in Section 3.6 of [RFC3253]) provides an extensible mechanism for obtaining information about one or more resources.
      <T> T report​(String path, org.apache.jackrabbit.webdav.version.report.ReportInfo info, org.apache.http.client.ResponseHandler<T> handler)  
      void unlock​(String path)
      The UNLOCK method removes the lock identified by the lock token in the Lock-Token request header.

    • Field Detail

      • httpClient

        protected org.apache.http.client.HttpClient httpClient
        The underlying HTTP client.

      • httpClientContext

        protected org.apache.http.client.protocol.HttpClientContext httpClientContext

    • Method Detail

      • mkCalendar

        public void mkCalendar​(String path,
                       org.apache.jackrabbit.webdav.property.DavPropertySet properties)
                throws IOException,
                       ObjectStoreException,
                       org.apache.jackrabbit.webdav.DavException
        Description copied from interface: CalDavSupport
        An HTTP request using the MKCALENDAR method creates a new calendar collection resource. A server MAY restrict calendar collection creation to particular collections. Support for MKCALENDAR on the server is only RECOMMENDED and not REQUIRED because some calendar stores only support one calendar per user (or principal), and those are typically pre-created for each account. However, servers and clients are strongly encouraged to support MKCALENDAR whenever possible to allow users to create multiple calendar collections to help organize their data better. Clients SHOULD use the DAV:displayname property for a human-readable name of the calendar. Clients can either specify the value of the DAV:displayname property in the request body of the MKCALENDAR request, or alternatively issue a PROPPATCH request to change the DAV:displayname property to the appropriate value immediately after issuing the MKCALENDAR request. Clients SHOULD NOT set the DAV: displayname property to be the same as any other calendar collection at the same URI "level". When displaying calendar collections to users, clients SHOULD check the DAV:displayname property and use that value as the name of the calendar. In the event that the DAV: displayname property is empty, the client MAY use the last part of the calendar collection URI as the name; however, that path segment may be "opaque" and not represent any meaningful human-readable text. If a MKCALENDAR request fails, the server state preceding the request MUST be restored. Marshalling: If a request body is included, it MUST be a CALDAV:mkcalendar XML element. Instruction processing MUST occur in the order instructions are received (i.e., from top to bottom). Instructions MUST either all be executed or none executed. Thus, if any error occurs during processing, all executed instructions MUST be undone and a proper error result returned. Instruction processing details can be found in the definition of the DAV:set instruction in Section 12.13.2 of [RFC2518]. If a response body for a successful request is included, it MUST be a CALDAV:mkcalendar-response XML element. The response MUST include a Cache-Control:no-cache header. Preconditions: (DAV:resource-must-be-null): A resource MUST NOT exist at the Request-URI; (CALDAV:calendar-collection-location-ok): The Request-URI MUST identify a location where a calendar collection can be created; (CALDAV:valid-calendar-data): The time zone specified in the CALDAV:calendar-timezone property MUST be a valid iCalendar object containing a single valid VTIMEZONE component; (DAV:needs-privilege): The DAV:bind privilege MUST be granted to the current user on the parent collection of the Request-URI. Postconditions: (CALDAV:initialize-calendar-collection): A new calendar collection exists at the Request-URI. The DAV:resourcetype of the calendar collection MUST contain both DAV:collection and CALDAV:calendar XML elements.
        Specified by:
        mkCalendar in interface CalDavSupport
        Parameters:
        path - the (partial) URI of the collection to create
        properties - a set of DAV properties to initialise the collection
        Throws:
        IOException - for failures such as network connectivity
        ObjectStoreException - when creation fails (i.e. non-2xx HTTP status)
        org.apache.jackrabbit.webdav.DavException

      • mkCol

        public void mkCol​(String path)
        Description copied from interface: WebDavSupport
        MKCOL creates a new collection resource at the location specified by the Request-URI. If the Request-URI is already mapped to a resource, then the MKCOL MUST fail. During MKCOL processing, a server MUST make the Request-URI an internal member of its parent collection, unless the Request-URI is "/". If no such ancestor exists, the method MUST fail. When the MKCOL operation creates a new collection resource, all ancestors MUST already exist, or the method MUST fail with a 409 (Conflict) status code. For example, if a request to create collection /a/b/c/d/ is made, and /a/b/c/ does not exist, the request must fail. When MKCOL is invoked without a request body, the newly created collection SHOULD have no members. A MKCOL request message may contain a message body. The precise behavior of a MKCOL request when the body is present is undefined, but limited to creating collections, members of a collection, bodies of members, and properties on the collections or members. If the server receives a MKCOL request entity type it does not support or understand, it MUST respond with a 415 (Unsupported Media Type) status code. If the server decides to reject the request based on the presence of an entity or the type of an entity, it should use the 415 (Unsupported Media Type) status code. This method is idempotent, but not safe (see Section 9.1 of [RFC2616]). Responses to this method MUST NOT be cached.
        Specified by:
        mkCol in interface WebDavSupport

      • propFind

        public org.apache.jackrabbit.webdav.property.DavPropertySet propFind​(String path,
                                                                     org.apache.jackrabbit.webdav.property.DavPropertyNameSet propertyNames)
                                                              throws IOException
        Description copied from interface: WebDavSupport
        The PROPFIND method retrieves properties defined on the resource identified by the Request-URI, if the resource does not have any internal members, or on the resource identified by the Request-URI and potentially its member resources, if the resource is a collection that has internal member URLs. All DAV-compliant resources MUST support the PROPFIND method and the propfind XML element (Section 14.20) along with all XML elements defined for use with that element. A client MUST submit a Depth header with a value of "0", "1", or "infinity" with a PROPFIND request. Servers MUST support "0" and "1" depth requests on WebDAV-compliant resources and SHOULD support "infinity" requests. In practice, support for infinite-depth requests MAY be disabled, due to the performance and security concerns associated with this behavior. Servers SHOULD treat a request without a Depth header as if a "Depth: infinity" header was included. A client may submit a 'propfind' XML element in the body of the request method describing what information is being requested. It is possible to: o Request particular property values, by naming the properties desired within the 'prop' element (the ordering of properties in here MAY be ignored by the server), o Request property values for those properties defined in this specification (at a minimum) plus dead properties, by using the 'allprop' element (the 'include' element can be used with 'allprop' to instruct the server to also include additional live properties that may not have been returned otherwise), o Request a list of names of all the properties defined on the resource, by using the 'propname' element. A client may choose not to submit a request body. An empty PROPFIND request body MUST be treated as if it were an 'allprop' request. Note that 'allprop' does not return values for all live properties. WebDAV servers increasingly have expensively-calculated or lengthy properties (see [RFC3253] and [RFC3744]) and do not return all properties already. Instead, WebDAV clients can use propname requests to discover what live properties exist, and request named properties when retrieving values. For a live property defined elsewhere, that definition can specify whether or not that live property would be returned in 'allprop' requests. All servers MUST support returning a response of content type text/ xml or application/xml that contains a multistatus XML element that describes the results of the attempts to retrieve the various properties. If there is an error retrieving a property, then a proper error result MUST be included in the response. A request to retrieve the value of a property that does not exist is an error and MUST be noted with a 'response' XML element that contains a 404 (Not Found) status value. Consequently, the 'multistatus' XML element for a collection resource MUST include a 'response' XML element for each member URL of the collection, to whatever depth was requested. It SHOULD NOT include any 'response' elements for resources that are not WebDAV-compliant. Each 'response' element MUST contain an 'href' element that contains the URL of the resource on which the properties in the prop XML element are defined. Results for a PROPFIND on a collection resource are returned as a flat list whose order of entries is not significant. Note that a resource may have only one value for a property of a given name, so the property may only show up once in PROPFIND responses. Properties may be subject to access control. In the case of 'allprop' and 'propname' requests, if a principal does not have the right to know whether a particular property exists, then the property MAY be silently excluded from the response. Some PROPFIND results MAY be cached, with care, as there is no cache validation mechanism for most properties. This method is both safe and idempotent (see Section 9.1 of [RFC2616]).
        Specified by:
        propFind in interface WebDavSupport
        Parameters:
        path - a resource URI
        propertyNames - the set of properties to return
        Returns:
        a property set matching the requested property names
        Throws:
        IOException

      • propFindResources

        public Map<String,​org.apache.jackrabbit.webdav.property.DavPropertySet> propFindResources​(String path,
                                                                                                org.apache.jackrabbit.webdav.property.DavPropertyNameSet propertyNames,
                                                                                                ResourceType... resourceTypes)
                                                                                         throws IOException
        Throws:
        IOException

      • report

        public Map<String,​org.apache.jackrabbit.webdav.property.DavPropertySet> report​(String path,
                                                                                     CalendarQuery query,
                                                                                     org.apache.jackrabbit.webdav.version.report.ReportType reportType,
                                                                                     org.apache.jackrabbit.webdav.property.DavPropertyNameSet propertyNames)
                                                                              throws IOException,
                                                                                     ParserConfigurationException
        Description copied from interface: CalDavSupport
        The REPORT method (defined in Section 3.6 of [RFC3253]) provides an extensible mechanism for obtaining information about one or more resources. Unlike the PROPFIND method, which returns the value of one or more named properties, the REPORT method can involve more complex processing. REPORT is valuable in cases where the server has access to all of the information needed to perform the complex request (such as a query), and where it would require multiple requests for the client to retrieve the information needed to perform the same request. CalDAV servers MUST support the DAV:expand-property REPORT defined in Section 3.8 of [RFC3253].
        Specified by:
        report in interface CalDavSupport
        Returns:
        Throws:
        IOException
        ParserConfigurationException

      • get

        public <T> T get​(String path,
                 org.apache.http.client.ResponseHandler<T> handler)
          throws IOException
        Description copied from interface: WebDavSupport
        The semantics of GET are unchanged when applied to a collection, since GET is defined as, "retrieve whatever information (in the form of an entity) is identified by the Request-URI" [RFC2616]. GET, when applied to a collection, may return the contents of an "index.html" resource, a human-readable view of the contents of the collection, or something else altogether. Hence, it is possible that the result of a GET on a collection will bear no correlation to the membership of the collection. Similarly, since the definition of HEAD is a GET without a response message body, the semantics of HEAD are unmodified when applied to collection resources.
        Specified by:
        get in interface WebDavSupport
        Returns:
        Throws:
        IOException

      • copy

        public void copy​(String src,
                 String dest)
          throws org.apache.jackrabbit.webdav.DavException,
                 IOException
        Description copied from interface: WebDavSupport
        The COPY method creates a duplicate of the source resource identified by the Request-URI, in the destination resource identified by the URI in the Destination header. The Destination header MUST be present. The exact behavior of the COPY method depends on the type of the source resource. All WebDAV-compliant resources MUST support the COPY method. However, support for the COPY method does not guarantee the ability to copy a resource. For example, separate programs may control resources on the same server. As a result, it may not be possible to copy a resource to a location that appears to be on the same server. This method is idempotent, but not safe (see Section 9.1 of [RFC2616]). Responses to this method MUST NOT be cached.
        Specified by:
        copy in interface WebDavSupport
        Throws:
        org.apache.jackrabbit.webdav.DavException
        IOException

      • move

        public void move​(String src,
                 String dest)
          throws IOException,
                 org.apache.jackrabbit.webdav.DavException
        Description copied from interface: WebDavSupport
        The MOVE operation on a non-collection resource is the logical equivalent of a copy (COPY), followed by consistency maintenance processing, followed by a delete of the source, where all three actions are performed in a single operation. The consistency maintenance step allows the server to perform updates caused by the move, such as updating all URLs, other than the Request-URI that identifies the source resource, to point to the new destination resource. The Destination header MUST be present on all MOVE methods and MUST follow all COPY requirements for the COPY part of the MOVE method. All WebDAV-compliant resources MUST support the MOVE method. Support for the MOVE method does not guarantee the ability to move a resource to a particular destination. For example, separate programs may actually control different sets of resources on the same server. Therefore, it may not be possible to move a resource within a namespace that appears to belong to the same server. If a resource exists at the destination, the destination resource will be deleted as a side-effect of the MOVE operation, subject to the restrictions of the Overwrite header. This method is idempotent, but not safe (see Section 9.1 of [RFC2616]). Responses to this method MUST NOT be cached.
        Specified by:
        move in interface WebDavSupport
        Throws:
        IOException
        org.apache.jackrabbit.webdav.DavException

      • delete

        public void delete​(String path)
            throws IOException,
                   org.apache.jackrabbit.webdav.DavException
        Description copied from interface: WebDavSupport
        DELETE is defined in [RFC2616], Section 9.7, to "delete the resource identified by the Request-URI". However, WebDAV changes some DELETE handling requirements. A server processing a successful DELETE request: MUST destroy locks rooted on the deleted resource MUST remove the mapping from the Request-URI to any resource. Thus, after a successful DELETE operation (and in the absence of other actions), a subsequent GET/HEAD/PROPFIND request to the target Request-URI MUST return 404 (Not Found).
        Specified by:
        delete in interface WebDavSupport
        Throws:
        IOException
        org.apache.jackrabbit.webdav.DavException

      • propPatch

        public org.apache.jackrabbit.webdav.MultiStatusResponse propPatch​(String path,
                                                                  List<? extends org.apache.jackrabbit.webdav.property.PropEntry> changeList)
                                                           throws IOException
        Description copied from interface: WebDavSupport
        The PROPPATCH method processes instructions specified in the request body to set and/or remove properties defined on the resource identified by the Request-URI. All DAV-compliant resources MUST support the PROPPATCH method and MUST process instructions that are specified using the propertyupdate, set, and remove XML elements. Execution of the directives in this method is, of course, subject to access control constraints. DAV-compliant resources SHOULD support the setting of arbitrary dead properties. The request message body of a PROPPATCH method MUST contain the propertyupdate XML element. Servers MUST process PROPPATCH instructions in document order (an exception to the normal rule that ordering is irrelevant). Instructions MUST either all be executed or none executed. Thus, if any error occurs during processing, all executed instructions MUST be undone and a proper error result returned. Instruction processing details can be found in the definition of the set and remove instructions in Sections 14.23 and 14.26. If a server attempts to make any of the property changes in a PROPPATCH request (i.e., the request is not rejected for high-level errors before processing the body), the response MUST be a Multi- Status response as described in Section 9.2.1. This method is idempotent, but not safe (see Section 9.1 of [RFC2616]). Responses to this method MUST NOT be cached.
        Specified by:
        propPatch in interface WebDavSupport
        Returns:
        Throws:
        IOException

      • post

        public void post()
        Description copied from interface: WebDavSupport
        Since by definition the actual function performed by POST is determined by the server and often depends on the particular resource, the behavior of POST when applied to collections cannot be meaningfully modified because it is largely undefined. Thus, the semantics of POST are unmodified when applied to a collection.
        Specified by:
        post in interface WebDavSupport

      • lock

        public void lock​(String path)
        Description copied from interface: WebDavSupport
        The following sections describe the LOCK method, which is used to take out a lock of any access type and to refresh an existing lock. These sections on the LOCK method describe only those semantics that are specific to the LOCK method and are independent of the access type of the lock being requested. Any resource that supports the LOCK method MUST, at minimum, support the XML request and response formats defined herein. This method is neither idempotent nor safe (see Section 9.1 of [RFC2616]). Responses to this method MUST NOT be cached.
        Specified by:
        lock in interface WebDavSupport

      • unlock

        public void unlock​(String path)
        Description copied from interface: WebDavSupport
        The UNLOCK method removes the lock identified by the lock token in the Lock-Token request header. The Request-URI MUST identify a resource within the scope of the lock. Note that use of the Lock-Token header to provide the lock token is not consistent with other state-changing methods, which all require an If header with the lock token. Thus, the If header is not needed to provide the lock token. Naturally, when the If header is present, it has its normal meaning as a conditional header. For a successful response to this method, the server MUST delete the lock entirely. If all resources that have been locked under the submitted lock token cannot be unlocked, then the UNLOCK request MUST fail. A successful response to an UNLOCK method does not mean that the resource is necessarily unlocked. It means that the specific lock corresponding to the specified token no longer exists. Any DAV-compliant resource that supports the LOCK method MUST support the UNLOCK method. This method is idempotent, but not safe (see Section 9.1 of [RFC2616]). Responses to this method MUST NOT be cached.
        Specified by:
        unlock in interface WebDavSupport