Mailing-List: contact httpclient-user-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "HttpClient User Discussion" <httpclient-user@jakarta.apache.org>
Received-SPF: pass (herse.apache.org: domain of lars@worldlingo.com designates
 204.15.165.130 as permitted sender)
Message-ID: <46980AA2.300@worldlingo.com>
Date: Fri, 13 Jul 2007 16:28:34 -0700
From: Lars George <lars@worldlingo.com>
User-Agent: Thunderbird 2.0.0.4 (Windows/20070604)
MIME-Version: 1.0
To: HttpClient User Discussion <httpclient-user@jakarta.apache.org>
Subject: Re: Serialize HttpState
References: <4697FD8F.9020609@worldlingo.com> <46980619.6030006@dubioso.net>
In-Reply-To: <46980619.6030006@dubioso.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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