[
https://issues.apache.org/jira/browse/SOLR-8887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15219980#comment-15219980
]
Mark Miller commented on SOLR-8887:
-----------------------------------
I have completed this change as part of SOLR-4509.
It basically moves us off the deprecated classes. It would be nice to
completely abstract out the plugin API from HttpClient classes, but that seems
like a stretch to accomplish well and maintain over internal refactorings. For
now, I've just moved us to non deprecated classes and also limited the surface
area of HttpClient that we expose.
I think we can expose some internals to users like this, but they just will
have to expect to keep up with changes to API's between releases. I do think
the work in SOLR-4509 is likely to be able to stay stable a long time though.
> Solr Security features cannot export the internal, deprecated
> DefaultHttpClient class as part of their user facing API.
> -----------------------------------------------------------------------------------------------------------------------
>
> Key: SOLR-8887
> URL: https://issues.apache.org/jira/browse/SOLR-8887
> Project: Solr
> Issue Type: Bug
> Reporter: Mark Miller
> Priority: Critical
> Fix For: master
>
>
> Seems security now really depends on HttpClientConfigurer. That class was
> only used for tests previously, and was at best completely unsupported. We
> can't promise an API that locks us into an internal, low level, class from a
> lib. Especially a deprecated one. Solr wants to own the http layer, not get
> locked into impls.
> We need to stop using DefaultHttpClient, and it's going to break this stuff.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
