You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by John Buren Southerland <jo...@southerland-consulting.com> on 2006/03/10 23:12:31 UTC
java.net.URL or URI
I'm sure their is a perfectly good reason for this, but none the less
the question is nawing at the very depths of my soul.
Why does the constructor to the standard methods not accept java.net.URL
or URI objects?
I just added support in my app for images and such from the returned
text and though how much functionality would be introduced by that
addition.
For instance, i have a top level url "http://www.ibm.com/index.html"
and that page contains, way too many links, all relative of course.
so to get the images my method creations look something like:
Pattern pat = new Pattern(someReallyCoolRegexHere);
Matcher match = pat.matcher(webPageTextHere);
while( match.find() )
GetMethod get = new GetMethod( new URL( topURL,
match.group(1)).toString() );
but if the url was supported, and extended with some of the simple
features, it would be cleaner:
GetMethod get = new GetMethod( topUrl, match.group(1) );
As I type this I realize it is probably trivial, but surely a reason
must exist that string was supported rather than url?
Thanks, John
Re: java.net.URL or URI
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Sat, 2006-03-11 at 10:39 -0500, John Buren Southerland wrote:
> Fair enough ;)
> I know it is silly, I just kept wondering why the URL class was not
> supported directly, the 1.2 support answers everything.
>
> Do any dreams/plans exist to add a "user" timeout that isn't tied to
> socket or connection timeout?
John,
While not entirely impossible to implement using classic IO model, the
support for a 'user' timeout would require a lot of _really_ ugly code.
It is by far better to implement a controller thread that aborts the
execution of methods if a certain condition is met.
The story is completely different for the NIO (non-blocking IO, that
is). It should be fairly uncomplicated to keep track of total tome spent
executing an operation when a channel selector is being employed. We
might consider adding the total timeout for HttpComponents HttpNIO
module
Oleg
> I have a sigalarm like thingy that requires 1.5, but obviously that
> won't work for a library like this.
> Thanks again, John
>
> PS: Don't worry about me, I am way to emotionally invested in log4j to
> nest statements so deep like the example I typed out for reference. I
> would have like six potential problems in each line of code.
>
> On Sat, 2006-03-11 at 10:20 +0100, Roland Weber wrote:
>
> > Hi John,
> >
> > > Pattern pat = new Pattern(someReallyCoolRegexHere);
> > > Matcher match = pat.matcher(webPageTextHere);
> > > while( match.find() )
> > > GetMethod get = new GetMethod( new URL( topURL,
> > > match.group(1)).toString() );
> > >
> > > but if the url was supported, and extended with some of the simple
> > > features, it would be cleaner:
> > >
> > > GetMethod get = new GetMethod( topUrl, match.group(1) );
> > >
> > > As I type this I realize it is probably trivial, but surely a reason
> > > must exist that string was supported rather than url?
> >
> > The URL class has 6 constructors in JDK 1.4.2 (I didn't bother to
> > check which ones were in the eralier JDK version which is the
> > prerequisite for HttpClient). Surely you don't expect us to duplicate
> > all of them just to save you a single line of code and two braces?
> >
> > while( match.find() ) {
> > URL from = new URL( topURL, match.group(1) );
> > GetMethod get = new GetMethod( from.toString() );
> > ... // I assume that something was omitted here, otherwise
> > // you are pointlessly creating objects in a loop :-)
> > }
> >
> > If you choose to make your code unreadable by nesting statements,
> > it is only fair that *you* should suffer the consequences.
> >
> > The URI class was introduced with JDK 1.4. HttpClient requires only
> > an older JDK, I don't have in mind whether that was 1.2 or 1.3. But
> > the URI class also has a toString() method that can easily be used
> > in the way shown above. See how flexible the string constructor is?
> >
> > cheers,
> > Roland
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org
> >
>
> John Buren Southerland
> Principal Consultant
> Southerland Consulting, Inc.
> Office: 801.467.8090
> Cell: 214.734.8099
> Email: john@southerland-consulting.com
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org
Re: java.net.URL or URI
Posted by Roland Weber <ht...@dubioso.net>.
Hi John,
> Do any dreams/plans exist to add a "user" timeout that isn't tied to
> socket or connection timeout?
We get questions about user timeouts once in a while. It is in no
specification I am aware of, and I don't know any elegant way to
simply put it in, so I don't think we'll implement it. Our standard
answer is: start a timeout thread and call HttpMethod.abort() after
the timeout. That's what we would have to do, too.
> PS: Don't worry about me, I am way to emotionally invested in log4j to
> nest statements so deep like the example I typed out for reference. I
> would have like six potential problems in each line of code.
We worry about all our users :-)
cheers,
Roland
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org
Re: java.net.URL or URI
Posted by John Buren Southerland <jo...@southerland-consulting.com>.
Fair enough ;)
I know it is silly, I just kept wondering why the URL class was not
supported directly, the 1.2 support answers everything.
Do any dreams/plans exist to add a "user" timeout that isn't tied to
socket or connection timeout?
I have a sigalarm like thingy that requires 1.5, but obviously that
won't work for a library like this.
Thanks again, John
PS: Don't worry about me, I am way to emotionally invested in log4j to
nest statements so deep like the example I typed out for reference. I
would have like six potential problems in each line of code.
On Sat, 2006-03-11 at 10:20 +0100, Roland Weber wrote:
> Hi John,
>
> > Pattern pat = new Pattern(someReallyCoolRegexHere);
> > Matcher match = pat.matcher(webPageTextHere);
> > while( match.find() )
> > GetMethod get = new GetMethod( new URL( topURL,
> > match.group(1)).toString() );
> >
> > but if the url was supported, and extended with some of the simple
> > features, it would be cleaner:
> >
> > GetMethod get = new GetMethod( topUrl, match.group(1) );
> >
> > As I type this I realize it is probably trivial, but surely a reason
> > must exist that string was supported rather than url?
>
> The URL class has 6 constructors in JDK 1.4.2 (I didn't bother to
> check which ones were in the eralier JDK version which is the
> prerequisite for HttpClient). Surely you don't expect us to duplicate
> all of them just to save you a single line of code and two braces?
>
> while( match.find() ) {
> URL from = new URL( topURL, match.group(1) );
> GetMethod get = new GetMethod( from.toString() );
> ... // I assume that something was omitted here, otherwise
> // you are pointlessly creating objects in a loop :-)
> }
>
> If you choose to make your code unreadable by nesting statements,
> it is only fair that *you* should suffer the consequences.
>
> The URI class was introduced with JDK 1.4. HttpClient requires only
> an older JDK, I don't have in mind whether that was 1.2 or 1.3. But
> the URI class also has a toString() method that can easily be used
> in the way shown above. See how flexible the string constructor is?
>
> cheers,
> Roland
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org
>
John Buren Southerland
Principal Consultant
Southerland Consulting, Inc.
Office: 801.467.8090
Cell: 214.734.8099
Email: john@southerland-consulting.com
Re: java.net.URL or URI
Posted by Ortwin Glück <od...@odi.ch>.
Roland Weber wrote:
> The URI class was introduced with JDK 1.4. HttpClient requires only
> an older JDK, I don't have in mind whether that was 1.2 or 1.3.
1.2 and we still have no statement about this on our website :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org
Re: java.net.URL or URI
Posted by Roland Weber <ht...@dubioso.net>.
Hi John,
> Pattern pat = new Pattern(someReallyCoolRegexHere);
> Matcher match = pat.matcher(webPageTextHere);
> while( match.find() )
> GetMethod get = new GetMethod( new URL( topURL,
> match.group(1)).toString() );
>
> but if the url was supported, and extended with some of the simple
> features, it would be cleaner:
>
> GetMethod get = new GetMethod( topUrl, match.group(1) );
>
> As I type this I realize it is probably trivial, but surely a reason
> must exist that string was supported rather than url?
The URL class has 6 constructors in JDK 1.4.2 (I didn't bother to
check which ones were in the eralier JDK version which is the
prerequisite for HttpClient). Surely you don't expect us to duplicate
all of them just to save you a single line of code and two braces?
while( match.find() ) {
URL from = new URL( topURL, match.group(1) );
GetMethod get = new GetMethod( from.toString() );
... // I assume that something was omitted here, otherwise
// you are pointlessly creating objects in a loop :-)
}
If you choose to make your code unreadable by nesting statements,
it is only fair that *you* should suffer the consequences.
The URI class was introduced with JDK 1.4. HttpClient requires only
an older JDK, I don't have in mind whether that was 1.2 or 1.3. But
the URI class also has a toString() method that can easily be used
in the way shown above. See how flexible the string constructor is?
cheers,
Roland
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org