DO NOT REPLY [Bug 22940] - gzip content-encoding support
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=22940. 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=22940 gzip content-encoding support [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: NameValuePair.equals
This bit defintely needs to be rewritten. Odi, can you take care of it?
Oleg
-Original Message-
From: Ortwin Glück [mailto:[EMAIL PROTECTED]
Sent: Monday, September 08, 2003 09:03
To: Commons HttpClient Project
Subject: NameValuePair.equals
I just came over the code:
public boolean equals(Object object) {
if (this == object) {
return true;
} else if (this.getClass().equals(object.getClass())) {
NameValuePair pair = (NameValuePair) object;
return ((null == name ? null == pair.name :
name.equals(pair.name))
(null == value ? null == pair.value :
value.equals(pair.value)));
} else {
return false;
}
}
I think the class check should be changed to using the instanceof
operator. Otherwise subclassing or different classloaders cause problems
here.
-
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 22926] - [patch] Support for digest auth MD5-sess
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=22926. 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=22926 [patch] Support for digest auth MD5-sess --- Additional Comments From [EMAIL PROTECTED] 2003-09-08 08:01 --- No objections from me. I believe it is good to be included into 2.0 release as well. Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 22969] - return value of PostMethod#removeParameter
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=22969. 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=22969 return value of PostMethod#removeParameter --- Additional Comments From [EMAIL PROTECTED] 2003-09-08 08:05 --- I'll add a test case for the bug and commit the patch tonight. Oleg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: NameValuePair.equals
This particular code and the accompaning test predates The Trojan War and the Fall of Troy. If the test case does not make sense, let's change it as well. Oleg -Original Message- From: Ortwin Glück [mailto:[EMAIL PROTECTED] Sent: Monday, September 08, 2003 10:14 To: Commons HttpClient Project Subject: Re: NameValuePair.equals Kalnichevski, Oleg wrote: This bit defintely needs to be rewritten. Odi, can you take care of it? Oleg Just tried that. It breaks the TestHeader#testNotEqualToNVP case. Why is it required that equals returns false if the classes do not match exactly? I thinks this is a weird behaviour for an equals method and should clearly be changed. - 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]
Re: NameValuePair.equals
Kalnichevski, Oleg wrote: This particular code and the accompaning test predates The Trojan War and the Fall of Troy. If the test case does not make sense, let's change it as well. Oleg *g* It doesn't seem to break anything else apart from that (webapp tests and external ones run through). The only exception I get is: [java] 2) testOptionsStar(org.apache.commons.httpclient.TestWebappMethods)junit.framework.AssertionFailedError: expected:200 but was:400 But I guess that is a Tomcat problem. If necessary we can always add that weird class checking thing to Header#equals where it is in the right place at least. But for now I will just leave it away until anybody reports a problem. Odi - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PATCH] NameValuePair.equals
see attached patch:
removed strict class check from NameValuePair#equals and rewrote code
for better readability. Updated API Doc. Test case changed to the
modified contract.
Index: java/org/apache/commons/httpclient/NameValuePair.java
===
RCS file:
/home/cvspublic/jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/NameValuePair.java,v
retrieving revision 1.14
diff -u -r1.14 NameValuePair.java
--- java/org/apache/commons/httpclient/NameValuePair.java 31 Jan 2003 00:33:36
- 1.14
+++ java/org/apache/commons/httpclient/NameValuePair.java 8 Sep 2003 08:36:58
-
@@ -163,24 +163,21 @@
}
/**
- * Test if the given iobject/i is equal to me. In this implementation,
- * an iobject/i is equal to me iff it has the same runtime type and the
- * iname/i and ivalue/i attributes are both ttequal/tt (or
- * tt==/tt).
+ * Test if the given iobject/i is equal to me. ttNameValuePair/tts
+ * are equals if both their ttname/tt and ttvalue/tt fields are equal.
+ * If ttobject/tt is ttnull/tt this method returns ttfalse/tt.
*
- * @param object the [EMAIL PROTECTED] Object} to compare to
+ * @param object the [EMAIL PROTECTED] Object} to compare to or ttnull/tt
* @return true if the objects are equal.
*/
public boolean equals(Object object) {
-if (this == object) {
-return true;
-} else if (this.getClass().equals(object.getClass())) {
-NameValuePair pair = (NameValuePair) object;
-return ((null == name ? null == pair.name : name.equals(pair.name))
-(null == value ? null == pair.value :
value.equals(pair.value)));
-} else {
-return false;
-}
+if (object == null) return false;
+if (this == object) return true;
+if (!(object instanceof NameValuePair)) return false;
+
+NameValuePair pair = (NameValuePair) object;
+return ((null == name ? null == pair.name : name.equals(pair.name))
+ (null == value ? null == pair.value : value.equals(pair.value)));
}
/**
Index: test/org/apache/commons/httpclient/TestHeader.java
===
RCS file:
/home/cvspublic/jakarta-commons/httpclient/src/test/org/apache/commons/httpclient/TestHeader.java,v
retrieving revision 1.4
diff -u -r1.4 TestHeader.java
--- test/org/apache/commons/httpclient/TestHeader.java 23 Jan 2003 22:48:25 -
1.4
+++ test/org/apache/commons/httpclient/TestHeader.java 8 Sep 2003 08:37:09 -
@@ -122,10 +122,10 @@
assertEquals(a: b\r\n,header.toExternalForm());
}
-public void testNotEqualToNVP() {
+public void testEqualToNVP() {
NameValuePair header = makePair(a,b);
NameValuePair pair = new NameValuePair(a,b);
-assertTrue(!header.equals(pair));
-assertTrue(!pair.equals(header));
+assertTrue(header.equals(pair));
+assertTrue(pair.equals(header));
}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 22984] - bug in tutorial example on recoverable exceptions
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=22984. 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=22984 bug in tutorial example on recoverable exceptions [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2003-09-08 13:54 --- Hi Gael, Thank you for submitting this bug. I'm glad that the tutorial is being read. Someone beat you to the punch though and submitted this last week. It has been fixed in CVS but not published to the site yet. I will take care of that this evening. Thanks, 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-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]
Re: NameValuePair.equals
Ortwin Glück wrote: Why is it required that equals returns false if the classes do not match exactly? I thinks this is a weird behaviour for an equals method and should clearly be changed. It's weird behavior, but you have to be careful when changing it to instanceof. If an equals method tries to get too clever and suports equality with other types, you can end up with cases where equals is not symmetric, e.g. a.equals(b)==true but b.equals(a)==false. The usual if (other instanceof ThisClass) is usually safe, though. There's a good discussion of this in Effective Java by Josh Bloch. I think this book is a must-read for anyone doing API or class library development in Java. BTW, sorry I've been fairly scarce lately. I started a new job two weeks ago and I'm spending lots of time trying to get up to speed and figure out the environment here. -- Laura - 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: NameValuePair.equals
Laura Werner wrote: It's weird behavior, but you have to be careful when changing it to instanceof. If an equals method tries to get too clever and suports equality with other types, you can end up with cases where equals is not symmetric, e.g. a.equals(b)==true but b.equals(a)==false. The usual if (other instanceof ThisClass) is usually safe, though. Yes, this would indeed have been the case if Header implemented a different version of equals. There's a good discussion of this in Effective Java by Josh Bloch. I think this book is a must-read for anyone doing API or class library development in Java. Thanks for the hint. I have just ordered that book. BTW, sorry I've been fairly scarce lately. I started a new job two weeks ago and I'm spending lots of time trying to get up to speed and figure out the environment here. Hey, good luck at your new job! I hope you enjoy it there. Odi - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 22926] - [patch] Support for digest auth MD5-sess
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=22926. 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=22926 [patch] Support for digest auth MD5-sess --- Additional Comments From [EMAIL PROTECTED] 2003-09-08 16:34 --- Not to argue feature/bugfix, but I think there was an actual bug here which is what got me looking in the first place. The server I was accessing was trying to negotiate the MD5-sess algorithm which was silently ignored and the client responded with an MD5 algorithm which caused a ``Bad request'' response from the server. I'd suggest that if this does not go into 2.0, that 2.0 at least log a warning when the algorithm is not MD5. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 22926] - [patch] Support for digest auth MD5-sess
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=22926. 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=22926 [patch] Support for digest auth MD5-sess [EMAIL PROTECTED] changed: What|Removed |Added CC||commons-httpclient- ||[EMAIL PROTECTED] AssignedTo|commons-httpclient- |[EMAIL PROTECTED] |[EMAIL PROTECTED] | --- Additional Comments From [EMAIL PROTECTED] 2003-09-08 16:47 --- If no objections arrive within 24 hours from now I will commit it to 2.0 branch and HEAD then. - 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]
Re: [VFS|HttpClient] Re: [VFS] Crashes in getContent()
On Fri, 5 Sep 2003, Adam R. B. Jack [EMAIL PROTECTED] wrote: Oleg wrote: Adam, with all due respect let me point out that we have stable HTTPCLIENT_2_0_BRANCH branch that should be used by those who need API and/or code stability. If GUMP cannot be configured to use any other CVS branch but HEAD, this is a totally different kind of a problem, and it should be brought up to GUMP folks, not to us. Gump can be configured, but it is community configured, and your project has selected this configuration. Please note that there already is a commons-httpclient-2.0-branch project in Gump's workspace. It would be trivial for projects to depend on that branch instead of CVS HEAD and in fact jakarta-slide and xml-rpc already do so. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VFS|HttpClient] Re: [VFS] Crashes in getContent()
On Mon, 8 Sep 2003, Adam R. B. Jack [EMAIL PROTECTED] wrote: However, most of my statement (and now question) is about friend-of-gump behaviour, and having that project is good, but not friendly 'cos it forces work onto sub-projects. I'm not sure. Do you not agree that the project should manage itself, should create the new (temporarily unstable) codebase as the sub-named project, and should either alias (via project name=commons-httpclient .. depend name=commons-httpclient-old-stable-branch inherit=all) or rename projects in order to manage it for folk? It would be nice if they did. Many projects consider Gump either a community service maintained by others (most committers don't even know they have commit access to the jakarta-gump module) or a nuisance. I think it is perfectly legitimate for a project to move forward and break backwards compatibility after a deprecation period that's been long enough and included at least one stable release. Whether such a project decides to move forward in CVS HEAD or in a branch is up to its committers. If they manage its Gump descriptor to take the problem into account is a different issue - see above. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VFS|HttpClient] Re: [VFS] Crashes in getContent()
Stefan wrote:
Please note that there already is a commons-httpclient-2.0-branch
project in Gump's workspace. It would be trivial for projects to
depend on that branch instead of CVS HEAD and in fact jakarta-slide
and xml-rpc already do so.
Thanks, I'd not seen that.
However, most of my statement (and now question) is about friend-of-gump
behaviour, and having that project is good, but not friendly 'cos it
forces work onto sub-projects. Do you not agree that the project should
manage itself, should create the new (temporarily unstable) codebase as the
sub-named project, and should either alias (via project
name=commons-httpclient .. depend
name=commons-httpclient-old-stable-branch inherit=all) or rename
projects in order to manage it for folk? It seems better for the active
project to manage this once (with sub-projects having named projects should
they chose) than for sub-projects to attempt to keep track.
If not, it gets into me as a user having to manage VFS ('cos they are too
busy off elsewhere to do such things) and that seems (1) rude [I oughtn't]
(2) messy we'd loose valuable gump runs due to folks trying to keep in
synch.
regards,
Adam
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 22968] - HttpConnection.isResponseAvailable() calls setSoTimeout() but does not catch IOException
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=22968. 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=22968 HttpConnection.isResponseAvailable() calls setSoTimeout() but does not catch IOException --- Additional Comments From [EMAIL PROTECTED] 2003-09-09 02:42 --- Created an attachment (id=8107) patch - 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]
