Can you try generating the code with the -noAddressBinding flag? That should map the EndpointReferenceType to our internal type instead of the JAX-WS type. That may allow it properly be extended. You are into some proprietary types/API's, but that may not a be a big deal. :-)
Dan On Thu January 7 2010 7:01:03 am Alasdair J G Gray wrote: > Hi, > > I am trying to develop a Web service that implements the WS-DAI Core > Standard [1] and have encountered a problem due to the WS-DAI Core XML > Schema defining a type that extends the WS-Addressing > EndpointReferenceType. > > The WSDL for my service, which extends the WS-DAI Core WSDL, validates > correctly and I can generate stubs using the CXF wsdl2java tool. However, > the generated stubs will not compile. I get the following error: > service-impl/eu/semsorgrid4env/service/wsdai/DataResourceAddressType.java: > 34: cannot inherit from final > javax.xml.ws.wsaddressing.W3CEndpointReference extends > W3CEndpointReference > The javax.xml.ws.wsaddressing.W3CEndpointReference implementation used > comes from the geronimo-jaxws_2.1_spec-1.0.jar shipped with CXF (I'm using > version 2.2.5). > > From what I understand, this stems from the WS-DAI XML Schema declaration > <xsd:complexType name="DataResourceAddressType"> > <xsd:complexContent> > <xsd:extension base="wsa:EndpointReferenceType"/> > </xsd:complexContent> > </xsd:complexType> > > Can anyone suggest some solutions/ work arounds to my problem? > > I have tried replacing the <xsd:extension... declaration, but cannot find a > suitable xml schema expression to say that DataResourceAddressType should > be an EndpointReferenceType. > > Thanks, > > Alasdair > > [1] http://www.ogf.org/documents/GFD.74.pdf > > Dr Alasdair J G Gray > Research Associate > [email protected] > > Room 2.126 > School of Computer Science > Kilburn Building > University of Manchester > Oxford Road > Manchester > M13 9PL, UK > > tel: (+44) 0161 275 6132 > fax: (+44) 0161 275 6204 > > Please consider the environment before printing this email. > -- Daniel Kulp [email protected] http://www.dankulp.com/blog
