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?).
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/XmlAnyElem
ent.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