[JBoss JIRA] (JBESB-3942) OGNLUtils.assertIsCollection() incorrectly interprets "Zero or more repetitions" comments in front of non-repeatable field
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/JBESB-3942?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration updated JBESB-3942:
-------------------------------------------
Bugzilla Update: Perform
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=983077
> OGNLUtils.assertIsCollection() incorrectly interprets "Zero or more repetitions" comments in front of non-repeatable field
> ---------------------------------------------------------------------------------…
[View More]-----------------------------------------
>
> Key: JBESB-3942
> URL: https://issues.jboss.org/browse/JBESB-3942
> Project: JBoss ESB
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Web Services
> Affects Versions: 4.12
> Reporter: Tom Cunningham
> Assignee: Tom Cunningham
> Fix For: 4.11 CP3
>
>
> Description of problem:
> * Suppose you have a long WSDL document and only set one single parameter in the request map using OGNL, such as:
> requestMap.put("mutiereGeschaeft.geschaeft.Kredit.KreStatus", "ssss");
> * WSDL snippet:
> <xs:element name='KreStatus' nillable='true' type='xs:string'/>
> * Generated Request - without parameters filed:
> <!--Zero or more repetitions: - cloned-->
>
> <java1:KreStatus>?</java1:KreStatus>
> * org.jboss.internal.soa.esb.soap.OGNLUtils.assertIsCollection() checks for this:
> if(commentBefore != null
> && (commentBefore.getTextContent().endsWith(SOAPUI_CLONE_COMMENT)
> || commentBefore.getTextContent().endsWith(SOAPUI_CLONE_COMMENT + CLONED_POSTFIX))) {
> return true;
> }
> which is true and this causes this parameter to not be filled at all. If
> mutiereGeschaeft.geschaeft.Kredit.KreStatus[0] is used, the parameter will be correctly filled.
> We need to make sure that assertIsCollection(), possibly assertIsParentCollection() also checks if the element can be repeated, or somehow else make sure that we actually have repeated the element and not some other elements.
> Version-Release number of selected component (if applicable):
> - JBoss SOA-P 5.3.1
> How reproducible:
> Always
> Steps to Reproduce:
> 1. Using attached modified quickstart
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[View Less]
11 years, 8 months
[JBoss JIRA] (JBESB-3942) OGNLUtils.assertIsCollection() incorrectly interprets "Zero or more repetitions" comments in front of non-repeatable field
by Tom Cunningham (JIRA)
Tom Cunningham created JBESB-3942:
-------------------------------------
Summary: OGNLUtils.assertIsCollection() incorrectly interprets "Zero or more repetitions" comments in front of non-repeatable field
Key: JBESB-3942
URL: https://issues.jboss.org/browse/JBESB-3942
Project: JBoss ESB
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Web Services
Affects Versions: 4.12
…
[View More]Reporter: Tom Cunningham
Assignee: Tom Cunningham
Fix For: 4.11 CP3
Description of problem:
* Suppose you have a long WSDL document and only set one single parameter in the request map using OGNL, such as:
requestMap.put("mutiereGeschaeft.geschaeft.Kredit.KreStatus", "ssss");
* WSDL snippet:
<xs:element name='KreStatus' nillable='true' type='xs:string'/>
* Generated Request - without parameters filed:
<!--Zero or more repetitions: - cloned-->
<java1:KreStatus>?</java1:KreStatus>
* org.jboss.internal.soa.esb.soap.OGNLUtils.assertIsCollection() checks for this:
if(commentBefore != null
&& (commentBefore.getTextContent().endsWith(SOAPUI_CLONE_COMMENT)
|| commentBefore.getTextContent().endsWith(SOAPUI_CLONE_COMMENT + CLONED_POSTFIX))) {
return true;
}
which is true and this causes this parameter to not be filled at all. If
mutiereGeschaeft.geschaeft.Kredit.KreStatus[0] is used, the parameter will be correctly filled.
We need to make sure that assertIsCollection(), possibly assertIsParentCollection() also checks if the element can be repeated, or somehow else make sure that we actually have repeated the element and not some other elements.
Version-Release number of selected component (if applicable):
- JBoss SOA-P 5.3.1
How reproducible:
Always
Steps to Reproduce:
1. Using attached modified quickstart
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[View Less]
11 years, 8 months
[JBoss JIRA] (JBESB-3941) ESB ignoring transacted flag on EPR element
by Kevin Conner (JIRA)
[ https://issues.jboss.org/browse/JBESB-3941?page=com.atlassian.jira.plugin... ]
Kevin Conner commented on JBESB-3941:
-------------------------------------
One comment to make is that the EPR is for the caller and not the service and it should be possible to specify these differently, as such the suggested fix is not really correct. As a workaround it is likely possible to specify the transacted flag as a property on the service.
> ESB ignoring transacted flag on EPR …
[View More]element
> -------------------------------------------
>
> Key: JBESB-3941
> URL: https://issues.jboss.org/browse/JBESB-3941
> Project: JBoss ESB
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Rosetta
> Affects Versions: 4.12
> Reporter: Tom Cunningham
> Assignee: Tom Cunningham
> Fix For: 4.11 CP3
>
>
> Description of problem:
> For example
> > <jbossesb-listeners
> > deployment="Quickstart_JMS_Transacted.esb"
> > parameterReloadSecs="5">
> > <listener
> > busIdRef="quickstartEsbChannel"
> > listenerClass="org.jboss.soa.esb.listeners.message.MessageAwareListener"
> > maxThreads="1"
> > mep="OneWay"
> > name="jmssecured"
> > service-category="JMSSecuredESB"
> > service-description="JMS Secured quickstart sample"
> > service-name="SimpleListener">
> > <EPR
> > acknowledge-mode="AUTO_ACKNOWLEDGE"
> > connection-factory="XAConnectionFactory"
> > destination-name="queue/quickstart_jms_transacted_Request_esb"
> > destination-type="queue"
> > persistent="true"
> > protocol="jms"
> > transacted="true"/>
> If you set a breakpoint on the MessageAwareListener where it retrieves the value for 'transacted', i.e. "transactional = _config.getBooleanAttribute(ListenerTagNames.TRANSACTED_TAG, false) ;", and if you then in Eclipse Debug mode analyse the 'this._config' (the ConfigTree variable), you can see that that ConfigTree does not have a 'transacted' key in its '_attributes' map. However, one of the Child ConfigTrees of this Listener tree, the 'EPR' ConfigTree, does have a 'transacted = true' value in it's tree. However, _config.getBooleanAttribute(..) does not do a recursive search through the child ConfigTrees (and it probably shouldn't, I'm not sure how this was designed), which explains why it does not return 'true'.
> > I have a proposed hack/fix that would resolve this.
> >
> > In MessageAwareListener line 169. Replace
> >
> > From
> > transactional = _config.getBooleanAttribute(ListenerTagNames.TRANSACTED_TAG, false) ;
> > To
> > transactional = _config.getChildren("EPR")[0]..getBooleanAttribute(ListenerTagNames.TRANSACTED_TAG, false) ;
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[View Less]
11 years, 8 months
[JBoss JIRA] (JBESB-3941) ESB ignoring transacted flag on EPR element
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/JBESB-3941?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration updated JBESB-3941:
-------------------------------------------
Bugzilla Update: Perform
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=980802
> ESB ignoring transacted flag on EPR element
> -------------------------------------------
>
> Key: JBESB-3941
> URL: https://issues.jboss.org/browse/JBESB-3941
…
[View More]> Project: JBoss ESB
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Rosetta
> Affects Versions: 4.12
> Reporter: Tom Cunningham
> Assignee: Tom Cunningham
> Fix For: 4.11 CP3
>
>
> Description of problem:
> For example
> > <jbossesb-listeners
> > deployment="Quickstart_JMS_Transacted.esb"
> > parameterReloadSecs="5">
> > <listener
> > busIdRef="quickstartEsbChannel"
> > listenerClass="org.jboss.soa.esb.listeners.message.MessageAwareListener"
> > maxThreads="1"
> > mep="OneWay"
> > name="jmssecured"
> > service-category="JMSSecuredESB"
> > service-description="JMS Secured quickstart sample"
> > service-name="SimpleListener">
> > <EPR
> > acknowledge-mode="AUTO_ACKNOWLEDGE"
> > connection-factory="XAConnectionFactory"
> > destination-name="queue/quickstart_jms_transacted_Request_esb"
> > destination-type="queue"
> > persistent="true"
> > protocol="jms"
> > transacted="true"/>
> If you set a breakpoint on the MessageAwareListener where it retrieves the value for 'transacted', i.e. "transactional = _config.getBooleanAttribute(ListenerTagNames.TRANSACTED_TAG, false) ;", and if you then in Eclipse Debug mode analyse the 'this._config' (the ConfigTree variable), you can see that that ConfigTree does not have a 'transacted' key in its '_attributes' map. However, one of the Child ConfigTrees of this Listener tree, the 'EPR' ConfigTree, does have a 'transacted = true' value in it's tree. However, _config.getBooleanAttribute(..) does not do a recursive search through the child ConfigTrees (and it probably shouldn't, I'm not sure how this was designed), which explains why it does not return 'true'.
> > I have a proposed hack/fix that would resolve this.
> >
> > In MessageAwareListener line 169. Replace
> >
> > From
> > transactional = _config.getBooleanAttribute(ListenerTagNames.TRANSACTED_TAG, false) ;
> > To
> > transactional = _config.getChildren("EPR")[0]..getBooleanAttribute(ListenerTagNames.TRANSACTED_TAG, false) ;
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[View Less]
11 years, 8 months
[JBoss JIRA] (JBESB-3941) ESB ignoring transacted flag on EPR element
by Tom Cunningham (JIRA)
[ https://issues.jboss.org/browse/JBESB-3941?page=com.atlassian.jira.plugin... ]
Tom Cunningham updated JBESB-3941:
----------------------------------
Affects Version/s: 4.12
> ESB ignoring transacted flag on EPR element
> -------------------------------------------
>
> Key: JBESB-3941
> URL: https://issues.jboss.org/browse/JBESB-3941
> Project: JBoss ESB
> Issue Type: Bug
> Security Level: Public(…
[View More]Everyone can see)
> Components: Rosetta
> Affects Versions: 4.12
> Reporter: Tom Cunningham
> Assignee: Tom Cunningham
> Fix For: 4.11 CP3
>
>
> Description of problem:
> For example
> > <jbossesb-listeners
> > deployment="Quickstart_JMS_Transacted.esb"
> > parameterReloadSecs="5">
> > <listener
> > busIdRef="quickstartEsbChannel"
> > listenerClass="org.jboss.soa.esb.listeners.message.MessageAwareListener"
> > maxThreads="1"
> > mep="OneWay"
> > name="jmssecured"
> > service-category="JMSSecuredESB"
> > service-description="JMS Secured quickstart sample"
> > service-name="SimpleListener">
> > <EPR
> > acknowledge-mode="AUTO_ACKNOWLEDGE"
> > connection-factory="XAConnectionFactory"
> > destination-name="queue/quickstart_jms_transacted_Request_esb"
> > destination-type="queue"
> > persistent="true"
> > protocol="jms"
> > transacted="true"/>
> If you set a breakpoint on the MessageAwareListener where it retrieves the value for 'transacted', i.e. "transactional = _config.getBooleanAttribute(ListenerTagNames.TRANSACTED_TAG, false) ;", and if you then in Eclipse Debug mode analyse the 'this._config' (the ConfigTree variable), you can see that that ConfigTree does not have a 'transacted' key in its '_attributes' map. However, one of the Child ConfigTrees of this Listener tree, the 'EPR' ConfigTree, does have a 'transacted = true' value in it's tree. However, _config.getBooleanAttribute(..) does not do a recursive search through the child ConfigTrees (and it probably shouldn't, I'm not sure how this was designed), which explains why it does not return 'true'.
> > I have a proposed hack/fix that would resolve this.
> >
> > In MessageAwareListener line 169. Replace
> >
> > From
> > transactional = _config.getBooleanAttribute(ListenerTagNames.TRANSACTED_TAG, false) ;
> > To
> > transactional = _config.getChildren("EPR")[0]..getBooleanAttribute(ListenerTagNames.TRANSACTED_TAG, false) ;
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[View Less]
11 years, 8 months
[JBoss JIRA] (JBESB-3941) ESB ignoring transacted flag on EPR element
by Tom Cunningham (JIRA)
[ https://issues.jboss.org/browse/JBESB-3941?page=com.atlassian.jira.plugin... ]
Tom Cunningham updated JBESB-3941:
----------------------------------
Fix Version/s: 4.11 CP3
> ESB ignoring transacted flag on EPR element
> -------------------------------------------
>
> Key: JBESB-3941
> URL: https://issues.jboss.org/browse/JBESB-3941
> Project: JBoss ESB
> Issue Type: Bug
> Security Level: Public(…
[View More]Everyone can see)
> Components: Rosetta
> Reporter: Tom Cunningham
> Assignee: Tom Cunningham
> Fix For: 4.11 CP3
>
>
> Description of problem:
> For example
> > <jbossesb-listeners
> > deployment="Quickstart_JMS_Transacted.esb"
> > parameterReloadSecs="5">
> > <listener
> > busIdRef="quickstartEsbChannel"
> > listenerClass="org.jboss.soa.esb.listeners.message.MessageAwareListener"
> > maxThreads="1"
> > mep="OneWay"
> > name="jmssecured"
> > service-category="JMSSecuredESB"
> > service-description="JMS Secured quickstart sample"
> > service-name="SimpleListener">
> > <EPR
> > acknowledge-mode="AUTO_ACKNOWLEDGE"
> > connection-factory="XAConnectionFactory"
> > destination-name="queue/quickstart_jms_transacted_Request_esb"
> > destination-type="queue"
> > persistent="true"
> > protocol="jms"
> > transacted="true"/>
> If you set a breakpoint on the MessageAwareListener where it retrieves the value for 'transacted', i.e. "transactional = _config.getBooleanAttribute(ListenerTagNames.TRANSACTED_TAG, false) ;", and if you then in Eclipse Debug mode analyse the 'this._config' (the ConfigTree variable), you can see that that ConfigTree does not have a 'transacted' key in its '_attributes' map. However, one of the Child ConfigTrees of this Listener tree, the 'EPR' ConfigTree, does have a 'transacted = true' value in it's tree. However, _config.getBooleanAttribute(..) does not do a recursive search through the child ConfigTrees (and it probably shouldn't, I'm not sure how this was designed), which explains why it does not return 'true'.
> > I have a proposed hack/fix that would resolve this.
> >
> > In MessageAwareListener line 169. Replace
> >
> > From
> > transactional = _config.getBooleanAttribute(ListenerTagNames.TRANSACTED_TAG, false) ;
> > To
> > transactional = _config.getChildren("EPR")[0]..getBooleanAttribute(ListenerTagNames.TRANSACTED_TAG, false) ;
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[View Less]
11 years, 8 months
[JBoss JIRA] (JBESB-3941) ESB ignoring transacted flag on EPR element
by Tom Cunningham (JIRA)
[ https://issues.jboss.org/browse/JBESB-3941?page=com.atlassian.jira.plugin... ]
Tom Cunningham updated JBESB-3941:
----------------------------------
Component/s: Rosetta
> ESB ignoring transacted flag on EPR element
> -------------------------------------------
>
> Key: JBESB-3941
> URL: https://issues.jboss.org/browse/JBESB-3941
> Project: JBoss ESB
> Issue Type: Bug
> Security Level: Public(…
[View More]Everyone can see)
> Components: Rosetta
> Reporter: Tom Cunningham
> Assignee: Tom Cunningham
>
> Description of problem:
> For example
> > <jbossesb-listeners
> > deployment="Quickstart_JMS_Transacted.esb"
> > parameterReloadSecs="5">
> > <listener
> > busIdRef="quickstartEsbChannel"
> > listenerClass="org.jboss.soa.esb.listeners.message.MessageAwareListener"
> > maxThreads="1"
> > mep="OneWay"
> > name="jmssecured"
> > service-category="JMSSecuredESB"
> > service-description="JMS Secured quickstart sample"
> > service-name="SimpleListener">
> > <EPR
> > acknowledge-mode="AUTO_ACKNOWLEDGE"
> > connection-factory="XAConnectionFactory"
> > destination-name="queue/quickstart_jms_transacted_Request_esb"
> > destination-type="queue"
> > persistent="true"
> > protocol="jms"
> > transacted="true"/>
> If you set a breakpoint on the MessageAwareListener where it retrieves the value for 'transacted', i.e. "transactional = _config.getBooleanAttribute(ListenerTagNames.TRANSACTED_TAG, false) ;", and if you then in Eclipse Debug mode analyse the 'this._config' (the ConfigTree variable), you can see that that ConfigTree does not have a 'transacted' key in its '_attributes' map. However, one of the Child ConfigTrees of this Listener tree, the 'EPR' ConfigTree, does have a 'transacted = true' value in it's tree. However, _config.getBooleanAttribute(..) does not do a recursive search through the child ConfigTrees (and it probably shouldn't, I'm not sure how this was designed), which explains why it does not return 'true'.
> > I have a proposed hack/fix that would resolve this.
> >
> > In MessageAwareListener line 169. Replace
> >
> > From
> > transactional = _config.getBooleanAttribute(ListenerTagNames.TRANSACTED_TAG, false) ;
> > To
> > transactional = _config.getChildren("EPR")[0]..getBooleanAttribute(ListenerTagNames.TRANSACTED_TAG, false) ;
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[View Less]
11 years, 8 months
[JBoss JIRA] (JBESB-3941) ESB ignoring transacted flag on EPR element
by Tom Cunningham (JIRA)
Tom Cunningham created JBESB-3941:
-------------------------------------
Summary: ESB ignoring transacted flag on EPR element
Key: JBESB-3941
URL: https://issues.jboss.org/browse/JBESB-3941
Project: JBoss ESB
Issue Type: Bug
Security Level: Public (Everyone can see)
Reporter: Tom Cunningham
Assignee: Tom Cunningham
Description of problem:
For example
> <jbossesb-listeners
> …
[View More]deployment="Quickstart_JMS_Transacted.esb"
> parameterReloadSecs="5">
> <listener
> busIdRef="quickstartEsbChannel"
> listenerClass="org.jboss.soa.esb.listeners.message.MessageAwareListener"
> maxThreads="1"
> mep="OneWay"
> name="jmssecured"
> service-category="JMSSecuredESB"
> service-description="JMS Secured quickstart sample"
> service-name="SimpleListener">
> <EPR
> acknowledge-mode="AUTO_ACKNOWLEDGE"
> connection-factory="XAConnectionFactory"
> destination-name="queue/quickstart_jms_transacted_Request_esb"
> destination-type="queue"
> persistent="true"
> protocol="jms"
> transacted="true"/>
If you set a breakpoint on the MessageAwareListener where it retrieves the value for 'transacted', i.e. "transactional = _config.getBooleanAttribute(ListenerTagNames.TRANSACTED_TAG, false) ;", and if you then in Eclipse Debug mode analyse the 'this._config' (the ConfigTree variable), you can see that that ConfigTree does not have a 'transacted' key in its '_attributes' map. However, one of the Child ConfigTrees of this Listener tree, the 'EPR' ConfigTree, does have a 'transacted = true' value in it's tree. However, _config.getBooleanAttribute(..) does not do a recursive search through the child ConfigTrees (and it probably shouldn't, I'm not sure how this was designed), which explains why it does not return 'true'.
> I have a proposed hack/fix that would resolve this.
>
> In MessageAwareListener line 169. Replace
>
> From
> transactional = _config.getBooleanAttribute(ListenerTagNames.TRANSACTED_TAG, false) ;
> To
> transactional = _config.getChildren("EPR")[0]..getBooleanAttribute(ListenerTagNames.TRANSACTED_TAG, false) ;
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[View Less]
11 years, 8 months