2.1.8 issue

View: New views
2 Messages — Rating Filter:   Alert me  

2.1.8 issue

by Claus Nagel :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

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@...
For additional commands, e-mail: users-help@...


Re: 2.1.8 issue

by Claus Nagel :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

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@jaxb.dev.java.net
For additional commands, e-mail: users-help@jaxb.dev.java.net
LightInTheBox - Buy quality products at wholesale price!