webservice_producer returns null result and a question about proper smooks and webservice_producer use ------------------------------------------------------------------------------------------------------ Key: JBESB-1205 URL: http://jira.jboss.com/jira/browse/JBESB-1205 Project: JBoss ESB Issue Type: Bug Security Level: Public(Everyone can see) Environment: Tested on both ESB Head as of 10/18/2007 and 4.2.0GA, using JBossWS 2.0.0 and JBossAS 4.2.1 on FedoraCore 6 and on Mac OS X. Reporter: James Williams Assigned To: Kevin Conner Attachments: startfrom-java.war, webservice_transformer.zip I created a simple quickstart to test a common WSDL and Java mismatch issue with webservices. WSDL centric development makes using JWS annotations very difficult if there is existing Java code. I want to use smooks + webservice_producer to fix this issue. The goal is to define a WSDL interface with disregard to the POJO backend. Then, use smooks to transform the SOAP payload to match the WSDL that JWS generates for the existing POJOs. I started with the webservice_producer quickstart. I stripped away the socket and JMS gateways and added a smooks transformation action. The transformation action modfies the SOAP payload so that it conforms the JWS generated WSDL. My transformation logic is really simplistic, but I have two outstanding issues with my approach. One has a workaround, the other problem is likely an ESB bug hence the JIRA ticket. The first issue is related to the smooks logic. I had to create a POJO placeholder and a smooks template because my WSDL has nested namespaces. I was unable to use a simple XSL snippet because the element that I need to change has a namespaced sub-element. The XSL parser chokes because the namespace of the sub-element isn't XSL recognizable. I don't think there is anyway around this issue by using an XSL resource type like the "XML2XML_simple" quickstart. But, I would like to know if there's a better, more elegant way to write smooks-res.xml tansformer logic. In particular, I want to ditch the POJO DTO. I suspect groovy is the best way to go, but I'm unsure of performance ramifications and the correct way to implement this type of transformer. The second issue is related to the http invocation. On jbossesb-4.2-GA, the http invoker returns prematurely. The transformation logic executes, then a transformed payload response is sent back to the http endpoint. Then the webservice executes using the transformed payload and returns the correct response. But, the http endpoint has already received it's response. I also tried esb-head and as of 10/18, a null response is returned. I also tested the webservice_producer quickstart and got the same null response. I suspect you are working on this code right now and might be fixing the issue I found, but I wanted to add a jira just in case. I would like to know if the smook-res.xml logic in my quickstart can be written in a more elegant fashion. Once, I resolve this issue on my end, the SA team will have a nice webservice_transformer quickstart and I will clean up the code, submit a jira request with the quickstart code and assign it to Kevin Conner.

webservice_producer returns null result and a question about proper smooks and webservice_producer use ------------------------------------------------------------------------------------------------------ Key: JBESB-1205 URL: http://jira.jboss.com/jira/browse/JBESB-1205 Project: JBoss ESB Issue Type: Bug Security Level: Public(Everyone can see) Components: Examples Affects Versions: 4.2 Environment: Tested on both ESB Head as of 10/18/2007 and 4.2.0GA, using JBossWS 2.0.0 and JBossAS 4.2.1 on FedoraCore 6 and on Mac OS X. Reporter: James Williams Assigned To: Tom Fennelly Fix For: 4.2.1 Attachments: startfrom-java.war, webservice_transformer.zip, webservice_transformer_v2.zip I created a simple quickstart to test a common WSDL and Java mismatch issue with webservices. WSDL centric development makes using JWS annotations very difficult if there is existing Java code. I want to use smooks + webservice_producer to fix this issue. The goal is to define a WSDL interface with disregard to the POJO backend. Then, use smooks to transform the SOAP payload to match the WSDL that JWS generates for the existing POJOs. I started with the webservice_producer quickstart. I stripped away the socket and JMS gateways and added a smooks transformation action. The transformation action modfies the SOAP payload so that it conforms the JWS generated WSDL. My transformation logic is really simplistic, but I have two outstanding issues with my approach. One has a workaround, the other problem is likely an ESB bug hence the JIRA ticket. The first issue is related to the smooks logic. I had to create a POJO placeholder and a smooks template because my WSDL has nested namespaces. I was unable to use a simple XSL snippet because the element that I need to change has a namespaced sub-element. The XSL parser chokes because the namespace of the sub-element isn't XSL recognizable. I don't think there is anyway around this issue by using an XSL resource type like the "XML2XML_simple" quickstart. But, I would like to know if there's a better, more elegant way to write smooks-res.xml tansformer logic. In particular, I want to ditch the POJO DTO. I suspect groovy is the best way to go, but I'm unsure of performance ramifications and the correct way to implement this type of transformer. The second issue is related to the http invocation. On jbossesb-4.2-GA, the http invoker returns prematurely. The transformation logic executes, then a transformed payload response is sent back to the http endpoint. Then the webservice executes using the transformed payload and returns the correct response. But, the http endpoint has already received it's response. I also tried esb-head and as of 10/18, a null response is returned. I also tested the webservice_producer quickstart and got the same null response. I suspect you are working on this code right now and might be fixing the issue I found, but I wanted to add a jira just in case. I would like to know if the smook-res.xml logic in my quickstart can be written in a more elegant fashion. Once, I resolve this issue on my end, the SA team will have a nice webservice_transformer quickstart and I will clean up the code, submit a jira request with the quickstart code and assign it to Kevin Conner.