woohooo!!! Please switch your email client to send plain text messages...

thanks,
dims

On 5/25/06, Daniel Jemiolo <[EMAIL PROTECTED]> wrote:


Hi - the latest snapshot did work - now I just to get the client side updated 
to Axis2.  :)

thanks,
Dan





 "Davanum Srinivas" <[EMAIL PROTECTED]>

05/23/2006 05:22 PM

Please respond to
 [email protected]


To [email protected]

cc


Subject Re: [Axis2] disabling prefix optimization








Dan,

 AFAIK, this problem has been fixed in AXIOM SVN. Could u please try that?

 thanks,
 dims

 On 5/23/06, Daniel Jemiolo <[EMAIL PROTECTED]> wrote:
 >
 > Hi,
 >
 > I'm encountering some behavior in Axis2/Axiom that I also saw in Axis 1.x,
 > and I want to make sure there's no flag/setting that's escaped me before I
 > go off and hack around it. I think the problem might be generic to Axiom,
 > but it definitely affects both versions of Axis, so I figure this list would
 > be a good place to start.
 >
 > My problem is that sometime in between the call to AxisEngine.send() and the
 > serialization of the SOAP response onto the wire, my SOAP response loses a
 > lot of prefix-namespace mappings. Here is an example:
 >
 >
 > SOAP body I create and return from an Axis2 service method:
 >
 >
 > <wsrf-rp:GetResourcePropertyResponse xmlns:wsrf-rp="...">
 >     <wsnt:Topic xmlns:wsnt="..." xmlns:foo="...">
 >        foo:MyTopicName
 >     </wsnt:Topic>
 > </wsrf-rp:GetResourcePropertyResponse>
 >
 >
 > SOAP body that I receive on the client side (w/ an Axis 1.x client):
 >
 >
 > <wsrf-rp:GetResourcePropertyResponse xmlns:wsrf-rp="...">
 >     <wsnt:Topic xmlns:wsnt="...">    <!-- foo is gone! -->
 >        foo:MyTopicName
 >     </wsnt:Topic>
 > </wsrf-rp:GetResourcePropertyResponse>
 >
 >
 > Notice the lack of xmlns:foo="...". It has been "optimized away", because
 > there is no element name or attribute name within the XML fragment that has
 > foo: as a prefix. But the prefix IS being used - it is referenced in the
 > text value of the <wsnt:Topic/> element. When this XML is received on the
 > client side, I try to parse the value as a QName, and, finding no match for
 > the foo: prefix, must either throw an exception or treat the value as a
 > simple name (neither will produce the correct results).
 >
 > I have tried using OMElement.setText(QName) in the hopes that this would
 > solve the problem, but a) it does not appear to change the behavior, and b)
 > it does not address the use of QNames as attribute values. Both of these
 > situations occur frequently in the WSRF, WSN, and WSDM specifications, and
 > it's not possible to build spec-compliant implementations without these
 > "unused" prefix declarations.
 >
 > Axis 1.x had a configuration flag called
 > "enableNamespacePrefixOptimization" which supposedly turned
 > off this XML optimization. Changing the value never seemed to work for me,
 > but nevertheless, the idea is a good one. Is it possible to add a setting to
 > Axis2 so that it will leave the SOAP envelope alone and send it as-is? Or,
 > more immediately, is there a suggested way to work around this? My current
 > hack (which is very ugly), is to create a dummy attribute within every
 > namespace whose prefix is being deleted in order to "trick" the SOAP/OM
 > implementation into keeping them around. This doesn't hurt interop, it's
 > just ugly and bad for performance.
 >
 > I guess it's also extremely ironic, since the goal of the original author
 > was to minimize the size of the XML payload.  :)
 >
 >
 > Thanks,
 > Dan
 >
 >
 >  Dan Jemiolo
 >  IBM Corporation
 >  Research Triangle Park, NC
 >
 >
 >  +++ I'm an engineer. I make slides that people can't read. Sometimes I eat
 > donuts. +++
 >
 >


 --
 Davanum Srinivas : http://wso2.com/blogs/


 ---------------------------------------------------------------------
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]






--
Davanum Srinivas : http://wso2.com/blogs/

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to