RE: AXIS Serialization / Deserialization problem with namespace prefixes
Title: Message
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.
markg
-Original Message-From: Anne Thomas
Manes [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 10, 2006
12:19 PMTo: axis-user@ws.apache.orgSubject: Re: AXIS
Serialization / Deserialization problem with namespace
prefixesMark'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:
1
2
and 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="urn:foo.bar"). If no default namespace has been declared, or if the
default namespace has been declared as xmlns="", then and
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 ( and ) must always be in no namespace.
If you are using document style, then the schema dictates whether or
not and should be qualified. If the schema specifies
elementFormDefault="qualified" or if and are defined
as global elements, then and must be qualified.
If you are using document style and you want and
to be unqualified, then you must define these element within the
complexType definition for , 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.) Anne
On 5/10/06, Griffin,
Mark <[EMAIL PROTECTED]>
wrote:
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.
markg
-Original Message-From:
Brown, Chris [mailto:[EMAIL PROTECTED]] Sent:
Wednesday, May 10, 2006 10:50 AMTo: axis-user@ws.apache.orgSubject: 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
1
2
Turns in to
1
2
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 use
XPath on the resulting XML
document.
Many thanks in
advance
Chris
=
Andy,This should make your boss happy:public static
Document serializeFromBinding(Object object, QName
qname)
throws ApplicationException
{ MessageContext
msgContext = new
MessageContext(newAxisServer());
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
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:
1
2
and 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="urn:foo.bar"). If no default namespace has been declared, or if
the default namespace has been declared as xmlns="", then
and 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 ( and ) must always be in no namespace. If you are using document style, then the schema dictates whether or not and should be qualified. If the schema specifies elementFormDefault="qualified" or if and are defined as global elements, then and must be qualified.
If you are using document style and you want and to be unqualified, then you must define these element within the complexType definition for , 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.)
AnneOn 5/10/06, Griffin, Mark <[EMAIL PROTECTED]> wrote:
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.
markg
-Original Message-From: Brown,
Chris [mailto:[EMAIL PROTECTED]] Sent: Wednesday,
May 10, 2006 10:50 AMTo: axis-user@ws.apache.orgSubject:
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
1
2
Turns
in to
1
2
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
use
XPath on the resulting XML
document.
Many thanks in advance
Chris
=
Andy,This should make your boss happy:public static
Document serializeFromBinding(Object object, QName
qname)
throws ApplicationException
{ MessageContext msgContext
= new
MessageContext(newAxisServer());
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(newStringReader(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); }
}YvesOn 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
b
Re: AXIS Serialization / Deserialization problem with namespace prefixes
Would you be able to test latest AXIOM jars? There should be a nightly
jar you can pick from
http://cvs.apache.org/repository/ws-commons/jars/ i remember a bug
getting fixed in this area.
thanks,
dims
On 5/10/06, Brown, Chris <[EMAIL PROTECTED]> wrote:
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
1
2
Turns in to
1
2
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 use
XPath on the resulting XML document.
Many thanks in advance
Chris
=
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
>
> Andy
Chris Brown
System Builder
Sopra Newell & Budge
Tel +44 (0)131 332 3311Fax +44 (0)131 332 5938
SopraNewell & Budge, Queensway House, 1 Queensferry Terrace,
Edinburgh, EH43ER
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.
_
--
Davanum Srinivas : http://wso2.com/blogs/
RE: AXIS Serialization / Deserialization problem with namespace prefixes
Title: Message
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.
markg
-Original Message-From: Brown,
Chris [mailto:[EMAIL PROTECTED] Sent: Wednesday,
May 10, 2006 10:50 AMTo: axis-user@ws.apache.orgSubject:
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
1
2
Turns
in to
1
2
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
use
XPath on the resulting XML
document.
Many thanks in advance
Chris
=
Andy,This should make your boss happy:public static
Document serializeFromBinding(Object object, QName
qname)
throws ApplicationException
{ MessageContext msgContext
= new
MessageContext(newAxisServer());
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(newStringReader(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); }
}YvesOn 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> > Andy
Chris
BrownSystem BuilderSopra 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
