Unmarshalling without validation against an XML Schema
is risky - one never knows whether the input is really what
one expects. JAXB tends to be tolerant, ignoring certain
things unless they really throw a spanner into the works.
I'm not sure what may happen if the XML doesn't match
with the way you call unmarshal. I've just run an
unmarshalling for an annotated JavaBean using an
Class<?> declaredType argument, and, surprisingly, the
unmarshaller didn't care about the local name of the
top level element. There was no exception, neither JAXB*
nor java.lang.*.
That said, we know that, when an unmarshalling call returns
a JAXBElement<?>, one can test the value's class dynamically,
and check the root element's qualified name (namespace and
local name).
This doesn't throw type-safety out of the window. You expect to
have to handle aberrations anyway, so checking the returned
value and then casting is still type-safe.
-W
On 14/07/2014, Timothy Astle <timothy.astle_at_caris.com> wrote:
> This question relates to JAX-RS working with JAX-B, so please bare with
> me as I start with JAX-RS.
>
> I have a message body reader that is like the following:
>
> @Override
> public T readFrom(Class<T> type, Type genericType, Annotation[]
> annotations,
> MediaType mediaType, MultivaluedMap<String, String>
> httpHeaders,
> InputStream entityStream) throws IOException,
> WebApplicationException {
>
> try {
> JAXBContext jc =
> JAXBContext.newInstance("com.acme.foo:com.acme.more");
> Unmarshaller u = jc.createUnmarshaller();
> return u.unmarshal(new StreamSource(entityStream),
> type).getValue(); // <--here
> } catch (JAXBException e) {
> // TODO Auto-generated catch block
> e.printStackTrace();
> }
> return null;
> }
>
> I know the type that I want to receive, but I have a case where it is
> possible that the type is incorrect for the given stream of XML data
> (posting an XML document to a URL that expects a different XML
> document). In that case, JAXB creates a basic instance of type T to
> return since the stream doesn't match the type expected. This matches
> the documentation I've read:
> https://jaxb.java.net/nonav/2.2.4/docs/api/javax/xml/bind/Unmarshaller.html
> https://jaxb.java.net/guide/_XmlRootElement_and_unmarshalling.html
>
> The type is actually the name of the root element in the incoming XML
> file. It'd be nice if I could keep the type-safety of
> unmarshal(StreamSource, Type), but also have it throw an exception if it
> is the wrong document.
>
> One thing we could do is use the unmarshal(StreamSource) let the
> unmarshaller figure the Type and then compare the JAX-RS Type to the
> JAXB Type. I'm just not sure if I'm overlooking something because it'd
> be nice if the unmarshaller could throw an UnmarshalException or
> something to that effect. (Maybe using a SAXSource or custom
> XMLReader?) It would make for a cleaner exception handling flow.
>
> Does anyone have any advice on doing this? Is there a better way?
>
>
>
> --
> Tim Astle
> Development Manager
> Web Technologies
>
> *CARIS* <http://www.caris.com>
> 115 Waggoners Lane
> Fredericton, New Brunswick
> Canada E3B 2L4
> Tel: +1.506.458.8533 Fax: +1.506.459.3849
> www.caris.com <http://www.caris.com>
>
> *Connect with CARIS*
> Twitter <http://www.twitter.com/CARIS_GIS> | LinkedIn
> <http://www.linkedin.com/groups?mostPopular=&gid=3217878> | Facebook
> <https://www.facebook.com/pages/CARIS-The-Marine-GIS-Experts/123907500987669?v=app_4949752878>
>
> | Google+
> <https://plus.google.com/b/114389770462919844434/114389770462919844434/posts>
>
> | YouTube <http://www.youtube.com/user/CARISGIS>
>
> Download your free copy of CARIS Easy View today!
> www.caris.com/easyview <http://www.caris.com/easyview>
>
> _________________________________________________________________________
> This email and any files transmitted with it are confidential and
> intended only for the addressee(s). If you are not the intended
> recipient(s) please notify us by email reply. You should not use,
> disclose, distribute or copy this communication if received in error.
>
> Any views or opinions expressed in this email are solely those of the
> author and do not necessarily represent those of the company. No binding
> contract will result from this email until such time as a written
> document is signed on behalf of the company.
>
>