Good catch Anders! I had a hunch it may be due to XFire since the WSDL gets generated by that lib. Hopefully this gets resolved in the next release (or two) of SMX so I can test it out. For now I'll stick to my ad-hoc unmarshaller component.
-los Anders Hammar wrote: > > 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#a7579825 Sent from the ServiceMix - User mailing list archive at Nabble.com.
