I see how the substitution groups throw a wrench in the works, but I
think my main concern is consistency and the early access release
doesn't seem to have it. If it always returns JAXBElement that would be
fine. But it mostly returns the objects themselves and sometimes (I
haven't figured out exactly when) JAXBElement. I feel that it should
always return the objects themselves and when the client needs the name,
a second Unmarshaller method can be provided. That way it is always
consistent and the developer doesn't have to guess when it will return
JAXBElement or the object. Here's what I was thinking for the new method:
JAXBContext c = JAXBContext.newInstance(ObjectFactory.class);
Unmarshaller um = c.createUnmarshaller();
MyRequest mr = um.umarhsal(inputStream); // object itself
JAXBElement<MyRequest> mr = um.unmarhsalElement(inputStream); // JAXBElement
(of course there would be casts in the code).
This would allow users to get at the JAXBElement when it is needed, but
also be able to just deal with the Objects directly. As for substitution
groups, those that need the name of the element can use the second
method and receive the JAXBElement.
Thoughts?
Kohsuke Kawaguchi wrote:
> Brian Pontarelli wrote:
>
>> Yeah, I'm getting a JAXBElement<SomeRequest> returned from the
>> unmarshaller rather than a SomeRequest. I just included the
>> ObjectFactory code to show you what is being generated. The
>> SomeRequest and Request classes look like normal JavaBeans and have
>> the correct annotations. Just looks like the unmarshaller is doing
>> something strange.
>
>
> The fact that the unmarshaller returns JAXBElement<SomeRequest> is
> actually by design. We are concerned about the usability implication
> of this, but OTOH we need this to support 100% XML Schema --- the idea
> here is that JAXBElement captures the tag name, which could be
> changed as a result of a substitution group.
>
> So in general, the unmarshal method can return JAXBElement.
>
> I'm curious what your thoughts are.
>
> For this particular case, I think we changed the XJC since the WS-I TP
> release so that it will not generate the code that uses JAXBElement,
> and it will associate "someRequest" element directly with the
> SomeRequest class.
>
>