This all looks OK for sending the B instance. Can you double check that on the service side it knows about the B.class via an XmlSeeAlso annotation or similar? If you do a ?wsdl on the service address, does the resulting wsdl/schema define the B type as an extension of A?
Dan On Mar 4, 2014, at 1:09 PM, allam-di14 <[email protected]> wrote: > In the meantime, I have made some improvements to my code. > > I resolved the issue at the client side: the problem is due to a space in > front of "address" in my spring configuration file: > address=" http://localhost:8080/SOAP-test2/services/ServicePort"; > > For the other problems, it was due to the JAXB validator. To resolve it, I > disabled the validator handler in my spring configuration file: > <jaxws:properties> > <entry key="schema-validation-enabled" value="false" /> > <entry key="set-jaxb-validation-event-handler" value="false" /> > </jaxws:properties> > > > My question now is, before when I used @XmlSeeAlso(B.class) on top of Class > A, the client was able to call op with a B instance and it corresponds to an > op invocation with a B instance at the server. > (to remind, my operation op is defined as follows: void op(A a) such that B > inherits A) > > Now, by using a single JAXBContext and JAXBElement conversions, if a client > calls op with a B instance, that corresponds to an op invocation with an A > instance at the server. > > Is-there a way to keep the same instances at the client and the server > sides? > > I did the following test code separately in JAXB: > JAXBContext jc = JAXBContext.newInstance("test"); > Marshaller marshaller = jc.createMarshaller(); > > B b = new B(); > b.setX("hello"); > b.setY(32); > Op op = new Op(); > op.setArg0(b); > JAXBElement<Op> op2 = new JAXBElement<Op>(new > QName("http://test/";, "op"), Op.class, op); > marshaller.marshal(op2, System.out); > > > File out = new File("src/test/output.xml"); > marshaller.marshal(op2, out); > Unmarshaller unmarshaller = > jc.createUnmarshaller(); > StreamSource xml2 = new > StreamSource("src/test/output.xml"); > JAXBElement<Op> op3 = > unmarshaller.unmarshal(xml2, Op.class); > > System.out.println( op3.getValue().getArg0()); > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% > the result of unmarshalling is an OP instance with a reference to a B > instance. > Thus, the issue is not from JAXB, but maybe from the way cxf calls the > unmarshal method on the received xml. > > Indeed, their is not a difference between the soap body created by cxf: > <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/";> > <soap:Body> > <ns2:op xmlns:ns2="http://test/";> > <arg0 > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; > xsi:type="ns2:b"> > <x>salut</x> > <y>2014</y> > </arg0> > </ns2:op> > </soap:Body> > </soap:Envelope> > -------------------------------------- > > and the xml created by my JAXB test code: > <?xml version="1.0" encoding="UTF-8" standalone="yes"?> > <ns2:op xmlns:ns2="http://test/";> > <arg0 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; > xsi:type="b"> > <x>hello</x> > <y>32</y> > </arg0> > </ns2:op> > > I am using cxf 2.7.10 version > > Any help please? > Kind regards, > Diana > > > > > > -- > View this message in context: > http://cxf.547215.n5.nabble.com/How-to-configure-CXF-for-a-single-JAXBContext-and-for-an-automatic-JAXBElement-conversion-tp5740782p5740803.html > Sent from the cxf-user mailing list archive at Nabble.com. -- Daniel Kulp [email protected] - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
