You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@solr.apache.org by Shawn Heisey <ap...@elyograg.org> on 2023/03/28 05:04:10 UTC
Problem with using classes from BOTH httpclients in Http2SolrClient
I have some simple solrj code pulling in solrj 9.2.0 that creates a
client (Http2SolrClient) and then uses that to send a collection
creation request. I know, I should probably use a Cloud client, but I'm
emulating a customer setup where they are on SolrJ 4.7.0 and using
HttpSolrServer.
In order to trim down the ultimate size of my sandbox app, I theorized
that Http2SolrClient was not using the Apache httpclient, so I excluded
all the org.apache.httpcomponents artifacts.
My simple code failed, because Http2SolrClient is using
org.apache.http.entity.ContentType from the Apache client.
The usage can be found in branch_9_2 Http2SolrClient.java on line 823.
I couldn't figure out a way to do that with the Jetty client, but I
admit I didn't try much beyond seeing if there was an alternate version
of the ContentType class. The usage is in a lambda, and I don't
understand lambdas very well.
How much of a mess is it going to be to remove that last Apache
httpclient usage?
There are a lot of other usages from httpcomponents across the main Solr
codebase. I think it might be a worthwhile project to convert those, to
use classes included with Java whenever possible, and resort to Jetty or
another already-present dependency where absolutely required.
I wonder if it might be worthwhile to create an abstract class in Solr
for http clients, and have descendants of that class which implement
functionality using jetty and apache clients. If that is pursued, that
work should probably be limited to main until it is stable. If we do
that and do it right, then we would be free to swap out the http client
implementation at any time, if we find something that works better than
either Jetty or Apache.
Thanks,
Shawn
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
For additional commands, e-mail: dev-help@solr.apache.org
Re: Problem with using classes from BOTH httpclients in Http2SolrClient
Posted by Kevin Risden <kr...@apache.org>.
https://issues.apache.org/jira/browse/SOLR-16723 and MR posted.
Kevin Risden
On Tue, Mar 28, 2023 at 3:34 PM Houston Putman <ho...@apache.org> wrote:
> I agree we shouldn't need the apache client when jetty is used. But making
> Apache and Jetty implementations of the APIs is a big ask, and I'm not sure
> it's worth the maintenance effort.
>
> - Houston
>
> On Tue, Mar 28, 2023 at 3:32 PM Kevin Risden <kr...@apache.org> wrote:
>
> > This was introduced here -
> >
> >
> https://github.com/apache/solr/commit/8efed0555898f485d435d53a72cb6441507d81e1#diff-db379c74efc9ff28acfd7571b07e16dbcdaa510783f2bee835b4a288927b5b3d
> >
> > It looks like it inadvertently copied from HttpSolrClient.java and
> > used ContentType.parse(ct).getMimeType() instead
> > of MimeTypes.getContentTypeWithoutCharset(ct)
> > Kevin Risden
> >
> >
> >
> > On Tue, Mar 28, 2023 at 1:49 AM Jan Høydahl <ja...@cominvent.com>
> wrote:
> >
> > > Good find! I’d say create a jira on making solrj client side work with
> > > apache client excluded. Makes sense.
> > >
> > > Jan Høydahl
> > >
> > > > 28. mar. 2023 kl. 07:04 skrev Shawn Heisey <ap...@elyograg.org>:
> > > >
> > > > I have some simple solrj code pulling in solrj 9.2.0 that creates a
> > > client (Http2SolrClient) and then uses that to send a collection
> creation
> > > request. I know, I should probably use a Cloud client, but I'm
> > emulating a
> > > customer setup where they are on SolrJ 4.7.0 and using HttpSolrServer.
> > > >
> > > > In order to trim down the ultimate size of my sandbox app, I
> theorized
> > > that Http2SolrClient was not using the Apache httpclient, so I excluded
> > all
> > > the org.apache.httpcomponents artifacts.
> > > >
> > > > My simple code failed, because Http2SolrClient is using
> > > org.apache.http.entity.ContentType from the Apache client.
> > > >
> > > > The usage can be found in branch_9_2 Http2SolrClient.java on line
> 823.
> > > >
> > > > I couldn't figure out a way to do that with the Jetty client, but I
> > > admit I didn't try much beyond seeing if there was an alternate version
> > of
> > > the ContentType class. The usage is in a lambda, and I don't
> understand
> > > lambdas very well.
> > > >
> > > > How much of a mess is it going to be to remove that last Apache
> > > httpclient usage?
> > > >
> > > > There are a lot of other usages from httpcomponents across the main
> > Solr
> > > codebase. I think it might be a worthwhile project to convert those,
> to
> > > use classes included with Java whenever possible, and resort to Jetty
> or
> > > another already-present dependency where absolutely required.
> > > >
> > > > I wonder if it might be worthwhile to create an abstract class in
> Solr
> > > for http clients, and have descendants of that class which implement
> > > functionality using jetty and apache clients. If that is pursued, that
> > > work should probably be limited to main until it is stable. If we do
> > that
> > > and do it right, then we would be free to swap out the http client
> > > implementation at any time, if we find something that works better than
> > > either Jetty or Apache.
> > > >
> > > > Thanks,
> > > > Shawn
> > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
> > > > For additional commands, e-mail: dev-help@solr.apache.org
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
> > > For additional commands, e-mail: dev-help@solr.apache.org
> > >
> > >
> >
>
Re: Problem with using classes from BOTH httpclients in Http2SolrClient
Posted by Houston Putman <ho...@apache.org>.
I agree we shouldn't need the apache client when jetty is used. But making
Apache and Jetty implementations of the APIs is a big ask, and I'm not sure
it's worth the maintenance effort.
- Houston
On Tue, Mar 28, 2023 at 3:32 PM Kevin Risden <kr...@apache.org> wrote:
> This was introduced here -
>
> https://github.com/apache/solr/commit/8efed0555898f485d435d53a72cb6441507d81e1#diff-db379c74efc9ff28acfd7571b07e16dbcdaa510783f2bee835b4a288927b5b3d
>
> It looks like it inadvertently copied from HttpSolrClient.java and
> used ContentType.parse(ct).getMimeType() instead
> of MimeTypes.getContentTypeWithoutCharset(ct)
> Kevin Risden
>
>
>
> On Tue, Mar 28, 2023 at 1:49 AM Jan Høydahl <ja...@cominvent.com> wrote:
>
> > Good find! I’d say create a jira on making solrj client side work with
> > apache client excluded. Makes sense.
> >
> > Jan Høydahl
> >
> > > 28. mar. 2023 kl. 07:04 skrev Shawn Heisey <ap...@elyograg.org>:
> > >
> > > I have some simple solrj code pulling in solrj 9.2.0 that creates a
> > client (Http2SolrClient) and then uses that to send a collection creation
> > request. I know, I should probably use a Cloud client, but I'm
> emulating a
> > customer setup where they are on SolrJ 4.7.0 and using HttpSolrServer.
> > >
> > > In order to trim down the ultimate size of my sandbox app, I theorized
> > that Http2SolrClient was not using the Apache httpclient, so I excluded
> all
> > the org.apache.httpcomponents artifacts.
> > >
> > > My simple code failed, because Http2SolrClient is using
> > org.apache.http.entity.ContentType from the Apache client.
> > >
> > > The usage can be found in branch_9_2 Http2SolrClient.java on line 823.
> > >
> > > I couldn't figure out a way to do that with the Jetty client, but I
> > admit I didn't try much beyond seeing if there was an alternate version
> of
> > the ContentType class. The usage is in a lambda, and I don't understand
> > lambdas very well.
> > >
> > > How much of a mess is it going to be to remove that last Apache
> > httpclient usage?
> > >
> > > There are a lot of other usages from httpcomponents across the main
> Solr
> > codebase. I think it might be a worthwhile project to convert those, to
> > use classes included with Java whenever possible, and resort to Jetty or
> > another already-present dependency where absolutely required.
> > >
> > > I wonder if it might be worthwhile to create an abstract class in Solr
> > for http clients, and have descendants of that class which implement
> > functionality using jetty and apache clients. If that is pursued, that
> > work should probably be limited to main until it is stable. If we do
> that
> > and do it right, then we would be free to swap out the http client
> > implementation at any time, if we find something that works better than
> > either Jetty or Apache.
> > >
> > > Thanks,
> > > Shawn
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
> > > For additional commands, e-mail: dev-help@solr.apache.org
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
> > For additional commands, e-mail: dev-help@solr.apache.org
> >
> >
>
Re: Problem with using classes from BOTH httpclients in Http2SolrClient
Posted by Kevin Risden <kr...@apache.org>.
This was introduced here -
https://github.com/apache/solr/commit/8efed0555898f485d435d53a72cb6441507d81e1#diff-db379c74efc9ff28acfd7571b07e16dbcdaa510783f2bee835b4a288927b5b3d
It looks like it inadvertently copied from HttpSolrClient.java and
used ContentType.parse(ct).getMimeType() instead
of MimeTypes.getContentTypeWithoutCharset(ct)
Kevin Risden
On Tue, Mar 28, 2023 at 1:49 AM Jan Høydahl <ja...@cominvent.com> wrote:
> Good find! I’d say create a jira on making solrj client side work with
> apache client excluded. Makes sense.
>
> Jan Høydahl
>
> > 28. mar. 2023 kl. 07:04 skrev Shawn Heisey <ap...@elyograg.org>:
> >
> > I have some simple solrj code pulling in solrj 9.2.0 that creates a
> client (Http2SolrClient) and then uses that to send a collection creation
> request. I know, I should probably use a Cloud client, but I'm emulating a
> customer setup where they are on SolrJ 4.7.0 and using HttpSolrServer.
> >
> > In order to trim down the ultimate size of my sandbox app, I theorized
> that Http2SolrClient was not using the Apache httpclient, so I excluded all
> the org.apache.httpcomponents artifacts.
> >
> > My simple code failed, because Http2SolrClient is using
> org.apache.http.entity.ContentType from the Apache client.
> >
> > The usage can be found in branch_9_2 Http2SolrClient.java on line 823.
> >
> > I couldn't figure out a way to do that with the Jetty client, but I
> admit I didn't try much beyond seeing if there was an alternate version of
> the ContentType class. The usage is in a lambda, and I don't understand
> lambdas very well.
> >
> > How much of a mess is it going to be to remove that last Apache
> httpclient usage?
> >
> > There are a lot of other usages from httpcomponents across the main Solr
> codebase. I think it might be a worthwhile project to convert those, to
> use classes included with Java whenever possible, and resort to Jetty or
> another already-present dependency where absolutely required.
> >
> > I wonder if it might be worthwhile to create an abstract class in Solr
> for http clients, and have descendants of that class which implement
> functionality using jetty and apache clients. If that is pursued, that
> work should probably be limited to main until it is stable. If we do that
> and do it right, then we would be free to swap out the http client
> implementation at any time, if we find something that works better than
> either Jetty or Apache.
> >
> > Thanks,
> > Shawn
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
> > For additional commands, e-mail: dev-help@solr.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
> For additional commands, e-mail: dev-help@solr.apache.org
>
>
Re: Problem with using classes from BOTH httpclients in Http2SolrClient
Posted by Jan Høydahl <ja...@cominvent.com>.
Good find! I’d say create a jira on making solrj client side work with apache client excluded. Makes sense.
Jan Høydahl
> 28. mar. 2023 kl. 07:04 skrev Shawn Heisey <ap...@elyograg.org>:
>
> I have some simple solrj code pulling in solrj 9.2.0 that creates a client (Http2SolrClient) and then uses that to send a collection creation request. I know, I should probably use a Cloud client, but I'm emulating a customer setup where they are on SolrJ 4.7.0 and using HttpSolrServer.
>
> In order to trim down the ultimate size of my sandbox app, I theorized that Http2SolrClient was not using the Apache httpclient, so I excluded all the org.apache.httpcomponents artifacts.
>
> My simple code failed, because Http2SolrClient is using org.apache.http.entity.ContentType from the Apache client.
>
> The usage can be found in branch_9_2 Http2SolrClient.java on line 823.
>
> I couldn't figure out a way to do that with the Jetty client, but I admit I didn't try much beyond seeing if there was an alternate version of the ContentType class. The usage is in a lambda, and I don't understand lambdas very well.
>
> How much of a mess is it going to be to remove that last Apache httpclient usage?
>
> There are a lot of other usages from httpcomponents across the main Solr codebase. I think it might be a worthwhile project to convert those, to use classes included with Java whenever possible, and resort to Jetty or another already-present dependency where absolutely required.
>
> I wonder if it might be worthwhile to create an abstract class in Solr for http clients, and have descendants of that class which implement functionality using jetty and apache clients. If that is pursued, that work should probably be limited to main until it is stable. If we do that and do it right, then we would be free to swap out the http client implementation at any time, if we find something that works better than either Jetty or Apache.
>
> Thanks,
> Shawn
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
> For additional commands, e-mail: dev-help@solr.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@solr.apache.org
For additional commands, e-mail: dev-help@solr.apache.org