Hi Willem,
some minor tests passed today so it looks quite good. I'm probably ready for
a "full" test tomorrow.
But right now this looks really promising.
Regards, Achim
2011/10/10 Willem Jiang
> Hi Achim,
>
> Did you have a chance to try to set the request context header of address ?
> You ca
Hi Willem,
I just was able to test this today, and it looks ok so far, but I wasn't
able to test "multiple" hosts yet :)
Will give feedback if that succeeds, so this looks also as
a promising solution.
Never the less I think the behavior I experienced seems to be a bug in the
endpoint cache.
Than
Hi Achim,
Did you have a chance to try to set the request context header of address ?
You can override the endpoint address by using it.
On Fri Oct 7 21:07:14 2011, Achim Nierbeck wrote:
Ok, this only solved half of my problem or better it postponed it.
Now I do have the following scenario:
Ok, this only solved half of my problem or better it postponed it.
Now I do have the following scenario:
Call for Service on Host A works as expected,
the Endpoint is stored in the cache.
Call for Service on Host B does create a new Endpoint
and this one is also stored in the cache.
Now a thir
The suggested workaround by Jon really does the trick.
instead of using the recipientlist inside the spring route:
cxf:bean:productionServer?address=${header.address}
I used a std. bean which looks like the following:
public class WebServiceRecip
Hi,
You can set the request context on the message to workaround this issue.
Here is an example from camel-cxf unit test[1] that you can take a look.
[1]https://svn.apache.org/repos/asf/camel/trunk/components/camel-cxf/src/test/java/org/apache/camel/component/cxf/CxfProducerContextTest.java
On
FYI created https://issues.apache.org/jira/browse/CAMEL-4503 for the
recipient list bug and Achim is trying out another approach to workaround
this issue.
On Thu, Sep 29, 2011 at 11:46 AM, Achim Nierbeck wrote:
> I did take a look at the sources and I think I found the
> root of my problem, thoug
I did take a look at the sources and I think I found the
root of my problem, though I'm not sure how to get around it:
RecipientList class contains a producer cache,
in this cache the RecipientListProcessor class does store the
endpoints depending on the uri as key.
Now since only my header change
Ok,
some more worrying details.
Right now I have two Remote Hosts
After a successful run on Host A a second run is done (not parallel
but sequential) on Host B.
And I'm able to see that the header.address is set to host B still I
see that the request is made on Host A.
Is this intentional, are t
Hi
using Camel 2.8.0 I'm having the following scenario.
I'm using the CXF for connecting to a couple .NET Webservices.
http://tempuri.org/";
xmlns:a="http://schemas.microsoft.com/2003/10/Serialization/Arrays";
xmlns:i="http://www.w3.org/2001/XMLSc
10 matches
Mail list logo
