users@jaxb.java.net

Re: Non-deterministic XJC code generation

From: Wolfgang Laun <wolfgang.laun_at_gmail.com>
Date: Wed, 19 Aug 2009 13:09:21 +0200

The "B" in JAXBElement<? extends B> is just the "lowermost" common class for
all the elements that appear in a xs:choice or xs:sequence, as determined by
xjc.

Some applications care about this (rather than just using <?>), especially
when the element set is from siblings of subclasses of some specific
application class. This means, that it won't be changed.

You know the strategy to adopt in your case.

-W


On Tue, Aug 18, 2009 at 4:55 PM, Craig McIlwee <
craig.mcilwee_at_openroadsconsulting.com> wrote:

> Hello,
>
>
>
> I am currently running into an issue where XJC generates slightly different
> code from consecutive runs. Sometimes I end up with a method that returns
> JAXBElement<? extends Serializable> and other times returns JAXBElement<?>.
> If our code tried to do something like
>
>
>
> JAXBElement<? extends Serializable> elem = obj.getTheJAXBElement();
>
>
>
> then the build will fail sometimes and succeed other times, depending on
> the code generated by XJC. We can work around this by always only expecting
> JAXBElement<?> because we don’t really care about the serializablity of the
> content object, but I’m just curious about what is causing this. At the
> moment we are using Java 6 with JAXB RI 2.1.10 and XJC 2.1.10.1, but we have
> also seen the same problem a couple of years ago when using Java 5 with an
> early (maybe even beta) version JAXB 2.0. Back then we just didn’t use that
> element and stored our data in a different element. The schema we are using
> is an IEEE standard (IEEE 1512) so we can’t modify it, here is the relevant
> element:
>
>
>
> <xs:complexType name="AdminAreaGroup" >
>
> <xs:choice minOccurs="1" maxOccurs="unbounded">
>
> <xs:element name="city" type="Text-name255" />
>
> <xs:element name="county" type="Text-name255" />
>
> <xs:element name="state" type="Text-name255" />
>
> <xs:element name="postalCode" type="PostalCode" />
>
> <xs:element name="countryCode" type="CountryCode" />
>
> <xs:element name="stateFIPS" type="Int-index8" />
>
> <xs:element name="entityIPS" type="Int-index32" />
>
> <xs:element name="countyFIPS" type="Int-index16" />
>
> <xs:element name="cityFIPS" type="Int-index32" />
>
> <xs:element name="localAdminAreaGroup" type="local:AdminAreaGroup"
> minOccurs="0"/>
>
> </xs:choice>
>
> </xs:complexType>
>
>
>
> And the code that sometimes fails is
>
>
>
> private static void adminAreasToOreo(final AdminAreaGroup adminAreas, final
> Incident inc) {
>
> for (JAXBElement<? extends Serializable> county :
> adminAreas.getCityOrCountyOrState()) {
>
> if (county.getName().getLocalPart().equals(“county”)) {
>
> // do something
>
> }
>
> }
>
> }
>
>
>
> Again, not a big deal since changing <? extends Serializable> to <?> gets
> us around the problem, but more so just curious about the cause and any
> possible parameters that could be passed to XJC to avoid this in the
> future.
>
>
>
> Thanks,
>
> Craig McIlwee
>
> Open Roads Consulting, Inc.
>
> 757-546-3401
>
> http://www.openroadsconsulting.com
>
>
>
> This e-mail communication (including any attachments) may contain
> confidential and/or privileged material intended solely for the individual
> or entity to which it is addressed. If you are not the intended recipient,
> you should immediately stop reading this message and delete it from all
> computers that it resides on. Any unauthorized reading, distribution,
> copying or other use of this communication (or its attachments) is strictly
> prohibited. If you have received this communication in error, please notify
> us immediately.
>
>
>