After some more investigation including using plain XFire it seems as the problem is within XFire. I also found this XFire JIRA: http://jira.codehaus.org/browse/XFIRE-739
Anders Hammar wrote: > > There is a JIRA raised already: > https://brutus.apache.org/activemq/browse/SM-749 > I'll try to get the code together to reproduce it and add it to the JIRA. > > /Anders > > > gnodet wrote: >> >> Would you mind raising a JIRA describing the exact problem >> and attach the necessary files to reproduce it ? >> >> On 11/21/06, moraleslos <[EMAIL PROTECTED]> wrote: >>> >>> Hey Anders, >>> >>> Thanks for all your help... I've actually went the ad hoc way since I >>> needed >>> to get something working. Its actually very easy... 4 extra lines in my >>> unmarshalling component... and it works like a charm. Of course I would >>> like to do it the JSR181-way since that is what its suppose to do. >>> >>> Anyway, I got rid of my little test harness (mainly due to frustration) >>> so I >>> won't be able to try out Aegis. Either way, I'd like to stick with >>> JAXB2 >>> since we can expose our domain model for other things too, and I'm >>> getting >>> pretty familiar with its annotations (great stuff). >>> >>> As for the Web Service style, I think I did use wrapped. I always >>> thought >>> wrapped was better than doc or rpc. Its more verbose so shouldn't it be >>> preferred? >>> >>> Yes, I do agree with you on the code-first route. I always think that >>> our >>> domain model should be controlled by us and hence will have everything >>> else >>> reflect it one way or another. Therefore I prefer the domain --> >>> schema/wsdl instead of vice-versa and hence will keep the domain model >>> clean >>> and precise. All incoming data that will be contained in our domain >>> must go >>> through a xsl transformation process and templates are easy to define. >>> I'm >>> not a big fan of schema/wsdl --> domain objects simply because of all >>> the >>> garbage the domain objects contain. If we are dealing with objects >>> other >>> than the domain, and if these objects can be considered *throw-away", >>> then I >>> would not mind the schema-first route. >>> >>> Hope later versions of smx will have this/these bugs fixed with a >>> working >>> example of code --> schema/wsdl (jaxb2) jsr181 example. >>> >>> -los >>> >>> >>> >>> Anders Hammar wrote: >>> > >>> > 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#a7475062 >>> Sent from the ServiceMix - User mailing list archive at Nabble.com. >>> >>> >> >> >> -- >> Cheers, >> Guillaume Nodet >> >> > > -- View this message in context: http://www.nabble.com/connecting-to-jsr-181-jaxb2-tf2523299s12049.html#a7575736 Sent from the ServiceMix - User mailing list archive at Nabble.com.
