DO NOT REPLY [Bug 15435] - New Preferences Architecture
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15435. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15435 New Preferences Architecture [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2003-10-26 09:57 --- Patch committed. It looks like the journey is finally over. Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 15435] - New Preferences Architecture
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15435. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15435 New Preferences Architecture --- Additional Comments From [EMAIL PROTECTED] 2003-10-25 11:43 --- Created an attachment (id=8734) Follow-up patch 4 (take 2) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 15435] - New Preferences Architecture
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15435. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15435 New Preferences Architecture --- Additional Comments From [EMAIL PROTECTED] 2003-10-25 11:46 --- - What happened to the soTimeout option? Mike, I do not quite get what is the point of your concern hrere. Socket read timeout has been moved to HttpConnectionManagerParams. I believe that is where it should be. Let me know what you think about the new patch Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 15435] - New Preferences Architecture
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15435. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15435 New Preferences Architecture --- Additional Comments From [EMAIL PROTECTED] 2003-10-25 18:22 --- Oleg, Perhaps I'm missing something but I don't see the soTimeout option on the HttpConnectionManagerParams. Mike - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 15435] - New Preferences Architecture
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15435. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15435 New Preferences Architecture --- Additional Comments From [EMAIL PROTECTED] 2003-10-25 18:33 --- Mike, HttpConnectionManagerParams inherits SO_TIMEOUT/TCP_NODELAY/SO_RCVBUF/SO_SNDBUF parameters along with several others from HttpConnectionParams. Do you see any problem with that? Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 15435] - New Preferences Architecture
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15435. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15435 New Preferences Architecture --- Additional Comments From [EMAIL PROTECTED] 2003-10-25 19:03 --- Oleg, You are quite right. Somehow I seem to have missed that :) I agree I think HttpConnectionParams is the right place for soTimeout, et al. The patch looks good to me. Mike - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 15435] - New Preferences Architecture
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15435. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15435 New Preferences Architecture --- Additional Comments From [EMAIL PROTECTED] 2003-10-24 02:03 --- Oleg, A few comments: - I think the connectionManagerTimeout should be left on the HttpClient. The value is used by HttpClient/HttpMethodDirector when retrieving connections and not directly by the connection managers. In fact this seems to be causing a compile error in HttpMethodDirector, which was initially undetected by Eclipse for some reason. - What happened to the soTimeout option? I agree MultiThreadedHttpConnectionManager maxHostConnections and maxTotalConnections should be moved to preferences and deprecated. Mike - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 15435] - New Preferences Architecture
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15435. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15435 New Preferences Architecture --- Additional Comments From [EMAIL PROTECTED] 2003-10-22 19:45 --- Follow-up patch 3 committed. I am planning to submit one more, hopefully the final, follow-up patch shortly Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 15435] - New Preferences Architecture
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15435. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15435 New Preferences Architecture --- Additional Comments From [EMAIL PROTECTED] 2003-10-22 20:56 --- Created an attachment (id=8679) Follow-up patch 4 (take 1) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 15435] - New Preferences Architecture
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15435. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15435 New Preferences Architecture --- Additional Comments From [EMAIL PROTECTED] 2003-10-20 12:14 --- Oleg, Ah. I see what you are doing. This seems like a decent solution, nothing better comes to mind. To keep things consistent I think setSoTimeout(int) should still set the timeout on the socket, if present. The new Javadoc @link on setSoTimeout() should be changed to setSocketTimeout(). Other than that I think it's good to be committed. Mike - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 15435] - New Preferences Architecture
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15435. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15435 New Preferences Architecture --- Additional Comments From [EMAIL PROTECTED] 2003-10-19 17:57 --- Mike, I agree it's ugly. The problem is there are situations when read timeout must be changed on an open socket (when handling 100-continue handshake) The choice here is between two evils: either make HttpConnectionParams tightly coupled with HttpConnection or Socket object, or to provide a way to set read timeout on Httpconnection directly. If you see a more elegant way of solving the problem, give me a hint Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 15435] - New Preferences Architecture
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15435. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15435 New Preferences Architecture --- Additional Comments From [EMAIL PROTECTED] 2003-10-17 16:24 --- Created an attachment (id=8609) Follow-up patch 3 (take 2) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 15435] - New Preferences Architecture
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15435. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15435 New Preferences Architecture --- Additional Comments From [EMAIL PROTECTED] 2003-10-17 16:26 --- New patch adds receive buffer size parameter for HttpConnection and HttpConnectionManager classes. Folks, any feedback on the follow-up patch 3 so far? Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 15435] - New Preferences Architecture
Hi Oleg, Sorry for being a little slow on this patch. I took a quick look at it a few days ago, but did not have enough time to make any useful comments. I will look again this weekend. Mike [EMAIL PROTECTED] wrote: DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15435. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15435 New Preferences Architecture --- Additional Comments From [EMAIL PROTECTED] 2003-10-17 16:26 --- New patch adds receive buffer size parameter for HttpConnection and HttpConnectionManager classes. Folks, any feedback on the follow-up patch 3 so far? Oleg - 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]
DO NOT REPLY [Bug 15435] - New Preferences Architecture
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15435. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15435 New Preferences Architecture --- Additional Comments From [EMAIL PROTECTED] 2003-10-03 21:04 --- Follow-up patch 2 (take 1) committed. Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 15435] - New Preferences Architecture
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15435. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15435 New Preferences Architecture --- Additional Comments From [EMAIL PROTECTED] 2003-10-02 13:58 --- Created an attachment (id=8429) Follow-up patch 2 (take 1) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 15435] - New Preferences Architecture
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15435. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15435 New Preferences Architecture --- Additional Comments From [EMAIL PROTECTED] 2003-10-03 02:18 --- Looks good to me. Mike - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 15435] - New Preferences Architecture
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15435. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15435 New Preferences Architecture --- Additional Comments From [EMAIL PROTECTED] 2003-09-23 06:19 --- Oleg, I like it. Mike, there is no copy constructor right now. As it would have the same signature as the constructor that takes default parameters, I suggest to leave it that way. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 15435] - New Preferences Architecture
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15435. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15435 New Preferences Architecture --- Additional Comments From [EMAIL PROTECTED] 2003-09-23 13:45 --- All right then. I'll commit the patch around 22:00 GMT, if nobody objects Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 15435] - New Preferences Architecture
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15435. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15435 New Preferences Architecture --- Additional Comments From [EMAIL PROTECTED] 2003-09-23 19:57 --- Follow-up patch 1 (take 2) committed. Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 15435] - New Preferences Architecture
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15435. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15435 New Preferences Architecture --- Additional Comments From [EMAIL PROTECTED] 2003-09-22 11:26 --- Hello Oleg, 1. public HttpClient(HttpClientParams params) Can we add something like HttpConnectionManager.setParams(p)? I think the newly created connection manager should have a chance to learn from the parameters how many connections it is supposed to create and such stuff. 2. DefaultHttpParams.clone() I believe the clone method is a little too smart. Think of the most common and simple case. You implemented an awfully complex way to clone objects of classes String, Integer, Long, Boolean and so on, all of which are serializable and non-modifiable classes that do not need to be cloned at all. I suggest the simple approach: clone the collection but not it's elements and tell folks they shouldn't put complex objects in there. In case of stored arrays such as for the date formats, a new array has to be created when the old one is supposed to be modified. If a parameter object cares about whether it needs to be cloned or not, then it implements way too much logic to be a parameter object. Otherwise, it's peachy :-) cheers, Roland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 15435] - New Preferences Architecture
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15435. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15435 New Preferences Architecture --- Additional Comments From [EMAIL PROTECTED] 2003-09-22 11:44 --- 1. public HttpClient(HttpClientParams params) Can we add something like HttpConnectionManager.setParams(p)? HttpParams-enable HttpConnection HttpConnectionManager is the next item on my list. 2. DefaultHttpParams.clone() I believe the clone method is a little too smart. Think of the most common and simple case. Actually I spent a healthy part of my last weekend studying different approaches to object cloning in Java. General sentiment is that java.lang.Object#clone() and java.lang.Cloneable are just plan broken. There are enough folks out there who believe that object serialization is the only way to go. I am a bit reluctant to put constraints on type of objects that may be used as parameter values as there's always a chance that we may overlook a legitimate use pattern. I would also prefer to use Collection classes instead of arrays as things may turn ugly if one wanted, for instance, just to add one additional DateFormat to the standard set of DateFormats. All that array content juggling can get a bit messy I agree my clone method does appear to be an overkill, but that was the only approach which I felt was robust enough to handle all sorts of cases without running a risk of screwing things up in a subtle way. Anyways, I do not mind having a simpler method, but first of all, we need to agree on what type of objects we should allow as parameter values. My opinion that we should allow all Cheers Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 15435] - New Preferences Architecture
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15435. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15435 New Preferences Architecture --- Additional Comments From [EMAIL PROTECTED] 2003-09-22 12:17 --- Hello Oleg, first, let me define the term's I'll use in this posting: params object: instance of DefaultHttpParams or one of it's subclasses parameter object: an object stored in a params object To me, a parameter object represents a value. The value may be simple or structured, but it is accessed read-only by the HTTP client. The parameter object may change it's value asynchronously, but such change is never effected directly by the HTTP client. Params objects may be modified by the HTTP client, namely by the setter methods that store the set values in the params object. However, such change is always an addition, replacement, or removal of a parameter object, never a modification of an existing one. Furthermore, the HTTP client never implicitly clones params objects. Under these assumptions, there is no need to make copies of parameter objects from the HTTP client's point of view, as they are read-only. An application programmer who uses parameter objects with changing values may have a need to control whether the same object or clones are stored in different params objects. However, as the HTTP client does not create clones implicitly, the application programmer has full freedom to clone all parameter objects that require cloning whenever params objects are prepared. Cloning may be controlled explicitly by replacing copy-by-reference entries in a cloned params object, or the params classes can be derived to clone specific entries. It is none of the HTTP client's concern. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 15435] - New Preferences Architecture
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15435. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15435 New Preferences Architecture --- Additional Comments From [EMAIL PROTECTED] 2003-09-22 14:53 --- Created an attachment (id=8313) Follow-up patch 1 (take 2) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 15435] - New Preferences Architecture
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15435. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15435 New Preferences Architecture --- Additional Comments From [EMAIL PROTECTED] 2003-09-19 08:36 --- Hi folks, my apologies for taking so long to look into this again. The current architecture is definitely useful, so take these comments as something that might just as well end up on the lower end of some to-do list :-) There are two things I'm not quite happy with: 1. Taking HttpClient as an example, I'm missing a constructor HttpClient(HttpClientParams) I really want a way to instantiate classes without triggering the properties loading mechanism at all. Second best would be a setParams(HttpClientParams), so I can simply copy the params of another client. Ok, the copying idea makes more sense using HttpMethodParams and HttpMethodBase as an example :-) 2. From a design point of view, shouldn't HttpMethodParams better be an attribute than a base class of HttpClientParams? Since that would require parsing properties into different params objects, I don't really think it's worth the effort. I just want to put it up for discussion. cheers, Roland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 15435] - New Preferences Architecture
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15435. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15435 New Preferences Architecture --- Additional Comments From [EMAIL PROTECTED] 2003-09-19 10:44 --- Having thought about it again, I now realize my misconception in point 2. HttpMethodParams and HttpClientParams are rather independent classes. Shouldn't they both be derived from DefaultHttpParams directly? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 15435] - New Preferences Architecture
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15435. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15435 New Preferences Architecture --- Additional Comments From [EMAIL PROTECTED] 2003-09-19 11:22 --- Hi Roland. Welcome back. 1. Taking HttpClient as an example, I'm missing a constructor HttpClient(HttpClientParams) I really want a way to instantiate classes without triggering the properties loading mechanism at all. Second best would be a setParams(HttpClientParams), so I can simply copy the params of another client. Ok, the copying idea makes more sense using HttpMethodParams and HttpMethodBase as an example :-) Addition of HttpClient#HttpClient(HttpClientParams) sounds reasonable. We might need to make DefaultHttpParams cloneable, which would be a good thing to do anyways HttpMethodParams and HttpClientParams are rather independent classes. Shouldn't they both be derived from DefaultHttpParams directly? Any of parameters relevant on the HttpMethod level should also be settable on HttpClient level when applicable of a number of methods, IMO. Off course, there is no real need for 'extends' relationship between HttpClientParams and HttpMethodParams other than for reusing a few methods Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 15435] - New Preferences Architecture
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15435. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15435 New Preferences Architecture --- Additional Comments From [EMAIL PROTECTED] 2003-09-19 12:31 --- Right, no-one should use the same params object for multiple clients or methods and expect setters to be invoked without side effects. That should be made clear in the JavaDocs for the constructors that accept params objects. I agree this could cause some strange problems. Is there even a case to share the same instance of a params object between multiple methods/clients? If not, perhaps the constructor should always make copies. It would surely be useful if all params objects were cloneable. I'd say that on cloning, a params object should copy the parameters it holds locally, but keep the same reference for the default params. No need to clone defaults, since they are accessed read-only. Sounds like a good idea. I would suggest a copy constructor along with/instead of Cloneable as cloning can be a little ugly. While you're at it, can you add an implements Serializable as well? I don't know what it would be good for, but maybe someone someday wants do deserialize params objects in an HttpParamsFactory. Agreed. Mike - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 15435] - New Preferences Architecture
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15435. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15435 New Preferences Architecture --- Additional Comments From [EMAIL PROTECTED] 2003-09-19 12:42 --- Hello Mike, Is there even a case to share the same instance of a params object between multiple methods/clients? If not, perhaps the constructor should always make copies. I intend to create params objects from my servlets's configuration, and to use them to create all methods affected by that configuration. The idea of having a constructor that accepts a params object was to avoid creating default params that get replaced immediately afterwards. Copying params in the constructor would leave me without a chance to avoid additional object creation, even though the one I pass in is exactly the one I want to be used by the method. I would suggest a copy constructor along with/instead of Cloneable as cloning can be a little ugly. Good point. I support along with. Cloning has the advantage that you do not need to know the exact class of the object you're dealing with. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 15435] - New Preferences Architecture
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15435. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15435 New Preferences Architecture --- Additional Comments From [EMAIL PROTECTED] 2003-09-19 13:23 --- Hello Roland, I intend to create params objects from my servlets's configuration, and to use them to create all methods affected by that configuration. The idea of having a constructor that accepts a params object was to avoid creating default params that get replaced immediately afterwards. Copying params in the constructor would leave me without a chance to avoid additional object creation, even though the one I pass in is exactly the one I want to be used by the method. Sounds like a good enough reason to me. Mike - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 15435] - New Preferences Architecture
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15435. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15435 New Preferences Architecture --- Additional Comments From [EMAIL PROTECTED] 2003-09-19 23:01 --- I'll be working on a patch this weekend that will incorporate the suggested improvements among other things. Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 15435] - New Preferences Architecture
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15435. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15435 New Preferences Architecture --- Additional Comments From [EMAIL PROTECTED] 2003-09-17 23:04 --- Oleg, I heartily agree. A collection makes much more sense than an array. I will make this change and apply the patch. Mike - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 15435] - New Preferences Architecture
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15435. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15435 New Preferences Architecture --- Additional Comments From [EMAIL PROTECTED] 2003-09-16 02:27 --- Created an attachment (id=8239) Javadocs + more configuration items. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 15435] - New Preferences Architecture
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15435. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15435 New Preferences Architecture --- Additional Comments From [EMAIL PROTECTED] 2003-09-16 02:29 --- This patch adds some javadocs, makes use the default connection manager config, and moves date parser formats to a configuration item. Please take a look. Mike - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 15435] - New Preferences Architecture
[EMAIL PROTECTED] wrote: Mike, I just could not get Eclipse to create a patch with *HttpParams* classes in org.apache.commons.httpclient.params package. Oleg, that has most probably nothing to do with eclipse but CVS only. AFAIK you need to create, add and commit the new (empty) directory FIRST, before the -N parameter of cvs diff will include files in such a new directory. HTH Odi - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 15435] - New Preferences Architecture
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15435. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15435 New Preferences Architecture --- Additional Comments From [EMAIL PROTECTED] 2003-09-11 20:19 --- Patch committed. I am leaving the bug report open until javadocs for new classes are provided and references to deprecated methods removed. Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 15435] - New Preferences Architecture
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15435. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15435 New Preferences Architecture --- Additional Comments From [EMAIL PROTECTED] 2003-09-10 20:42 --- Created an attachment (id=8137) Patch (take 4) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 15435] - New Preferences Architecture
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15435. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15435 New Preferences Architecture --- Additional Comments From [EMAIL PROTECTED] 2003-09-10 20:49 --- The forth revision of the patch incorporates Mike's code with some minor variations. As far as I am concerned that looks pretty much like it. What do you think? Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 15435] - New Preferences Architecture
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15435. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15435 New Preferences Architecture --- Additional Comments From [EMAIL PROTECTED] 2003-09-10 21:22 --- Mike, I just could not get Eclipse to create a patch with *HttpParams* classes in org.apache.commons.httpclient.params package. I'll move them back before committing the patch. If no objections raised by tomorrow 22:00 GMT, I'll commit the patch. Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 15435] - New Preferences Architecture
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15435. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15435 New Preferences Architecture --- Additional Comments From [EMAIL PROTECTED] 2003-09-08 16:11 --- Hello Oleg, I'm currently stuck at a customer site and can dial in only occasionally. Since I'm unable to browse through the source, could you consider the following two use cases? 1. A servlet class is instantiated multiple times with different config, but in the same classloader context. Can different instances of the servlet create HttpClient instances with different parameters? 2. A framework uses HttpClient and has it's own mechanism for defining properties. How tricky is it to pass the properties - once they are loaded - to the Http Client? Loading the set of default properties should be initiated by the application. I don't see a need for an automatic loading mechanism, or automatic selection of an HttpParamsFactory. Make it a one-liner to choose a factory and delegate that responsibility to the application (or the framework) that is using the Http Client. cheers, Roland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 15435] - New Preferences Architecture
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15435.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15435
New Preferences Architecture
--- Additional Comments From [EMAIL PROTECTED] 2003-09-08 16:36 ---
1. A servlet class is instantiated multiple times with different config,
but in the same classloader context. Can different instances of the servlet
create HttpClient instances with different parameters?
Of course! What would my patch be worth otherwise? It is still up to you to
decide if you want your HttpClient instances to share the same global defaults.
One can simply set HttpClient#getParams#setDefaults(null) to make it disregard
global defaults.
2. A framework uses HttpClient and has it's own mechanism for defining
properties. How tricky is it to pass the properties - once they are
loaded - to the Http Client?
Allow me to try to explain that with the following pseudo-code snippet:
// Select either global HttpParams or HttpClient's params or HttpMethod's params
HttpParams params = GLOBAL_DEFAULTS // Or
HttpParams params = httpClient.getParams(); // Or
HttpParams params = httpMethod.getParams();
while (storage.hasMore()) {
storageitem = storage.getNext();
String paramName = storageitem.getName();
Object paramValue = storageitem.getObject();
params.setParameter(paramName, paramValue);
}
This may look trivial, but at the moment I can't see why we would want
something more complex. I still would like to know, though, what Mike has got
on his mind with the HttpParamsFactory
Cheers
Oleg
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 15435] - New Preferences Architecture
I will write a little something about my ideas behind the
HttpParamsFactory when I get home tonight.
Mike
[EMAIL PROTECTED] wrote:
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15435.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15435
New Preferences Architecture
--- Additional Comments From [EMAIL PROTECTED] 2003-09-08 16:36 ---
1. A servlet class is instantiated multiple times with different config,
but in the same classloader context. Can different instances of the servlet
create HttpClient instances with different parameters?
Of course! What would my patch be worth otherwise? It is still up to you to
decide if you want your HttpClient instances to share the same global defaults.
One can simply set HttpClient#getParams#setDefaults(null) to make it disregard
global defaults.
2. A framework uses HttpClient and has it's own mechanism for defining
properties. How tricky is it to pass the properties - once they are
loaded - to the Http Client?
Allow me to try to explain that with the following pseudo-code snippet:
// Select either global HttpParams or HttpClient's params or HttpMethod's params
HttpParams params = GLOBAL_DEFAULTS // Or
HttpParams params = httpClient.getParams(); // Or
HttpParams params = httpMethod.getParams();
while (storage.hasMore()) {
storageitem = storage.getNext();
String paramName = storageitem.getName();
Object paramValue = storageitem.getObject();
params.setParameter(paramName, paramValue);
}
This may look trivial, but at the moment I can't see why we would want
something more complex. I still would like to know, though, what Mike has got
on his mind with the HttpParamsFactory
Cheers
Oleg
-
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]
DO NOT REPLY [Bug 15435] - New Preferences Architecture
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15435. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15435 New Preferences Architecture --- Additional Comments From [EMAIL PROTECTED] 2003-09-09 03:27 --- Created an attachment (id=8109) Patch (HttpParamsFactory) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 15435] - New Preferences Architecture
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15435. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15435 New Preferences Architecture --- Additional Comments From [EMAIL PROTECTED] 2003-09-09 03:43 --- The attached patch contains a quick implementation of what I had in mind with regard to a HttpParamsFactory. The main purpose is to consolidate all of the initialization of the HttpParams to a single/configurable location. I see the benefits of this approach as the following: - Initialization of HttpParams is localized and formalized. The method for specifying a new initialization routine is clear and easily modifiable. - Creation/initialization of the default HttpParams is not necessarily a one time occurrence. Since HttpParamsFactory.getDefaultParams() is called every time the default params are requested, the defaults could be completely static, new for every call, or perhaps created on a per-thread basis. The choice is up to the implementor. We would most likely just provide the default static initialization factory. Overall, I think this approach buys us some nice flexibility with little overhead. What do you think? Mike - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 15435] - New Preferences Architecture
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15435. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15435 New Preferences Architecture --- Additional Comments From [EMAIL PROTECTED] 2003-09-06 13:27 --- Created an attachment (id=8082) Patch (take 2) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 15435] - New Preferences Architecture
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15435. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15435 New Preferences Architecture --- Additional Comments From [EMAIL PROTECTED] 2003-09-06 13:30 --- With property file gone things got surprisingly easier. The new patch should address a lot of concerns expressed above. Please give me your feedback. Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 15435] - New Preferences Architecture
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15435. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15435 New Preferences Architecture --- Additional Comments From [EMAIL PROTECTED] 2003-09-06 15:32 --- Hi Oleg, I'm glad you decided to take another stab at this. This version has some definite improvements, and I think I can see the light at the end of the tunnel now. Specifics below: - Removing the reliance on the properties and string based values was an excellent idea. This greatly simplifies things and makes the process of loading defaults separate. Nice. - To replace the loading of defaults from properties I think we need an HttpParamsFactory. This would replace the static GLOBAL_DEFAULTS. HttpParamsFactory would have a plugable mechanism for defining the default params. Things like the static initializer in HttpMethodParams could be moved there. - Are isParameterFalse() and isParameterTrue() necessary? Seems like getBooleanParameter() should be enough :) - All of the various PROTOCOL_STRICTNESS_PARAMS should be broken out to individual methods I think. - Once parameters have methods for getting/setting them I do not think the public param Strings for them are required. Again, nice work. Mike - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 15435] - New Preferences Architecture
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15435. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15435 New Preferences Architecture --- Additional Comments From [EMAIL PROTECTED] 2003-09-04 12:28 --- I thought about this quite a bit more last night as I was going to sleep and I have changed my mind, particularly in regard to specific vs. generic configuration. My feeling now is that HttpParams should be a source for generic configuration and that specific configuration should be handled by the specific users of the values. For example HttpParams would have methods like: String getParam(String key) long getLongParam(String key) and default options like: String getParam(String key, String default) long getLongParam(String key, long default) Then classes like HttpVersion or HttpMethodBase would have the specifics like: public static final String PARAM_PROTOCOL_VERSION = http.protocol.version and public static void setHttpVersion(HttpVersion version, HttpParams params) Again, these are just some ideas. I like this separation of things better though. This allows HttpParams to be flexible enough to handle various kinds of configuration, and pushes the specifics to the classes that care about them. What do you think? Mike - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 15435] - New Preferences Architecture
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15435. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15435 New Preferences Architecture --- Additional Comments From [EMAIL PROTECTED] 2003-09-04 13:22 --- Some quick thoughts from here, having scanned the proposed patch only very briefly: * I like the idea of keeping parameters generic. I use the Slide WebDAV extensions, and likely there will be options that make sense to specify for that in the future (default encoding of XML requests, for example). Clients may also have preferences that they associate with HttpClient, but are not necessarily used by HttpClient. By keeping the options generic, extensions like WebDAV, and other client wrappers can use the same mechanism for setting their preferences. If you make the settings functions specific, it will be harder over time for the library to accommodate new options, and clients will not be able to extend it as easily. * The discovery process standard could use the approach outlined here: http://java.sun.com/j2se/1.4.2/docs/api/javax/xml/parsers/SAXParserFactory.html#newInstance() which is as close to a standard as Java has for this kind of thing. * Ortwin has an excellent point, namely that the discovery process should kick in only if the caller doesn't provide default information. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 15435] - New Preferences Architecture
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15435. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15435 New Preferences Architecture --- Additional Comments From [EMAIL PROTECTED] 2003-09-04 14:22 --- Folks, It's my first day at work after two weeks of holidays, so things are a bit hectic right now. I'll try to respond to every comment made but that may take a while and a few postings # 2 - indirection http.dateFormats=format1, format2 format1=EEE, dd-MMM- HH:mm:ss z format2=EEE dd-MMM- HH-mm-ss z That's the way Sun does it, and it may well be the way most users would expect it to work (me for one) - Is there a need for both specific configuration params like getConnectionManagerTimeout() and generic ones like getParameter (String)? Not really. I also agree that ideally two methods should not be mixed up. I sense that the majority of respondent favor the generic approach over specific, like I do. I just felt that having to parse some frequently values such as protocol version might be too much of a performance hit. I thought an exception could be made for the most frequently used parameters (maybe just protocol version). However, if we all agree that performance degradation will be offset by greater flexibility, I do not mind taking purely generic approach - I think HttpParams.load() should use a PropertyResourceBundle to load/parse the configuration. It avoids implementing the nasty details and provides support for splitting lines with \, among other things. Agreed. - I think we probably want a HttpMethodBase.setParams() or something of the sort. Can do. Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 15435] - New Preferences Architecture
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15435. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15435 New Preferences Architecture --- Additional Comments From [EMAIL PROTECTED] 2003-09-04 14:26 --- I don't like the generic approach so much. It involves defining property names which introduce typos and requires converting data representations. If you know you need a boolean to indicate whether redirects should be chased or not (just to give an example), give it a setter and a getter and let the compiler check for typos. To me, a generic mechanism is something for things we haven't thought about, or things we couldn't know about in Eric's case. Useful, but rather a fallback than a preferred choice. Unfortunately, I won't find the time to look at the code in the near future. But is there a way to have base class that provides a generic mechanism and to use adapter classes for the individual components? Something like: HttpParams: generic parameters and conversion methods from and to strings HttpClientParams: specific getters and setters for the client's properties, kept in attributes. Constructor and/or readFrom(HttpParams) to initialize the attributes, and saveTo(HttpParams) to write them back. HttpMethodParams: like HttpClientParams, just for the HttpMethodBase params HttpGetMethodParams: derived from HttpMethodParams, adding some GET-specific attributes. ...and so on for every component that defines parameters I know this may create a lot of new classes, but I always was a friend of lots of (simple) classes :-) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 15435] - New Preferences Architecture
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15435. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15435 New Preferences Architecture --- Additional Comments From [EMAIL PROTECTED] 2003-09-03 21:17 --- Important points: - collections of HTTP parameters may be linked together to form a hierarchy - Parameters can be set at the global level, Http client level or Http method level - If a parameter is not defined at the current level, its value is drawn from a higher levels of the hierarchy at which the parameter is defined - If parameter is not defined at the current level or any level above, a default value is returned - Some parameters are not applicable at the Http method level - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 15435] - New Preferences Architecture
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15435. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15435 New Preferences Architecture --- Additional Comments From [EMAIL PROTECTED] 2003-09-04 02:09 --- Hi Oleg, I like it. Overall the design is quite good. I have number of ideas/questions which I will elaborate on below. High level stuff: - How should we handle the storage of more complicated configuration options, like the date formats used in DateParser? This is definitely something that I think should be able to configure, in the default case at least. Another item that has been brought up is the ability to define a set of default headers to be applied to all methods. Here a couple of ideas off the top of my head: # 1 - delimit values http.dateFormats=EEE, dd-MMM- HH:mm:ss zSOME_DELIMEEE dd-MMM- HH-mm- ss z # 2 - indirection http.dateFormats=format1, format2 format1=EEE, dd-MMM- HH:mm:ss z format2=EEE dd-MMM- HH-mm-ss z The first choice is the easiest but has the delimiter choice problem. The second choice is more exact but requires more work and is a little less obvious. I think the solution here will depend somewhat on the answer to the next question. - Is there a need for both specific configuration params like getConnectionManagerTimeout() and generic ones like getParameter(String)? I feel like we should have custom methods for all configuration values, or all generic ones with support for type specific params like getLongValue(String), but not both. I am leaning more toward all specific configuration methods. This configuration system is only meant to support HttpClient. It should not need to be generic enough to be usable for other purposes. Implementation details (perhaps too soon for this): - I think HttpParams.load() should use a PropertyResourceBundle to load/parse the configuration. It avoids implementing the nasty details and provides support for splitting lines with \, among other things. - I think we probably want a HttpMethodBase.setParams() or something of the sort. What do you think? Mike - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 15435] - New Preferences Architecture
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15435. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15435 New Preferences Architecture [EMAIL PROTECTED] changed: What|Removed |Added OtherBugsDependingO||10790 nThis|| - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 15435] - New Preferences Architecture
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15435. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15435 New Preferences Architecture --- Additional Comments From [EMAIL PROTECTED] 2003-08-30 14:48 --- See my comments above - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
