I tried it with the mini engine, and it works now. Fixing the SimpleSoapClient and the ElementSerializer is all that is needed in Muse. Axis still breaks the message by re-indenting it, but the mini engine is ok.
Regards, Erik Erik Rissanen wrote: > Daniel, > > I have looked for the source of the indentation. In > SimpleSoapClient.java at line 247: > > byte[] soapBytes = XmlUtils.toString(soapRequest).getBytes(); > > This does indentation, so it will break the message on the client side > before it is sent. However, fixing this didn't take care of the problem, > so something else does indentation as well. > > I made a search for the use of XmlUtils.toString in the muse source and > I got 45 hits. Most seemed ok, but I didn't go through all of them. > > I have not looked at the Axis code, which might also do indentation. > > I need to work on some other things today, but I will look into this > later. If Axis is the source of the remaining problems, using the mini > engine might solve it for me. I will try the mini engine later when I > have time again. > > Regards, > Erik > > > Daniel Jemiolo wrote: > >> From a Muse perspective, the only time we add indentation is in >> XmlUtils.toString(), which is used if you turn on SOAP tracing (log-level >> = FINE in muse.xml). This just makes it easier to read the log file. You >> can stop the indentation all together by using this version of >> XmlUtils.toString(): >> >> http://ws.apache.org/muse/docs/2.2.0/javadoc/org/apache/muse/util/xml/XmlUtils.html#toString(org.w3c.dom.Node,%20boolean,%20boolean) >> >> The point is that, from a Muse perspective, we don't add any additional >> whitespace nodes/indentation when processing the message - it just happens >> when we trace. If you look in the Axis2 service code, we just take the >> SOAP body as it comes from Axis2 (in Axiom form), convert it to DOM, and >> hand off the DOM tree to your method: >> >> http://svn.apache.org/viewvc/webservices/muse/trunk/modules/muse-platform-axis2/src/org/apache/muse/core/platform/axis2/AxisIsolationLayer.java?revision=522017&view=markup >> >> The Axiom -> DOM conversion is pretty straightforward - I could understand >> if we had *missed* something in the copying, but *adding* new things would >> be hard. >> >> Does this problem happen if you use the Mini SOAP engine (-j2ee mini)? If >> not, the problem may be with Axiom/Axis2. I've noticed that, like Axis >> 1.x, there are still cases where Axis2 adds in prefix/namespace >> declarations, and so the addition of blank/whitespace text nodes does not >> seem impossible. >> >> >> >> Erik Rissanen <[EMAIL PROTECTED]> wrote on 04/09/2007 02:51:06 AM: >> >> >> >>> Daniel Jemiolo wrote: >>> >>> >>>> Can you give an example of the changing of XML prefixes? This was >>>> >>>> >> actually >> >> >>>> a major problem for us with the various SOAP engines we targeted >>>> >>>> >> (because >> >> >>>> WSRF is very dependent on prefixes staying the same), so we make sure >>>> >>>> >> not >> >> >>>> to modify prefixes in the request handling. Let me know what's >>>> >>>> >> happening. >> >> >>>> Also, are you signing things as part of the operation implementations? >>>> >>>> >> >> >>>> Normally this is done with something like WSS4J, which you can enable >>>> >>>> >> as >> >> >>>> an Axis2 handler (so the envelope will be completely finished when you >>>> >>>> >> >> >>>> sign or validate it). >>>> >>>> Dan >>>> >>>> >>>> >>>> Erik Rissanen <[EMAIL PROTECTED]> wrote on 04/08/2007 01:52:42 PM: >>>> >>>> >>>> >>>> >>>>> Hello, >>>>> >>>>> I am using Apache Muse 2.2.0 for implementing a web service. I need >>>>> >>>>> >> to >> >> >>>>> pass digitally signed XML documents to the service. The problem I >>>>> >>>>> >> have >> >> >>>>> is that Muse re-indents the XML and changes namespace prefixes. This >>>>> breaks the signatures. >>>>> >>>>> Is this a bug, feature or do I need to reconfigure muse somehow? I >>>>> >>>>> >> tried >> >> >>>>> to search the web, this list and the bug tracking system, but I >>>>> >>>>> >> couldn't >> >> >>>>> find anything. >>>>> >>>>> Regards, >>>>> Erik >>>>> >>>>> >>>>> >>>>> >>> The signature is for an XML document which is signed standalone. I am >>> not signing the WS invocation itself, rather I am transmitting a >>> document which has been previously signed. So WSS4J is not what I am >>> looking for here. >>> >>> The schema for the messages looks like this: >>> >>> <xsd:schema elementFormDefault="qualified" >>> targetNamespace="http://sics.se/my-stuff";> >>> >>> <xsd:element name="AddPolicy"> >>> <xsd:complexType> >>> <xsd:sequence> >>> <xsd:element ref="saml:Assertion" /> >>> </xsd:sequence> >>> </xsd:complexType> >>> </xsd:element> >>> >>> <xsd:element name="AddPolicyResponse" type="xsd:anyURI"/> >>> </xsd:schema> >>> >>> I use wsdl2java to generate a client proxy which has the following >>> >>> >> method: >> >> >>> URI addPolicy(Element assertion) throws SoapFault; >>> >>> I read my signed document from disc and parse it into a DOM. I pass the >>> document element of this DOM to the above method. The document looks >>> like this (fragments only since it is quite long): >>> >>> <?xml version="1.0" encoding="UTF-8"?> >>> <saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" >>> ID="ID_191adef5-f5a9-40b6-a0c1-c23ca7de3c6c" >>> IssueInstant="2007-04-08T13:56:13Z" Version="2.0"> >>> <saml:Issuer >>> Format="http://www.w3.org/2001/XMLSchema#string";>...</saml:Issuer> >>> <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#";> >>> ... >>> <ds:Reference URI="#ID_191adef5-f5a9-40b6-a0c1-c23ca7de3c6c"> >>> ... >>> </ds:Signature> >>> <saml:Statement >>> xmlns:xacml-saml="urn:oasis:xacml:3.0:saml:assertion:schema:os" >>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; >>> xsi:type="xacml-saml:XACMLPolicyStatementType"> >>> <xacml:Policy xmlns="urn:oasis:names:tc:xacml:3.0:schema:os" >>> xmlns:xacml="urn:oasis:names:tc:xacml:3.0:schema:os" PolicyId="..." >>> RuleCombiningAlgId="..." Version="1.0"> >>> <xacml:Target> >>> <xacml:DisjunctiveMatch> >>> ... >>> >>> >>> On the server side wsdl2java generates the following: >>> >>> public URI addPolicy(Element Assertion) throws Exception { >>> .... >>> } >>> >>> When I receive the document here it doesn't look right. notice the >>> prefix "pfx3" and the excessive amount of indentation: >>> >>> <pfx3:Assertion ID="ID_191adef5-f5a9-40b6-a0c1-c23ca7de3c6c" >>> IssueInstant="2007-04-08T13:56:13Z" Version="2.0"> >>> >>> >>> >>> <saml:Issuer >>> >>> >>> >> Format="http://www.w3.org/2001/XMLSchema#string";>...</saml:Issuer><ds:Signature> >> >> >>> .... >>> >>> <ds:SignedInfo> >>> </ds:KeyInfo></ds:Signature><saml:Statement >>> xmlns:xacml-saml="urn:oasis:xacml:3.0:saml:assertion:schema:os" >>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; >>> type="xacml-saml:XACMLPolicyStatementType"> >>> >>> <xacml:Policy PolicyId="..." RuleCombiningAlgId="..." >>> Version="1.0"> >>> >>> >>> <xacml:Target> >>> >>> >>> >>> <xacml:DisjunctiveMatch> >>> >>> >>> xsi:type has also been changed to just type in the saml:Statement >>> >>> >> element. >> >> >>> I got the above document by encoding the received Assertion element to a >>> file in the capability implementation. I used the apache xml-security >>> canonicalizer for the encoding: >>> >>> Canonicalizer canon = Canonicalizer.getInstance >>> (Canonicalizer.ALGO_ID_C14N_WITH_COMMENTS); >>> FileOutputStream fouts = new >>> >>> >> FileOutputStream("/tmp/tete2.xml"); >> >> >>> fouts.write(canon.canonicalizeSubtree(Assertion)); >>> fouts.close(); >>> >>> I don't think it is the canonicalizer which messes up the file. I also >>> tried to use the Muse XmlUtils class for this encoding, in which case >>> the document looks different from above. (The indentation is prettier.) >>> >>> I am using the axis2 engine and I deploy the war in tomcat 5 on Fedora >>> Core 6 Linux. >>> >>> Thanks for your assistance, >>> Erik >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>> For additional commands, e-mail: [EMAIL PROTECTED] >>> >>> >>> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
