users@jaxb.java.net

Re: 2.1.8 issue

From: Claus Nagel <claus.nagel_at_gmail.com>
Date: Thu, 4 Sep 2008 02:11:23 -0700 (PDT)

To illustrate my issue with JAXB 2.1.8, I uploaded a .zip file to my ftp
server which contains the XML schemata to be compiled, my binding file and
an ant build file. If you unzip the file, you will find a subfolder "lib".
Please put the JAXB libaries there (the folder already contains the .jars of
JAXB 2.1.8). The main schema together with the corresponding binding rules
can be found in "schema/CityGML".

I suggest running the ant script with JAXB 2.1.8. This results in a
subfolder "src-gen" containing the generated JAXB classes. Move this folder
somewhere else and re-run the ant script, this time replacing the libraries
in "lib" with JAXB 2.1.7. Finally, run a diff tool on the two created
"src-gen" folders. Have a look, for example, at the class
"net/opengis/gml/AbstractGMLType.java".

You will find the .zip file at:
ftp://jaxb:issue@cassius.bv.tu-berlin.de

Here are my questions:
* Why is JAXB 2.1.8 using the generated element classes as data types of
instance variables for the classes representing complex type definitions?

JAXB 2.1.7 is not. Since generating element classes is optional, in my
opinion the final mapping should not rely on these element classes. If you
turn off "generateElementClass", the output of JAXB 2.1.7 and 2.1.8 is the
same again. This should also be true if the "generateElementClass" is set to
true (after all, 2.1.8 is only a minor JAXB update - otherwise I would
perhaps expect an update to JAXB 2.2?!). At the moment, my business code is
not compiling any more due to the differing output of JAXB 2.1.8, although I
did not change the schemata, my binding file, or my ant script...

* I could not find a documentation on this new behaviour. Is it documented
somewhere?
* Do I have to adapt my business code, i.e., will this be the normal
behaviour of upcoming JAXB releases?

After all, this issue could also be related to some errors in my project
set-up. It would be of great help, if someone could check my .zip file and
tell me.

Many thanks in advance!
Looking forward to your answers,
Claus




Claus Nagel wrote:
>
> Hi all -
>
> I just updated to JAXB RI 2.1.8 and re-compiled my schema using xjc. The
> resulting Java classes are different to a great extent. Have a look at the
> following class snippets:
>
> JAXB 2.1.7:
>> public abstract class AbstractGMLType {
>> protected List<MetaDataPropertyType> metaDataProperty;
>> protected StringOrRefType description;
>
> JAXB 2.1.8:
>> public abstract class AbstractGMLType {
>> @XmlElementRef(name = "metaDataProperty", namespace =
> "http://www.opengis.net/gml", type = MetaDataPropertyElement.class)
>> protected List<MetaDataPropertyElement> metaDataProperty;
>> @XmlElementRef(name = "description", namespace =
> "http://www.opengis.net/gml", type = DescriptionElement.class)
>> protected DescriptionElement description;
>
>
> I have a jaxb:bindings file where I set "generateElementClass" to "true"
> and
> element classes are marked using the suffix "Element".
>
> As you can see from the code snippets, for JAXB 2.1.7, the data type of
> the
> generated instance variables refers to the class representing the xsd
> complex type definition. For JAXB 2.1.8, the data type is the generated
> element class (well, however, also JAXB 2.1.8 sometimes uses the classes
> representing the type definition as data type...)
>
> I did not change my binding rules. This behaviour of JAXB 2.1.8 is quite
> annoying since my whole project does not compile any more due to the
> differing data types.
>
> Any ideas, how I can tell JAXB 2.1.8 not to use the element classes as
> data
> types?
>
> Regards,
> Claus
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jaxb.dev.java.net
> For additional commands, e-mail: users-help_at_jaxb.dev.java.net
>
>
>

-- 
View this message in context: http://www.nabble.com/2.1.8-issue-tp19286385p19306310.html
Sent from the java.net - jaxb users mailing list archive at Nabble.com.