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
