So we modified our code and did the following logic:
Object cookie = loginResponse.getMetadata().getFirst("Set-Cookie");
webClient.header("Cookie", cookie);
So now we get our response from our original login (3rd party invocation),
we get the response and retrieve the first "Set-Cookie", which gives us a
String containing our two cookies.
We then use the header method to add the cookie back to the WebClient
instance before we make our second invocation.
This seems to work with a single request, but when we start to send 11
requests in (as an example), we get our problem again where some requests
succeed, and some requests seem to lose the cookie because our 3rd party
service says we tried the second invocation service without logging in. So
unless I set the cookie incorrectly, this didn't work for us yet.
The totally insane part of this is we are doing two parallel paths, one
solution using WebClient and one with Apache's HttpClient. WebClient so far
is tripping over itself in a multi-threaded fashion, but Apache's HttpClient
is not (it works with the multiple requests). But HttpClient fails on the
hostname verification (because WLS has a problem with wildcarded certs), yet
the WebClient's hostname verification works within WLS. So we are trying to
get both WebClient to work by working with the Cookies, and HttpClient to
work by determining where WLS is invoking it's own classpath and ignoring
Apache's AllowAllHostnameVerifier.
--
View this message in context:
http://cxf.547215.n5.nabble.com/WebClient-multithreading-within-a-DefaultMessageListenerContainer-tp5719525p5719745.html
Sent from the cxf-user mailing list archive at Nabble.com.
