Firstly, thank you for speaking up, user feedback is always important to us - even to Evil Comrade Oleg :)
Is that the general development strategy?
I extremely strongly recommend that you follow the basic pattern outlined in the tutorial, but that shouldn't stop you from customizing huge amounts of HttpClient's behaviour, just that it will be a heck of a lot easier if you use HttpClient the way it expects to be used.
I ask since I am about to try to integrate the HttpClient 2.0 beta 2 into an existing framework. I would be doing this to benefit from robust and performant communication with servers, not from features provided by the HttpClient class. For exaple, regardless of whether the HttpClient class handles redirects properly now, I will never use it to transparently handle them as I need to see them and handle them myself.
I'm sure you have more examples than this so maybe we'll wind up having to go through them one by one to see what is best, I'm not sure. In this case, if you want to handle redirects yourself simply use the setFollowRedirects method - these days I think you can just supply your own retry handler as well though I'm not terribly familiar with that API and exactly what it can do.
Similarly, if you want to manage the connections yourself (as seems to be the case for the original bug report) you most definitely can, but you should provide a HttpConnectionManager interface to it so that it works the way HttpClient expects it to.
For the record, my usage of HttpClient is a very minimal replacement for using Sun's URL connection and we already had most of the user agent stuff written already and just plugged HttpClient in. We could drop HttpClient in using the pattern outlined in the tutorial very simply and over time we have come to leverage more and more of it's functionality - but we didn't have to. Our requirements are extremely simple so it may be more difficult or totally impractical for you. I imagine there are cases out there that the HttpClient class doesn't cater for and you need to just use the connections and methods directly instead of through HttpClient - you'll find it more confusing and run into some odd behavior every now and then (like not being able to release a connection twice) but it can work. Mostly if you're going down this road I'd suggest just using the HttpConnection class and the Methods, don't try and manually interface with an existing connection manager or any of the automated stuff that HttpClient provides (this will be much, much easier after HttpMethodBase is refactored).
If I am to be forever doomed to continual revisions due to 'internal' api changes because I don't go through the HttpClient class then I may have to reconsider whether I can use the library.
We try not to change stuff too often, even if we recommend people don't delve into that stuff directly. There are people who need to write their own connection manager for instance and we do provide an officially supported way to do that - as such we are tightly restricted in how much we can change connection management and pooling because a lot of it is actually a public API that we recommend people use.
After reading through "http://jakarta.apache.org/commons/httpclient/tutorial.html"; I see that there is no distinction made between "HttpClient" the library and "HttpClient" the class. Is this deliberate?
I think it's mostly my poor writing style actually, but in this case it represents the way I view HttpClient pretty well. The main entrance point to the HttpClient library is the HttpClient class and my view of things is that we should make that entrance point flexible enough that everyone can use it even if they want to configure nearly everything imaginable. For instance we already support or at some point in the future we plan to support pluggable:
* authentication handling * retry handling * cookie handling * connection pooling/management * method implementations
and there are probably more areas that I just don't know about that will wind up being pluggable. So in the end should be able to plug all your existing logic into HttpClient which while it sounds the opposite way to what you want, if you think of it as a series of defined callbacks between two libraries it's probably close to what you'd wind up with if you plugged HttpClient into your existing library interface anyway. Certainly the outward interface to the rest of the application should be shielded from what HTTP implementation your using.
Sorry for beating on you people for this, and I realise I am probably in a minority, but there is not much point in me going down this route if I am destined to have to drop it all.
Nope great to hear input! I see that Oleg and I have quite different view points on HttpClient anyway and while I really don't see me needing anything more than an add-water solution I definitely understand the need to have flexibility and be able to have more control. I would just tend to do this by using the HttpClient class and providing the appropriate interface (eg HttpConnectionManager) for HttpClient to callback to your existing code instead of using it's own.
I don't know, maybe even that doesn't suit your purpose at all. From a HttpClient development perspective we will definitely need to stabilize the internals anyway just for maintainability, but we need to get it right first and currently we're scheduling getting it "completely right" for the 3.0 release so it will take a bit of time to get there.
Mike
I'd love to be able to work through your use case some more so I can show you exactly how I'd go about it (possibly creating fictional methods to add configurability to HttpClient if required). That way we can both see just how feasible it is to use the HttpClient class in your particular case.
Again, thanks for bringing this up.
Adrian Sutton.
---------------------------------------------- Intencha "tomorrow's technology today" Ph: 38478913 0422236329 Suite 8/29 Oatland Crescent Holland Park West 4121 Australia QLD www.intencha.com
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
