Ok, I spent yesterday getting a dummy scenario up and running and it works. However, I had to skip jaxb2 annotations and switch to the aegis binding. The aegis binding don't give all possibilities as jaxb2 does, but at least it works. As I'd like to have my domain pojos in a java package that doesn't match the namespace I must specify the "correct" namespace in the binding (the namespace that the service is within) to work around the namespace bug.
So what I actually have working is getting a message (basically just a string) from a jms queue (in-only) onto an eip pipeline that calls a jsr181 service (in-out) that creates a domain object. That domain object is then returned (marshalled to xml) to the pipeline and then passed onto (in-only) another jsr-181 service which prints the domain object by doing .toString(). In the last step the unmarshalling is done by the framework. Regarding your error, what style are you using - wrapped (default) or document? Could it be that you're using wrapped and that you're missing the operation in the xml passed in? I've switched to document and don't specify the operation but only the in paramater. Like this: <name xmlns="http://b.a.se/c";> AndersHammar </name> In this case I've named my inparamater 'name' by using the possibilities of jsr181 annotation: @WebMethod @WebResult(name="DummyObject", targetNamespace="http://b.a.se/c";) public DummyObject getDummyObject(@WebParam(name="name") String name); Great that you filed the fire. Either I'm doing something wrong with jaxb2 or there's a bug with smx or XFire using jaxb2 bindings. I thing we can rely on the jaxb2 implementation being ok. Being desperat I also patched the jsr181 component with the latest (v2.0.4) jaxb2 impl. No difference. Important to note is that we're going the code first road and what the schema/wsdl to be generated. However, both me and you want to do xsl transformation and for that to be reliable we want to control the schema generation by jaxb2 annotations (at least I want to). Otherwise a new jaxb2 implementation could result in a different schema and thus errors in the transformation. /Anders moraleslos wrote: > > I spent about a half-a-day deploying various combinations--all of them > still producing the an XFireFault: "org.codehaus.xfire.fault.XFireFault: > Invalid operation: document" > > However, you're right about the jaxb2 annotations. Removing them from my > POJOs seem to produce a more valid WSDL--all of the types seem to get > generated--but the unmarshalling won't work probably due to the fact that > there are no jaxb2 annotations. > > Anyway, just wanted to let you know that I posted an issue on JIRA-- > https://brutus.apache.org/activemq/browse/SM-749. I am not sure if this > is a bug with smx, xfire, or a combination of both. Hopefully this can > get resolved. I also agree with you that more examples on using the > jsr181 component would be very helpful if included in future smx distros, > when all of the kinks have been ironed out. > > For now, I'll probably have to revert back to a more ad hoc approach in > unmarshaling data rather on relying the JSR181 component to magically do > it for me. > > -los > > > > Anders Hammar wrote: >> >> Yep, your wsdl is missing the schema for Document. Yesterday, after >> writing the reply to you, I found out that I had the same problem. I >> solved it by removing the jaxb2 annotations from my domain pojo. By doing >> that the wsdl includes the schema for the domain object. Don't understand >> why it doesn't work as I had it in the first place as the namespace >> specified is the same as my service. Possibly this is related to the >> filed jira about schemas not being included. >> >> So, remove the jaxb2 annotations and see if that solves it. I don't >> really remember if I also removed the typeMapping property in xbean.xml >> file. You can try that as well if needed. >> >> I'm sorry to say that the jsr181 component feels shaky. The lack of >> examples is also a big problem. I'm basically guessing and trying all >> sorts of things as I'm also quite new to xml web services. The wsdl_first >> example exists, but we're going the other way around and an example with >> two jsr181 services communicating to each other would be excellent! >> >> By the way, I've switched to the not yet released (but packaged) 3.0.1 >> version of smx if that could do any difference. >> >> /Anders >> >> >> moraleslos wrote: >>> >>> Hi Anders, >>> >>> Thanks for the reply... I retrofitted your example code into mine. I >>> finally got past the compilation step so that worked great. Now when I >>> deploy my jbi, I get this exception: >>> >>> #################### >>> 11:36:49,293 | INFO | Thread-15 | DefaultFaultHandler | >>> re.handler.DefaultFaultHandler 39 | Fault occurred! >>> org.codehaus.xfire.fault.XFireFault: Invalid operation: document >>> at >>> org.codehaus.xfire.service.binding.WrappedBinding.readMessage(WrappedBinding.java:41) >>> at >>> org.codehaus.xfire.soap.handler.SoapBodyHandler.invoke(SoapBodyHandler.java:42) >>> at >>> org.codehaus.xfire.handler.HandlerPipeline.invoke(HandlerPipeline.java:131) >>> at >>> org.codehaus.xfire.transport.DefaultEndpoint.onReceive(DefaultEndpoint.java:64) >>> at >>> org.codehaus.xfire.transport.AbstractChannel.receive(AbstractChannel.java:38) >>> at >>> org.apache.servicemix.jsr181.Jsr181ExchangeProcessor.doProcess(Jsr181ExchangeProcessor.java:113) >>> at >>> org.apache.servicemix.jsr181.Jsr181ExchangeProcessor.process(Jsr181ExchangeProcessor.java:68) >>> at >>> org.apache.servicemix.common.AsyncBaseLifeCycle.processExchange(AsyncBaseLifeCycle.java:410) >>> at >>> org.apache.servicemix.common.BaseLifeCycle.onMessageExchange(BaseLifeCycle.java:43) >>> at >>> org.apache.servicemix.jbi.messaging.DeliveryChannelImpl.processInBound(DeliveryChannelImpl.java:624) >>> at >>> org.apache.servicemix.jbi.nmr.flow.AbstractFlow.doRouting(AbstractFlow.java:170) >>> at >>> org.apache.servicemix.jbi.nmr.flow.seda.SedaFlow.doRouting(SedaFlow.java:177) >>> at >>> org.apache.servicemix.jbi.nmr.flow.seda.SedaQueue$1.run(SedaQueue.java:227) >>> at >>> org.apache.geronimo.connector.work.WorkerContext.run(WorkerContext.java:291) >>> at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(Unknown >>> Source) >>> at java.lang.Thread.run(Thread.java:619) >>> ######################################## >>> >>> >>> I used JConsole to probe my TestUnmarshallingService endpoint and >>> everything looks ok. The WSDL output looks like this: >>> >>> ######################################## >>> <?xml version="1.0" encoding="UTF-8"?><wsdl:definitions >>> xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"; >>> xmlns:soap11="http://schemas.xmlsoap.org/soap/envelope/"; >>> xmlns:soap12="http://www.w3.org/2003/05/soap-envelope"; >>> xmlns:soapenc11="http://schemas.xmlsoap.org/soap/encoding/"; >>> xmlns:soapenc12="http://www.w3.org/2003/05/soap-encoding"; >>> xmlns:tns="http://test.com/integration/servicemix"; >>> xmlns:wsdlsoap="http://schemas.xmlsoap.org/wsdl/soap/"; >>> xmlns:xsd="http://www.w3.org/2001/XMLSchema"; >>> targetNamespace="http://test.com/integration/servicemix";> >>> <wsdl:types> >>> <xsd:schema attributeFormDefault="qualified" >>> elementFormDefault="qualified" >>> targetNamespace="http://test.com/integration/servicemix"; >>> xmlns:xsd="http://www.w3.org/2001/XMLSchema";> >>> <xsd:element name="retrieveData"> >>> <xsd:complexType> >>> <xsd:sequence> >>> <xsd:element maxOccurs="1" minOccurs="1" ref="tns:Document"/> >>> </xsd:sequence> >>> </xsd:complexType> >>> </xsd:element> >>> <xsd:element name="retrieveDataResponse"> >>> <xsd:complexType/> >>> </xsd:element> >>> </xsd:schema> >>> </wsdl:types> >>> <wsdl:message name="retrieveDataRequest"> >>> <wsdl:part element="tns:retrieveData" name="parameters"/> >>> </wsdl:message> >>> <wsdl:message name="retrieveDataResponse"> >>> <wsdl:part element="tns:retrieveDataResponse" name="parameters"/> >>> </wsdl:message> >>> <wsdl:portType name="thomsonUnmarshallerPortType"> >>> <wsdl:operation name="retrieveData"> >>> <wsdl:input message="tns:retrieveDataRequest" >>> name="retrieveDataRequest"/> >>> <wsdl:output message="tns:retrieveDataResponse" >>> name="retrieveDataResponse"/> >>> </wsdl:operation> >>> </wsdl:portType> >>> </wsdl:definitions> >>> ###################################### >>> >>> Notice that there is a referenced namespace for Document, but its not >>> defined anywhere in the WSDL. Not sure if this is ok or if something is >>> wrong with the WSDL generation (I'm not at all proficient with WSDL/Web >>> Services). My Document pojo looks like this: >>> >>> ###################################### >>> >>> @XmlRootElement(namespace="http://test.com/integration/servicemix";) >>> public class Document { >>> // accessors to other XML subelements >>> } >>> >>> ###################################### >>> >>> Again, I packaged my domain objects in the same place where my services >>> are located. Any additional help would be appreciated. Thanks in >>> advance! >>> >>> -los >>> >>> >> >> > > -- View this message in context: http://www.nabble.com/connecting-to-jsr-181-jaxb2-tf2523299s12049.html#a7468616 Sent from the ServiceMix - User mailing list archive at Nabble.com.
