[JBoss JIRA] (JBESB-3950) SOAPClient generates empty objects for not-required fields
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/JBESB-3950?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on JBESB-3950:
------------------------------------------------
nwallace <nwallace(a)redhat.com> changed the Status of [bug 998677|https://bugzilla.redhat.com/show_bug.cgi?id=998677] from MODIFIED to ON_QA
> SOAPClient generates empty objects for not-required fields
> ----------------------------------------------------------
>
> Key: JBESB-3950
> URL: https://issues.jboss.org/browse/JBESB-3950
> Project: JBoss ESB
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Web Services
> Affects Versions: 4.11 CP3
> Reporter: Tom Cunningham
> Assignee: Tom Cunningham
> Fix For: 4.11 CP3
>
>
> From Musharraf Hussein :
> I have a case [1] where customer is having a problem with the way "SOAPClient" generates SOAP messages to invoke the backend WebServices. Actually it is observed that if a complex type of message (element in SOAP message) contains a 'null' then 'SOAPClient' sends an empty element (as well as an empty child element). According to the customer this shouldn't happen and ESB should rather omit the entire parent-child elements altogether, as it is causing them an NPE in their code. This is how executing their test case (attached) look like.
--
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
10 years, 6 months
[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 commented on JBESB-3942:
------------------------------------------------
nwallace <nwallace(a)redhat.com> changed the Status of [bug 983077|https://bugzilla.redhat.com/show_bug.cgi?id=983077] from MODIFIED to ON_QA
> 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
> 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
10 years, 6 months
[JBoss JIRA] (JBESB-3945) Bpm5Processor does not support processes containing sub-processes
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/JBESB-3945?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on JBESB-3945:
------------------------------------------------
nwallace <nwallace(a)redhat.com> changed the Status of [bug 980530|https://bugzilla.redhat.com/show_bug.cgi?id=980530] from MODIFIED to ON_QA
> Bpm5Processor does not support processes containing sub-processes
> -----------------------------------------------------------------
>
> Key: JBESB-3945
> URL: https://issues.jboss.org/browse/JBESB-3945
> Project: JBoss ESB
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Process flow
> Affects Versions: 4.11
> Reporter: Tom Cunningham
> Assignee: Tom Cunningham
> Fix For: 4.11 CP3
>
>
> Bpm5Processor (or rather AbstractBpm5Action) adds the configured process definitions to the knowledgebase:
> kbuilder.add(ResourceFactory.newClassPathResource(processDefName), ResourceType.BPMN2);
> But there is no support for processes which are calling sub-processes. The class should be extended to read a list of process definition names from the configuration, and add them all to the kbase, so that process->sub-process invocation is possible from Bpm5Processor.
--
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
10 years, 6 months
[JBoss JIRA] (JBESB-3960) Issue with AOP / webservice_consumer1 on AS 4.2.3.GA
by Tom Cunningham (JIRA)
Tom Cunningham created JBESB-3960:
-------------------------------------
Summary: Issue with AOP / webservice_consumer1 on AS 4.2.3.GA
Key: JBESB-3960
URL: https://issues.jboss.org/browse/JBESB-3960
Project: JBoss ESB
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Build and Release
Affects Versions: 4.12
Reporter: Tom Cunningham
Assignee: Tom Cunningham
Fix For: 4.13
Running the webservice_consumer1 QS, I see the following error on 4.2.3.GA :
Caused by: java.lang.ClassNotFoundException: No ClassLoaders found for: org.jboss.aop.advice.SecurityActions
at org.jboss.mx.loading.LoadMgr3.beginLoadTask(LoadMgr3.java:306)
at org.jboss.mx.loading.RepositoryClassLoader.loadClassImpl(RepositoryClassLoader.java:521)
at org.jboss.mx.loading.RepositoryClassLoader.loadClass(RepositoryClassLoader.java:415)
--
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
10 years, 6 months
[JBoss JIRA] (JBESB-3959) ServiceInvoker spans multiple nodes when gateway and esb queue are both defined as non clustered
by Dave Siracusa (JIRA)
[ https://issues.jboss.org/browse/JBESB-3959?page=com.atlassian.jira.plugin... ]
Dave Siracusa updated JBESB-3959:
---------------------------------
Summary: ServiceInvoker spans multiple nodes when gateway and esb queue are both defined as non clustered (was: ServiceInvokerspans multiple nodes when gateway and esb queue are both defined as non clustered)
> ServiceInvoker spans multiple nodes when gateway and esb queue are both defined as non clustered
> ------------------------------------------------------------------------------------------------
>
> Key: JBESB-3959
> URL: https://issues.jboss.org/browse/JBESB-3959
> Project: JBoss ESB
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 4.11
> Environment: Linux
> Reporter: Dave Siracusa
>
> Messages are crossing server boundaries in a multi-server cluster even though queues are defined as non-clustered.
> Enqueuing a message only to the first server node is accepted by the first server, and is routed in round robin fashion to each server in the cluster.
> The reason for this is that during ESB deployment RegistryUtil.register(_config, _epr) is called when it resolves the epr via jmsEprFromElement.
> The jndi url is resolved via Configuration.getJndiServerURL(). This returns the hostname, so the registered EPR in JUUDI includes host specific EPR entries. The ServiceInvoker appears to route in round robin fashion to each registered entry. Inspecting our older/existing SOA 5.2.0 yields a jnp address which happen to reflect the -b (bind address) we specify (in our case 0.0.0.0).
> The registration process between SOA 5.2.0 and SOA 5.3.1 differ, where the default behavior in SOA 5.3.1 registration is to register services for use and available to all other node regardless of queue isolation settings and bind address.
> A combination of clustered and non-clustered queues will likely have problems.
--
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
10 years, 6 months
[JBoss JIRA] (JBESB-3959) ServiceInvokerspans multiple nodes when gateway and esb queue are both defined as non clustered
by Dave Siracusa (JIRA)
[ https://issues.jboss.org/browse/JBESB-3959?page=com.atlassian.jira.plugin... ]
Dave Siracusa updated JBESB-3959:
---------------------------------
Description:
Messages are crossing server boundaries in a multi-server cluster even though queues are defined as non-clustered.
Enqueuing a message only to the first server node is accepted by the first server, and is routed in round robin fashion to each server in the cluster.
The reason for this is that during ESB deployment RegistryUtil.register(_config, _epr) is called when it resolves the epr via jmsEprFromElement.
The jndi url is resolved via Configuration.getJndiServerURL(). This returns the hostname, so the registered EPR in JUUDI includes host specific EPR entries. The ServiceInvoker appears to route in round robin fashion to each registered entry. Inspecting our older/existing SOA 5.2.0 yields a jnp address which happen to reflect the -b (bind address) we specify (in our case 0.0.0.0).
The registration process between SOA 5.2.0 and SOA 5.3.1 differ, where the default behavior in SOA 5.3.1 registration is to register services for use and available to all other node regardless of queue isolation settings and bind address.
A combination of clustered and non-clustered queues will likely have problems.
was:
Messages are crossing server boundaries in a multi-server cluster even though queues are defined as non-clustered.
Enqueuing a message only to the first server node is accepted by the first server, and is routed in round robin fashion to each server in the cluster.
The reason for this is that during ESB deployment RegistryUtil.register(_config, _epr) is called when it resolves the epr via jmsEprFromElement.
The jndi url is resolved via Configuration.getJndiServerURL(). This returns the hostname, so the registered EPR in JUUDI includes host specific EPR entries. The ServiceInvoker appears to route in round robin fashion to each registered entry. Inspecting our existing SOA 5.2.0 yields a jnp address which happen to reflect the -b (bind address) we specify (in our case 0.0.0.0).
The registration process between SOA 5.2.0 and SOA 5.3.1 differ, where the default behavior in SOA 5.3.1 registration is to register services for use and available to all other node regardless of queue isolation settings.
A possible partial workaround exists for environments which don't define any clustered queues. If you define a JNDI bind address at launch time to 127.0.0.1 calls will not be asynchronously delivered to all nodes in your cluster as the JNP address will reflect 127.0.0.1.
A combination of clustered and non-clustered queues will likely have problems.
Workaround Description:
Workarounds:
1. Environments which don't define any clustered queues. If you define a JNDI bind address at launch time to 127.0.0.1 calls will not be asynchronously delivered to all nodes in your cluster as the JNP address will reflect 127.0.0.1.
2. Specify an alternate loadbalancer (jbossesb-properties.xml), replacing: org.jboss.soa.esb.listeners.ha.RoundRobin. Perhaps the new load balancer can determine via JUDDI and the ESB JMS aware queue definition whether the queue is clustered or not. If so, it can filter out other services running on other nodes which are non-clustered.
3. Investigate using Registry Interceptor?
> ServiceInvokerspans multiple nodes when gateway and esb queue are both defined as non clustered
> -----------------------------------------------------------------------------------------------
>
> Key: JBESB-3959
> URL: https://issues.jboss.org/browse/JBESB-3959
> Project: JBoss ESB
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 4.11
> Environment: Linux
> Reporter: Dave Siracusa
>
> Messages are crossing server boundaries in a multi-server cluster even though queues are defined as non-clustered.
> Enqueuing a message only to the first server node is accepted by the first server, and is routed in round robin fashion to each server in the cluster.
> The reason for this is that during ESB deployment RegistryUtil.register(_config, _epr) is called when it resolves the epr via jmsEprFromElement.
> The jndi url is resolved via Configuration.getJndiServerURL(). This returns the hostname, so the registered EPR in JUUDI includes host specific EPR entries. The ServiceInvoker appears to route in round robin fashion to each registered entry. Inspecting our older/existing SOA 5.2.0 yields a jnp address which happen to reflect the -b (bind address) we specify (in our case 0.0.0.0).
> The registration process between SOA 5.2.0 and SOA 5.3.1 differ, where the default behavior in SOA 5.3.1 registration is to register services for use and available to all other node regardless of queue isolation settings and bind address.
> A combination of clustered and non-clustered queues will likely have problems.
--
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
10 years, 6 months
[JBoss JIRA] (JBESB-3959) ServiceInvokerspans multiple nodes when gateway and esb queue are both defined as non clustered
by Dave Siracusa (JIRA)
[ https://issues.jboss.org/browse/JBESB-3959?page=com.atlassian.jira.plugin... ]
Dave Siracusa updated JBESB-3959:
---------------------------------
Security: Public (was: JBoss Customer)
> ServiceInvokerspans multiple nodes when gateway and esb queue are both defined as non clustered
> -----------------------------------------------------------------------------------------------
>
> Key: JBESB-3959
> URL: https://issues.jboss.org/browse/JBESB-3959
> Project: JBoss ESB
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 4.11
> Environment: Linux
> Reporter: Dave Siracusa
>
> Messages are crossing server boundaries in a multi-server cluster even though queues are defined as non-clustered.
> Enqueuing a message only to the first server node is accepted by the first server, and is routed in round robin fashion to each server in the cluster.
> The reason for this is that during ESB deployment RegistryUtil.register(_config, _epr) is called when it resolves the epr via jmsEprFromElement.
> The jndi url is resolved via Configuration.getJndiServerURL(). This returns the hostname, so the registered EPR in JUUDI includes host specific EPR entries. The ServiceInvoker appears to route in round robin fashion to each registered entry. Inspecting our existing SOA 5.2.0 yields a jnp address which happen to reflect the -b (bind address) we specify (in our case 0.0.0.0).
> The registration process between SOA 5.2.0 and SOA 5.3.1 differ, where the default behavior in SOA 5.3.1 registration is to register services for use and available to all other node regardless of queue isolation settings.
> A possible partial workaround exists for environments which don't define any clustered queues. If you define a JNDI bind address at launch time to 127.0.0.1 calls will not be asynchronously delivered to all nodes in your cluster as the JNP address will reflect 127.0.0.1.
> A combination of clustered and non-clustered queues will likely have problems.
--
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
10 years, 6 months
[JBoss JIRA] (JBESB-3958) Please make DefaultJmsReplyToEpr more compatible with industry conventions for Messaging.
by Tom Cunningham (JIRA)
[ https://issues.jboss.org/browse/JBESB-3958?page=com.atlassian.jira.plugin... ]
Tom Cunningham closed JBESB-3958.
---------------------------------
> Please make DefaultJmsReplyToEpr more compatible with industry conventions for Messaging.
> -----------------------------------------------------------------------------------------
>
> Key: JBESB-3958
> URL: https://issues.jboss.org/browse/JBESB-3958
> Project: JBoss ESB
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Transports
> Affects Versions: 4.12
> Environment: All JBossESB.
> Reporter: Rick Wagner
> Assignee: Tom Cunningham
> Priority: Minor
> Fix For: 4.13
>
>
> org.jboss.internal.soa.esb.addressing.eprs.DefaultJmsReplyToEpr does not allow the user to choose a queue name that includes uppercase letters.
> The most widespread messaging system in the field is most often used with uppercase queue names. This forces administrators to break conventions for JBossESB.
> 1) The constructor needs to pass along JMS credentials to it's parent.
> 2) An option should be added so WSMQ users can comply with IBM queue naming standards (upper case names).
> These can be implemented with the following code snippets:
> >>> In the class declarations <<<
> private static final String ackMode = AcknowledgeMode.AUTO_ACKNOWLEDGE.toString();
> >>> Replace the 'short' constructor with this longer one <<<
> super(epr.getVersion(), epr.getDestinationType(), replyDestinationName(epr), epr.getConnectionFactory(), epr.getJndiEnvironment(), replySelector(epr), epr.getPersistent(), ackMode, epr.getJMSSecurityPrincipal(), epr.getJMSSecurityCredential());
> >>> Implement 'replyDestinationName' with conditional <<<
> private static String replyDestinationName(JMSEpr toEpr)
> throws URISyntaxException
> {
> if ("UPPERCASE" == System.getProperty("REPLY_TO_SUFFIX_CASE")){
> return new StringBuilder().append(toEpr.getDestinationName()).append("_REPLY").toString();
> }else{
> return new StringBuilder().append(toEpr.getDestinationName()).append("_reply").toString();
> }
> }
--
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
10 years, 6 months