>>>>>> I personally would not be in favor of throwing an IllegalStateException in case of conflicting configurations for the compatibility sake. My preference would be either to log a big, scary warning or investing some time into making HttpClientParamConfig capable merging old style and new style configurations, the latter being the preferred option. <<<<<<
Your preferred option is fine with me, and would make things more backwards compatible. But I thought you wanted to get away from supported deprecated code. ;-) Karl On Fri, May 23, 2014 at 8:25 AM, Oleg Kalnichevski <[email protected]> wrote: > On Thu, 2014-05-22 at 18:16 -0400, Karl Wright wrote: > > The resolution to this problem was simple -- after I audited both > > HttpClient and SolrJ code. > > > > (0) Expect/continue handling, in the POST-case I was looking at, was in > > fact *off*. It was disguised by the fact that the thread ID differed > and I > > did not note that in the log when I looked at it. > > (1) In InternalHttpClient, if *any* configuration parameters are set, > then > > configuration parameters are used, and the RequestConfig is *thrown > away*. > > (2) In HttpSolrServer, randomly, it sets *one* configuration parameter, > > namely one turning on redirection handling. This was actually in the > code > > I included in the ticket, and it was sufficient to completely throw away > my > > builder-created configuration. > > (3) The solution was to create a modified version of HttpSolrServer and > fix > > the code so that it didn't do that. > > > > Any of the following would have been very helpful: > > > > (a) At least, output a log message when both parameters AND Config object > > were present. > > (b) Documentation (javadoc) making the implemented behavior clear. > > (c) Ideally, if you set a parameter and you've already got a Config > object, > > an IllegalStateException should be thrown. > > > > This would have likely made it much quicker to diagnose than repeated > > debugging sessions, via patched diagnostic jars, with clients half a > world > > away. Better to fail immediately than give the impression that things > were > > okay when they were not. Thoughts? > > > > HttpParams interface and related classes are deprecated, aren't they? > > I personally would not be in favor of throwing an IllegalStateException > in case of conflicting configurations for the compatibility sake. My > preference would be either to log a big, scary warning or investing some > time into making HttpClientParamConfig capable merging old style and new > style configurations, the latter being the preferred option. > > Oleg > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
