> often the reason we are grabbing JSON from some random URL is because we > don’t have SolrJ support for that specific API
I know of some tests that intentionally _don't_ use SolrJ because they're trying to validate some aspect of the form of the API. i.e. The test isn't validating the API functionality so much as it's validating that the HTTP path, parameter names, etc. are all what they should be. So IMO there are at least a few valid usecases for the "grabbing JSON from some random URL" approach. But in general I agree with your theory above that a lot of this is driven by lack of support for particular APIs in SolrJ. We put a lot of work into our SolrJ client, that's what we should be dogfooding internally (and in our tests). If we're not doing that in some places because there's no SolrJ class for a particular API, then that seems like the thing to fix IMO. SOLR-16825 will help with closing these gaps in SolrJ as time progresses by ensuring that all v2 APIs at least are covered in SolrJ. It'd be awesome to get some dogfooding on these experimental generated classes, as long as we're OK with them continuing to evolve a bit over time. On Mon, Oct 2, 2023 at 2:35 PM Eric Pugh <ep...@opensourceconnections.com> wrote: > > I had another thought which is that often the reason we are grabbing JSON > from some random URL is because we don’t have SolrJ support for that specific > API. However, with the upcoming V2 api’s and the code generated Java client > objects, maybe we could start using them in our tests. > > This would let us use Java code with all the type support in a lot of places. > Another reason to push forward on the V2 API’s!!! > > > Eric > > > > On Sep 29, 2023, at 10:46 AM, Eric Pugh <ep...@opensourceconnections.com> > > wrote: > > > > In SOLR-14496 for adding basic auth to our CLI, I ran again into “I need to > > call an end point that spits back JSON and do something with it”. > > > > Specifically, you can see this rather convoluted method > > https://github.com/apache/solr/pull/1954/files#diff-9cf9bffde79b0e6e23224cd3240c4a2b281ba91eed9ad1fb050759b2018f4f3c > > testForResponseElement. > > > > It is copied from TestSolrConfigHandler.testForResponseElement but then > > reworked to actually use the ApiTool under the covers. Good? Bad? Dunno. > > > > I feel like through the code base, both in the code and tests, multiple > > places we need to do this, and they each work a bit different. Including > > my own flavour that I just added using the ApiTool! > > > > Are there any strong opinions on the “right way” that exist out there that > > we could try and standardize around? I’d be willing to invest in the > > migration work if we had a “right way” ;-). > > > > Eric > > _______________________ > > Eric Pugh | Founder & CEO | OpenSource Connections, LLC | 434.466.1467 | > > http://www.opensourceconnections.com > > <http://www.opensourceconnections.com/> | My Free/Busy > > <http://tinyurl.com/eric-cal> > > Co-Author: Apache Solr Enterprise Search Server, 3rd Ed > > <https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw> > > This e-mail and all contents, including attachments, is considered to be > > Company Confidential unless explicitly stated otherwise, regardless of > > whether attachments are marked as such. > > > > _______________________ > Eric Pugh | Founder & CEO | OpenSource Connections, LLC | 434.466.1467 | > http://www.opensourceconnections.com <http://www.opensourceconnections.com/> > | My Free/Busy <http://tinyurl.com/eric-cal> > Co-Author: Apache Solr Enterprise Search Server, 3rd Ed > <https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw> > This e-mail and all contents, including attachments, is considered to be > Company Confidential unless explicitly stated otherwise, regardless of > whether attachments are marked as such. > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org For additional commands, e-mail: dev-h...@solr.apache.org
