Hi Marc,
I am sorry for my patch just tested with the http transport not the
local transport.
Your patch is very helpful, in this way we could set the properties from
the CxfEndpoint spring configuration.
That is why I love Open Source, shaping the software with community :).
I will put it into the repository.
Cheers,
Willem
Marc Giger wrote:
Hi Willem
On Fri, 14 Mar 2008 13:07:13 +0800
Willem Jiang <[EMAIL PROTECTED]> wrote:
Hi Marc,
I just committed your patch for CAMEL-384 and my patch for CAMEL-386
which will fix your HTTP 500 response code issue :)
Please check them out.
I tested your patch, but see no difference in the behavor.
After studying the local-transport code from cxf I found out why a
fault got returnes as 200 HTTP code. The local-transport code uses
as default a piped in/out stream with threads. As a result the CxfClient
doesn't know what is returned. I have two solutions to my problem:
Either I write my own local-transport
or you accept the following patch , so we can set a property
on the jaxws-endpont so that the LocalConduit uses direct-dispatch
instead of the piped-dispatch. (@see
org.apache.cxf.transport.local.LocalConduit)
Index: src/main/java/org/apache/camel/component/cxf/invoker/CxfClient.java
===================================================================
--- src/main/java/org/apache/camel/component/cxf/invoker/CxfClient.java
(revision 637142)
+++ src/main/java/org/apache/camel/component/cxf/invoker/CxfClient.java
(working copy)
@@ -109,6 +109,12 @@
Message message = prepareMessage(exchange, requestContext, param, invokingContext);
+ //add the endpoint props to the message
+ Endpoint ep = getEndpoint();
+ if (ep != null) { //can ep be null?
+ message.putAll(ep);
+ }
+
PhaseInterceptorChain chain = setupInterceptorChain(getEndpoint());
message.setInterceptorChain(chain);
What do you think? I don't see another way to set this property.
Thanks
Marc
Cheers,
Willem
Marc Giger wrote:
Hi Willem
On Wed, 12 Mar 2008 20:33:38 +0800
Willem Jiang <[EMAIL PROTECTED]> wrote:
Hi Marc
I think we could do some improvement on the MESSAGE Data format,
so we could handle the customer Exception more easily. Why do you
not want the HTTP 200 return to the client side?
Because the soap specification wants a 500 in case of an
soap-fault;-)
Perhaps I didn't express me exactly:
If I throw a fault in my service-method (localEndpoint;JAXB
Binding) it will be marshalled and returned as 200 instead of a 500
status code. And that's not correct...
I have to investigate more time to understand how camel-cxf
interacts with cxf so that I can come up with a solution. It would
be very nice if camel-cxf supports dataformat mixing between source
endpoint and destination endpoint. Would it be helpful to write
some testcases...?
BTW,
I am looking forward your better patch :)
My patch is not better, but an enhancement;-) It's a addition to
your commits and allows also to set the detail and the fault-code
in the soap-fault.
Thanks for your time
Greets
Marc
Willem
Marc Giger wrote:
Hi,
Following scenario:
<camelContext id="camel"
xmlns="http://activemq.apache.org/camel/schema/spring">
<route> <from uri="cxf:bean:routerEndpoint?dataFormat=MESSAGE"/>
<process ref="decryptProcessor"/>
<choice>
<when>
<methodCall bean="endpointSelector"
method="matches"/> <to
uri="cxf:bean:serviceEndpoint?dataFormat=MESSAGE"/> </when>
<otherwise>
<to uri="cxf:bean:localEndpoint"/>
</otherwise>
</choice>
</route>
</camelContext>
Where the localEndpoint is POJO (JAXB).
The requirements are the following:
Route the message to a local endpoint if some criteria matches in
the endpointSelector. Otherwise do a invoke of a remote endpoint.
An important point is that the message is nowhere
marshalled/unmarshalled when the remote endpoint is invoked.
Otherwise the wss-signature will be invalid. So handle the
message as raw inputStream.
All is working fine so far but the localEndpoint invocation.
If I specify the dataFormat=MESSAGE on the local endpoint, it
works. But an User generated exception will be returned as 200
http code.
Do you see any chance to get this mixes dataFormat setup somehow
working with camel-cxf?
@Willem: I've tested your changes to the fault handling. It's
better now but not perfect;-) I have a patch in my queue which
solves the custom soap-fault handling in camel-cxf. I will report
it in jira.
Thanks!
Cheers,
Marc