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.<init>(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