December 2012 - esb-issues - Jboss List Archives

[JBoss JIRA] (JBESB-3707) Cached resource creation is not synchronized in SOAPUIClientService

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JBESB-3707?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on JBESB-3707: ------------------------------------------------ Julian Coleman <jcoleman(a)redhat.com> changed the Status of [bug 781074|https://bugzilla.redhat.com/show_bug.cgi?id=781074] from NEW to MODIFIED > Cached resource creation is not synchronized in SOAPUIClientService > ------------------------------------------------------------------- > > Key: JBESB-3707 > URL: https://issues.jboss.org/browse/JBESB-3707 > Project: JBoss ESB > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Web Services > Affects Versions: 4.10 > Reporter: Magesh Bojan > Assignee: Magesh Bojan > Fix For: 5.0 initial development > > > Wsdl and Smooks Resource cache creation are not synchronized and hence could lead to a race condition when the same resource is being created by multiple threads. > Fix is to synchronize the cached resource creation. -- 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

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JBESB-3884) jruby.jar as shipped with JBoss ESB exposes CVE-2012-5370

by David Jorm (JIRA)

[ https://issues.jboss.org/browse/JBESB-3884?page=com.atlassian.jira.plugin... ] David Jorm updated JBESB-3884: ------------------------------ Affects Version/s: 4.11 > jruby.jar as shipped with JBoss ESB exposes CVE-2012-5370 > --------------------------------------------------------- > > Key: JBESB-3884 > URL: https://issues.jboss.org/browse/JBESB-3884 > Project: JBoss ESB > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 4.11 > Reporter: David Jorm > Assignee: Tom Cunningham > > jruby.jar as shipped with JBoss ESB exposes CVE-2012-5370. We are shipping JRuby 1.6.5.1. The upstream Ruby language has replaced the vulnerable Murmur hash function / algorithm implementation with the SipHash-2-4 implementation: > http://www.ruby-lang.org/en/news/2012/11/09/ruby19-hashdos-cve-2012-5371/ > An upstream fix is not yet available for JRuby. Once an upstream fix is available, we should incorporate it into a future release via a component upgrade. -- 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

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JBESB-3862) AbstractBpm5Action is registering handlers too freely

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JBESB-3862?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on JBESB-3862: ------------------------------------------------ Rick Wagner <rwagner(a)redhat.com> made a comment on [bug 876280|https://bugzilla.redhat.com/show_bug.cgi?id=876280] Removing this BZ from 5.3 Roll up 2. BZ 850891 tracks this issue into SOA-P 5.3.1. (We need to provide it there.) This change made to allow Roll up 2 to proceed back to QE, without waiting on this BZ. Thanks, Rick > AbstractBpm5Action is registering handlers too freely > ----------------------------------------------------- > > Key: JBESB-3862 > URL: https://issues.jboss.org/browse/JBESB-3862 > 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 CP1 > > > Explanation from Rick Wagner's BZ : > AbstractBpm5Action is doing some handler registration for *each* process instance start and service callback: > .... > ksession.getWorkItemManager().registerWorkItemHandler("JBossESB", esbhandler); > ksession.getWorkItemManager().registerWorkItemHandler("ESBAction", actionhandler); > ksession.getWorkItemManager().registerWorkItemHandler("Human Task", khandler); > 'khandler' in particular is an instance of CommandBasedHornetQWSHumanTaskHandler by default. > So when the user goes to close a task, all those handlers fire (JPA trips up, too): > 012-08-22 12:32:06,006 INFO [STDOUT] (Thread-32) Notification of completed task 132 > 2012-08-22 12:32:06,017 INFO [STDOUT] (Thread-34) Notification of completed task 132 > 2012-08-22 12:32:06,025 INFO [STDOUT] (Thread-35) Notification of completed task 132 > 2012-08-22 12:32:06,033 INFO [STDOUT] (Thread-36) Notification of completed task 132 > 2012-08-22 12:32:06,042 INFO [STDOUT] (Thread-37) Notification of completed task 132 > 2012-08-22 12:32:06,049 INFO [STDOUT] (Thread-37) Notification of completed task 132 > 2012-08-22 12:32:06,056 INFO [STDOUT] (Thread-38) Notification of completed task 132 > 2012-08-22 12:32:06,063 INFO [STDOUT] (Thread-39) Notification of completed task 132 > 2012-08-22 12:32:06,069 INFO [STDOUT] (Thread-40) Notification of completed task 132 > 2012-08-22 12:32:06,076 INFO [STDOUT] (Thread-41) Notification of completed task 132 > 2012-08-22 12:32:06,082 INFO [STDOUT] (Thread-41) Notification of completed task 132 > 2012-08-22 12:32:05,985 INFO [STDOUT] (Thread-31) Notification of completed task 132 > 2012-08-22 12:32:05,998 ERROR [org.hibernate.event.def.AbstractFlushingEventListener] (Thread-31) Could not synchronize database state with session > org.hibernate.StaleObjectStateException: Row was updated or deleted by another transaction (or unsaved-value mapping was incorrect): [org.jbpm.persistence.processinstance.ProcessInstanceInfo#44] > at org.hibernate.persister.entity.AbstractEntityPersister.check(AbstractEntityPersister.java:1782) > ....... > at org.jbpm.task.service.hornetq.CommandBasedHornetQWSHumanTaskHandler$GetCompletedTaskResponseHandler.execute(CommandBasedHornetQWSHumanTaskHandler.java:273) -- 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

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBESB-3862) AbstractBpm5Action is registering handlers too freely

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JBESB-3862?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on JBESB-3862: ------------------------------------------------ Rick Wagner <rwagner(a)redhat.com> changed the Status of [bug 881925|https://bugzilla.redhat.com/show_bug.cgi?id=881925] from ON_QA to CLOSED > AbstractBpm5Action is registering handlers too freely > ----------------------------------------------------- > > Key: JBESB-3862 > URL: https://issues.jboss.org/browse/JBESB-3862 > 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 CP1 > > > Explanation from Rick Wagner's BZ : > AbstractBpm5Action is doing some handler registration for *each* process instance start and service callback: > .... > ksession.getWorkItemManager().registerWorkItemHandler("JBossESB", esbhandler); > ksession.getWorkItemManager().registerWorkItemHandler("ESBAction", actionhandler); > ksession.getWorkItemManager().registerWorkItemHandler("Human Task", khandler); > 'khandler' in particular is an instance of CommandBasedHornetQWSHumanTaskHandler by default. > So when the user goes to close a task, all those handlers fire (JPA trips up, too): > 012-08-22 12:32:06,006 INFO [STDOUT] (Thread-32) Notification of completed task 132 > 2012-08-22 12:32:06,017 INFO [STDOUT] (Thread-34) Notification of completed task 132 > 2012-08-22 12:32:06,025 INFO [STDOUT] (Thread-35) Notification of completed task 132 > 2012-08-22 12:32:06,033 INFO [STDOUT] (Thread-36) Notification of completed task 132 > 2012-08-22 12:32:06,042 INFO [STDOUT] (Thread-37) Notification of completed task 132 > 2012-08-22 12:32:06,049 INFO [STDOUT] (Thread-37) Notification of completed task 132 > 2012-08-22 12:32:06,056 INFO [STDOUT] (Thread-38) Notification of completed task 132 > 2012-08-22 12:32:06,063 INFO [STDOUT] (Thread-39) Notification of completed task 132 > 2012-08-22 12:32:06,069 INFO [STDOUT] (Thread-40) Notification of completed task 132 > 2012-08-22 12:32:06,076 INFO [STDOUT] (Thread-41) Notification of completed task 132 > 2012-08-22 12:32:06,082 INFO [STDOUT] (Thread-41) Notification of completed task 132 > 2012-08-22 12:32:05,985 INFO [STDOUT] (Thread-31) Notification of completed task 132 > 2012-08-22 12:32:05,998 ERROR [org.hibernate.event.def.AbstractFlushingEventListener] (Thread-31) Could not synchronize database state with session > org.hibernate.StaleObjectStateException: Row was updated or deleted by another transaction (or unsaved-value mapping was incorrect): [org.jbpm.persistence.processinstance.ProcessInstanceInfo#44] > at org.hibernate.persister.entity.AbstractEntityPersister.check(AbstractEntityPersister.java:1782) > ....... > at org.jbpm.task.service.hornetq.CommandBasedHornetQWSHumanTaskHandler$GetCompletedTaskResponseHandler.execute(CommandBasedHornetQWSHumanTaskHandler.java:273) -- 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

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBESB-3862) AbstractBpm5Action is registering handlers too freely

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JBESB-3862?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on JBESB-3862: ------------------------------------------------ Rick Wagner <rwagner(a)redhat.com> made a comment on [bug 881925|https://bugzilla.redhat.com/show_bug.cgi?id=881925] > AbstractBpm5Action is registering handlers too freely > ----------------------------------------------------- > > Key: JBESB-3862 > URL: https://issues.jboss.org/browse/JBESB-3862 > 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 CP1 > > > Explanation from Rick Wagner's BZ : > AbstractBpm5Action is doing some handler registration for *each* process instance start and service callback: > .... > ksession.getWorkItemManager().registerWorkItemHandler("JBossESB", esbhandler); > ksession.getWorkItemManager().registerWorkItemHandler("ESBAction", actionhandler); > ksession.getWorkItemManager().registerWorkItemHandler("Human Task", khandler); > 'khandler' in particular is an instance of CommandBasedHornetQWSHumanTaskHandler by default. > So when the user goes to close a task, all those handlers fire (JPA trips up, too): > 012-08-22 12:32:06,006 INFO [STDOUT] (Thread-32) Notification of completed task 132 > 2012-08-22 12:32:06,017 INFO [STDOUT] (Thread-34) Notification of completed task 132 > 2012-08-22 12:32:06,025 INFO [STDOUT] (Thread-35) Notification of completed task 132 > 2012-08-22 12:32:06,033 INFO [STDOUT] (Thread-36) Notification of completed task 132 > 2012-08-22 12:32:06,042 INFO [STDOUT] (Thread-37) Notification of completed task 132 > 2012-08-22 12:32:06,049 INFO [STDOUT] (Thread-37) Notification of completed task 132 > 2012-08-22 12:32:06,056 INFO [STDOUT] (Thread-38) Notification of completed task 132 > 2012-08-22 12:32:06,063 INFO [STDOUT] (Thread-39) Notification of completed task 132 > 2012-08-22 12:32:06,069 INFO [STDOUT] (Thread-40) Notification of completed task 132 > 2012-08-22 12:32:06,076 INFO [STDOUT] (Thread-41) Notification of completed task 132 > 2012-08-22 12:32:06,082 INFO [STDOUT] (Thread-41) Notification of completed task 132 > 2012-08-22 12:32:05,985 INFO [STDOUT] (Thread-31) Notification of completed task 132 > 2012-08-22 12:32:05,998 ERROR [org.hibernate.event.def.AbstractFlushingEventListener] (Thread-31) Could not synchronize database state with session > org.hibernate.StaleObjectStateException: Row was updated or deleted by another transaction (or unsaved-value mapping was incorrect): [org.jbpm.persistence.processinstance.ProcessInstanceInfo#44] > at org.hibernate.persister.entity.AbstractEntityPersister.check(AbstractEntityPersister.java:1782) > ....... > at org.jbpm.task.service.hornetq.CommandBasedHornetQWSHumanTaskHandler$GetCompletedTaskResponseHandler.execute(CommandBasedHornetQWSHumanTaskHandler.java:273) -- 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

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBESB-3862) AbstractBpm5Action is registering handlers too freely

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JBESB-3862?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on JBESB-3862: ------------------------------------------------ Rick Wagner <rwagner(a)redhat.com> made a comment on [bug 850891|https://bugzilla.redhat.com/show_bug.cgi?id=850891] > AbstractBpm5Action is registering handlers too freely > ----------------------------------------------------- > > Key: JBESB-3862 > URL: https://issues.jboss.org/browse/JBESB-3862 > 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 CP1 > > > Explanation from Rick Wagner's BZ : > AbstractBpm5Action is doing some handler registration for *each* process instance start and service callback: > .... > ksession.getWorkItemManager().registerWorkItemHandler("JBossESB", esbhandler); > ksession.getWorkItemManager().registerWorkItemHandler("ESBAction", actionhandler); > ksession.getWorkItemManager().registerWorkItemHandler("Human Task", khandler); > 'khandler' in particular is an instance of CommandBasedHornetQWSHumanTaskHandler by default. > So when the user goes to close a task, all those handlers fire (JPA trips up, too): > 012-08-22 12:32:06,006 INFO [STDOUT] (Thread-32) Notification of completed task 132 > 2012-08-22 12:32:06,017 INFO [STDOUT] (Thread-34) Notification of completed task 132 > 2012-08-22 12:32:06,025 INFO [STDOUT] (Thread-35) Notification of completed task 132 > 2012-08-22 12:32:06,033 INFO [STDOUT] (Thread-36) Notification of completed task 132 > 2012-08-22 12:32:06,042 INFO [STDOUT] (Thread-37) Notification of completed task 132 > 2012-08-22 12:32:06,049 INFO [STDOUT] (Thread-37) Notification of completed task 132 > 2012-08-22 12:32:06,056 INFO [STDOUT] (Thread-38) Notification of completed task 132 > 2012-08-22 12:32:06,063 INFO [STDOUT] (Thread-39) Notification of completed task 132 > 2012-08-22 12:32:06,069 INFO [STDOUT] (Thread-40) Notification of completed task 132 > 2012-08-22 12:32:06,076 INFO [STDOUT] (Thread-41) Notification of completed task 132 > 2012-08-22 12:32:06,082 INFO [STDOUT] (Thread-41) Notification of completed task 132 > 2012-08-22 12:32:05,985 INFO [STDOUT] (Thread-31) Notification of completed task 132 > 2012-08-22 12:32:05,998 ERROR [org.hibernate.event.def.AbstractFlushingEventListener] (Thread-31) Could not synchronize database state with session > org.hibernate.StaleObjectStateException: Row was updated or deleted by another transaction (or unsaved-value mapping was incorrect): [org.jbpm.persistence.processinstance.ProcessInstanceInfo#44] > at org.hibernate.persister.entity.AbstractEntityPersister.check(AbstractEntityPersister.java:1782) > ....... > at org.jbpm.task.service.hornetq.CommandBasedHornetQWSHumanTaskHandler$GetCompletedTaskResponseHandler.execute(CommandBasedHornetQWSHumanTaskHandler.java:273) -- 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

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBESB-3772) SyncServiceInvoker does not reset ReplyTo and FaultTo EPR when deliverSync is succesful

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JBESB-3772?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on JBESB-3772: ------------------------------------------------ Robert Balent <rbalent(a)redhat.com> made a comment on [bug 881919|https://bugzilla.redhat.com/show_bug.cgi?id=881919] Verified in SOA-P 5.3.1 ER1 > SyncServiceInvoker does not reset ReplyTo and FaultTo EPR when deliverSync is succesful > --------------------------------------------------------------------------------------- > > Key: JBESB-3772 > URL: https://issues.jboss.org/browse/JBESB-3772 > Project: JBoss ESB > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Rosetta > Affects Versions: 4.10, 4.10 CP1, 4.11 > Environment: Fedora 16 x86_64, JBoss SOA-P 5.2.0, HornetQ TechPreview, > Reporter: Duncan Doyle > Assignee: Tadayoshi Sato > Labels: esb > Fix For: 4.11 CP2 > > > I have a number of chained async, one-way services, which all use transacted JCA (with HornetQ tech preview). I set a generic "FaultTo" EPR in a custom composer-class set on the FS-Provider of the first service (entry point into the ESB), with the intention that, if any of async, one-way services fail, the Fault Message will be sent to my FaultService. > One of my one-way services uses a SyncServiceInvoker to do a request-response call, in the middle of its action pipeline to a synchronous request-response service for message validation. The result is then used in the same pipeline to do some CBR. The problem is that, when I pass the message to the SyncServiceInvoker (which is configured to suspend the transaction), the ReplyTo and FaultTo headers get set to 'null' (as expected, as the synchronous request-response service needs to pass its reply and fault message to the caller), however, these ReplyTo and FaultTo headers never get set back to their original value if the call succeeds. In the exception flow of SyncServiceInvoker, the ReplyTo and FaultTo do get reset to their original value (with the remark that this is not actually necessary, which is wrong). So, when my CBR routes the message to the next service, the ReplyTo and FaultTo headers are null, implying that the async, one-way services will not sent a possible Fault Message to the FaultService. > In my opinion, resetting the ReplyTo and FaultTo headers needs to be done in the 'finally' block, not the 'catch' block. -- 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

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBESB-3796) Exception handling after SyncServiceInvoker fails

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JBESB-3796?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on JBESB-3796: ------------------------------------------------ Robert Balent <rbalent(a)redhat.com> made a comment on [bug 881857|https://bugzilla.redhat.com/show_bug.cgi?id=881857] Verified in SOA-P 5.3.1 ER1 > Exception handling after SyncServiceInvoker fails > ------------------------------------------------- > > Key: JBESB-3796 > URL: https://issues.jboss.org/browse/JBESB-3796 > Project: JBoss ESB > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Rosetta > Affects Versions: 4.10, 4.11 > Environment: SOA Platform 5.2.0 > Reporter: Jason Shepherd > Assignee: Tadayoshi Sato > Fix For: 4.11 CP2 > > Attachments: BZ820031.patch, SupportCase00634223.zip > > > I have an EBWS based service which is using the SyncServiceInvoker to call a second service. This all works fine but if I throw an exception after the SyncServiceInvoker call the exception is not propagated to the client as a soap fault. > However if I remove the invocation of the SyncServiceInvoker and throw an exception, a soap fault is sent to the client. > I have attached a test project which demonstrates this. > To see the fault just comment out the SyncServiceInvoker call. -- 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

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBESB-3796) Exception handling after SyncServiceInvoker fails

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JBESB-3796?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on JBESB-3796: ------------------------------------------------ Robert Balent <rbalent(a)redhat.com> changed the Status of [bug 881857|https://bugzilla.redhat.com/show_bug.cgi?id=881857] from ON_QA to VERIFIED > Exception handling after SyncServiceInvoker fails > ------------------------------------------------- > > Key: JBESB-3796 > URL: https://issues.jboss.org/browse/JBESB-3796 > Project: JBoss ESB > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Rosetta > Affects Versions: 4.10, 4.11 > Environment: SOA Platform 5.2.0 > Reporter: Jason Shepherd > Assignee: Tadayoshi Sato > Fix For: 4.11 CP2 > > Attachments: BZ820031.patch, SupportCase00634223.zip > > > I have an EBWS based service which is using the SyncServiceInvoker to call a second service. This all works fine but if I throw an exception after the SyncServiceInvoker call the exception is not propagated to the client as a soap fault. > However if I remove the invocation of the SyncServiceInvoker and throw an exception, a soap fault is sent to the client. > I have attached a test project which demonstrates this. > To see the fault just comment out the SyncServiceInvoker call. -- 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

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBESB-3838) Http Provider returns 200 http response code for Soap Fault

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JBESB-3838?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on JBESB-3838: ------------------------------------------------ Lucie Fabrikova <lfabriko(a)redhat.com> made a comment on [bug 881861|https://bugzilla.redhat.com/show_bug.cgi?id=881861] Verified in SOA-P 5.3.1 ER1. > Http Provider returns 200 http response code for Soap Fault > ----------------------------------------------------------- > > Key: JBESB-3838 > URL: https://issues.jboss.org/browse/JBESB-3838 > Project: JBoss ESB > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Web Services > Affects Versions: 4.10, 4.11 > Environment: SOA-P 5.2.0 > CXF WS stack > Reporter: Jason Shepherd > Assignee: Magesh Bojan > Fix For: 4.11 CP1 > > Attachments: JBESB-3838.patch, jbossesb-soap.jar, webservice_producer.zip > > > When a pipeline includes a SOAPProcessor action which calls a Web Service, if the wrapped web service returns a soap fault, and HTTP response code 500, the HTTP Provider Gateway returns a response code 200 to an ESB Client, instead of the expected 500 response. > This seems contrary to the WS-I 1.0 Basic Profile specification, and breaks some Spring WS Clients. > This issue does not happen with a JBR-Provider using the HTTP protocol. The expected 500 response code is returned by it. > You can use the attached project to reproduce the issue. > 1. Replace the 'webservice_producer' quickstart in SOA-P 5.2 samples/quickstart directory with the one attached. > 2. Run 'ant clean deploy' to deploy it to a running instance > 3. Run 'ant runtest' to send a WS Request to the HTTP Provider gateway. > When I hit the GoodbyeWorldWS directly with SOAPUI I can see that I get a 500 HTTP response code. However in the output of the test, I can see the response of the HTTP Provider was 200: > runtest: > [echo] Http Client > [java] Request payload: > [java] <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:good="http://webservice_producer/goodbyeworld"> > [java] <soapenv:Header/> > [java] <soapenv:Body> > [java] <good:sayGoodbye> > [java] <message>goodbye</message> > [java] </good:sayGoodbye> > [java] </soapenv:Body> > [java] </soapenv:Envelope> > [java] -------------------------- > [java] > [java] 16:30:38,927 DEBUG [main][header] >> "POST /Quickstart_webservice_producer/http/test/x HTTP/1.1[\r][\n]" > [java] 16:30:38,970 DEBUG [main][header] >> "Content-Type: text/xml;charset=UTF-8[\r][\n]" > [java] 16:30:38,973 DEBUG [main][header] >> "User-Agent: Jakarta Commons-HttpClient/3.1[\r][\n]" > [java] 16:30:38,973 DEBUG [main][header] >> "Host: localhost:8080[\r][\n]" > [java] 16:30:38,973 DEBUG [main][header] >> "Content-Length: 292[\r][\n]" > [java] 16:30:38,973 DEBUG [main][header] >> "[\r][\n]" > [java] 16:30:38,973 DEBUG [main][content] >> "<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:good="http://webservice_producer/goodbyeworld">[\n]" > [java] 16:30:38,973 DEBUG [main][content] >> " <soapenv:Header/>[\n]" > [java] 16:30:38,973 DEBUG [main][content] >> " <soapenv:Body>[\n]" > [java] 16:30:38,973 DEBUG [main][content] >> " <good:sayGoodbye>[\n]" > [java] 16:30:38,973 DEBUG [main][content] >> " <message>goodbye</message>[\n]" > [java] 16:30:38,974 DEBUG [main][content] >> " </good:sayGoodbye>[\n]" > [java] 16:30:38,974 DEBUG [main][content] >> " </soapenv:Body>[\n]" > [java] 16:30:38,974 DEBUG [main][content] >> "</soapenv:Envelope>" > [java] 16:30:39,265 DEBUG [main][header] << "HTTP/1.1 200 OK[\r][\n]" > [java] 16:30:39,266 DEBUG [main][header] << "HTTP/1.1 200 OK[\r][\n]" > [java] 16:30:39,267 DEBUG [main][header] << "Server: Apache-Coyote/1.1[\r][\n]" > [java] 16:30:39,267 DEBUG [main][header] << "X-Powered-By: Servlet 2.5; JBoss-5.0/JBossWeb-2.1[\r][\n]" > [java] 16:30:39,267 DEBUG [main][header] << "asyncServiceInvoke: false[\r][\n]" > [java] 16:30:39,267 DEBUG [main][header] << "Content-Length: 298[\r][\n]" > [java] 16:30:39,268 DEBUG [main][header] << "Date: Mon, 30 Jul 2012 06:30:39 GMT[\r][\n]" > [java] 16:30:39,268 DEBUG [main][header] << "[\r][\n]" > [java] 16:30:39,273 DEBUG [main][content] << "<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"><soap:Body><soap:Fault><faultcode>soap:Server</faultcode><faultstring>app exception!</faultstring><detail><ns1:AppException xmlns:ns1="http://webservice_producer/goodbyeworld" /></detail" > [java] 16:30:39,273 DEBUG [main][content] << "></soap:Fault></soap:Body></soap:Envelope>" > [java] > [java] Response Status Code: 200 > [java] Response payload: > [java] <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"><soap:Body><soap:Fault><faultcode>soap:Server</faultcode><faultstring>app exception!</faultstring><detail><ns1:AppException xmlns:ns1="http://webservice_producer/goodbyeworld" /></detail></soap:Fault></soap:Body></soap:Envelope> > [java] -------------------------- > [java] -- 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

11 years, 5 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

esb-issues December 2012