Hi,
the JAXB spec does not mandate the way to process these cases. I think
best would be if you file a spec issue so that we are able to clarify
this in future releases of the spec,
MartiNG
On 11/29/2011 01:44 PM, jviswana wrote:
> Hi ,
>
> Any update on this ?
>
> On 24/11/2011 16:48, jviswana wrote:
>> Hi ,
>>
>> We also see the generally the override is not working in many other
>> cases as well . In a JAXWS test scenario as well we seem to create 2
>> Operation under request .
>>
>> <definitions targetNamespace="http://test/" name="TestWsgenService"
>> xmlns="http://schemas.xmlsoap.org/wsdl/"
>> xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:tns="http://test/"
>> xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/">
>> <types>
>> <xsd:schema>
>> <xsd:import namespace="http://test/"
>> schemaLocation="TestWsgenService_schema1.xsd"/>
>> </xsd:schema>
>> </types>
>> <message name="*returnClassA*">
>> <part name="parameters" element="tns:returnClassA"/>
>> </message>
>> <message name="returnClassAResponse">
>> <part name="parameters" element="tns:returnClassAResponse"/>
>> </message>
>> <message name="*returnClassA*">
>> <part name="parameters" element="tns:returnClassA"/>
>> </message>
>> <message name="returnClassAResponse">
>> <part name="parameters" element="tns:returnClassAResponse"/>
>> </message>
>>
>> I believe there is an inherent problem in implementation of
>> Overriding consider all the 3 issues in both JAXB and JAXWS .
>>
>>
>> On 23/11/2011 18:26, jviswana wrote:
>>> Hello,
>>>
>>> JAXB is not getting bound to getter/setter property of a Java bean
>>> if it is Overridden at method level . This is being observed under
>>> the following scenarios:Override behavioral conflict
>>>
>>> _*Scenario 1:*_
>>>
>>> -> The variable "name" in base class is getting bound twice and
>>> breaking the XML schema's "Unique Particle Attribution
>>> constraint(2) , throwing the following exception while executing xjc.
>>>
>>> [ERROR] cos-nonambig: name and name (or elements from their
>>> substitution group) violate "Unique Particle Attribution". During
>>> validation against this
>>> schema, ambiguity would be created for those two particles.
>>> line 6 of file:/E:/OpenJDK/PMR/mytrial/schema1.xsd ]
>>>
>>> Here's the snapshot of the schema being used:
>>> _*snapshot of schema*_
>>> <xs:complexType name="*usAddress*">
>>> <xs:complexContent>
>>> <xs:extension base="address">
>>> <xs:sequence>
>>> <xs:element name="*name*" type="xs:string" minOccurs="0"/>
>>> <xs:element name="state" type="usState" minOccurs="0"/>
>>> <xs:element name="zip" type="xs:integer" minOccurs="0"/>
>>>
>>> <xs:complexType name="*address*">
>>> <xs:complexContent>
>>> <xs:extension base="exception">
>>> <xs:sequence>
>>> <xs:element name="*name*" type="xs:string" minOccurs="0"/>
>>> <xs:element name="city" type="xs:string" minOccurs="0"/>
>>> <xs:element name="street" type="xs:string" minOccurs="0"/>
>>>
>>>
>>> _*Scenario 2*_
>>> I see that we are missing Variable "message" derived from
>>> "Throwable" class . It doesn't appear in the derived class until
>>> unless the varaible is declared public or annotated, for eg: with
>>> @XmlElement 1. I suspect the reason for this being neither the base
>>> class[Throwable] nor the derived class[Address] have the "message"
>>> variable making us to loose the value and break functionality of
>>> application .
>>> Please see "message" string in Address.java
>>>
>>> _snapshot of Beans_
>>> protected String city;
>>> //change this to public to see message in address of schema
>>> //derived from thorwable
>>> //_at_XmlElement
>>> protected String message;
>>>
>>> See that schema is *missing "message *"
>>>
>>> _snapshot of schema_
>>>
>>> <xs:complexType name="*address*">
>>> <xs:complexContent>
>>> <xs:extension base="exception">
>>> <xs:sequence>
>>> <xs:element name="name" type="xs:string" minOccurs="0"/>
>>> <xs:element name="city" type="xs:string" minOccurs="0"/>
>>> <xs:element name="street" type="xs:string" minOccurs="0"/>
>>> </xs:sequence>
>>> </xs:extension>
>>> </xs:complexContent>
>>> </xs:complexType>
>>>
>>> Which is there if we use *public access/ @XmlElement* this message
>>> will appear
>>>
>>> <xs:complexType name="*address*">
>>> <xs:complexContent>
>>> <xs:extension base="exception">
>>> <xs:sequence>
>>> <xs:element name="*message*" type="xs:string" minOccurs="0"/>
>>> <xs:element name="city" type="xs:string" minOccurs="0"/>
>>> <xs:element name="name" type="xs:string" minOccurs="0"/>
>>> <xs:element name="street" type="xs:string" minOccurs="0"/>
>>> </xs:sequence>
>>> </xs:extension>
>>> </xs:complexContent>
>>> </xs:complexType>
>>>
>>> The exception stack is not having message,
>>>
>>> <xs:complexType name="*exception*">
>>> <xs:complexContent>
>>> <xs:extension base="throwable">
>>> <xs:sequence/>
>>> </xs:extension>
>>> </xs:complexContent>
>>> </xs:complexType>
>>>
>>> <xs:complexType name="throwable">
>>> <xs:sequence>
>>> <xs:element name="stackTrace" type="stackTraceElement"
>>> nillable="true" minOccurs="0" maxOccurs="unbounded"/>
>>> </xs:sequence>
>>> </xs:complexType>
>>>
>>> <xs:complexType name="stackTraceElement" final="extension
>>> restriction">
>>> <xs:sequence/>
>>> </xs:complexType>
>>>
>>>
>>> I see that , the getter/setter is not getting bound considering
>>> method override
>>> Case 1: misses to see if base class has getter/setter binding
>>> already
>>> Case 2: misses to see getter/setter base-derived relation
>>> totally . Please note that the base class has only getter and
>>> derived class has both getter/setter .
>>>
>>> Isn't it a bug ?
>>>
>>> _*Reference *_:
>>> 1)Javadoc
>>> I see that we have JAVA API doc as part of
>>> XmlAccessType.html#PUBLIC_MEMBER
>>>
>>> "Every public getter/setter pair and every public field will be
>>> automatically bound to XML, unless annotated by XmlTransient. Fields
>>> or getter/setter pairs that are private, protected, or defaulted to
>>> package-only access are bound to XML only when they are explicitly
>>> annotated by the appropriate JAXB annotations. "
>>>
>>> and
>>>
>>> 2) we also have a spec for Unique Particle Attribution constraint
>>> http://www.w3.org/TR/xmlschema-1/#non-ambig
>>> for a schema generation
>>>
>>> Regards,
>>> Jayashree V
>>>
>>
>
--
Martin Grebac, GlassFish/Metro/JAXWS/JAXB/Tooling at Oracle
http://blogs.oracle.com/mgrebac
ICQ: 93478885