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.

Reply via email to