webdav-jaxrs
  1. webdav-jaxrs
  2. WEBDAV_JAXRS-33

LOCK throws Exception when returning Prop

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Works as designed
    • Affects Version/s: 1.2
    • Fix Version/s: 1.2
    • Component/s: www
    • Labels:
      None
    • Environment:

      OSX

      Description

      When calling the HTTP LOCK, I get an exception.

      In it's most simple form,

      @LOCK
      @Produces(MediaType.APPLICATION_XML)
      public Prop lockFile(@Context SecurityContext securityContext,
      @PathParam("fileId") String fileIdStr)
      {
      return new Prop(new LockDiscovery());
      }

      I get the following exception:
      [com.sun.istack.internal.SAXException2: class net.java.dev.webdav.jaxrs.xml.properties.LockDiscovery nor any of its super class is known to this context.
      javax.xml.bind.JAXBException: class net.java.dev.webdav.jaxrs.xml.properties.LockDiscovery nor any of its super class is known to this context.]
      at com.sun.xml.internal.bind.v2.runtime.MarshallerImpl.write(MarshallerImpl.java:311)
      at com.sun.xml.internal.bind.v2.runtime.MarshallerImpl.marshal(MarshallerImpl.java:236)
      at javax.xml.bind.helpers.AbstractMarshallerImpl.marshal(AbstractMarshallerImpl.java:95)
      at org.glassfish.jersey.message.internal.AbstractRootElementJaxbProvider.writeTo(AbstractRootElementJaxbProvider.java:189)
      at org.glassfish.jersey.message.internal.AbstractRootElementJaxbProvider.writeTo(AbstractRootElementJaxbProvider.java:168)
      ... 25 more

        Activity

        Hide
        glagnar added a comment -

        My workaround until now, is to add @XmlSeeAlso(LockDiscovery.class) to the Prop.java file, and build it myself. But I would like to see a better solution.

        Show
        glagnar added a comment - My workaround until now, is to add @XmlSeeAlso(LockDiscovery.class) to the Prop.java file, and build it myself. But I would like to see a better solution.
        Hide
        mkarg added a comment -

        Reduced priority according to conventions as simple workaround is already known to user.

        Show
        mkarg added a comment - Reduced priority according to conventions as simple workaround is already known to user.
        Hide
        mkarg added a comment - - edited

        Cannot reproduce using 1.2 (see attached new unit test). Are you sure that (1) you are using version 1.2 and (2) you are using an application which manually creates a WebDavContextResolver? If the latter is the case, does providing

        LockDiscovery.class

        as an argument to the WebDavContextResolver's constructor actually workaround the problem or does it still occur? In the latter case, can you please adjust the new Bug33Test so that it will reproduce the behaviour? Without that I do not see how this could be fixed, as you proposed workaround actually is strange – the information provided by @XmlSeeAlso in fact is already known to the context due to the WebDavContextResolver, hence I assume that your application actually is providing a "normal" JAXB context, but does not use the one provided by WebDavContextResolver.

        Show
        mkarg added a comment - - edited Cannot reproduce using 1.2 (see attached new unit test). Are you sure that (1) you are using version 1.2 and (2) you are using an application which manually creates a WebDavContextResolver? If the latter is the case, does providing LockDiscovery.class as an argument to the WebDavContextResolver's constructor actually workaround the problem or does it still occur? In the latter case, can you please adjust the new Bug33Test so that it will reproduce the behaviour? Without that I do not see how this could be fixed, as you proposed workaround actually is strange – the information provided by @XmlSeeAlso in fact is already known to the context due to the WebDavContextResolver, hence I assume that your application actually is providing a "normal" JAXB context, but does not use the one provided by WebDavContextResolver.
        Hide
        glagnar added a comment -

        You are absolutely correct. I am not using the webDavContextResolver. I hadn't spotted that, so thank you.

        Is it possible to work with an 'ordinary' ContextResolver ? I am not sure, I want to change this for the entire project ?

        Show
        glagnar added a comment - You are absolutely correct. I am not using the webDavContextResolver. I hadn't spotted that, so thank you. Is it possible to work with an 'ordinary' ContextResolver ? I am not sure, I want to change this for the entire project ?
        Hide
        mkarg added a comment -

        What you reported is not a bug but designed behaviour of JAX-RS.

        There is not much to change in your program. Due to the technical design of JAX-RS and due to the extensibility of the WebDAV standard, using an "ordinary" context resolver won't work (the side effect is what you noticed). Also note that JAX-RS will use the WebDAVContextResolver only to resolve WebDAV methods (decided by the received / sent MIME types), so it is really safe to register the WebDAVContextResolver, as for all other MIME types JAX-RS will not utilize it but choose the "ordinary" one. If you see a way that is JAX-RS and WebDAV compliant, feel free to post a feature request and / or a test case demonstrating the imagined solution.

        Show
        mkarg added a comment - What you reported is not a bug but designed behaviour of JAX-RS. There is not much to change in your program. Due to the technical design of JAX-RS and due to the extensibility of the WebDAV standard, using an "ordinary" context resolver won't work (the side effect is what you noticed). Also note that JAX-RS will use the WebDAVContextResolver only to resolve WebDAV methods (decided by the received / sent MIME types), so it is really safe to register the WebDAVContextResolver, as for all other MIME types JAX-RS will not utilize it but choose the "ordinary" one. If you see a way that is JAX-RS and WebDAV compliant, feel free to post a feature request and / or a test case demonstrating the imagined solution.

          People

          • Assignee:
            mkarg
            Reporter:
            glagnar
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: