Chris,
The
difference is coming from being fully qualified to the namespace and not fully
qualified. In your first example, bob is assumed to be part of http:/blah, where
as in your second example it is explicitly set.
Depending on how your WSDL is constructed, clients will
send either fully qualified or will assume the default namespace. I've
found that this varies from Client to Client depending on the stack they are
using for web services/soap/xml etc and how they interpret the WSDL. So
you might get a prefix from some clients. Your xpath query should be able to
handle this by using a wildcard for the prefix spot. Something like
//*:test/*:bob/text() for example. I believe the clients should follow the
namespace qualification as it is set in the WSDL but I haven't always found this
to be the case.
-----Original Message-----
From: Brown,
Chris [mailto:[EMAIL PROTECTED]
Sent: Wednesday,
May 10, 2006 10:50 AM
To: axis-user@ws.apache.org
Subject:
AXIS Serialization / Deserialization problem with namespace
prefixes
Hi,I am using the code below to serialize / deserialize AXIS beans back and forth to XML.However, I have recently came across a situation where say...Original<n:test xmlns:n="http:/blah"><bob>1</bob><jim>2</jim></n:test>Turns in to<n:test xmlns:n="http:/blah"><n:bob>1</n:bob><n:jim>2</n:jim></n:test>Once serialization / deserialization has occured.Does anyone know of a way to prevent this happening as it causing a lot of problems when attempting to useXPath on the resulting XML document.Many thanks in advanceChris=====================================Andy,
This should make your boss happy:
public static Document serializeFromBinding(Object object, QName qname)
throws ApplicationException {
MessageContext msgContext = new MessageContext(new
AxisServer());
msgContext.setEncodingStyle(null);
TypeMappingRegistry tmr = new TypeMappingRegistryImpl();
msgContext.setTypeMappingRegistry(tmr);
StringWriter writer = new StringWriter(); //temp
SerializationContext ser = new SerializationContext(writer,
msgContext);
ser.setPretty(true);
ser.setSendDecl(false);
ser.setDoMultiRefs(false);
try {
ser.serialize(qname, new AttributesImpl(), object, null,
Boolean.FALSE, Boolean.FALSE);
writer.flush();
return XMLUtils.newDocument(new InputSource(new
StringReader(writer.toString())));
}
catch(ParserConfigurationException e) {
throw new ApplicationException(e.getMessage(), e);
}
catch(SAXException e) {
throw new DocumentStructureException(e.getMessage(), e);
}
catch(IOException e) {
throw new ApplicationException(e.getMessage(), e);
}
}
Yves
On Fri, 2005-11-11 at 18:10 -0500, Andy Foster wrote:
> Hi all,
>
> I'm at my last chance now, so if someone can help that would be great else
> I'm going to have to hand code XML output.
>
> If you use WSDL2JAVA to generate stubs and call them you get a java response
> object back that represents the XML response
>
> I need to get that response back into XML not the stub java representation.
>
> I know axis can re serialise for me I just do not know how to invoke it
>
> Please help as I have been searching for two days now and my boss is giving
> me the weekend and then we have to find another way to hand crank it which
> would be a very poor solution
>
> AndyChris Brown
System Builder
Sopra Newell & Budge
Tel +44 (0)131 332 3311 Fax +44 (0)131 332 5938
Sopra Newell & Budge, Queensway House, 1 Queensferry Terrace, Edinburgh, EH4 3ER www.sopranewellandbudge.com
_____________________________________________________________________________________________________
Sopra Newell & Budge is the trading name of: Newell & Budge Limited (Registered in Scotland No. 94545 with Registered Offices at: 1 Queensferry Terrace, Edinburgh, EH4 3ER, VAT No. 774 7553 86), Newell & Budge Security Limited (Registered in Northern Ireland No. 39008, with Registered Offices at: 199 Airport Road West, Belfast, BT3 9ED, VAT No. 774 7553 86) and Sopra Group Limited (Registered in England, No. 1588948 with Registered Offices at: 17 St Helen's Place, London, EC3A 6DG, VAT No. 366 9784 84).
IMPORTANT NOTICE: This message is intended for the addressee only. The content may be confidential, legally privileged and protected by law. Unauthorised use, copying or disclosure of any of it may be unlawful. If you are not the intended recipient please notify the sender and remove it from your system. Internet e-mails are not necessarily secure. Although we have taken steps to ensure this e-mail and attachments are free from any virus, we advise that in keeping with good computing practice you should ensure they are actually virus free. The right to monitor e-mail communications through our network is reserved by Sopra Newell & Budge.
_____________________________________________________________________________________________________
