Bug 777659 (SOA-169) - WebService consuming does not work - exception
Summary: WebService consuming does not work - exception
Keywords:
Status: CLOSED NOTABUG
Alias: SOA-169
Product: JBoss Enterprise SOA Platform 4
Classification: JBoss
Component: JBossWS
Version: 4.2 IR6
Hardware: Unspecified
OS: Unspecified
urgent
urgent
Target Milestone: ---
: 4.2 IR8
Assignee: Jiri Pechanec
QA Contact:
URL: http://jira.jboss.org/jira/browse/SOA...
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2007-11-22 08:47 UTC by Jiri Pechanec
Modified: 2007-11-26 20:47 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2007-11-25 16:01:01 UTC
Type: Bug


Attachments (Terms of Use)
test.log (47.47 KB, text/plain)
2007-11-22 11:08 UTC, Jiri Pechanec
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker SOA-169 0 None None None Never

Description Jiri Pechanec 2007-11-22 08:47:16 UTC
Date of First Response: 2007-11-22 06:34:02
project_key: SOA

When trying to consume Web Service, the follwoing exception is thrown 
java.lang.ClassCastException: java.lang.String 
        at org.jboss.soa.esb.actions.soap.SOAPClient.process(SOAPClient.java:321) 
        at org.jboss.soa.esb.listeners.message.ActionProcessingPipeline.process(ActionProcessingPipeline.java:273) 
        at org.jboss.soa.esb.listeners.message.MessageAwareListener$1.run(MessageAwareListener.java:303) 
        at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650) 
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675) 
        at java.lang.Thread.run(Thread.java:595)

Example is webservice_consumer quickstart

Comment 1 Jiri Pechanec 2007-11-22 08:47:52 UTC
Link: Added: This issue depends JBESB-1281


Comment 2 Jiri Pechanec 2007-11-22 08:48:51 UTC
Link: Added: This issue related SOA-84


Comment 3 Jiri Pechanec 2007-11-22 11:07:44 UTC
Sorry for confusement

The problem is still there
When params
<property name="paramsLocation" value="helloworld-request-parameters" />
<property name="responseLocation" value="helloworld-response" />

are used then the exception
java.lang.ClassCastException: java.lang.String
        at org.jboss.soa.esb.actions.soap.SOAPClient.process(SOAPClient.java:321)
        at org.jboss.soa.esb.listeners.message.ActionProcessingPipeline.process(ActionProcessingPipeline.java:316)
        at org.jboss.soa.esb.listeners.message.MessageAwareListener$1.run(MessageAwareListener.java:303)
        at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675)
        at java.lang.Thread.run(Thread.java:595)

is thrown

Moreover when the test client is invoked as a part of test suite then the deliverSync blocks indefinitely. The test then fails with timeout, prints the message WARN  [Thread-1][CourierFactory] Calling cleanup on existing couriers for identity ID-DEFAULT and hangs !!

The last lines in log are
2007-11-22 12:03:10,776 DEBUG [Thread-1][org.jboss.soa.esb.lifecycle.LifecycleResource] Cleaning up resource using factory: org.jboss.soa.esb.couriers.CourierFactory$LifecycleCourierFactory@16cd83d8 with identity ID-DEFAULT
2007-11-22 12:03:10,776 WARN  [Thread-1][org.jboss.soa.esb.couriers.CourierFactory] Calling cleanup on existing couriers for identity ID-DEFAULT
2007-11-22 12:03:10,784 DEBUG [Thread-1][org.jboss.soa.esb.couriers.CourierFactory] Courier allocation stacktrace
java.lang.Exception: Courier Assignment stacktrace
	at org.jboss.soa.esb.couriers.CourierFactory.registerCourier(CourierFactory.java:148)
	at org.jboss.soa.esb.couriers.CourierFactory.getCourier(CourierFactory.java:134)
	at org.jboss.soa.esb.couriers.CourierFactory.getMessageCourier(CourierFactory.java:96)
	at org.jboss.soa.esb.client.ServiceInvoker.getCourier(ServiceInvoker.java:338)
	at org.jboss.soa.esb.client.ServiceInvoker$EPRInvoker.attemptDelivery(ServiceInvoker.java:404)
	at org.jboss.soa.esb.client.ServiceInvoker$EPRInvoker.access$200(ServiceInvoker.java:370)
	at org.jboss.soa.esb.client.ServiceInvoker.post(ServiceInvoker.java:259)
	at org.jboss.soa.esb.client.ServiceInvoker.deliverSync(ServiceInvoker.java:155)
	at org.jboss.soa.esb.samples.quickstart.webservice_consumer1.WebServiceConsumerTest.postESBMessage(WebServiceConsumerTest.java:60)
	at org.jboss.soa.esb.samples.quickstart.webservice_consumer1.WebServiceConsumerTest.testWSConsumer(WebServiceConsumerTest.java:71)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:585)
	at org.testng.internal.MethodHelper.invokeMethod(MethodHelper.java:604)
	at org.testng.internal.InvokeMethodRunnable.run(InvokeMethodRunnable.java:36)
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:417)
	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:269)
	at java.util.concurrent.FutureTask.run(FutureTask.java:123)
	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675)
	at java.lang.Thread.run(Thread.java:595)

The whole log is attached



Comment 4 Jiri Pechanec 2007-11-22 11:08:02 UTC
Attachment: Added: test.log


Comment 5 Tom Fennelly 2007-11-22 11:34:02 UTC
Since 4.2.1, all ESB components are using the MessagePayloadProxy class to access the message payload (http://labs.jboss.org/jbossesb/docs/4.2.1GA/javadoc/esb/org/jboss/soa/esb/message/MessagePayloadProxy.html).  

So, you shouldn't define "paramsLocation" and "responseLocation" for the payload get and set locations for the action.  You shouldn't need to define anything at all, but if the input params are not in the default location you need to configure the "get-payload-location" property and if the response is not to be set back in the default location you need to set the "set-payload-location" property. 

Example of overriding default get/set location (*normally not required*):
<property name="get-payload-location" value="helloworld-request-parameters" />
<property name="set-payload-location" value="helloworld-response" />


Comment 6 Len DiMaggio 2007-11-26 20:47:11 UTC
Link: Removed: This issue related SOA-84 



Note You need to log in before you can comment on or make changes to this bug.