On Thu, 3 May 2001, Morgan Delagrange wrote:
>
>
> On Thu, 3 May 2001, Park, Sung-Gu wrote:
>
> > > > > I'm thinking about reworking the way the constructors and startSession
> > > > > methods work in the HttpClient class. I think it's a little confusing
> > > > > right now. Currently HttpClient has three constructors:
> > > > >
> > > > > HttpClient()
> > > > > HttpClient(URL url)
> > > > > HttpClient(URL url, String user, String password)
> > > > >
> > > > > and three startSession methods:
> > > > >
> > > > > startSession()
> > > > > startSession(URL url)
> > > > > startSession(String hostname, String port)
> > > > >
> > > > > I think that this will introduct too much confusion. For example,
> > what
> > > > > happens when I do the following?
> > > > >
> > > > > HttpClient client = new HttpClient(new URL("http://java.sun.com";));
> > > > > client.startSession();
> > > > >
> > > > > You may think that you've opened a session on "java.sun.com:80", but
> > what
> > > > > you've actually done is opened a session for "localhost:80". Even if
> > we
> > > > > noted this in the javadocs, I still think programmers would screw it
> > > > > up. Also worthy of note is that the above code instantiates the State
> > > > > object twice before it is even used. :(
> > > >
> > > > > I think a more clear API would be only two constructors and only two
> > start
> > > > > session methods:
> > > > >
> > > > > HttpClient()
> > > > > HttpClient(String user, String password)
> > > > > startSession(URL url)
> > > > > startSession(String hostname, String port)
> > > > >
> > > > > This will have the added advantage of not having to instantiate the
> > State
> > > > > objects multiple times for a single request.
> > > >
> > > > Ok, you have a case ;)
> > > > I don't like the alternate constructors either. Originally, there was
> > only
> > > > the default constructor, which was simpler IMO.
> > > > I would deprecate instead of removing right away.
> > > >
> > > > > Also, the javadocs should note that using startSession(URL) only
> > populates
> > > > > the hostname and port, not the path of any subsequent HttpMethods.
> > > >
> > > > Good idea.
> > > >
> > > > Remy
> > >
> > > Great! If there are no objections, I'll deprecate those methods and
> > > update the JavaDocs today.
> >
> > I'd like recommend you not to use java.net.URL class.
> > It's confused develpers to use it related to the compatibility.
> > The calss in JDK 1.x doesn't have the userinfo part.
> > However, The class in JDK 2.x have the userinfo part.
> > Perhaps, developers might expect to set credentails for
> > HttpClient by using the class.
> > So I recommend us to have the arguments of host, port and
> > possibly path as String.
> > (It's just like the user and password for credentials... )
> > Actually, the class is just for parsing... not URLConnection. here...
> >
> > What do you guys think of my opinion? ;-)
> >
>
> I take your point, but can't we simply note this in the JavaDocs? It
> seems like many applications that use HttpClient will be working from
> URLs, and it would be nice to support them in the interface with the
> appropriate warnings.
>
I would suggest that HttpClient should, at a minimum, *support* the use of
URLs as constructor arguments. Getting the syntax of a URL correct is
something lots of Java developers do with string manipulations, and it
causes untold numbers of bugs. I'm going to be going through the code for
Tomcat and Struts to clean up the cases where I am currently doing this,
to avoid future problems with funky things like IPv6 literal host
addresses (which use ":" instead of "." to separate the components of the
IP address.
Take string arguments if you want in alternative constructors -- just
don't deprecate the URL based ones, please :-).
> - Morgan
>
>
>
Craig
PS: With regards to JDK 1.1 versus 1.2 -- is that really an
issue? HttpClient is of course free to decide what the minimum platform
it wants is, but I note that many/most of the Commons packages are
starting with JDK 1.2 as a minimum platform.
