Hi, Thanks for the feedback. I spent some time with gt-tile-client today to see if there were any time gain by using MultithreadedHttpClient. I didn't see that, so I have decided to skip that part. Those two client's can live their lives within gt-wms and gt-wfs-ng, until we have something new in gt-http.
I do want to contribute my work on HttpClientFactory. Instead of looking at Apache HttpComponents, which are the successor to Commons HttpClient, I would like to look at the Http Client within JDK 11. Regards, Roar Brænden > 10. des. 2020 kl. 13:29 skrev Mark Prins <mc.pr...@gmail.com>: > > On 09-12-2020 09:47, Roar Brænden wrote: >> Hi, >> I have started to work on a new library gt-http that tries to collect all >> usage of HTTP clients within Geotools. For the moment there are two client >> implementations. SimpleHttpClient in gt-main and MultithreadedHttpClient in >> gt-wms and gt-wfs-ng. You see there are actually three, but the last two are >> almost identical. >> MultithreadedHttpClient have the advantage that it uses a connection pool >> favoring connections to the same host. I see the advantage in using this for >> all the listed projects. The disadvantage is that you would have a new >> dependency on the external library commons-httpclient. >> In the near future this dependency will vanish when Geotools is ready for >> JDK 11, and we could use the new HTTP client inside JDK. Before going that >> direction, it would be great to have one place for all HTTP clients. >> If you really think it's horrible to include this dependency, I could turn >> it into a plugin. >> Any opinions? > > At the risk of this being out of scope; the commons-httpclient version 3 .x > that is in use by GeoTools is and has been EOL for quite a while. upgrades > from 3.x to 4.x or 5.x are non trivial because the API is quite different if > I recall correctly. > So I'm ambivalent with respect to further reliance on an EOL dependency; on > the one hand the imapct can be quite substantial if something shows up awry > in that lib (this is ofcourse already a risk), on the otherhand you're > centralizing in one place, so that could make upgrading an easier task. > > -M > > > _______________________________________________ > GeoTools-Devel mailing list > GeoTools-Devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/geotools-devel _______________________________________________ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
