AW: [WSS4J] AW: AW: WSDoAllReceiver/AxisUtil problem report

Dittmann Werner <[email protected]> Tue, 10 Feb 2004 17:04:28 +0100
Newsgroups gmane.text.xml.wss4j
Message-ID <79D5F4B2D775204D9C7852EE41C547730141A5AA@mchh2a1e.mchh.siemens.de>
Hi,

just checked in a modified version of WsDoAllReceiver that
perform the same serialization as WsDoAllSender. According
to my tests that could solve the problem. Pls check out.

Dims, Axis performs a "PrettyElementToStream" in the course
of its serialization when it converts DOMSource to bytes.
Refer to "sourceToInputSource(Source source)"
in XMLUtils. Thus setting the flag in SOAPBody wouldn't help,
wouldn't it?

Regards,
Werner

> -----Urspr=FCngliche Nachricht-----
> Von: wss4j-devel-admin-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org=20
> [mailto:wss4j-devel-admin-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org] Im Auftrag=20
> von Dittmann Werner
> Gesendet: Dienstag, 10. Februar 2004 16:22
> An: 'dims-/[email protected]'; 'Sashka'; [email protected]
> Betreff: [WSS4J] AW: AW: WSDoAllReceiver/AxisUtil problem report
>=20
>=20
> sorry, Dims. Don't have a current Axis tree=20
> on my system, need to set-up the environment,
> will take a day or two.
>=20
> Regards,
> Werner
>=20
> > -----Urspr=FCngliche Nachricht-----
> > Von: Davanum Srinivas [mailto:dims-/[email protected]]=20
> > Gesendet: Dienstag, 10. Februar 2004 14:03
> > An: Dittmann Werner; 'Sashka'; [email protected]
> > Betreff: Re: AW: WSDoAllReceiver/AxisUtil problem report
> >=20
> >=20
> > Can one of you set disableFormatting to true in Axis'=20
> > SOAPBody.java (line 93) and see if that
> > helps? if it does, i can add a global switch to disable formatting.
> >=20
> > thanks,
> > dims
> >=20
> > --- Dittmann Werner <[email protected]> wrote:
> > > Sashka,
> > >=20
> > > just to make sure: as I understand your report
> > > the problem is soemwhere in class DOMSource?
> > >=20
> > > Well, I checked this beast (contained in Axis
> > > sources) and found that it does nothing to the
> > > content at all, just stores the node an provides
> > > a way to access the node.
> > >=20
> > > That means, that the problem is somewhere in Axis
> > > serialization as we just replace the nodes,
> > > basically.
> > >=20
> > > Dims, do you know of any problem there?
> > >=20
> > > BTW, while implementing and testing the interop
> > > scenarios I discovered a similar problem. That's
> > > the reason why I do a String.trim() on the String
> > > input parameter at the server side to get rid
> > > of unwanted \n. Well, I didn't follow up that
> > > problem then, but it seems that something is wrong
> > > with Axis serialization when there is a new node.
> > >=20
> > > Regards,
> > > Werner
> > >=20
> > >=20
> > >=20
> > > > -----Urspr=FCngliche Nachricht-----
> > > > Von: Sashka [mailto:[email protected]]=20
> > > > Gesendet: Dienstag, 10. Februar 2004 12:38
> > > > An: Dittmann Werner; Davanum Srinivas
> > > > Betreff: WSDoAllReceiver/AxisUtil problem report
> > > >=20
> > > >=20
> > > > Werner, Dims, hi.
> > > > It seems there is a problem in the call to=20
> > > >  AxisUtil.updateSOAPMessage(doc, sm) in WSDoAllReceiver - the=20
> > > > document=20
> > > > is corrupted while the message is updated in this point:
> > > > ///---------------------
> > > >     WSSecurityEngineResult wsResult =3D null;
> > > >     try {
> > > >         wsResult =3D
> > > >                 secEngine.processSecurityHeader(
> > > >                         doc,
> > > >                         null,
> > > >                         cbHandler,
> > > >                         sigCrypto,
> > > >                         decCrypto);
> > > >     } catch (Exception ex) {
> > > >         throw new AxisFault(
> > > >                 "WSDoAllReceiver: security processing failed",
> > > >                 ex);
> > > >     }
> > > >     try {
> > > >       AxisUtil.updateSOAPMessage(doc, sm); /// <<--- Here
> > > >     ...........
> > > > ///-------------------------
> > > >=20
> > > > Full description.
> > > > ------------------
> > > > I'm testing the WSS4J with a standard basic axis sample: 
> > > > samples.addr.=20
> > > > On the call AddressBook.addEntry(String name, Address=20
> > addr) <executed=20
> > > > as rpc/encoded, for more exactness> I receive unexpected=20
> > server-side=20
> > > > exception while Address object deserialization:
> > > > //----- start of except. stack ------------
> > > >     java.lang.NumberFormatException: For input string:=20
> '\n1 ' at=20
> > > >     java.lang.NumberFormatException.forInputString=20
> > > >                               =20
> (NumberFormatException.java:48) at=20
> > > >     java.lang.Integer.parseInt(Integer.java:426) at=20
> > > >     java.lang.Integer.&lt;init&gt;(Integer.java:567) at
> > > >     sun.reflect.NativeConstructorAccessorImpl.newInstance0
> > > >                                      (Native Method) at=20
> > > >     sun.reflect.NativeConstructorAccessorImpl.newInstance
> > > >                       =20
> (NativeConstructorAccessorImpl.java:39) at=20
> > > >     sun.reflect.DelegatingConstructorAccessorImpl.newInstance
> > > >                       =20
> > (DelegatingConstructorAccessorImpl.java:27) at=20
> > > >    =20
> > > >=20
> > java.lang.reflect.Constructor.newInstance(Constructor.java:274) at=20
> > > >     org.apache.axis.encoding.ser.SimpleDeserializer.makeValue
> > > >                        (SimpleDeserializer.java:284) at=20
> > > >     =
org.apache.axis.encoding.ser.SimpleDeserializer.onEndElement
> > > >                        (SimpleDeserializer.java:214) at=20
> > > >     org.apache.axis.encoding.DeserializerImpl.endElement
> > > >                       (DeserializerImpl.java:544) at=20
> > > >    =20
> org.apache.axis.encoding.DeserializationContextImpl.endElement
> > > >                       (DeserializationContextImpl.java:1092) at =

> > > >     ..... etc ......
> > > > //----- end of except. stack ------------
> > > >=20
> > > > As the check shows, the problematic whitespaces were=20
> added in the=20
> > > > mentioned point: =20
> > > >      AxisUtil.updateSOAPMessage(doc, sm). This claim may=20
> > be proved by=20
> > > > next:
> > > > In my case the document returned after description call
> > > >  			wsResult =3D
> > > > 				secEngine.processSecurityHeader(
> > > > 					doc,
> > > > 					null,
> > > > 					cbHandler,
> > > > 					sigCrypto,
> > > > 					decCrypto);
> > > > is fine, it may be seen in attached fine_doc.xml
> > > > The updated after the the AxisUtil.updateSOAPMessage()=20
> > call Message=20
> > > > contains data entries corrupted by extra white spaces, as=20
> > appears in=20
> > > > the corrupted_doc.xml
> > > > Just to check the assuption that the problem caused within=20
> > > > AxisUtil.updateSOAPMessage() code by the DOMSource=20
> class, it was=20
> > > > changed by much worse, but suitable for test purposes:
> > > >=20
> > > >   original:
> > > > 	public static SOAPMessage updateSOAPMessage(
> > > > 		Document doc,
> > > > 		SOAPMessage message)
> > > > 		throws Exception {
> > > > 		DOMSource domSource =3D new DOMSource(doc);
> > > > 		message.getSOAPPart().setContent(domSource);
> > > > 		return message;
> > > > 	}
> > > >   changed:
> > > > 	public static SOAPMessage updateSOAPMessage(
> > > > 		Document doc,
> > > > 		SOAPMessage message)
> > > > 		throws Exception {
> > > >             String msgstr =3D=20
> > > > org.apache.axis.utils.XMLUtils.DocumentToString(doc);
> > > >             java.io.StringBufferInputStream sbis =3D new=20
> > > > java.io.StringBufferInputStream(msgstr);
> > > >             javax.xml.transform.stream.StreamSource source =3D
> > > >                     new=20
> > javax.xml.transform.stream.StreamSource(sbis);
> > > >             sm.getSOAPPart().setContent(source);=09
> > > >       }
> > > >=20
> > > > which solves the serialization problem.=20
> > > >=20
> > > > Sincerely
> > > > Sasha
> > > >=20
> >=20
> >=20
> > =3D=3D=3D=3D=3D
> > Davanum Srinivas - http://webservices.apache.org/~dims/
> >=20
>=20
>=20
> -------------------------------------------------------
> The SF.Net email is sponsored by EclipseCon 2004
> Premiere Conference on Open Tools Development and Integration
> See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
> http://www.eclipsecon.org/osdn
> _______________________________________________
> wss4j-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/wss4j-devel
>=20


-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn