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]
