Thanks for your reply Andrew I'm using Castor as data-binding framwork in Axis. So the Marshalling magic is happening in these files:
http://cvs.apache.org/viewcvs.cgi/ws-axis/java/src/org/apache/axis/encod ing/ser/castor/ To temporarily solve my namespace issues I will modify CastorSerializer.java to include this code: if (value.getClass().getName().equalsIgnoreCase("main Response object for Web Service 1")) { marshaller.setNamespaceMapping("a","http://www.test.com/namespace1";); marshaller.setNamespaceMapping("b","http://www.test.com/namespace2";); marshaller.setNamespaceMapping("c","http://www.test.com/namespace3";); } else if (value.getClass().getName().equalsIgnoreCase("main Response object for Web Service 2")) { marshaller.setNamespaceMapping("a","http://www.test.com/namespace1";); marshaller.setNamespaceMapping("b","http://www.test.com/namespace2";); marshaller.setNamespaceMapping("d","http://www.test.com/namespace4";); marshaller.setNamespaceMapping("e","http://www.test.com/namespace5";); } else if (etc etc...) { } // Marshall the Castor object into the stream (sink) marshaller.marshal(value); This is (in my eyes) a bit ugly, but I have no other choice at the moment (I think :o) The Response will now look something like this (This is taken from the schemas in my original post without the schema manipulation I did mention some postings ago): <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"; xmlns:xsd="http://www.w3.org/2001/XMLSchema"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";> <soapenv:Body> <MyServiceResponse xmlns="http://www.test.com/webservices/service";> <ns1:MyServiceResponseWrapper xmlns:ns1="http://www.test.com/webservices/service"; xmlns:ns2="http://www.test.com/webservices/service/common"; xmlns:ns3="http://www.test.com/webservices/common";> <ns3:elementOne> <ns3:child1>0</ns3:child1> <ns3:child2>0</ns3:child2> <ns3:child3>0</ns3:child3> <ns3:child4>0</ns3:child4> </ns3:elementOne> <ns1:ElementTwo> <ns1:elementTwoResponseArray> <ns1:arrayElement> <ns2:baseElement1>test text</ns2:baseElement1> <ns2:baseElement2>888</ns2:baseElement2> <ns2:baseElement3>test text</ns2:baseElement3> <ns2:extensionBaseElement1>12345678910</ns2:extensionBaseElement1> <ns2:extensionBaseElement2> <ns3:Addr1>test text</ns3:Addr1> <ns3:Addr2>test text</ns3:Addr2> <ns3:Zip>0000</ns3:Zip> <ns3:City>City</ns3:City> </ns2:extensionBaseElement2> <ns2:simpleElementOne>1234567</ns2:simpleElementOne> <ns2:simpleElementTwo>1234567</ns2:simpleElementTwo> </ns1:arrayElement> </ns1:elementTwoResponseArray> </ns1:ElementTwo> </ns1:MyServiceResponseWrapper> </MyServiceResponse> </soapenv:Body> </soapenv:Envelope> I am not 100% happy because I would like to have the namespace declaration in the Envelope (root !?). But I have not successfully managed to manipulate Axis's SerializationContext to achieve this. My task now is to verify if I need to do the same changes in CastorEnumTypeSerializer.java :o) Cheers, Are T. Tysnes -----Original Message----- From: Andrew Fawcett [mailto:[EMAIL PROTECTED] Sent: 19. mai 2005 16:33 To: [email protected] Subject: RE: [castor-dev][XML] too many namespace declarations in element attributes Folks, Yes the key issue is when multiple namespaces are used. You can preload the Marshaler instance with your namespaces so that it declares them on the root node. So it doesn't have to keep declaring them over and over as they drop in and out of scope in the XML. However I understand that in generic solutions this isn't always possible to know this at coding time. So if you have generated descriptors it is possible to search through these and build up a list of namespaces that would be needed to serialise a given object graph. It can be an expensive operation so you should probably cache the results. I wouldn't be against considering this as an enhancement to Castor XML if I thought there was demand for it. Andy. -----Original Message----- From: Gregory Block [mailto:[EMAIL PROTECTED] Sent: 18 May 2005 12:14 To: [email protected]; Fredo Corleone Subject: Re: [castor-dev][XML] too many namespace declarations in element attributes On 16 May 2005, at 03:10, Fredo Corleone wrote: > Its been my observation that Castor creates xml with several > unnecessary namespace declarations when the schema includes/imports > schemas from several different files. I haven't had the time or need > to pursue this further because its not breaking anything.. I routinely do this without problems. <?xml version="1.0" encoding="UTF-8"?> <wow-feeds:article xmlns:wow-type="http://xml.whatsonwhen.com/schemas/1.0/wow- types.xsd" xmlns:wow-feeds="http://xml.whatsonwhen.com/schemas/1.0/wow- feeds.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; xsi:schemaLocation="http://xml.whatsonwhen.com/schemas/1.0/wow- feeds.xsd http://xml.whatsonwhen.com/schemas/1.0/wow-feeds.xsd"; id="19224" ongoing="false"> <wow-type:article-date tbc="false"> <wow-type:start-date>2005-04-18T00:00:00.000+01:00</wow- type:start-date> <wow-type:end-date>2005-05-09T00:00:00.000+01:00</wow- type:end-date> </wow-type:article-date> <wow-type:article-date tbc="true"> <wow-type:start-date>2006-04-18T00:00:00.000+01:00</wow- type:start-date> <wow-type:end-date>2006-05-09T00:00:00.000+01:00</wow- type:end-date> </wow-type:article-date> <wow-type:article-date tbc="true"> <wow-type:start-date>2007-04-18T00:00:00.000+01:00</wow- type:start-date> <wow-type:end-date>2007-05-09T00:00:00.000+01:00</wow- type:end-date> </wow-type:article-date> <wow-type:title>Buenos Aires Book Fair</wow-type:title> <wow-type:summary>The Buenos Aires Book Fair is eagerly awaited every year by bibliophiles in the Argentine capital. More than a million people head for this three-week event at the La Rural exhibition complex.</wow-type:summary> .. All castor-generated XML, no mess, no fuss. The information in this message is confidential and may be legally privileged. It may not be disclosed to, or used by, anyone other than the addressee. If you receive this message in error, please advise us immediately. Internet emails are not necessarily secure. CODA does not accept responsibility for changes to any email which occur after the email has been sent. Attachments to this email may contain software viruses, which could damage your systems. CODA has checked the attachments for viruses before sending, but you should virus-check them before opening.
