[JBoss JIRA] Created: (JBESB-3311) ReplyTo EPR must be manually reset after Aggregator action is used
by Kevin Conner (JIRA)
ReplyTo EPR must be manually reset after Aggregator action is used
------------------------------------------------------------------
Key: JBESB-3311
URL: https://jira.jboss.org/jira/browse/JBESB-3311
Project: JBoss ESB
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Content Based Routing
Affects Versions: 4.8
Reporter: David van Balen
Fix For: 4.9
The ESB depends on the message's replyTo to know where to send a reply in a RequestResponse service. However, the Aggregator action makes no attempt to preserve the replyTo when it creates an aggregate message for a series. In most cases, I would think the replyTo on the aggregated messages would be the same, so adding it onto the resulting aggregated message would seem like a good idea. Otherwise, it has to be handled manually in the assembler action.
--
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
15 years, 8 months
[JBoss JIRA] Created: (JBESB-3310) Aggregator meta data in properties
by Kevin Conner (JIRA)
Aggregator meta data in properties
----------------------------------
Key: JBESB-3310
URL: https://jira.jboss.org/jira/browse/JBESB-3310
Project: JBoss ESB
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Content Based Routing
Affects Versions: 4.8
Reporter: Kevin Conner
Fix For: 4.9
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
15 years, 8 months
[JBoss JIRA] Created: (JBESB-3452) SOAPClient's OGNL util does not map collections properly from SOAP responses
by Kevin Conner (JIRA)
SOAPClient's OGNL util does not map collections properly from SOAP responses
----------------------------------------------------------------------------
Key: JBESB-3452
URL: https://jira.jboss.org/browse/JBESB-3452
Project: JBoss ESB
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Rosetta, Web Services
Affects Versions: 4.8
Reporter: Magesh Kumar B
Assignee: Magesh Kumar B
Fix For: 4.9
When SOAP responses contain collections like shown below they are not processed properly. Only the last value is retained in the resulting OGNL map.
<OrderStatus>
<id>1</id>
<comment>order processed</comment>
<returnCode>1</returnCode>
<comments>Additional Comment1</comments>
<comments>Additional Comment2</comments>
<comments>Additional Comment3</comments>
<comments>Additional Comment4</comments>
</OrderStatus>
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 8 months
[JBoss JIRA] Created: (JBESB-3451) SOAPClient action remappes objects with null strings to empty strings
by Kevin Conner (JIRA)
SOAPClient action remappes objects with null strings to empty strings
---------------------------------------------------------------------
Key: JBESB-3451
URL: https://jira.jboss.org/browse/JBESB-3451
Project: JBoss ESB
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Web Services
Affects Versions: 4.2.1 CP1
Reporter: Jiri Pechanec
Assignee: Magesh Kumar B
Fix For: 4.9
Use webservice_consumer2 quickstart and use the attached files - contains enhanced equals and toString defintions. Make sure that option1 is used.
The object with following contents is sent to processing to ivoke web service
id = 101 lineItems = [Line Item ID= 1 Price=10.0 Ship To=aname, Line Item ID= 2 Price=20.0 Ship To=aname2] shipTo = null
But in the web service processing method the contents is
id = 101 lineItems = [Line Item ID= 1 Price=10.0 Ship To=aname, Line Item ID= 2 Price=20.0 Ship To=aname2] shipTo =
The difference is in shipTo property which was set tu null on the input but comes to web service as empty string.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 8 months
[JBoss JIRA] Created: (JBESB-3457) Riftsaw is unable to invoke services exposed via SOAPProcessor.
by Marek Baluch (JIRA)
Riftsaw is unable to invoke services exposed via SOAPProcessor.
---------------------------------------------------------------
Key: JBESB-3457
URL: https://jira.jboss.org/browse/JBESB-3457
Project: JBoss ESB
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Rosetta
Affects Versions: 4.8
Reporter: Marek Baluch
Rifsaw uses SOAPMessageImpl from JBoss WS to invoke a concrete web service. Because the MarshalUnmarshalManager does not have the correct plugin which can unpack the message an XMLStreamException is thrown. See stack-trace bellow.
Stack-Trace:
12:47:23,297 DEBUG [JBossRemotingGatewayListener] JBoss Remoting Gateway failed to synchronously deliver message to target service [ESBCategory:GoodByeService].
org.jboss.soa.esb.listeners.message.MessageDeliverException: Caught (un)marshal related exception during attempted send/receive.
at org.jboss.soa.esb.client.ServiceInvoker$EPRInvoker.attemptDelivery(ServiceInvoker.java:697)
at org.jboss.soa.esb.client.ServiceInvoker$EPRInvoker.access$200(ServiceInvoker.java:569)
at org.jboss.soa.esb.client.ServiceInvoker.post(ServiceInvoker.java:359)
at org.jboss.soa.esb.client.ServiceInvoker.deliverAsync(ServiceInvoker.java:254)
at org.jboss.soa.esb.client.ServiceInvoker.deliverToDeadLetterService(ServiceInvoker.java:296)
at org.jboss.soa.esb.client.ServiceInvoker.deliverSync(ServiceInvoker.java:227)
at org.jboss.soa.esb.listeners.message.UncomposedMessageDeliveryAdapter.deliverSyncWithoutDecomposing(UncomposedMessageDeliveryAdapter.java:107)
at org.jboss.soa.esb.listeners.message.UncomposedMessageDeliveryAdapter.deliverSync(UncomposedMessageDeliveryAdapter.java:86)
at org.jboss.soa.esb.listeners.gateway.JBossRemotingGatewayListener.invoke(JBossRemotingGatewayListener.java:375)
at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:930)
at org.jboss.remoting.transport.local.LocalClientInvoker.invoke(LocalClientInvoker.java:106)
at org.jboss.remoting.Client.invoke(Client.java:2034)
at org.jboss.remoting.Client.invoke(Client.java:877)
at org.jboss.ws.core.client.HTTPRemotingConnection.invoke(HTTPRemotingConnection.java:232)
at org.jboss.ws.core.client.SOAPProtocolConnectionHTTP.invoke(SOAPProtocolConnectionHTTP.java:71)
at org.jboss.ws.core.jaxws.client.DispatchImpl.invokeInternalSOAP(DispatchImpl.java:249)
at org.jboss.ws.core.jaxws.client.DispatchImpl.invokeInternal(DispatchImpl.java:171)
at org.jboss.ws.core.jaxws.client.DispatchImpl.invoke(DispatchImpl.java:134)
at org.jboss.soa.bpel.runtime.ws.WebServiceClient$TwoWayCallable$1.call(WebServiceClient.java:236)
at org.apache.ode.scheduler.simple.SimpleScheduler.execTransaction(SimpleScheduler.java:284)
at org.apache.ode.scheduler.simple.SimpleScheduler.execTransaction(SimpleScheduler.java:239)
at org.jboss.soa.bpel.runtime.ws.WebServiceClient$TwoWayCallable.call(WebServiceClient.java:210)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:619)
Caused by: org.jboss.soa.esb.couriers.CourierMarshalUnmarshalException: Failed to serialize ESB Message.
at org.jboss.internal.soa.esb.couriers.JmsCourier.internalDeliver(JmsCourier.java:225)
at org.jboss.internal.soa.esb.couriers.JmsCourier.deliver(JmsCourier.java:182)
at org.jboss.internal.soa.esb.couriers.TwoWayCourierImpl.deliver(TwoWayCourierImpl.java:189)
at org.jboss.soa.esb.client.ServiceInvoker$EPRInvoker.attemptDelivery(ServiceInvoker.java:667)
... 26 more
Caused by: java.io.IOException: Util.serialize caught XMLStreamException:
at org.jboss.soa.esb.util.Util.serialize(Util.java:198)
at org.jboss.internal.soa.esb.couriers.JmsCourier.internalDeliver(JmsCourier.java:219)
... 29 more
Caused by: javax.xml.stream.XMLStreamException: Cannot pack object:org.jboss.soa.esb.message.defaultEntry org.jboss.ws.core.soap.SOAPMessageImpl@136c2c1
at org.jboss.internal.soa.esb.message.format.xml.BodyImpl.writeChildContent(BodyImpl.java:148)
at org.jboss.internal.soa.esb.util.stax.ElementContent.writeContent(ElementContent.java:41)
at org.jboss.internal.soa.esb.util.stax.StreamHelper.writeElement(StreamHelper.java:125)
at org.jboss.internal.soa.esb.message.format.xml.MessageImpl.writeChildContent(MessageImpl.java:236)
at org.jboss.internal.soa.esb.util.stax.ElementContent.writeContent(ElementContent.java:41)
at org.jboss.soa.esb.util.Util.serialize(Util.java:188)
... 30 more
Caused by: org.jboss.soa.esb.couriers.CourierMarshalUnmarshalException: Failed to serialize ESB Message.
at org.jboss.internal.soa.esb.couriers.JmsCourier.internalDeliver(JmsCourier.java:225)
at org.jboss.internal.soa.esb.couriers.JmsCourier.deliver(JmsCourier.java:182)
at org.jboss.internal.soa.esb.couriers.TwoWayCourierImpl.deliver(TwoWayCourierImpl.java:189)
at org.jboss.soa.esb.client.ServiceInvoker$EPRInvoker.attemptDelivery(ServiceInvoker.java:667)
... 26 more
Caused by: java.io.IOException: Util.serialize caught XMLStreamException:
at org.jboss.soa.esb.util.Util.serialize(Util.java:198)
at org.jboss.internal.soa.esb.couriers.JmsCourier.internalDeliver(JmsCourier.java:219)
... 29 more
Caused by: javax.xml.stream.XMLStreamException: Cannot pack object:org.jboss.soa.esb.message.defaultEntry org.jboss.ws.core.soap.SOAPMessageImpl@136c2c1
at org.jboss.internal.soa.esb.message.format.xml.BodyImpl.writeChildContent(BodyImpl.java:148)
at org.jboss.internal.soa.esb.util.stax.ElementContent.writeContent(ElementContent.java:41)
at org.jboss.internal.soa.esb.util.stax.StreamHelper.writeElement(StreamHelper.java:125)
at org.jboss.internal.soa.esb.message.format.xml.MessageImpl.writeChildContent(MessageImpl.java:236)
at org.jboss.internal.soa.esb.util.stax.ElementContent.writeContent(ElementContent.java:41)
at org.jboss.soa.esb.util.Util.serialize(Util.java:188)
... 30 more
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 8 months
[JBoss JIRA] Created: (JBESB-3453) OGNLUtils.assertIsCollection fails
by Kevin Conner (JIRA)
OGNLUtils.assertIsCollection fails
----------------------------------
Key: JBESB-3453
URL: https://jira.jboss.org/browse/JBESB-3453
Project: JBoss ESB
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Rosetta
Affects Versions: 4.5
Reporter: jarkko Lietolahti
Assignee: Magesh Kumar B
Fix For: 4.9
The method
{code}
private static boolean assertIsCollection(Element element) {
if(element.getAttributeNS(JBOSSESB_SOAP_NS, IS_COLLECTION_ATTRIB).equals("true")) {
// It's already been attributed... no need to check for the soapui comment...
return true;
}
Comment firstComment = (Comment) YADOMUtil.getFirstChildByType(element, Node.COMMENT_NODE);
// TODO: Get Ole (soapUI) to add an attribute to the collection element - better than looking for this comment.
if(firstComment != null && firstComment.getTextContent().indexOf("1 or more repetitions") != -1) {
return true;
}
return false;
}
{code}
Especially row;
Comment firstComment = (Comment) YADOMUtil.getFirstChildByType(element, Node.COMMENT_NODE);
is causing a grief.
Given an WSDL like below;
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" >
<soapenv:Header/>
<soapenv:Body>
<QueryRequest>
<username>?</username>
<password>?</password>
<Customer id="?" telcoid="?"/>
<!--1 or more repetitions:-->
<productIds>?</productIds>
<isLookup>?</isLookup>
<maxWaitTime>?</maxWaitTime>
</QueryRequest>
</soapenv:Body>
</soapenv:Envelope>
OGNLUtils creates ognlExpression QueryRequest[0] for all the elements below QueryRequest. E.g. ognl for username, password etc is "QueryRequest[0]" for username and also "QueryRequest[0]" for password, when in reality it should be QueryRequest.username , QueryRequest.password etc..
This is caused by the array element LATER in the WSDL;
<!--1 or more repetitions:-->
<productIds>?</productIds>
combined with the Comment firstComment = (Comment) YADOMUtil.getFirstChildByType(element, Node.COMMENT_NODE); which somehow finds the "<!-- 1 or .." later in the wsdl.
I think.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 8 months