Re: Configurable DNS resolver?
Mike Moran wrote: Ah, yes, that is a point. I suspect JNDI will be rather too much overhead for a simple host lookup, but it's worth a look. Async lookups may also still be impossible. I don't see much overhead. The only expensive call is the service lookup. After that the performance fully depends on the implementation of the service. Some more resources: http://java.sun.com/j2se/1.4/docs/guide/jndi/jndi-dns.html I've actually already made a wrapper around the dnsjava library (quite old by now, perhaps, as it was done a year ago) so I'd rather make use of that. I'll have a look at the latest HTTPClient release to see how easy it is to do what I suggested before (accept a resolved IP address) We are looking forward for a proposal. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Configurable DNS resolver?
Ortwin Glück wrote: Michael Becke wrote: If you set the host of a method or HttpClient to an IP address then it will connect to that address. DNS names are not required, but will be resolved using the default Java method if used. Mike This causes problems on Multi-Homed sites. A DNS name is required in the HTTP request (Host request header) to uniquely reference the site. I was having a look through the latest release code and that was one of the things that occurred to me. Am I right in thinking that it would be HostConfiguration/HttpConnection that would require extra methods/calls to make a distinction between the host connected to (Socket level) and the advertised host (Host: header)? -- Mike -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [HttpClient] Proposed style change
For the most part, I'll stay out of this, since I don't work with this code base much, so my personal preferences shouldn't make a difference. However, I do want to point out one more consideration regarding line lengths. Many people like to use tools such as tkdiff (or ViewCVS, for that matter) to do side-by-side colourised diffs. That becomes a real pain when the line lengths go much over 80, because you end up having to do a lot of horizontal scrolling to make sure you've seen all the changes. -- Martin Cooper -Original Message- From: Mike Bowler [mailto:[EMAIL PROTECTED]] Sent: Monday, January 27, 2003 8:39 AM To: [EMAIL PROTECTED] Subject: [HttpClient] Proposed style change I am going through the code and changing it to conform to the style as per checkstyle. There are two places that I think we may want to be a little more lenient than the defaults and so I'm putting them here for discussion. 1) Line length of 80 The number 80 originally came from the days when printers could only print 80 columns. These days, that number doesn't make nearly as much sense. While I think we still want to have a maximum length, I believe that 80 is too short. In most of the places that we are exceeding the limit, we are just over by a bit (between 80 and 90). I propose that we change the max length to 100. This is still short enough that nobody should have to scroll to see the source but long enough that we aren't artificially breaking lines. 2) Instance variable names Some of the code uses leading underscores for variable names but this isn't allowed by checkstyle. The pattern it checks for is ^[a-z][a-zA-Z0-9]*$ I find significant benefit to being able to quickly distinguish instance variables from local variables and the leading underscore lets me do that easily. (I personally prefer trailing underscores to leading ones but I can live with either) I propose that we change the pattern for instance variables to ^_?[a-z][a-zA-Z0-9]*$ so that we will allow leading underscores but will not insist on it. Comments? -- Mike Bowler Principal, Gargoyle Software Inc. Voice: (416) 822-0973 | Email : [EMAIL PROTECTED] Fax : (416) 822-0975 | Website: http://www.GargoyleSoftware.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 16429] - Align the code base with checkstyle
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=16429. 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=16429 Align the code base with checkstyle --- Additional Comments From [EMAIL PROTECTED] 2003-01-27 22:50 --- Created an attachment (id=4572) Round two of the cleanup -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [HttpClient] Proposed style change
I propose that we change the pattern for instance variables to ^_?[a-z][a-zA-Z0-9]*$ so that we will allow leading underscores but will not insist on it. Uuuugh, please no! Besides being ugly, it's worth sticking to the Sun coding style (as is the default with checkstyle). That way, anyone who has done any Java will be immediately familiar with it. I'd agree with Simon on this. Leading (and trailing) underscores are ugly (just look a Python!). If its too difficult to determine if a variable is a member or a local, then the method is probablly too big. And you can always prefix this to a member for clarity. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PATCH] Bug 16429 Align the code base with checkstyle
Mike Bowler wrote: I've added a second patch to the bug which fixes more checkstyle warnings. I'm still not sure why the patches were being discarded from my emails this morning so I'm just playing it safe and putting them in bugzilla. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16429 Hi Mike, shouldn't this be the default? Not everybody reading the list needs all the patches, they increase only the list traffic. But everybody, who needs a patch before it's added to CVS, can get it from Bugzilla. Furthermore they couldn't get lost there. I definitely prefer Bugzilla instead of mail attachement. Regards, Joerg -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[PATCH] relative URIs
Attached is a patch and test case for a few minor bugs I discovered in the URI(URI, URI) constructor. The patch changes the following: - fixes the case when the second arg to URI(URI,URI) is just a fragment (e.g. #s). According to RFC 2396 a relative reference that is just a fragment should resolve to the current document plus the fragment. I took this to mean that URI( http://a/b/c/d;p?q;, #s ) should resolve to http://a/b/c/d;p?q#s;. Please let me know if this seems incorrect. - changes setURI() to no longer ignores fragments, getURI() and toString() now return the full URI including the fragment. Enjoy, Mike testUri.patch Description: Binary data -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PATCH] Bug 16429 Align the code base with checkstyle
Ok, I thought we might wait on style related patches untill we finalize some guidelines, but you have focused on issues not is dispute so thats good. I do prefer patches to bugzilla, less traffic generated by email (someone has to be paying for the apache bandwitdh). Mike Bowler wrote: I've added a second patch to the bug which fixes more checkstyle warnings. I'm still not sure why the patches were being discarded from my emails this morning so I'm just playing it safe and putting them in bugzilla. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16429 -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [HttpClient] Proposed style change
Personally, 1) Line length of 80 +1 2) Instance variable names ^_?[a-z][a-zA-Z0-9] +0 Sung-Gu -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PATCH] Bug 16429 Align the code base with checkstyle
Hey Mike, A couple issues with the patch. The tests failed due to a change to the parameters member in HeaderElement. A protected member was made to be private and given an accessor. I think that this is a good change, but patches should pass the tests before they are posted. The tests were pretty bogus anyway, so I just patched them so its OK now. This is what I had: [java] There was 1 error: [java] 1) testOldMain(org.apache.commons.httpclient.TestHeaderElement)java.lang.NoSuchFieldError: parameters [java] at org.apache.commons.httpclient.TestHeaderElement.testOldMain(TestHeaderElement.java:118) [java] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [java] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [java] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [java] FAILURES!!! [java] Tests run: 161, Failures: 0, Errors: 1 Also, I don't want to change to using any style that is contentious. In particular allowing members to be prefixed with an underscore. Its fine to leave them untill this is ironed out, but don't add any new ones! I commited the patch regardless because it represents several hours of good work and can be changed (or not) later with a search and replace depending on the decision. Jandalf. Mike Bowler wrote: I've added a second patch to the bug which fixes more checkstyle warnings. I'm still not sure why the patches were being discarded from my emails this morning so I'm just playing it safe and putting them in bugzilla. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16429 -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
