On Jan 9, 2009, at 9:09 PM, Markus KARG wrote:
> My application is implementing a single ContextResolver<JAXBContext>
> which uses a single JAXBContext. So this cannot be the problem (or
> Jersey is possibly not using my content resolver in that particular
> case -- why chould that happen?).
>
Odd, if you could create a simple isolated test case i can debug it.
The reason i suspected the context resolver is that for the latter
case i am guessing JAXB knows nothing about how to bind the
"propertyupdate" element.
You could verify if the media type makes any difference by replacing
the XML media type in your explicit use of providers with application/
octet-stream. You might also be able to verify if your context
resolver gets called in both cases.
Paul.
> Regards
> Markus
>
> 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
>