You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@cxf.apache.org by "Craig Tataryn (JIRA)" <ji...@apache.org> on 2010/01/12 04:30:54 UTC
[jira] Created: (CXF-2614) cxf-common-xsd plugin generated files
differ from xjc generated ones
cxf-common-xsd plugin generated files differ from xjc generated ones
--------------------------------------------------------------------
Key: CXF-2614
URL: https://issues.apache.org/jira/browse/CXF-2614
Project: CXF
Issue Type: Bug
Components: Tooling
Affects Versions: 2.2.5
Environment: $ mvn --version
Apache Maven 2.2.1 (r801777; 2009-08-06 14:16:01-0500)
Java version: 1.6.0
Java home: D:\Program Files\IBM\RAD75\jdk\jre
Default locale: en_US, platform encoding: Cp1252
OS name: "windows xp" version: "5.1 build 2600 service pack 3" arch: "x86" Family: "windows"
Reporter: Craig Tataryn
Noticed a problem where *cxf-common-xsd* was spitting out {{.java}} files that didn't have a {{setContent(String)}} method when their corresponding {{<xsd:element>}} types had a {{mixed="true"}} attribute.
I setup a test (which will be attached), ran both xjc from the command line (see {{xjc-output}} directory in the attached test project) as well as setting up a pom file to run cxf-common-xsd against the same set of schemas.
There is a type in {{datatypes-base.xsd}} called {{BIN}} which extends a base type called {{ANY}}. {{BIN}} has been marked with {{mixed="true"}} and thus it's {{BIN.java}} class should have a {{setContent(String)}} method. When running the xsd through xjc from the command line, it does indeed generate a {{BIN.java}} file with a {{setContent(String)}} method.
The definition of BIN is as follows:
{code:title=datatypes-base.xsd}
<xs:complexType name="BIN" abstract="true" mixed="true">
<xs:annotation>
<xs:documentation>
Binary data is a raw block of bits. Binary data is a
protected type that MUST not be used outside the data
type specification.
</xs:documentation>
</xs:annotation>
<xs:complexContent mixed="true">
<xs:extension base="ANY">
<xs:attribute name="representation" type="BinaryDataEncoding" use="optional" default="TXT">
<xs:annotation>
<xs:documentation>
Specifies the representation of the binary data that
is the content of the binary data value.
</xs:documentation>
</xs:annotation>
</xs:attribute>
</xs:extension>
</xs:complexContent>
</xs:complexType>
{code}
I ran this command after running {{mvn clean package}} from the base directory of the test project:
{{diff xjc-output/org/hl7/v3/BIN.java target/generated/src/main/java/org/hl7/v3/BIN.java > xcj-vs-plugin.diff}}
And the diff output is (note "<" are from the xjc file, ">" is from the cxf-common-xsd generated ones):
{code}
2c2
< // This file was generated by the JavaTM Architecture for XML Binding(JAXB) Reference Implementation, vJAXB 2.1.3 in JDK 1.6
---
> // This file was generated by the JavaTM Architecture for XML Binding(JAXB) Reference Implementation, vhudson-jaxb-ri-2.1-833
5c5
< // Generated on: 2010.01.11 at 08:29:22 PM CST
---
> // Generated on: 2010.01.11 at 08:42:50 PM CST
16d15
< import javax.xml.bind.annotation.XmlValue;
43,45c42
< @XmlType(name = "BIN", namespace = "urn:hl7-org:v3", propOrder = {
< "content"
< })
---
> @XmlType(name = "BIN")
49c46,48
< public abstract class BIN {
---
> public abstract class BIN
> extends ANY
> {
51,52d49
< @XmlValue
< protected String content;
57,88d53
< *
< * Binary data is a raw block of bits. Binary data is a
< * protected type that MUST not be used outside the data
< * type specification.
< *
< *
< * @return
< * possible object is
< * {@link String }
< *
< */
< public String getContent() {
< return content;
< }
<
< /**
< *
< * Binary data is a raw block of bits. Binary data is a
< * protected type that MUST not be used outside the data
< * type specification.
< *
< *
< * @param value
< * allowed object is
< * {@link String }
< *
< */
< public void setContent(String value) {
< this.content = value;
< }
<
< /**
{code}
First thing I noticed is that cxf-common-xsd is using {{vhudson-jaxb-ri-2.1-833}} as it's jaxb-ri, which is different than my JDK. Secondly, I noticed that cxf-common-xsd also correctly extends the ANY type, where my jdk's xjc didn't, but then forgets to respect the {{mixed="true"}} attribute.
I'm almost assuming in this instance both implementations are right and wrong, one should be extending ANY, the other should be including setContent(String)!
Is there any type of work around?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CXF-2614) cxf-common-xsd plugin generated files
differ from xjc generated ones
Posted by "Craig Tataryn (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-2614?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12799268#action_12799268 ]
Craig Tataryn commented on CXF-2614:
------------------------------------
Thanks Dan, I'll log a bug with them. I tool thought of doing an XJC plugin, I guess I could custom tailor it for the specific class I'm dealing with to get by.
Otherwise, maybe I should just drop back to version 2.1.3? The one thing I'll loose though is the class not extending it's base type, which I can live with for now I think.
Again, thanks for your comments and investigation.
> cxf-common-xsd plugin generated files differ from xjc generated ones
> --------------------------------------------------------------------
>
> Key: CXF-2614
> URL: https://issues.apache.org/jira/browse/CXF-2614
> Project: CXF
> Issue Type: Bug
> Components: Tooling
> Affects Versions: 2.2.5
> Environment: $ mvn --version
> Apache Maven 2.2.1 (r801777; 2009-08-06 14:16:01-0500)
> Java version: 1.6.0
> Java home: D:\Program Files\IBM\RAD75\jdk\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows xp" version: "5.1 build 2600 service pack 3" arch: "x86" Family: "windows"
> Reporter: Craig Tataryn
> Attachments: xsdtest.zip
>
>
> Noticed a problem where *cxf-common-xsd* was spitting out {{.java}} files that didn't have a {{setContent(String)}} method when their corresponding {{<xsd:element>}} types had a {{mixed="true"}} attribute.
> I setup a test (which will be attached), ran both xjc from the command line (see {{xjc-output}} directory in the attached test project) as well as setting up a pom file to run cxf-common-xsd against the same set of schemas.
> There is a type in {{datatypes-base.xsd}} called {{BIN}} which extends a base type called {{ANY}}. {{BIN}} has been marked with {{mixed="true"}} and thus it's {{BIN.java}} class should have a {{setContent(String)}} method. When running the xsd through xjc from the command line, it does indeed generate a {{BIN.java}} file with a {{setContent(String)}} method.
> The definition of BIN is as follows:
> {code:title=datatypes-base.xsd}
> <xs:complexType name="BIN" abstract="true" mixed="true">
> <xs:annotation>
> <xs:documentation>
> Binary data is a raw block of bits. Binary data is a
> protected type that MUST not be used outside the data
> type specification.
> </xs:documentation>
> </xs:annotation>
> <xs:complexContent mixed="true">
> <xs:extension base="ANY">
> <xs:attribute name="representation" type="BinaryDataEncoding" use="optional" default="TXT">
> <xs:annotation>
> <xs:documentation>
> Specifies the representation of the binary data that
> is the content of the binary data value.
> </xs:documentation>
> </xs:annotation>
> </xs:attribute>
> </xs:extension>
> </xs:complexContent>
> </xs:complexType>
> {code}
> I ran this command after running {{mvn clean package}} from the base directory of the test project:
> {{diff xjc-output/org/hl7/v3/BIN.java target/generated/src/main/java/org/hl7/v3/BIN.java > xcj-vs-plugin.diff}}
> And the diff output is (note "<" are from the xjc file, ">" is from the cxf-common-xsd generated ones):
> {code}
> 2c2
> < // This file was generated by the JavaTM Architecture for XML Binding(JAXB) Reference Implementation, vJAXB 2.1.3 in JDK 1.6
> ---
> > // This file was generated by the JavaTM Architecture for XML Binding(JAXB) Reference Implementation, vhudson-jaxb-ri-2.1-833
> 5c5
> < // Generated on: 2010.01.11 at 08:29:22 PM CST
> ---
> > // Generated on: 2010.01.11 at 08:42:50 PM CST
> 16d15
> < import javax.xml.bind.annotation.XmlValue;
> 43,45c42
> < @XmlType(name = "BIN", namespace = "urn:hl7-org:v3", propOrder = {
> < "content"
> < })
> ---
> > @XmlType(name = "BIN")
> 49c46,48
> < public abstract class BIN {
> ---
> > public abstract class BIN
> > extends ANY
> > {
> 51,52d49
> < @XmlValue
> < protected String content;
> 57,88d53
> < *
> < * Binary data is a raw block of bits. Binary data is a
> < * protected type that MUST not be used outside the data
> < * type specification.
> < *
> < *
> < * @return
> < * possible object is
> < * {@link String }
> < *
> < */
> < public String getContent() {
> < return content;
> < }
> <
> < /**
> < *
> < * Binary data is a raw block of bits. Binary data is a
> < * protected type that MUST not be used outside the data
> < * type specification.
> < *
> < *
> < * @param value
> < * allowed object is
> < * {@link String }
> < *
> < */
> < public void setContent(String value) {
> < this.content = value;
> < }
> <
> < /**
> {code}
> First thing I noticed is that cxf-common-xsd is using {{vhudson-jaxb-ri-2.1-833}} as it's jaxb-ri, which is different than my JDK. Secondly, I noticed that cxf-common-xsd also correctly extends the ANY type, where my jdk's xjc didn't, but then forgets to respect the {{mixed="true"}} attribute.
> I'm almost assuming in this instance both implementations are right and wrong, one should be extending ANY, the other should be including setContent(String)!
> Is there any type of work around?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (CXF-2614) cxf-common-xsd plugin generated files
differ from xjc generated ones
Posted by "Daniel Kulp (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-2614?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Daniel Kulp resolved CXF-2614.
------------------------------
Resolution: Not A Problem
Fix Version/s: Invalid
I'm going to mark this resolved as the generated files are the same as that generated by XJC if you use a recent version of Java 6. This really is due to them changing the version of JAXB in Java 6 from 2.1.3 to something newer and the newer version generates different code. Whether the generated code is correct or incorrect is definitely an issue for them, but this bug report is mostly about it being different, which it's not. :-)
> cxf-common-xsd plugin generated files differ from xjc generated ones
> --------------------------------------------------------------------
>
> Key: CXF-2614
> URL: https://issues.apache.org/jira/browse/CXF-2614
> Project: CXF
> Issue Type: Bug
> Components: Tooling
> Affects Versions: 2.2.5
> Environment: $ mvn --version
> Apache Maven 2.2.1 (r801777; 2009-08-06 14:16:01-0500)
> Java version: 1.6.0
> Java home: D:\Program Files\IBM\RAD75\jdk\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows xp" version: "5.1 build 2600 service pack 3" arch: "x86" Family: "windows"
> Reporter: Craig Tataryn
> Fix For: Invalid
>
> Attachments: xsdtest.zip
>
>
> Noticed a problem where *cxf-common-xsd* was spitting out {{.java}} files that didn't have a {{setContent(String)}} method when their corresponding {{<xsd:element>}} types had a {{mixed="true"}} attribute.
> I setup a test (which will be attached), ran both xjc from the command line (see {{xjc-output}} directory in the attached test project) as well as setting up a pom file to run cxf-common-xsd against the same set of schemas.
> There is a type in {{datatypes-base.xsd}} called {{BIN}} which extends a base type called {{ANY}}. {{BIN}} has been marked with {{mixed="true"}} and thus it's {{BIN.java}} class should have a {{setContent(String)}} method. When running the xsd through xjc from the command line, it does indeed generate a {{BIN.java}} file with a {{setContent(String)}} method.
> The definition of BIN is as follows:
> {code:title=datatypes-base.xsd}
> <xs:complexType name="BIN" abstract="true" mixed="true">
> <xs:annotation>
> <xs:documentation>
> Binary data is a raw block of bits. Binary data is a
> protected type that MUST not be used outside the data
> type specification.
> </xs:documentation>
> </xs:annotation>
> <xs:complexContent mixed="true">
> <xs:extension base="ANY">
> <xs:attribute name="representation" type="BinaryDataEncoding" use="optional" default="TXT">
> <xs:annotation>
> <xs:documentation>
> Specifies the representation of the binary data that
> is the content of the binary data value.
> </xs:documentation>
> </xs:annotation>
> </xs:attribute>
> </xs:extension>
> </xs:complexContent>
> </xs:complexType>
> {code}
> I ran this command after running {{mvn clean package}} from the base directory of the test project:
> {{diff xjc-output/org/hl7/v3/BIN.java target/generated/src/main/java/org/hl7/v3/BIN.java > xcj-vs-plugin.diff}}
> And the diff output is (note "<" are from the xjc file, ">" is from the cxf-common-xsd generated ones):
> {code}
> 2c2
> < // This file was generated by the JavaTM Architecture for XML Binding(JAXB) Reference Implementation, vJAXB 2.1.3 in JDK 1.6
> ---
> > // This file was generated by the JavaTM Architecture for XML Binding(JAXB) Reference Implementation, vhudson-jaxb-ri-2.1-833
> 5c5
> < // Generated on: 2010.01.11 at 08:29:22 PM CST
> ---
> > // Generated on: 2010.01.11 at 08:42:50 PM CST
> 16d15
> < import javax.xml.bind.annotation.XmlValue;
> 43,45c42
> < @XmlType(name = "BIN", namespace = "urn:hl7-org:v3", propOrder = {
> < "content"
> < })
> ---
> > @XmlType(name = "BIN")
> 49c46,48
> < public abstract class BIN {
> ---
> > public abstract class BIN
> > extends ANY
> > {
> 51,52d49
> < @XmlValue
> < protected String content;
> 57,88d53
> < *
> < * Binary data is a raw block of bits. Binary data is a
> < * protected type that MUST not be used outside the data
> < * type specification.
> < *
> < *
> < * @return
> < * possible object is
> < * {@link String }
> < *
> < */
> < public String getContent() {
> < return content;
> < }
> <
> < /**
> < *
> < * Binary data is a raw block of bits. Binary data is a
> < * protected type that MUST not be used outside the data
> < * type specification.
> < *
> < *
> < * @param value
> < * allowed object is
> < * {@link String }
> < *
> < */
> < public void setContent(String value) {
> < this.content = value;
> < }
> <
> < /**
> {code}
> First thing I noticed is that cxf-common-xsd is using {{vhudson-jaxb-ri-2.1-833}} as it's jaxb-ri, which is different than my JDK. Secondly, I noticed that cxf-common-xsd also correctly extends the ANY type, where my jdk's xjc didn't, but then forgets to respect the {{mixed="true"}} attribute.
> I'm almost assuming in this instance both implementations are right and wrong, one should be extending ANY, the other should be including setContent(String)!
> Is there any type of work around?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (CXF-2614) cxf-common-xsd plugin generated files
differ from xjc generated ones
Posted by "Craig Tataryn (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-2614?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Craig Tataryn updated CXF-2614:
-------------------------------
Attachment: xsdtest.zip
> cxf-common-xsd plugin generated files differ from xjc generated ones
> --------------------------------------------------------------------
>
> Key: CXF-2614
> URL: https://issues.apache.org/jira/browse/CXF-2614
> Project: CXF
> Issue Type: Bug
> Components: Tooling
> Affects Versions: 2.2.5
> Environment: $ mvn --version
> Apache Maven 2.2.1 (r801777; 2009-08-06 14:16:01-0500)
> Java version: 1.6.0
> Java home: D:\Program Files\IBM\RAD75\jdk\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows xp" version: "5.1 build 2600 service pack 3" arch: "x86" Family: "windows"
> Reporter: Craig Tataryn
> Attachments: xsdtest.zip
>
>
> Noticed a problem where *cxf-common-xsd* was spitting out {{.java}} files that didn't have a {{setContent(String)}} method when their corresponding {{<xsd:element>}} types had a {{mixed="true"}} attribute.
> I setup a test (which will be attached), ran both xjc from the command line (see {{xjc-output}} directory in the attached test project) as well as setting up a pom file to run cxf-common-xsd against the same set of schemas.
> There is a type in {{datatypes-base.xsd}} called {{BIN}} which extends a base type called {{ANY}}. {{BIN}} has been marked with {{mixed="true"}} and thus it's {{BIN.java}} class should have a {{setContent(String)}} method. When running the xsd through xjc from the command line, it does indeed generate a {{BIN.java}} file with a {{setContent(String)}} method.
> The definition of BIN is as follows:
> {code:title=datatypes-base.xsd}
> <xs:complexType name="BIN" abstract="true" mixed="true">
> <xs:annotation>
> <xs:documentation>
> Binary data is a raw block of bits. Binary data is a
> protected type that MUST not be used outside the data
> type specification.
> </xs:documentation>
> </xs:annotation>
> <xs:complexContent mixed="true">
> <xs:extension base="ANY">
> <xs:attribute name="representation" type="BinaryDataEncoding" use="optional" default="TXT">
> <xs:annotation>
> <xs:documentation>
> Specifies the representation of the binary data that
> is the content of the binary data value.
> </xs:documentation>
> </xs:annotation>
> </xs:attribute>
> </xs:extension>
> </xs:complexContent>
> </xs:complexType>
> {code}
> I ran this command after running {{mvn clean package}} from the base directory of the test project:
> {{diff xjc-output/org/hl7/v3/BIN.java target/generated/src/main/java/org/hl7/v3/BIN.java > xcj-vs-plugin.diff}}
> And the diff output is (note "<" are from the xjc file, ">" is from the cxf-common-xsd generated ones):
> {code}
> 2c2
> < // This file was generated by the JavaTM Architecture for XML Binding(JAXB) Reference Implementation, vJAXB 2.1.3 in JDK 1.6
> ---
> > // This file was generated by the JavaTM Architecture for XML Binding(JAXB) Reference Implementation, vhudson-jaxb-ri-2.1-833
> 5c5
> < // Generated on: 2010.01.11 at 08:29:22 PM CST
> ---
> > // Generated on: 2010.01.11 at 08:42:50 PM CST
> 16d15
> < import javax.xml.bind.annotation.XmlValue;
> 43,45c42
> < @XmlType(name = "BIN", namespace = "urn:hl7-org:v3", propOrder = {
> < "content"
> < })
> ---
> > @XmlType(name = "BIN")
> 49c46,48
> < public abstract class BIN {
> ---
> > public abstract class BIN
> > extends ANY
> > {
> 51,52d49
> < @XmlValue
> < protected String content;
> 57,88d53
> < *
> < * Binary data is a raw block of bits. Binary data is a
> < * protected type that MUST not be used outside the data
> < * type specification.
> < *
> < *
> < * @return
> < * possible object is
> < * {@link String }
> < *
> < */
> < public String getContent() {
> < return content;
> < }
> <
> < /**
> < *
> < * Binary data is a raw block of bits. Binary data is a
> < * protected type that MUST not be used outside the data
> < * type specification.
> < *
> < *
> < * @param value
> < * allowed object is
> < * {@link String }
> < *
> < */
> < public void setContent(String value) {
> < this.content = value;
> < }
> <
> < /**
> {code}
> First thing I noticed is that cxf-common-xsd is using {{vhudson-jaxb-ri-2.1-833}} as it's jaxb-ri, which is different than my JDK. Secondly, I noticed that cxf-common-xsd also correctly extends the ANY type, where my jdk's xjc didn't, but then forgets to respect the {{mixed="true"}} attribute.
> I'm almost assuming in this instance both implementations are right and wrong, one should be extending ANY, the other should be including setContent(String)!
> Is there any type of work around?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CXF-2614) cxf-common-xsd plugin generated files
differ from xjc generated ones
Posted by "Daniel Kulp (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-2614?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12799257#action_12799257 ]
Daniel Kulp commented on CXF-2614:
----------------------------------
What version of the JDK are you using? With 1.6.0_17, the version of JAXB included in the JDK is 2.1.10 which generates the same thing that the CXF plugin generates. I also downloaded the full JAXB 2.1.12 package and ran xjc from there and it generates the same as CXF.
I then updated you pom to pull in 2.1.3 by adding:
{code:xml}
<plugin>
<groupId>org.apache.cxf</groupId>
<artifactId>cxf-common-xsd</artifactId>
<version>2.3.0-SNAPSHOT</version>
<executions>
<execution>
<id>generate-sources</id>
<phase>generate-sources</phase>
<configuration>
<sourceRoot>${basedir}/target/generated/src/main/java</sourceRoot>
<xsdOptions>
<xsdOption>
<xsd>${basedir}/src/main/resources/coreschemas/</xsd>
</xsdOption>
</xsdOptions>
</configuration>
<goals>
<goal>xsdtojava</goal>
</goals>
</execution>
</executions>
<dependencies>
<dependency>
<groupId>com.sun.xml.bind</groupId>
<artifactId>jaxb-xjc</artifactId>
<version>2.1.3</version>
</dependency>
<dependency>
<groupId>com.sun.xml.bind</groupId>
<artifactId>jaxb-impl</artifactId>
<version>2.1.3</version>
</dependency>
</dependencies>
</plugin>
{code}
And that generates your original code. If I change to 2.1.4, it generates the same as cxf. Thus, it's something they changed between 2.1.3 and 2.1.4.
In anycase, this is definitely a JAXB XJC bug and a bug would need to be logged there:
https://jaxb.dev.java.net/issues
The only "workaround" I can think of is to write an XJC plugin that would put the mixed stuff back on. Not sure how complicated that would be.
> cxf-common-xsd plugin generated files differ from xjc generated ones
> --------------------------------------------------------------------
>
> Key: CXF-2614
> URL: https://issues.apache.org/jira/browse/CXF-2614
> Project: CXF
> Issue Type: Bug
> Components: Tooling
> Affects Versions: 2.2.5
> Environment: $ mvn --version
> Apache Maven 2.2.1 (r801777; 2009-08-06 14:16:01-0500)
> Java version: 1.6.0
> Java home: D:\Program Files\IBM\RAD75\jdk\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows xp" version: "5.1 build 2600 service pack 3" arch: "x86" Family: "windows"
> Reporter: Craig Tataryn
> Attachments: xsdtest.zip
>
>
> Noticed a problem where *cxf-common-xsd* was spitting out {{.java}} files that didn't have a {{setContent(String)}} method when their corresponding {{<xsd:element>}} types had a {{mixed="true"}} attribute.
> I setup a test (which will be attached), ran both xjc from the command line (see {{xjc-output}} directory in the attached test project) as well as setting up a pom file to run cxf-common-xsd against the same set of schemas.
> There is a type in {{datatypes-base.xsd}} called {{BIN}} which extends a base type called {{ANY}}. {{BIN}} has been marked with {{mixed="true"}} and thus it's {{BIN.java}} class should have a {{setContent(String)}} method. When running the xsd through xjc from the command line, it does indeed generate a {{BIN.java}} file with a {{setContent(String)}} method.
> The definition of BIN is as follows:
> {code:title=datatypes-base.xsd}
> <xs:complexType name="BIN" abstract="true" mixed="true">
> <xs:annotation>
> <xs:documentation>
> Binary data is a raw block of bits. Binary data is a
> protected type that MUST not be used outside the data
> type specification.
> </xs:documentation>
> </xs:annotation>
> <xs:complexContent mixed="true">
> <xs:extension base="ANY">
> <xs:attribute name="representation" type="BinaryDataEncoding" use="optional" default="TXT">
> <xs:annotation>
> <xs:documentation>
> Specifies the representation of the binary data that
> is the content of the binary data value.
> </xs:documentation>
> </xs:annotation>
> </xs:attribute>
> </xs:extension>
> </xs:complexContent>
> </xs:complexType>
> {code}
> I ran this command after running {{mvn clean package}} from the base directory of the test project:
> {{diff xjc-output/org/hl7/v3/BIN.java target/generated/src/main/java/org/hl7/v3/BIN.java > xcj-vs-plugin.diff}}
> And the diff output is (note "<" are from the xjc file, ">" is from the cxf-common-xsd generated ones):
> {code}
> 2c2
> < // This file was generated by the JavaTM Architecture for XML Binding(JAXB) Reference Implementation, vJAXB 2.1.3 in JDK 1.6
> ---
> > // This file was generated by the JavaTM Architecture for XML Binding(JAXB) Reference Implementation, vhudson-jaxb-ri-2.1-833
> 5c5
> < // Generated on: 2010.01.11 at 08:29:22 PM CST
> ---
> > // Generated on: 2010.01.11 at 08:42:50 PM CST
> 16d15
> < import javax.xml.bind.annotation.XmlValue;
> 43,45c42
> < @XmlType(name = "BIN", namespace = "urn:hl7-org:v3", propOrder = {
> < "content"
> < })
> ---
> > @XmlType(name = "BIN")
> 49c46,48
> < public abstract class BIN {
> ---
> > public abstract class BIN
> > extends ANY
> > {
> 51,52d49
> < @XmlValue
> < protected String content;
> 57,88d53
> < *
> < * Binary data is a raw block of bits. Binary data is a
> < * protected type that MUST not be used outside the data
> < * type specification.
> < *
> < *
> < * @return
> < * possible object is
> < * {@link String }
> < *
> < */
> < public String getContent() {
> < return content;
> < }
> <
> < /**
> < *
> < * Binary data is a raw block of bits. Binary data is a
> < * protected type that MUST not be used outside the data
> < * type specification.
> < *
> < *
> < * @param value
> < * allowed object is
> < * {@link String }
> < *
> < */
> < public void setContent(String value) {
> < this.content = value;
> < }
> <
> < /**
> {code}
> First thing I noticed is that cxf-common-xsd is using {{vhudson-jaxb-ri-2.1-833}} as it's jaxb-ri, which is different than my JDK. Secondly, I noticed that cxf-common-xsd also correctly extends the ANY type, where my jdk's xjc didn't, but then forgets to respect the {{mixed="true"}} attribute.
> I'm almost assuming in this instance both implementations are right and wrong, one should be extending ANY, the other should be including setContent(String)!
> Is there any type of work around?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.