Petals SE XSLT

Invalid behavior with the InOnly MEP

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Minor Minor
  • Resolution: Fixed
  • Affects Version/s: 2.4
  • Fix Version/s: 2.4.1
  • Component/s: None
  • Security Level: Public
  • Description:
    Hide

    If we try to invoke a XSL transformation with invalid parameters and with the InOnly MEP, a fault is set on the exchange.
    This is not allowed with this pattern.

    Besides, the faults are built manually.
    If it works correctly with Java clients, the faults should still be SOAP faults.

    This second point needs to be discussed and will be the object of another report if it is confirmed.

    Show
    If we try to invoke a XSL transformation with invalid parameters and with the InOnly MEP, a fault is set on the exchange. This is not allowed with this pattern.
    Besides, the faults are built manually. If it works correctly with Java clients, the faults should still be SOAP faults.
    This second point needs to be discussed and will be the object of another report if it is confirmed.
  • Environment:
    Windows XP.

Activity

Ascending order - Click to sort in descending order
Vincent Zurczak made changes - Tue, 19 Oct 2010 - 11:49:35 +0200
Field Original Value New Value
Status New [ 10000 ] Open [ 10002 ]
Priority Minor [ 4 ]
Vincent Zurczak made changes - Tue, 19 Oct 2010 - 11:49:37 +0200
Status Open [ 10002 ] In Progress [ 10003 ]
Vincent Zurczak made changes - Tue, 19 Oct 2010 - 12:19:19 +0200
Status In Progress [ 10003 ] Open [ 10002 ]
Hide
Permalink
Christophe DENEUX added a comment - Tue, 19 Oct 2010 - 13:52:13 +0200

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.

Show
Christophe DENEUX added a comment - Tue, 19 Oct 2010 - 13:52:13 +0200 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.
Hide
Permalink
Vincent Zurczak added a comment - Tue, 19 Oct 2010 - 13:56:50 +0200

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.

Show
Vincent Zurczak added a comment - Tue, 19 Oct 2010 - 13:56:50 +0200 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.
Hide
Permalink
Roland Naudin added a comment - Tue, 19 Oct 2010 - 14:27:56 +0200

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!

Show
Roland Naudin added a comment - Tue, 19 Oct 2010 - 14:27:56 +0200 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!
Hide
Permalink
Vincent Zurczak added a comment - Tue, 19 Oct 2010 - 14:56:22 +0200

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?

Show
Vincent Zurczak added a comment - Tue, 19 Oct 2010 - 14:56:22 +0200 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?
Hide
Permalink
Roland Naudin added a comment - Tue, 19 Oct 2010 - 15:02:48 +0200

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.

Show
Roland Naudin added a comment - Tue, 19 Oct 2010 - 15:02:48 +0200 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.
Hide
Permalink
Vincent Zurczak added a comment - Tue, 19 Oct 2010 - 15:06:56 +0200

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.

Show
Vincent Zurczak added a comment - Tue, 19 Oct 2010 - 15:06:56 +0200 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.
Vincent Zurczak made changes - Tue, 19 Oct 2010 - 15:08:09 +0200
Description If we try to invoke a XSL transformation with invalid parameters and with the InOnly MEP, a fault is set on the exchange.
This is not allowed with this pattern.

Besides, the faults are built manually.
If it works correctly with Java clients, the faults should still be SOAP faults. 		If we try to invoke a XSL transformation with invalid parameters and with the InOnly MEP, a fault is set on the exchange.
This is not allowed with this pattern.

{quote}
Besides, the faults are built manually.
If it works correctly with Java clients, the faults should still be SOAP faults.
{quote}

This second point needs to be discussed and will be the object of another report if it is confirmed.
Vincent Zurczak made changes - Tue, 19 Oct 2010 - 15:13:48 +0200
Status Open [ 10002 ] In Progress [ 10003 ]
Hide
Permalink
Vincent Zurczak added a comment - Tue, 19 Oct 2010 - 15:13:59 +0200

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

Show
Vincent Zurczak added a comment - Tue, 19 Oct 2010 - 15:13:59 +0200 Commit # 16531 A fault is not set anymore if the invocation MEP is InOnly. The XSD was updated too.
Vincent Zurczak made changes - Tue, 19 Oct 2010 - 15:13:59 +0200
Status In Progress [ 10003 ] Resolved [ 10004 ]
Fix Version/s 2.4.1 [ 10154 ]
Resolution Fixed [ 1 ]
Vincent Zurczak made changes - Tue, 19 Oct 2010 - 15:14:04 +0200
Status Resolved [ 10004 ] Closed [ 10005 ]
Vincent Zurczak made changes - Tue, 19 Oct 2010 - 15:14:20 +0200
Summary Invalid management of faults in the component Invalid behavior with the InOnly MEP
Hide
Permalink
Christophe DENEUX added a comment - Tue, 19 Oct 2010 - 15:16:25 +0200

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

Show
Christophe DENEUX added a comment - Tue, 19 Oct 2010 - 15:16:25 +0200 Yes, one entry by subject. Don't fix two different kind of subject in the same entry
Transition Status Change Time Execution Times Last Executer Last Execution Date
New New Open Open
17s
1
Vincent Zurczak
Tue, 19 Oct 2010 - 11:49:35 +0200
Open Open In Progress In Progress
2s
1
Vincent Zurczak
Tue, 19 Oct 2010 - 11:49:37 +0200
In Progress In Progress Open Open
29m 42s
1
Vincent Zurczak
Tue, 19 Oct 2010 - 12:19:19 +0200
Open Open In Progress In Progress
2h 54m
1
Vincent Zurczak
Tue, 19 Oct 2010 - 15:13:48 +0200
In Progress In Progress Resolved Resolved
11s
1
Vincent Zurczak
Tue, 19 Oct 2010 - 15:13:59 +0200
Resolved Resolved Closed Closed
5s
1
Vincent Zurczak
Tue, 19 Oct 2010 - 15:14:04 +0200



People

Dates

  • Created:
    Tue, 19 Oct 2010 - 11:49:18 +0200
    Updated:
    Tue, 19 Oct 2010 - 15:16:25 +0200
    Resolved:
    Tue, 19 Oct 2010 - 15:13:59 +0200
Atlassian JIRA (v4.1.2#531) | Report a problem | Request a feature | Contact administrators
Powered by a free Atlassian JIRA open source license for Petals ESB. Try JIRA - bug tracking software for your team.