You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@cxf.apache.org by "Daniel Kulp (JIRA)" <ji...@apache.org> on 2010/01/12 17:31:54 UTC
[jira] Commented: (CXF-2614) cxf-common-xsd plugin generated files
differ from xjc generated ones
[ 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.