On 2009-11-24, at 下午8:04, Salgar, Mehmet (external) wrote:
Hallo.
thx for the answer and I am sorry for the late response....
I solved this problem by changing saxon:xslt result type to 'dom'
actually I don't like this because I prefer the solution stays
stream based and not DOM based but I would look to the problem
further when I get the complete scenario runnning...
Now I have another funnier problem, now I can make the XSLT
transformation and transformed message is forwarded to CXF Provider
component but when Provider module deletes the namespaces that I
included during the transformation...
I think code first, learn later the internals method had reached to
it limits...So do you have any idea why the namespaces from like
bottom is dissapeared..
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/
envelope/" xmlns:suc="http://xxx.test.org/types" ...
is converted only to
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
Hi,
That's because cxf bc provider transform soap message based on the
wsdl model, so any namespace which is not defined in wsdl will be
ignored.
Freeman
in CXF Provider component, I can see that in Exchange debug content
is correctly delivered (Debug from
org.apache.servicemix.nmr.core.ChannelImpl display the correct SOAP
Message)...
My only theorie is, saxon make the correct translation but it
doesn't enter the namespace information someplace in exchange?????
Thx for the answers....
T-Mobile Deutschland GmbH
Aufsichtsrat: Timotheus Höttges (Vorsitzender)
Geschäftsführung: Niek Jan van Damme (Sprecher), Thomas Berlemann,
Thomas Dannenfeldt, Albert Henn,
Dr. Christian P. Illek, Dr. Bruno Jacobfeuerborn, Dr. Dirk Rohweder
Handelsregister: Amtsgericht Bonn, HRB 59 19
Sitz der Gesellschaft: Bonn
WEEE-Reg.-Nr.: DE60800328
-----Ursprüngliche Nachricht-----
Von: Gert Vanthienen [mailto:[email protected]]
Gesendet: Donnerstag, 12. November 2009 18:46
An: [email protected]
Betreff: Re: Is this possible
L.S.,
That use case is definitely supported by ServiceMix, but it's very
hard to figure out what the problem is without seeing the actual
exception. Can you post the full stacktrace of the exception you get?
There are two things that come to mind:
- could you try varying the output type on the servicemix-saxon
endpoint to e.g. output="string" to see if that avoids the
ClassCastException?
- have you specified useJBIWrapper="false" on the CXF provider
endpoint? without this setting, the CXF BC provider endpoint
expects the message to be in the JBI wrapper format instead of a
plain SOAP message
Regards,
Gert Vanthienen
------------------------
Open Source SOA: http://fusesource.com
Blog: http://gertvanthienen.blogspot.com/
2009/11/12 Salgar, Mehmet (external) <[email protected]
>:
Hi everybody,
I am trying to configure to transform a cxf-bc-consumer received
soap
message with xslt and redirect to another cxf-bc-provider...
Receiving the message at consumer and transforming the message with
saxon and an eip pipeline works fine but when the provider receives
the message it throws a ClassCastException that it can't cast
org.w3.Element to org.apache.....xerces.DeferedElement (I don't have
the exact class name at the moment)....
What is not clear to me, I can see with debuging that xslt
transformation is valid and I have a valid soap message (String
output
of the message, I can send with SOAP UI to server without any
problem)...
So why a transformed xslt message in a eip pipeline is not valid for
cxf-bc-provider, has anybody an idea?
Thx for the answers....
T-Mobile Deutschland GmbH
Aufsichtsrat: Timotheus Hottges (Vorsitzender)
Geschaftsfuhrung: Niek Jan van Damme (Sprecher), Thomas Berlemann,
Thomas Dannenfeldt, Albert Henn, Dr. Christian P. Illek, Dr. Bruno
Jacobfeuerborn, Dr. Dirk Rohweder
Handelsregister: Amtsgericht Bonn, HRB 59 19 Sitz der Gesellschaft:
Bonn
WEEE-Reg.-Nr.: DE60800328
--
Freeman Fang
------------------------
Open Source SOA: http://fusesource.com