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#a7486767 Sent from the ServiceMix - User mailing list archive at Nabble.com.
