You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by bu...@apache.org on 2004/09/10 16:24:20 UTC
DO NOT REPLY [Bug 31163] New: -
DateParser refactoring; Stateful cookie specs
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=31163>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=31163
DateParser refactoring; Stateful cookie specs
Summary: DateParser refactoring; Stateful cookie specs
Product: Commons
Version: Nightly Builds
Platform: Other
OS/Version: Other
Status: NEW
Severity: Normal
Priority: Other
Component: HttpClient
AssignedTo: commons-httpclient-dev@jakarta.apache.org
ReportedBy: olegk@apache.org
Presently DateParser is tightly coupled with the DefaultHttpParams class. I find
this sub-optimal from the design standpoint. Moreover, I believe that date
patterns should be specifiable at the method, host, and client levels, not only
global one. Currently this is not the case, and out of sync with the rest of the
preference framework, which can result in quite a bit of confusion.
When refactoring the DateParser class I also realized that the cookie specs were
shared by all the HttpMethod instances and as such had to be stateless. Even
though it is presently the case, technically there's nothing that prevents the
user from implementing a stateful cookie spec, plugging it into HttpClient, and
by doing so potentially causing quite unpleasant concurrency issues. Therefore,
I believe pluggable cookie specs MAY NOT be shared. There should be a cookie
spec instance created per method invocation
Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org