Hi Jakub,
I've created a patch to deal with the per user/per thread state management with the HttpClient. I've also noticed that the same issue has been ported to the new Jersey ApacheConnector. I have also provided a patch for that as well. ApacheHttpClient4Handler is for Jersey 1.17 and the ApacheClientProperties as well as ApacheConnector are for Jersey 2.1.
I haven't tested it, but we have been using a Javassist to manipulate the byte code to do what the patch is supposed to do and that works fine.
Let me know if this helps,
Russ Baker
From: Russ Baker [mailto:rbaker_at_ghx.com]
Sent: Tuesday, July 16, 2013 3:16 PM
To: users_at_jersey.java.net
Subject: [Jersey] Re: per user/thread cookie management
Hi Jakub,
Please see inline.
From: Jakub Podlesak [mailto:jakub.podlesak_at_oracle.com]
Sent: Friday, July 12, 2013 6:36 AM
To: users_at_jersey.java.net<mailto:users_at_jersey.java.net>
Subject: [Jersey] Re: per user/thread cookie management
Hi Russ,
Please see inline.
On Jul 9, 2013, at 4:29 PM, Russ Baker <rbaker_at_ghx.com<mailto:rbaker_at_ghx.com>> wrote:
Hello Jersey Users,
We have implemented a performance enhancement by using only one HttpClient per application, and we are having issues with the cookie store. It seems as if each time we make a call, the cookie store is shared across calls instead of a new one used for each user/thread. This is causing us problems with our identity service because it thinks that the same user is making a call, when in fact it is another authenticated user.
There is the possibility to configure a non default connection manager. Is your enhancement related to this?
Could your please explain?
No the enhancement would not pertain to the default connection manager.
From looking at the HttpComponents website -
http://hc.apache.org/httpcomponents-client-ga/tutorial/html/statemgmt.html#d5e849 -it would appear that we need be able to access the "execute" method of the httpclient that specifies the cookie policy and provides a BasicCookieStore. In jersey-apache-client4-1.17.1, we are not able to do this as this is in the final class "ApacheHttpClient4Handler" and cannot override the class with our own implementation.
I presume, you want to stick with the Jersey client API, but need to propagate the localContext down the stack, right? - That is correct
Would you be willing to contribute your implementation to Jersey? Then i think you just need to extend the original class(es), no need to inherit from there.
Could your please clarify?
I can provide a patch if that would help.
Besides using Javasisst to insert this code dynamically, is there a way that we can get the wrapped httpclient in the ApacheHttpClient4Handler to use a cookie jar on a per user/thread basis programatically or via configuration?
I am not aware of such a possibility. We would most likely need to update Jersey. It would be brilliant, if you would be willing
to contribute this piece of functionality to Jersey. - I would love to do that!
If you do not want to contribute (which is also fine), please share some details on your implementation, so that we can agree
on changes needed on the Jersey side, so that you can easily plug in. - Will do. I'm really busy at work, but I will be able to put some time into it in the next few weeks. Stay tuned...
Thanks,
~Jakub
P.S. Here is a writing on how to contribute:
https://jersey.java.net/scm.html
Russ Baker
Senior Software Engineer