Petals SE XSLT

Yes, one entry by subject. Don't fix two different kind of subject in the same entry

Commit # 16531
A fault is not set anymore if the invocation MEP is InOnly.
The XSD was updated too.

The fact is that I prefer a precise bug, and it seems there is no agreement yet.
Let's first discuss it (on the forum) and then we will post bugs to define what to do.

For the moment, there is no interest to define a JBI Fault not SOAP Fault like...
But, there is interest to define a JBI Fault as a SOAP Fault, as i explained before...

What we want do for the future about the Fault can be defined as an improvement or new feature, if you wish, maybe more a thread on the forum? As you want.

OK. Maybe we could split this bug in two.
I fixed the MEP issue. Only remains the fault thing, that we could delay.

About the fault being SOAP faults or something else, maybe we could study it first.
Do you agree?

It's true that in theory, we can define any XML message (and attachment + properties) as a JBI FAULT.

But, there is no official binding JBI that we support on the WSDL exposed in the bus, with some rules about how describe a JBI FAULT that can be generically handled.
Thus, we commonly use binding SOAP, for ease SE BPEL and BC SOAP manipulations.

EG, if a SOAP fault is returned by a JBI component when a invocation comes from the BC SOAP, the actor is relayed in the SOAP Fault returned by the SOAP. I think it is interesting to know the component name of the origin of the fault.

To go further, we can define so rules about how handling and define a JBI Fault in Petals ESB. Open discussion, for my point of view, i don't know!

I got this remark from the team.
With the SOAP BC 4.x, it was working fine, even if the fault was not a SOAP fault.
But things might have changed with the new version of the SOAP BC. Tests are on the way.

Why faults should be SOAP faults ? IMO, The SOAP faults should be returned by the BC SOAP to its client, and into the NMR we should have only fault not using SOAP message protocol.