[JBoss JIRA] Created: (JBESB-2966) SOAPProxy does not ensure valid SOAP response comes back from proxied endpoint
by Aaron Pestel (JIRA)
SOAPProxy does not ensure valid SOAP response comes back from proxied endpoint
------------------------------------------------------------------------------
Key: JBESB-2966
URL: https://jira.jboss.org/jira/browse/JBESB-2966
Project: JBoss ESB
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 4.6
Reporter: Aaron Pestel
SOAPProxy delegates HTTP transport to HttpRouter, however, SOAPProxy does not check to make sure that the response from HttpRouter is valid SOAP. For example, if the wsdl points to an existing JBoss server, but bad URL (http://localhost:8080/a/bad/WS/url), then the message body after the SOAPProxy action will be HTML text basically saying there was a 404 error. If SOAPProxy were just an HTTP proxy, this may make sense, but giving that it's an abstraction layer higher, it seems this should generate an exception in the action. My expectation would be that after the SOAPProxy action finishes successfully, there should be a SOAP response or SOAP fault in the default body of the ESB message. If a non-SOAP response was returned, then I think an exception should be raised in the action chain. Now, I'm not real excited about the overhead of having to parse the response from the endpoint, but maybe we could at least check for HTTP 200 or check that the response starts with this or something:
------------------
<?xml version="1.0"?>
<soap:Envelope
------------------
Basically, I'm trying to setup a demo where webservices are retried (if using JCA listener) or sent to DLQ. But without the SOAPProxy throwing an exception in error conditions, this requires writing an action to follow the SOAPProxy to check if the response was valid and then possibly throw an exception.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 5 months
[JBoss JIRA] Created: (JBESB-2768) Aggregator meta data in properties
by Kevin Conner (JIRA)
Aggregator meta data in properties
----------------------------------
Key: JBESB-2768
URL: https://jira.jboss.org/jira/browse/JBESB-2768
Project: JBoss ESB
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Content Based Routing
Affects Versions: 4.4 CP3
Reporter: Kevin Conner
Fix For: 4.4 CP4
The MessageMulticaster creates an aggregation id and stores this value in message properties. Normally this does not prove to be an issue but when using invm transport it may cause issues.
When the message is sent to multiple services, using pass by reference semantics, then all services will see the *same* properties and may, depending on timing, see the same aggregation id.
The aggregation value should really be in the message context as this section is always duplicated when creating a reference, never shared. The problem we face is that users may already be referencing the property, especially if they are creating a fresh response message, so we need to think about handling this.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 5 months