We've talked on IRC and decided to create a Stax based transform feature. I'm not sure where to document it yet but see https://issues.apache.org/jira/browse/CXF-3338 (the SVN Activity tab).
The configuration of this feature will be identical to the way a JAXRS JAXBElementProvider can be configured: http://cxf.apache.org/docs/jax-rs-data-bindings.html#JAX-RSDataBindings-CustomizingJAXBXMLandJSONinputandoutput The merge includes a test showing a SOAP client reading and writing the unqualified body content (by dropping and adding namespaces as needed), here is an example: @Test public void testGetUnqualifiedBookSoap() throws Exception { String wsdlAddress = "http://localhost:"; + PORT + "/test/services/soap-transform/bookservice?wsdl"; URL wsdlUrl = new URL(wsdlAddress); BookSoapService service = new BookSoapService(wsdlUrl, new QName("http://books.com";, "BookService")); BookStoreJaxrsJaxws store = service.getBookPort(); // here in/out interceptors are added explicitly, but a feature can be injected instead TransformInInterceptor in = new TransformInInterceptor(); Map<String, String> mapIn = new HashMap<String, String>(); mapIn.put("*", "{http://jaxws.jaxrs.systest.cxf.apache.org/}*";); in.setInTransformElements(mapIn); TransformOutInterceptor out = new TransformOutInterceptor(); Map<String, String> mapOut = new HashMap<String, String>(); mapOut.put("{http://jaxws.jaxrs.systest.cxf.apache.org/}*";, "getBookRequest"); out.setOutTransformElements(mapOut); Client cl = ClientProxy.getClient(store); cl.getInInterceptors().add(in); cl.getOutInterceptors().add(out); Book book = store.getBook(new Long(123)); assertEquals("id is wrong", book.getId(), 123); } the server: <jaxws:endpoint xmlns:s="http://books.com"; serviceName="s:BookService" endpointName="s:BookPort" id="soapservice-transform" implementor="#bookstore-simple" address="/soap-transform/bookservice"> <jaxws:features> <ref bean="transformFeatureSoap" /> </jaxws:features> </jaxws:endpoint> <bean id="transformFeatureSoap" class="org.apache.cxf.feature.StaxTransformFeature"> <property name="outTransformElements"> <map> <entry key="{http://jaxws.jaxrs.systest.cxf.apache.org/}*"; value="*"/> </map> </property> <property name="inTransformElements"> <map> <entry key="*" value="{http://jaxws.jaxrs.systest.cxf.apache.org/}*"/> </map> </property> </bean> This feature works for JAXRS endpoints too Sergey On Fri, Feb 11, 2011 at 2:24 PM, monitorjbl <[email protected]> wrote: > > After some more though, I thought of another way that this might be done. If > there's a way to make the annotated classes somehow inherit the namespace > from the class that called them, I wouldn't need to do anything else. I > didn't mention this before, but the server responses are namespaced and > unqualified, so in just XML terms, this inheritance is already kind of > happening. I've tried doing this: > > @XmlAccessorType(XmlAccessType.FIELD) > @XmlRootElement(name = "ServerResponse", namespace = > "http://some.namespace.com/";) > public class ServerResponse{ > > @XmlElement(name = "Entries") > protected Entries entries= new Entries(); > > public Entries getEntries() { > return entries; > } > > public void setEntries(Entries entries) { > this.entries = entries; > } > } > > for the server response and using this for the request: > > @XmlAccessorType(XmlAccessType.FIELD) > @XmlRootElement(name = "ServerResponse", namespace = "") > public class ServerRequest{ > > @XmlElement(name = "Entries") > protected Entries entries= new Entries(); > > public Entries getEntries() { > return entries; > } > > public void setEntries(Entries entries) { > this.entries = entries; > } > } > > In this case the requests work, but the responses don't. JAXB seems to only > unmarshall the root element, <ServerResponse> unless I explicitly annotate a > namespace for the child <Entries> element as well. It doesn't throw an > exception, mind you, it just doesn't set the "entries" member variable to > anything. If these elements could just inherit the namespace of their > parents, the way the actual XML seems to be calling for them to do, my > problem would be fixed by just having two version of the top-level classes. > -- > View this message in context: > http://cxf.547215.n5.nabble.com/Removing-namespaces-tp3380211p3381267.html > Sent from the cxf-user mailing list archive at Nabble.com. >
