Hi, I have just submitted a patch for a fix in this area and I was getting the same result as you. The body of the message that was been sent from the cxfbc:provider was null.
Freeman is in the process of applying my patches for a fix and testcase. I suggest you wait for these fixes and rebuild or download the next snapshot. The issue is https://issues.apache.org/activemq/browse/SM-1304 if you want to apply the patches. Edell. On 4/8/08, Ivanhoe Abrahams <[EMAIL PROTECTED]> wrote: > > Hi Freeman > > I figured out the reason why I was getting the strange behaviour, it was > because I configured a jms consumer as well which had the same > jmsProviderDestinationName as the provider. > That said I am still no closer to getting this simple test to work. > > I have changed the jms provider attribute back to soap="true", since it is > a > soap message that I am testing. > I am not getting errors but only an empty Soap envelope/body. > > Belowis the eventual response I receive in SoapUI > <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> > <soap:Body/> > </soap:Envelope> > > The following is the hard-coded message I send from the test standalone > ActiveMQ app. > String soapResponse = > "<?xml version='1.0' encoding='UTF-8'?>" + > "\n<soap:Envelope xmlns:soap=\" > http://schemas.xmlsoap.org/soap/envelope/\">\n" + > "<soap:Body>\n" + > " <GetPersonResponse xmlns=\" > http://servicemix.apache.org/cxf-jms/types\">\n" + > " <personId>1</personId>\n" + > " <ssn>000-000-0000</ssn>\n" + > " <name>Guillaume</name>\n" + > " </GetPersonResponse>\n" + > "</soap:Body>\n" + > "</soap:Envelope>\n"; > > It seems the as the above message comes back into the JmsProvider the > SoapReader reads the response but strips out the Envelope/body, so by the > time the message reaches the CXF JbiOutWsdl1Interceptor, the following > piece > of code writes out nothing > > if (!useJBIWrapper) { > SoapVersion soapVersion = message.getVersion(); > if (element != null) { > element = (Element) element.getElementsByTagNameNS( > element.getNamespaceURI(), > soapVersion.getBody().getLocalPart()).item(0); > if (element != null) { > > ///////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////// > THIS VALUE IS THEN NULL > > SO NOTHING GETS WRITTEN IN THE BELOW LINE > > StaxUtils.writeElement((Element)element.getFirstChild(), xmlWriter, > false); > } > } > return; > } > > > So, still struggling, I just hope someone can point out my mistake. or > forward me a simple SA to show me how to send a soap message from > ...External SOAP Client <-> CXF BC <-> JMS BC <-> External JMS > > Thank you in advance > > Ivanhoe > > > On Tue, Apr 8, 2008 at 2:51 PM, Freeman Fang <[EMAIL PROTECTED]> > wrote: > > > Hi Ivanhnoe, > > > > Not sure why only the first invocation failed, if you can dump the soap > > message, it would be helpful. > > About the build issue, yes, 3.3 snapshot need jaxb-api 2.1, so if you > are > > using some early version of jdk 16(which is shipped with jaxb-api 20), > you > > will see the class conflict problem. Make sure you build snapshot 3.3 > with > > jdk 1.5. > > And I recommand that currently you should try with 3.2.2 snapshot, which > > will be release very soon. > > Best Regards > > > > Freeman > > > > > > Ivanhoe Abrahams wrote: > > > > > Hi Freeman > > > > > > Thank you for your response, I tried this on servicemix 3.2.1 but the > > > useJBIWrapper attribute is not available there, so I checked out the > > > latestversion from svn, which is servicemix 3.3. > > > I am now receiving a soap message on the SoapUI client but the body > was > > > empty. > > > > > > The message looked like this > > > <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> > > > <soap:Body/> > > > </soap:Envelope> > > > > > > After some debugging I found that by the time the message reached the > > > CXF > > > binding component (on the way back from the JMS component)the soap > > > envelope/body had already been removed (only the XSD defined message > > > remained), so I changed the soap attribute on the JMS Binding > component > > > to > > > "false".. > > > > > > NOW I have really strange behaviour. When I start servicemix and try > > > out my > > > sa, the first time it fails with the following message > > > <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> > > > <soap:Body> > > > <soap:Fault> > > > <faultcode>soap:Server</faultcode> > > > <faultstring>org.apache.xerces.dom.DeferredTextImpl cannot be > > > cast > > > to org.w3c.dom.Element</faultstring> > > > </soap:Fault> > > > </soap:Body> > > > </soap:Envelope> > > > > > > BUT thereafter, If I try it a gain, it works just as I expect. The > above > > > error only happens on the very first try. > > > Also on this first try the message that reaches the JMS standalone > test > > > app > > > is different than the other messages that work. > > > On the first try it contains a soap envelope/body but on subsequent > > > calls it > > > only contains only the XSD defined message. > > > > > > This is really confusing. > > > > > > By the way, I had a couple of problems building servicemix 3.3 > > > specifically > > > the JAXB-API which now depends on JAXB-API 2.1 > > > So, maybe servicemix 3.3 is not stable enough yet????. > > > I am now downloading the servicemix 3.2.2 binary to see if that helps. > > > > > > So to recap, all I am trying to do is send a soap message from SoapUI > > > <-> > > > ServicemixCXF-BC <-> ServiceMixJMS-BC <-> ActiveMQ Test App > > > > > > If you have any other suggestions on what I am doing wrong, please do > so > > > > > > Thank you in advance > > > > > > Ivanhnoe Abrahams > > > > > > On Mon, Apr 7, 2008 at 4:44 PM, Freeman Fang <[EMAIL PROTECTED]> > > > wrote: > > > > > > > > > > > > > Hi, > > > > > > > > I assume you are using servicemix 3.2.2 snapshot, then you can add > > > > useJBIWrapper="false" to cxf consumer configuration. > > > > > > > > Freeman > > > > > > > > > > > > > > > > Ivanhoe Abrahams wrote: > > > > > > > > > > > > > > > > > Hello > > > > > > > > > > I am trying to set up a simple example whereby I have a CXF > consumer > > > > > endpoint which forwards to my JMS provider which calls out to a > > > > > simple > > > > > ActiveMQ queue which responds with a hardcoded message > > > > > I can make the call from SoapUI and can see the message ending up > at > > > > > the > > > > > external ActiveMQ test-app which responds with the hardcoded > > > > > message, > > > > > > > > > > The problem is that the JMS provider component does not SEEM wrap > > > > > the > > > > > response in a Normalized message, and as a result the CXF > consumer > > > > > complains.... > > > > > and sends back the following fault to the SoapUI. > > > > > > > > > > <faultstring>Message wrapper element is '{ > > > > > http://servicemix.apache.org/cxf-jms/types}GetPersonResponse< > http://servicemix.apache.org/cxf-jms/types%7DGetPersonResponse> > > > > > <http://servicemix.apache.org/cxf-jms/types%7DGetPersonResponse>' > > > > > but expected > > > > > '{http://java.sun.com/xml/ns/jbi/wsdl-11-wrapper}message< > http://java.sun.com/xml/ns/jbi/wsdl-11-wrapper%7Dmessage> > > > > > <http://java.sun.com/xml/ns/jbi/wsdl-11-wrapper%7Dmessage> > > > > > '</faultstring> > > > > > > > > > > Below is my CXF consumer SU xbean.xml and my JMS provider SU > > > > > xbean.xml > > > > > > > > > > CXF XBEAN.XML --> > > > > > <beans xmlns:cxfbc="http://servicemix.apache.org/cxfbc/1.0" > > > > > xmlns:test=" > > > > > http://servicemix.apache.org/cxf-jms"> > > > > > <cxfbc:consumer wsdl="classpath:test.wsdl" > > > > > targetService="test:MyPersonService"/> > > > > > </beans> > > > > > > > > > > > > > > > <jms:endpoint service="test:MyPersonService" > > > > > endpoint="myProvider" > > > > > role="provider" > > > > > destinationStyle="queue" > > > > > jmsProviderDestinationName="TOOL.DEFAULT" > > > > > connectionFactory="#connectionFactory" > > > > > wsdlResource="classpath:test.wsdl" > > > > > defaultMep="http://www.w3.org/2004/08/wsdl/in-out" > > > > > soap="true" /> > > > > > > > > > > > > > > > Any help would be appreciated > > > > > > > > > > ICA > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
