Hi Roland,
Done that as you suggested:
http://issues.apache.org/jira/browse/HTTPCLIENT-665
Now, as far as the new architecture is concerned, is that using something completely different? I
suppose so looking at the different project names alone (separate auth package). How can we make
sure we get this working there too as soon as possible, since sooner or later we will migrate to it
as well.
Should I investigate into it and suggest (another JIRA issue I suppose) or is there someone working
on this and just needs to be informed so that he/she can include it? Just asking.
Thanks,
Lars
Roland Weber wrote:
Hello Lars,
I am looking for a way to persist (and actually replicate in a cluster
using Tomcat) the state of a user. It was suggested to do this in a
derived class and eventually put this into contrib. That would be fine,
but I cannot seem to figure out how to achieve that without at least
some sort of hook into the current HttpState class. Especially the
credentials are not made available as a list. It keeps the lists
private, so even derived classes cannot access them.
What I need is some sort of protected access, either to the maps
themselves or to a getter method returning the maps (or an Iterator etc.)
Please open a feature request in JIRA. The API for 3.1 is frozen,
but personally I could live with making the attributes protected
instead of private.
Is there a way to build this into the class - or any other means to
fully have access to the conversational state of a http session -
because otherwise I will have to resort drastic measures like changing
the class locally and recompile the lib. But then updates are a nightmare.
Don't worry about updates anymore. We hope that 3.1 final, due
in a few weeks, will be the last release of the 3.x codebase.
The 4.0 codebase is not compatible anyway.
Is there any reason why this is not wanted?
Nobody requested that the attributes be made accessible, or
provided a patch to that effect. It's as simple as that.
Now we don't touch the old code anymore unless we have to.
cheers,
Roland
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
