[ 
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.

Reply via email to