[
https://issues.apache.org/jira/browse/SOLR-8887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15208971#comment-15208971
]
Ishan Chattopadhyaya edited comment on SOLR-8887 at 3/23/16 7:26 PM:
---------------------------------------------------------------------
I think we had to bite the bullet and go this route for security (esp for
kerberos) -as we didn't have any other easy choice.- (maybe we didn't look hard
enough for an alternative, and this sounded like the best choice).
Given that the usage of deprecated parts of HttpClient and the non-deprecated
parts are very different (and hence require non-trivial refactoring to
upgrade), something that [~elyograg] explored in SOLR-5604, I think we should
treat both as almost two separate http client libraries. So, in essence, my
suggestion is that we would be better served if our http client layer was
agnostic of any particular library, but just a wrapper around various possible
implementations.
In such an architecture, it should be possible to support the security plugins
and apis for only those who want to use HttpClient (deprecated), and we
continue to innovate using other library implementations separately.
What do you think? [[email protected]], [~anshumg], [~noble.paul]
was (Author: ichattopadhyaya):
I think we had to bite the bullet and go this route for security (esp for
kerberos) as we didn't have any other easy choice.
Given that the usage of deprecated parts of HttpClient and the non-deprecated
parts are very different (and hence require non-trivial refactoring to
upgrade), something that [~elyograg] explored in SOLR-5604, I think we should
treat both as almost two separate http client libraries. So, in essence, my
suggestion is that we would be better served if our http client layer was
agnostic of any particular library, but just a wrapper around various possible
implementations.
In such an architecture, it should be possible to support the security plugins
and apis for only those who want to use HttpClient (deprecated), and we
continue to innovate using other library implementations separately.
What do you think? [[email protected]], [~anshumg], [~noble.paul]
> 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]
