Hi Dan,
I tried your fix. It doesn't work. ElementSerializer is like this:
public Element toXML(Object obj, QName qname)
{
if (obj == null)
return XmlUtils.createElement(qname);
//
// short circuit - no need to recreate the Element if
// the names are already the same
//
QName currentName = XmlUtils.getElementQName((Element)obj);
if (currentName.equals(qname))
return (Element)obj;
return XmlUtils.createElement(XmlUtils.EMPTY_DOC, qname, obj);
}
It throws an exception like this:
org.apache.muse.ws.addressing.soap.SoapFault: WRONG_DOCUMENT_ERR: A node
is used in a different document than the one that created it.
at
org.apache.muse.core.AbstractResourceClient.invoke(AbstractResourceClient.java:298)
at
org.apache.muse.core.AbstractResourceClient.invoke(AbstractResourceClient.java:232)
at
org.apache.muse.core.AbstractResourceClient.invoke(AbstractResourceClient.java:211)
[my code begins here...]
It seems the code calling the serializer assumes that the returned
element belongs to the XmlUtils.EMPTY_DOC document. This works:
public Element toXML(Object obj, QName qname)
{
if (obj == null)
return XmlUtils.createElement(qname);
//
// short circuit - no need to recreate the Element if
// the names are already the same
//
QName currentName = XmlUtils.getElementQName((Element)obj);
if (currentName.equals(qname))
return (Element) XmlUtils.EMPTY_DOC.importNode((Element)
obj, true);
return XmlUtils.createElement(XmlUtils.EMPTY_DOC, qname, obj);
}
Cheers,
Erik
Daniel Jemiolo wrote:
> Just wanted to let you know that tonight's build will incorporate both
> those fixes... the JARs you'd need are muse-core and muse-wsa-soap.
>
> Dan
>
>
>
> Erik Rissanen <[EMAIL PROTECTED]> wrote on 04/12/2007 02:06:54 PM:
>
>
>> I actually used toString(xml, true, false) since it was the indentation
>> which was the problem, not the <?xml> header.
>>
>> Don't forget to fix the ElementSerializer as well. It breaks the
>> signature by changing the namespace prefix. I am not sure what the
>> correct fix is there since other Muse code might depend on the current
>> behavior.
>>
>> I'll let you know if I find problems in Axis, but I'll go with the mini
>> engine for now. Lots of work to do. :-)
>>
>> Thanks,
>> Erik
>>
>>
>> Daniel Jemiolo wrote:
>>
>>> Thanks for the SoapClient fix - that's a tricky one. I knew were
>>>
> weren't
>
>>> adding actual whitespace text nodes to the DOM, so I couldn't fathom
>>>
> why
>
>>> there would be more whitespace on the outgoing message. I'll fix it so
>>>
>
>
>>> that we use toString(xml, false, false), which will disable
>>>
> indentation.
>
>>> Please update us if you find a similar problem in the Axis2/Axiom code
>>>
>
>
>>> that accounts for the remaining issues.
>>>
>>> Dan
>>>
>>>
>>>
>>> Erik Rissanen <[EMAIL PROTECTED]> wrote on 04/10/2007 05:58:54 AM:
>>>
>>>
>>>
>>>> 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]
>>>
>>>
>>>
>> ---------------------------------------------------------------------
>> 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]
