Petals Distribution

I agree with you, with the following adds:

• a business error is a JBI fault,
• a technical error is a JBI error,
• a JBI fault is not a SOAP fault, so a dedicated JIRA issue should be created to change the JBI fault format (from SOAPFault to simple XML payload compliant with the WSDL)
• a chapter should be added into the Petals documentation about the error management and explain the error vs faults,
• each MEP should be documented, in a business view, into Petals documentation to defined explicitly where a business fault can occur, and where a technical error can occur in MEP. For example, no business error could be occur with MEP InOnly,
• each component should be review to manage correctly error/fault, mainly binding-components against their external side, so one JIRA issue by component should be added if needed

a business error is a JBI fault,

And a business error is a fault declared in a wsdl.

a technical error is a JBI error,

a JBI fault is not a SOAP fault, so a dedicated JIRA issue should be created to change the JBI fault format (from SOAPFault to simple XML payload compliant with the WSDL)

A JBI Fault is a SOAPFault, in SOAP, see http://docs.oracle.com/cd/E24329_01/web.1211/e24965/faults.htm
A ticket is already open for the CDK PETALSCDK-130 (and for the BC SOAP so that SOAPFault are created as needed: PETALSBCSOAP-145).

a chapter should be added into the Petals documentation about the error management and explain the error vs faults,

each MEP should be documented, in a business view, into Petals documentation to defined explicitly where a business fault can occur, and where a technical error can occur in MEP. For example, no business error could be occur with MEP InOnly,

That seems obvious to me, isn't that already defined in all the norms, standard and recommendation of the W3C on the meaning of the different patterns?
Faults can happen when Faults appear in the definition in the pattern…

each component should be review to manage correctly error/fault, mainly binding-components against their external side, so one JIRA issue by component should be added if needed

a business error is a JBI fault,

And a business error is a fault declared in a wsdl.

Yes

a technical error is a JBI error,

a JBI fault is not a SOAP fault, so a dedicated JIRA issue should be created to change the JBI fault format (from SOAPFault to simple XML payload compliant with the WSDL)

A JBI Fault is a SOAPFault, in SOAP, see http://docs.oracle.com/cd/E24329_01/web.1211/e24965/faults.htm

No, a JBI fault is transformed in a SOAPFault by the consumer side of the Petals BC SOAP, and a SOAPFault is transformed in a JBI fault by the provider side of the Petals BC SOAP.

A ticket is already open for the CDK PETALSCDK-130 (and for the BC SOAP so that SOAPFault are created as needed: PETALSBCSOAP-145).

The main goal of PETALSCDK-130 is about technical errors that should not be transformed in fault, but kept as error. We should create another issue to change the content format of JBI fault, from SOAP Fault to a simple XML payload.

a chapter should be added into the Petals documentation about the error management and explain the error vs faults,

each MEP should be documented, in a business view, into Petals documentation to defined explicitly where a business fault can occur, and where a technical error can occur in MEP. For example, no business error could be occur with MEP InOnly,

That seems obvious to me, isn't that already defined in all the norms, standard and recommendation of the W3C on the meaning of the different patterns?

Sure, but our users are not expert in each technology involved in Petals ESB. So we should explain these concepts in the user documentation.

Faults can happen when Faults appear in the definition in the pattern…

Sure.

each component should be review to manage correctly error/fault, mainly binding-components against their external side, so one JIRA issue by component should be added if needed

The main goal of PETALSCDK-130 is about technical errors that should not be transformed in fault, but kept as error. We should create another issue to change the content format of JBI fault, from SOAP Fault to a simple XML payload.

Ok, but we have nothing to do in practice, there is no ticket to create to do any actions: FAULTS are like IN or OUT message, they have to be set on the message by the component or the SU using any mean desired as long as the component or the SU respects the WSDL it is meant to implement!

In the implementation of the MessageExchange, a Fault is simply implemented with a NormalizedMessage (more precisely with the class Fault that extends NormalizedMessage).

There is nothing specific to SOAP in this implementation, only the CDK creates such artificiality, and this should be removed as explained in PETALSCDK-130 (i.e. everything related to SOAPFault and FaultException will just disappear from the CDK and any specific treatment of the errors will too).

You're right, faults are like IN or OUT message and they have to be set on the message by the component. But, are you sure that we have nothing to do ? I'm not.
At least, we should remove some source code as SourceUtil.createSoapFaultDocument(..) that is used to set an exception as a Fault in the message exchange. Perhaps, few other changes can occur.

If you have examples of what specific should be done, I'm curious.

The only specific thing I can see is that depending on the MEP, faults can or cannot be set, but it has always been like that.

Again, the changes you are talking about (such as those in SourceUtil) have to occurs in the CDK and can be discussed in PETALSCDK-130, I don't see how they relate to something else than "removing any Fault/SOAPFault related useless code", which is just a subtask of "not transforming errors to fault".
If you want to create a specific ticket for removing code that will become useless once we stop transforming errors to fault, then feel free to do so

This is mostly resolved in 5.0.0-M1, there still some fixup to do.

Reopen for issues still open in components.