[JBoss JIRA] (JBESB-3947) SoapUI SOAPClient doesn't pick up HttpClient properties if "wsdl" specifies local file ("file://...")
by Tadayoshi Sato (JIRA)
[ https://issues.jboss.org/browse/JBESB-3947?page=com.atlassian.jira.plugin... ]
Tadayoshi Sato reassigned JBESB-3947:
-------------------------------------
Assignee: Tadayoshi Sato
> SoapUI SOAPClient doesn't pick up HttpClient properties if "wsdl" specifies local file ("file://...")
> -----------------------------------------------------------------------------------------------------
>
> Key: JBESB-3947
> URL: https://issues.jboss.org/browse/JBESB-3947
> Project: JBoss ESB
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Web Services
> Affects Versions: 4.12
> Reporter: Tadayoshi Sato
> Assignee: Tadayoshi Sato
>
> In the soapUI version of {{SOAPClient}}, when hosting a WSDL locally (i.e. {{"file://...")}}, the Apache HttpClient which is used in {{SOAPClient}} does not pick up the proxy server settings:
> {code:xml}
> <action name="soapui-client-action" class="org.jboss.soa.esb.actions.soap.SOAPClient">
> <property name="wsdl" value="file:///opt/jboss-soa-p-5.3.1/jboss-as/samples/quickstarts/webservice_consumer1/HelloWorldWS.wsdl" />
> <property name="http-client-properties">
> <http-client-property name="http.proxyHost" value="192.168.0.101"/>
> <http-client-property name="http.proxyPort" value="18080"/>
> </property>
> ...
> </action>
> {code}
--
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, 7 months
[JBoss JIRA] (JBESB-3952) Performance regression with Bpm5Processor
by Tom Cunningham (JIRA)
[ https://issues.jboss.org/browse/JBESB-3952?page=com.atlassian.jira.plugin... ]
Tom Cunningham closed JBESB-3952.
---------------------------------
> Performance regression with Bpm5Processor
> -----------------------------------------
>
> Key: JBESB-3952
> URL: https://issues.jboss.org/browse/JBESB-3952
> Project: JBoss ESB
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Process flow
> Affects Versions: 4.11 CP3
> Reporter: Tom Cunningham
> Assignee: Tom Cunningham
> Fix For: 4.11 CP3
>
>
> From Martin Weiler :
> I did a quick test comparing the original code they used (based on the
> SOA-5.3.0 jBPM5 integration layer) with the new one (based on the
> SOA-5.3.1 jBPM5 integration layer).
> The main difference between the two codebases is the session utilization
> pattern. 5.3.0 uses a session-per-process-instance pattern, 5.3.1 uses a
> session-per-process-definition pattern.
> I did a test with a process that takes 4 sec to execute, using a JMS
> listener with 20 threads of executions.
> With the 5.3.0. code, it takes 90 sec to execute 380 process instances.
> With the 5.3.1 code, it takes 27 min to execute 380 process instances.
> The reason for this huge performance difference is simple: the 5.3.1
> uses only one session, and the this session is synchronized (thus
> single-threaded). So the benefit of using multiple threads of execution
> in the ESB is lost.
--
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, 7 months
[JBoss JIRA] (JBESB-3952) Performance regression with Bpm5Processor
by Tom Cunningham (JIRA)
[ https://issues.jboss.org/browse/JBESB-3952?page=com.atlassian.jira.plugin... ]
Tom Cunningham resolved JBESB-3952.
-----------------------------------
Resolution: Done
> Performance regression with Bpm5Processor
> -----------------------------------------
>
> Key: JBESB-3952
> URL: https://issues.jboss.org/browse/JBESB-3952
> Project: JBoss ESB
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Process flow
> Affects Versions: 4.11 CP3
> Reporter: Tom Cunningham
> Assignee: Tom Cunningham
> Fix For: 4.11 CP3
>
>
> From Martin Weiler :
> I did a quick test comparing the original code they used (based on the
> SOA-5.3.0 jBPM5 integration layer) with the new one (based on the
> SOA-5.3.1 jBPM5 integration layer).
> The main difference between the two codebases is the session utilization
> pattern. 5.3.0 uses a session-per-process-instance pattern, 5.3.1 uses a
> session-per-process-definition pattern.
> I did a test with a process that takes 4 sec to execute, using a JMS
> listener with 20 threads of executions.
> With the 5.3.0. code, it takes 90 sec to execute 380 process instances.
> With the 5.3.1 code, it takes 27 min to execute 380 process instances.
> The reason for this huge performance difference is simple: the 5.3.1
> uses only one session, and the this session is synchronized (thus
> single-threaded). So the benefit of using multiple threads of execution
> in the ESB is lost.
--
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, 7 months
[JBoss JIRA] (JBESB-3952) Performance regression with Bpm5Processor
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/JBESB-3952?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration updated JBESB-3952:
-------------------------------------------
Bugzilla Update: Perform
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=981291
> Performance regression with Bpm5Processor
> -----------------------------------------
>
> Key: JBESB-3952
> URL: https://issues.jboss.org/browse/JBESB-3952
> Project: JBoss ESB
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Process flow
> Affects Versions: 4.11 CP3
> Reporter: Tom Cunningham
> Assignee: Tom Cunningham
> Fix For: 4.11 CP3
>
>
> From Martin Weiler :
> I did a quick test comparing the original code they used (based on the
> SOA-5.3.0 jBPM5 integration layer) with the new one (based on the
> SOA-5.3.1 jBPM5 integration layer).
> The main difference between the two codebases is the session utilization
> pattern. 5.3.0 uses a session-per-process-instance pattern, 5.3.1 uses a
> session-per-process-definition pattern.
> I did a test with a process that takes 4 sec to execute, using a JMS
> listener with 20 threads of executions.
> With the 5.3.0. code, it takes 90 sec to execute 380 process instances.
> With the 5.3.1 code, it takes 27 min to execute 380 process instances.
> The reason for this huge performance difference is simple: the 5.3.1
> uses only one session, and the this session is synchronized (thus
> single-threaded). So the benefit of using multiple threads of execution
> in the ESB is lost.
--
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, 7 months
[JBoss JIRA] (JBESB-3952) Performance regression with Bpm5Processor
by Tom Cunningham (JIRA)
Tom Cunningham created JBESB-3952:
-------------------------------------
Summary: Performance regression with Bpm5Processor
Key: JBESB-3952
URL: https://issues.jboss.org/browse/JBESB-3952
Project: JBoss ESB
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Process flow
Affects Versions: 4.11 CP3
Reporter: Tom Cunningham
Assignee: Tom Cunningham
Fix For: 4.11 CP3
>From Martin Weiler :
I did a quick test comparing the original code they used (based on the
SOA-5.3.0 jBPM5 integration layer) with the new one (based on the
SOA-5.3.1 jBPM5 integration layer).
The main difference between the two codebases is the session utilization
pattern. 5.3.0 uses a session-per-process-instance pattern, 5.3.1 uses a
session-per-process-definition pattern.
I did a test with a process that takes 4 sec to execute, using a JMS
listener with 20 threads of executions.
With the 5.3.0. code, it takes 90 sec to execute 380 process instances.
With the 5.3.1 code, it takes 27 min to execute 380 process instances.
The reason for this huge performance difference is simple: the 5.3.1
uses only one session, and the this session is synchronized (thus
single-threaded). So the benefit of using multiple threads of execution
in the ESB is lost.
--
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, 7 months
[JBoss JIRA] (JBESB-3951) Please make DefaultJmsReplyToEpr more compatible with industry conventions for Messaging.
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/JBESB-3951?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration updated JBESB-3951:
-------------------------------------------
Bugzilla Update: Perform
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=998537
> Please make DefaultJmsReplyToEpr more compatible with industry conventions for Messaging.
> -----------------------------------------------------------------------------------------
>
> Key: JBESB-3951
> URL: https://issues.jboss.org/browse/JBESB-3951
> 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
> Priority: Minor
>
> 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, 7 months
[JBoss JIRA] (JBESB-3951) Please make DefaultJmsReplyToEpr more compatible with industry conventions for Messaging.
by Rick Wagner (JIRA)
Rick Wagner created JBESB-3951:
----------------------------------
Summary: Please make DefaultJmsReplyToEpr more compatible with industry conventions for Messaging.
Key: JBESB-3951
URL: https://issues.jboss.org/browse/JBESB-3951
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
Priority: Minor
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, 7 months
[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:
------------------------------------------------
tcunning(a)redhat.com changed the Status of [bug 998677|https://bugzilla.redhat.com/show_bug.cgi?id=998677] from NEW to MODIFIED
> 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, 8 months
[JBoss JIRA] (JBESB-3950) SOAPClient generates empty objects for not-required fields
by Tom Cunningham (JIRA)
[ https://issues.jboss.org/browse/JBESB-3950?page=com.atlassian.jira.plugin... ]
Tom Cunningham closed JBESB-3950.
---------------------------------
> 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, 8 months
[JBoss JIRA] (JBESB-3950) SOAPClient generates empty objects for not-required fields
by Tom Cunningham (JIRA)
[ https://issues.jboss.org/browse/JBESB-3950?page=com.atlassian.jira.plugin... ]
Tom Cunningham resolved JBESB-3950.
-----------------------------------
Resolution: Done
> 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, 8 months