Hi Markus,
For the latest Jersey you should get an error when the request does
not contain a Content-Type. If there is no Content-Type present then
Jersey will assume a type of "application/octet-stream". There is no
message body reader configured for JAXB types and "application/octet-
stream".
As to the root cause of the problem, i am really not sure, the media
type should not make any difference. My suspicion is that it is due to
different JAXB contexts being used.
Paul.
On Jan 1, 2009, at 3:50 PM, Markus KARG wrote:
> Paul,
>
> found a small problem yesterday, so before checking in, I wanted to
> clarify:
>
> In WebDAV some XML Elements can have "ANY" content, i. e. it can
> have "unknown" XML Elements ("unknown" means: The programmer of the
> application will provide a JAXBClass for it and add it to the
> JAXBContext, but the WebDAV framework which I provide cannot know
> that classes, since those are not part of WebDAV itself -- a nice
> "custom extensibility" feature of WebDAV).
>
> So I simply used "@XmlRootElement(lax = true)" which (according to https://jaxb.dev.java.net/jaxb20-ed/api/javax/xml/bind/annotation/XmlAnyElement.html
> #lax()) should allow that.
>
> And it seems to work pretty well. :-)
>
> In the WebDAV sample, I implemented the following code which
> actually nicely prints a list of "unkown" JAXBElements that are
> correctly recognized at runtime. (The complexity comes from the fact
> that I wanted to deal with Microsoft's known "Content-Length=0-
> Problem".) No problem so far. :-)
>
> @PROPPATCH
> @Path("{filename}.adr")
> public final void proppatch(final InputStream body, @Context final
> Providers providers, @Context final HttpHeaders httpHeaders) throws
> IOException {
> final PropertyUpdate propertyUpdate =
> providers.getMessageBodyReader(PropertyUpdate.class,
> PropertyUpdate.class, new Annotation[0],
> MediaType.APPLICATION_XML_TYPE).readFrom(PropertyUpdate.class,
> PropertyUpdate.class, new Annotation[0],
> MediaType.APPLICATION_XML_TYPE, httpHeaders.getRequestHeaders(),
> body);
>
> System.out.println("PATCH PROPERTIES: " + propertyUpdate);
> }
>
> But then I recognized in the WebDAV specification that the PROPPATCH
> command will NEVER have an empty body but ALWAYS have exactly one
> <propertyupdate> element as its sole body. So I thought I can make
> the sample easiert to read and just removed the manual body reader
> stuff:
>
> @PROPPATCH
> @Path("{filename}.adr")
> public final void proppatch(final PropertyUpdate propertyUpdate) {
> System.out.println("PATCH PROPERTIES: " + propertyUpdate);
> }
>
> Now here comes the funny thing: Now "lax=true" is not working
> anymore -- all the "unknown" JAXBElements are marshalled as DOM
> Elements instead of JAXBElements. Strange!
>
> Do you have an explanation what the technical difference this makes,
> and how I can workaround this problem? I'd like to provide the
> sample code in the most possible simple form, you know. Is that a
> Jersey bug? Or is it my fault?
>
> I already checked the Content-Type using WireShark. Content-Type is
> missing actually in the request, while my explicit version provides
> APPLICATION_XML_TYPE manually. Maybe this is the difference?
>
> Thanks for you kind help! :-)
> Markus
>
> Regards
> Markus