Community
Participate
Working Groups
Steps to reproduce: within the wsdl design page add a fault to a process by right clicking on the process. Save the wsdl. If you look at the source you will see this fault has been added. Now go back to the design page and delete the fault, save the wsdl. If you look at the source you will see the fault is part of the wsdl. <?xml version="1.0"?> <definitions name="HelloWorld" targetNamespace="http://sample.bpel.org/bpel/sample" xmlns:tns="http://sample.bpel.org/bpel/sample" xmlns:plnk="http://docs.oasis-open.org/wsbpel/2.0/plnktype" xmlns="http://schemas.xmlsoap.org/wsdl/" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:p="http://www.w3.org/2001/XMLSchema"> <!-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ TYPE DEFINITION - List of types participating in this BPEL process The BPEL Designer will generate default request and response types but you can define or import any XML Schema type and use them as part of the message types. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ --> <types> <schema attributeFormDefault="unqualified" elementFormDefault="qualified" targetNamespace="http://sample.bpel.org/bpel/sample" xmlns="http://www.w3.org/2001/XMLSchema"> <element name="HelloWorldRequest"> <complexType> <sequence> <element name="input" type="string"/> </sequence> </complexType> </element> <element name="HelloWorldResponse"> <complexType> <sequence> <element name="result" type="string"/> </sequence> </complexType> </element> <element name="process_fault"> <complexType> <sequence> <element name="process_fault" type="string"></element> </sequence> </complexType> </element> </schema> </types> <!-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ MESSAGE TYPE DEFINITION - Definition of the message types used as part of the port type defintions ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ --> <message name="HelloWorldRequestMessage"> <part name="payload" element="tns:HelloWorldRequest"/> </message> <message name="HelloWorldResponseMessage"> <part name="payload" element="tns:HelloWorldResponse"/> </message> <!-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ PORT TYPE DEFINITION - A port type groups a set of operations into a logical service unit. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ --> <!-- portType implemented by the HelloWorld BPEL process --> <message name="process_faultMsg"> <part name="parameters" element="tns:process_fault"></part> </message> <portType name="HelloWorld"> <operation name="process"> <input message="tns:HelloWorldRequestMessage" /> <output message="tns:HelloWorldResponseMessage"/> </operation> </portType> <!-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ PARTNER LINK TYPE DEFINITION ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ --> <plnk:partnerLinkType name="HelloWorld"> <plnk:role name="HelloWorldProvider" portType="tns:HelloWorld"/> </plnk:partnerLinkType> <binding name="NewBinding" type="tns:HelloWorld"> <soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http" /> <operation name="process"> <soap:operation soapAction="http://sample.bpel.org/bpel/sample/process" /> <input> <soap:body use="literal" /> </input> <output> <soap:body use="literal" /> </output> </operation> </binding> <service name="NewService"> <port name="NewPort" binding="tns:NewBinding"> <soap:address location="http://www.example.org/"></soap:address> </port> </service> </definitions> It appears that when the fault is deleted, it is only removed from the operation definitions from within porttype. If you add a fault back - the name gets incremented and you end up with multiple definitions within the schema and messages: <element name="process_fault"> <complexType> <sequence> <element name="process_fault" type="string"></element> </sequence> </complexType> </element> <element name="process_fault1"> <complexType> <sequence> <element name="process_fault" type="string"></element> </sequence> </complexType> </element> </schema> </types> <!-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ MESSAGE TYPE DEFINITION - Definition of the message types used as part of the port type defintions ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ --> <message name="HelloWorldRequestMessage"> <part name="payload" element="tns:HelloWorldRequest"/> </message> <message name="HelloWorldResponseMessage"> <part name="payload" element="tns:HelloWorldResponse"/> </message> <!-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ PORT TYPE DEFINITION - A port type groups a set of operations into a logical service unit. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ --> <!-- portType implemented by the HelloWorld BPEL process --> <message name="process_faultMsg"> <part name="parameters" element="tns:process_fault"></part> </message> <message name="process_faultMsg1"> <part name="parameters" element="tns:process_fault1"></part> </message> <portType name="HelloWorld"> <operation name="process"> <input message="tns:HelloWorldRequestMessage" /> <output message="tns:HelloWorldResponseMessage"/> <fault name="fault" message="tns:process_faultMsg1"></fault> </operation> </portType>
Gabriel, I think I've seen similar bugs before. Can you please check if there's already one open? If so mark as duplicate. If not necessarily a dup, at least cross reference so we know all the similar ones.
I believe we have a few RFEs open to clean-up components that appear unused after deleting a reference (just like in this case the fault message and element appear unused). However, due to the possibility that a component (message) is referenced from multiple places, and perhaps even used in other WSDLs through imports, this is not a simple task. Deleting a top level component could result in other WSDLs being broken, and perhaps the safest path is not to delete. Given that nothing is really broken here, I'll mark this as an enhancement request and welcome any contributions.
