On 3/11/2015 4:28 PM, Shawn Heisey wrote: > When I have some time to actually work on the code, I'm going to write > it using 4.x classes because that's what I have immediate access to, > but if you do 5.x, SolrServer becomes SolrClient, and HttpSolrServer > becomes HttpSolrClient.
At the URL below is the code I came up with. It shows how to do an add, a commit, and a query where the Solr core (collection) is specified as part of the request, rather than the server connection: http://apaste.info/lRi I did test this code successfully, although there was one difference in that code (/update instead of /update/javabin) because my dev Solr server is running 4.9.1, not 3.5. The code I've shared uses SolrJ 4.x, but is tailored to a server running 3.x with a typical 3.x config. I hope this code will work as-is ... and if it doesn't, that it will be easy for you to figure out what I did wrong. If you want to figure out how to use SolrRequest to implement a query with a specific handler path, you could probably implement all of this in SolrJ 3.5, where SolrQuery#setRequestHandler does not exist. I'm sure that if you look at the SolrQuery class and the CommonsHttpSolrServer#query method from the 3.5 source code, you could piece together how to do this. It might be a good idea to abstract these procedures for add, commit, and query into your own local methods that include the collection parameter. If you need it, you can also implement UpdateRequest.ACTION.OPTIMIZE in a similar manner to the way that I used UpdateRequest.ACTION.COMMIT. See the following issue for the recent work that will go into a new 5.x version (probably 5.1), which adds the capability you are seeking directly to HttpSolrClient, implementing abstract methods from SolrClient: https://issues.apache.org/jira/browse/SOLR-7201 Thanks, Shawn