axis-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Griffin, Mark" <>
Subject RE: AXIS Serialization / Deserialization problem with namespace prefixes
Date Wed, 10 May 2006 16:32:47 GMT
Anne is right, of course. I was assuming that since your client was
sending the prefix with qualifies it to http:/blah, that bob and jim
belong to that namespace in your WSDL.   Your second client(example) is
interpreting it that way.


	-----Original Message-----
	From: Anne Thomas Manes [] 
	Sent: Wednesday, May 10, 2006 12:19 PM
	Subject: Re: AXIS Serialization / Deserialization problem with
namespace prefixes
	Mark's comment here is inaccurate:
	In your first example, bob is assumed to be part of http:/blah,
where as in your second example it is explicitly set.

	In this example:
	<n:test xmlns:n="http:/blah">

	<bob> and <jim> are never "assumed" to be in the namespace of
their parent element. When no namespace qualification is specified, the
elements are assigned to the default namespace (the namespace declared
with no prefix set, e.g., xmlns=""). If no default namespace
has been declared, or if the default namespace has been declared as
xmlns="", then <bob> and <jim> are in no namespace. 
	Clients must always follow the namespace qualification rules
specified in the WSDL or schema. 
	The question is, how is the WSDL and/or schema defined for this
document instance? 
	If you are using RPC style, then the accessor elements for the
parameter types (<bob> and <jim>) must always be in no namespace. 
	If you are using document style, then the schema dictates
whether or not <bob> and <jim> should be qualified. If the schema
specifies elementFormDefault="qualified" or if <bob> and <jim> are
defined as global elements, then <bob> and <jim> must be qualified. 
	If you are using document style and you want <bob> and <jim> to
be unqualified, then you must define these element within the
complexType definition for <test>, and you must make sure that the
schema does not specify elementFormDefault="qualified". (Either
explicitly specify elementFormDefault="unqualified" or do not include
the attribute. I recommend the former.) 
	On 5/10/06, Griffin, Mark <> wrote: 

		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
		Sent: Wednesday, May 10, 2006 10:50 AM
		Subject: AXIS Serialization / Deserialization problem
with namespace prefixes

			  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...
			  <n:test xmlns:n="http:/blah">
			   Turns in to    
			  <n:test xmlns:n="http:/blah">
			  Once serialization / deserialization has
			  Does anyone know of a way to prevent this
happening as it causing a lot of problems when attempting to use
			  XPath on the resulting XML document.
			Many thanks in advance
			This should make your boss happy:
			public static Document
serializeFromBinding(Object object, QName qname)
			            throws ApplicationException {
			        MessageContext msgContext = new
			        TypeMappingRegistry tmr = new
			        StringWriter writer = new
StringWriter(); //temp
			        SerializationContext ser = new
			        try {
			            ser.serialize(qname, new
AttributesImpl(), object, null,
			Boolean.FALSE, Boolean.FALSE);
			            return XMLUtils.newDocument(new
			        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);
			On Fri, 2005-11-11 at 18:10 -0500, Andy Foster
			> 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
			> Andy
			Chris 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 <> 	

			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.

View raw message