Hide Forgot
project_key: SOA The juddi WSDL fails parsing under CXF because of the definition of the input message for the get_changeRecords within the esb_replication_service.wsdl. The message is defined as follows (within uddi_v3replication.xsd) <element name="get_changeRecords"> <complexType> <sequence> <element name="requestingNode" type="uddi_repl:operatorNodeID_type"/> <element name="changesAlreadySeen" type="uddi_repl:highWaterMarkVector_type" minOccurs="0"/> <choice minOccurs="0"> <element name="responseLimitCount" type="integer"/> <element name="responseLimitVector" type="uddi_repl:highWaterMarkVector_type"/> </choice> </sequence> </complexType> </element> This leads to the following exception, triggered by accessing the wsdl. java.lang.NullPointerException at org.apache.cxf.service.factory.ReflectionServiceFactoryBean.initializeClassInfo(ReflectionServiceFactoryBean.java:754) at org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.initializeWSDLOperation(JaxWsServiceFactoryBean.java:222) at org.apache.cxf.service.factory.ReflectionServiceFactoryBean.initializeWSDLOperations(ReflectionServiceFactoryBean.java:674) at org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.initializeWSDLOperations(JaxWsServiceFactoryBean.java:258) at org.apache.cxf.service.factory.ReflectionServiceFactoryBean.buildServiceFromWSDL(ReflectionServiceFactoryBean.java:424) at org.apache.cxf.service.factory.ReflectionServiceFactoryBean.initializeServiceModel(ReflectionServiceFactoryBean.java:528) at org.apache.cxf.service.factory.ReflectionServiceFactoryBean.create(ReflectionServiceFactoryBean.java:278) at org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.create(JaxWsServiceFactoryBean.java:178) at org.apache.cxf.frontend.AbstractWSDLBasedEndpointFactory.createEndpoint(AbstractWSDLBasedEndpointFactory.java:100) at org.apache.cxf.frontend.ServerFactoryBean.create(ServerFactoryBean.java:105) at org.apache.cxf.jaxws.JaxWsServerFactoryBean.create(JaxWsServerFactoryBean.java:167) at org.apache.cxf.jaxws.EndpointImpl.getServer(EndpointImpl.java:346) at org.apache.cxf.jaxws.EndpointImpl.doPublish(EndpointImpl.java:259) at org.apache.cxf.jaxws.EndpointImpl.publish(EndpointImpl.java:209) at org.apache.cxf.jaxws.EndpointImpl.publish(EndpointImpl.java:404) The CXF code expects the operation to be wrapped however its verification does not agree. The deployment executes the following within initializeClassInfo if (o.getUnwrappedOperation() == null) { //the "normal" algorithm didn't allow for unwrapping, //but the annotations say unwrap this. We'll need to //make it. WSDLServiceBuilder.checkForWrapped(o, true); } However the invocation of WSDLServiceBuilder.checkForWrapped does not populate the unwrapped operation, leading to the NPE when it is later referenced. WSDLServiceBuilder.checkForWrapped fails to populate the operation information because the isWrappableSequence method expects everything within the type to be an element, and it does not support the 'choice' element. Changing the element definition to the following allows it to parse successfully, however it is not equivalent. <element name="get_changeRecords"> <complexType> <sequence> <element name="requestingNode" type="uddi_repl:operatorNodeID_type"/> <element name="changesAlreadySeen" type="uddi_repl:highWaterMarkVector_type" minOccurs="0"/> <element name="responseLimitCount" type="integer" minOccurs="0"/> <element name="responseLimitVector" type="uddi_repl:highWaterMarkVector_type" minOccurs="0"/> </sequence> </complexType> </element>
War files containing original schema and modified schema.
Attachment: Added: juddiv3.war.orig Attachment: Added: juddiv3.war.new
The WSDL associated with this service can be accessed via the following URL, http://127.0.0.1:8080/juddiv3/services/replication?wsdl, triggering the exception, however accessing any wsdl within the juddiv3 deployment will currently cause this issue due to a second CXF integration bug.
From section 2.3.1.2 of the JAX-WS specification the wrapper style restrictions are defined as: - 2.3.1.2 Wrapper Style A WSDL operation qualifies for wrapper style mapping only if the following criteria are met: (i) The operation’s input and output messages (if present) each contain only a single part (ii) The input message part refers to a global element declaration whose localname is equal to the opera- tion name (iii) The output message (if present) part refers to a global element declaration (iv) The elements referred to by the input and output message (if present) parts (henceforth referred to as wrapper elements) are both complex types defined using the xsd:sequence compositor May 7, 2007 JAX-WS 2.1 13 Chapter 2. WSDL 1.1 to Java Mapping (v) The wrapper elements only contain child elements, they MUST not contain other structures such as wildcards (element or attribute), xsd:choice, substitution groups (element references are not permitted) or attributes; furthermore, they MUST not be nillable. It is v above being violated and the endpoint should not be wrapped so this is a tooling issue in the generated endpoint.
In that case I would be tempted to reject this issue as this is jUDDI WSDL and not, to the best of my knowledge, generated by any tool. I can modify my local version of the jUDDI WSDL in the meantime.
This is a jUDDI bug, we will override the schema within the ESB build.
Link: Added: This issue depends JBESB-3512
Link: Removed: This issue depends JBESB-3512
Link: Added: This issue Cloned to SOA-3014