You are viewing a plain text version of this content. The canonical link for it is here.
Posted to httpclient-users@hc.apache.org by Lars George <la...@worldlingo.com> on 2007/07/14 00:32:47 UTC
Serialize HttpState
Hi,
As discussed quite some time ago here
http://mail-archives.apache.org/mod_mbox/jakarta-commons-httpclient-dev/200306.mbox/%3C0C9CA5EC-9CD1-11D7-8308-000393016056@intencha.com%3E
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.)
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.
Is there any reason why this is not wanted? I do understand the reasoning in the mail thread above
and agree that the developers (we) have to make sure we handle those credentials properly
internally. But since we sort of have access to them already, why not at least provide some means to
extend the class and implement the serialization on top of it?
Any help or comment is appreciated.
Regards,
Lars
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-user-help@jakarta.apache.org
Re: Serialize HttpState
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Sat, 2007-07-14 at 01:40 +0200, Roland Weber wrote:
> Hi Lars,
>
> > 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).
>
> Yes, it is completely different. The HttpState class will make
> it into client alpha1 (though in a different package), but I'm
> already sharpening my axe to split it in two.
>
Folks,
I am planning to replace HttpState with two interfaces, CookieStore and
CredentialsProvider, during ALPHA2 unless someone else beats me to it.
We are going to provide default implementations of these interfaces but
users should easily be able to plug in custom implementations as well.
Oleg
> > 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.
>
> I'm not sure what your interpretation of "sooner or later" is.
> We don't even have client alpha1 out of the door. HttpCore is
> currently at alpha5 with releases about every 3 to 4 months.
> You can expect the new client API to stabilize some time in 2008.
> Of course you can help us by being an early adopter and providing
> feedback on how the API can be improved. But if you have code
> that is supposed to go productive in 2007 or early 2008, then
> HttpClient 3.1 is still the preferred choice.
>
> > 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.
>
> No need for JIRA issues on this level of detail at this time.
> We are informed, thanks :-)
>
> cheers,
> Roland
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: httpclient-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-user-help@jakarta.apache.org
Re: Serialize HttpState
Posted by Roland Weber <os...@dubioso.net>.
Hi Lars,
> 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).
Yes, it is completely different. The HttpState class will make
it into client alpha1 (though in a different package), but I'm
already sharpening my axe to split it in two.
> 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.
I'm not sure what your interpretation of "sooner or later" is.
We don't even have client alpha1 out of the door. HttpCore is
currently at alpha5 with releases about every 3 to 4 months.
You can expect the new client API to stabilize some time in 2008.
Of course you can help us by being an early adopter and providing
feedback on how the API can be improved. But if you have code
that is supposed to go productive in 2007 or early 2008, then
HttpClient 3.1 is still the preferred choice.
> 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.
No need for JIRA issues on this level of detail at this time.
We are informed, thanks :-)
cheers,
Roland
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-user-help@jakarta.apache.org
Re: Serialize HttpState
Posted by Lars George <la...@worldlingo.com>.
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: httpclient-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: httpclient-user-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-user-help@jakarta.apache.org
Re: Serialize HttpState
Posted by Roland Weber <os...@dubioso.net>.
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: httpclient-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-user-help@jakarta.apache.org