{"id":64718,"date":"2017-03-29T13:00:14","date_gmt":"2017-03-29T10:00:14","guid":{"rendered":"http:\/\/www.javacodegeeks.com\/?p=64718"},"modified":"2023-12-11T10:17:23","modified_gmt":"2023-12-11T08:17:23","slug":"elasticsearch-java-developers-elasticsearch-java","status":"publish","type":"post","link":"https:\/\/www.javacodegeeks.com\/2017\/03\/elasticsearch-java-developers-elasticsearch-java.html","title":{"rendered":"Elasticsearch for Java Developers: Elasticsearch from Java"},"content":{"rendered":"

This article is part of our Academy Course titled Elasticsearch Tutorial for Java Developers<\/a>.<\/p>\n

In this course, we provide a series of tutorials so that you can develop your own Elasticsearch based applications. We cover a wide range of topics, from installation and operations, to Java API Integration and reporting. With our straightforward tutorials, you will be able to get your own projects up and running in minimum time. Check it out here<\/a>!<\/em><\/p>\n

<\/a>1. Introduction<\/h2>\n

In the previous part of the tutorial<\/a> we mastered the skills of establishing meaningful conversations with Elasticsearch<\/a> by leveraging its numerous RESTful APIs<\/a>, using the command line tools only. It is very handful knowledge, however when you are developing Java \/ JVM applications, you would need better options than command line. Luckily, Elasticsearch<\/a> has more than one offering in this area.<\/p>\n

\n

Table Of Contents<\/h3>\n
\n
1. Introduction<\/a><\/dt>\n
2. Using Java Client API<\/a><\/dt>\n
3. Using Java Rest Client<\/a><\/dt>\n
4. Using Testing Kit<\/a><\/dt>\n
5. Conclusions<\/a><\/dt>\n
6. What\u2019s next<\/a><\/dt>\n<\/dl>\n<\/div>\n

Along this part of the tutorial we are going learn how to talk to Elasticsearch<\/a> by means of native Java APIs. Our approach to that would be to code and to work on a couple of Java applications, using Apache Maven<\/a> for build management, terrific Spring Framework<\/a> for dependency wiring and inversion of control<\/a>, and awesome JUnit<\/a> \/ AssertJ<\/a> as test scaffolding.<\/p>\n

<\/a>2. Using Java Client API<\/h2>\n

Since the early versions, Elasticsearch<\/a> distributes a dedicated Java client API<\/a> with each release, also known as transport client. It talks Elasticsearch<\/a> native transport protocol and as such, imposes the constraint that the version of the client library should at least match the major version of Elasticsearch<\/a> distribution you are using (ideally, the client should have exactly the same version).<\/p>\n

As we are \u00adusing Elasticsearch<\/a> version 5.2.0<\/code>, it would make sense to add the respective client version dependency to our pom.xml<\/code> file.<\/p>\n

<dependency>\n    <groupId>org.elasticsearch.client<\/groupId>\n    <artifactId>transport<\/artifactId>\n    <version>5.2.0<\/version>\n<\/dependency>\n<\/pre>\n
Since we have chosen Spring Framework<\/a> to power our application, literally the only thing we need is a transport client configuration.<\/p>\n
@Configuration\npublic class ElasticsearchClientConfiguration {\n    @Bean(destroyMethod = \"close\")\n    TransportClient transportClient() throws UnknownHostException  {\n        return new PreBuiltTransportClient(\n            Settings.builder()-\n                .put(ClusterName.CLUSTER_NAME_SETTING.getKey(), \"es-catalog\")\n                .build()\n            )\n            .addTransportAddress(new InetSocketTransportAddress(\n                InetAddress.getByName(\"localhost\"), 9300));\n    }\n}\n<\/pre>\n
The PreBuiltTransportClient<\/code> follows the builder pattern<\/a> (as most of the classes as we are going to see soon) to construct TransportClient<\/code> instance, and once it is there, we could use the injection techniques supported by Spring Framework<\/a> to access it:<\/p>\n
@Autowired private TransportClient client;\n<\/pre>\n
The CLUSTER_NAME_SETTING<\/code> is worth of our attention: it should match exactly the name of the Elasticsearch<\/a> cluster we are connecting to, which in our case is es-catalog<\/code>.<\/p>\n
Great, we have our transport client initialized, so what can we do with it? Essentially, the transport client exposes a whole bunch of methods (following the fluent interface<\/a> style) to open the access to all Elasticsearch<\/a> APIs from the Java code. To get one step ahead, it should be noted that transport client has explicit separation between regular APIs and admin APIs. The latter is available by invoking admin()<\/code> method on the transport client instance.<\/p>\n
Before rolling the sleeves and getting our hands dirty, it is necessary to mention that Elasticsearch<\/a> Java APIs are designed to be fully asynchronous and as such, are centered around two key abstractions:\u00a0 ActionFuture<?><\/code> and ListenableActionFuture<?><\/code>. In fact, ActionFuture<?><\/code> is just a plain old Java Future<?><\/a>\u00a0with a couple of handful methods added, stay tuned on that. From the other side, ListenableActionFuture<?><\/code> is more powerful abstraction with the ability to take the callbacks and notify the caller about the result of the execution.<\/p>\n
Picking one style over the other is totally dictated by the needs of your applications, as both of them do have own pros and cons. Without further ado, let us go ahead and make sure our Elasticsearch<\/a> cluster is healthy and is ready to rock.<\/p>\n
final ClusterHealthResponse response = client\n    .admin()\n    .cluster()\n    .health(\n        Requests\n            .clusterHealthRequest()\n            .waitForGreenStatus()\n            .timeout(TimeValue.timeValueSeconds(5))\n    )\n    .actionGet();\n\nassertThat(response.isTimedOut())\n    .withFailMessage(\"The cluster is unhealthy: %s\", response.getStatus())\n    .isFalse();\n\n<\/pre>\n
The example is pretty simple and straightforward. What we do is inquiring Elasticsearch<\/a> cluster about its status while explicitly asking to wait at most 5 seconds<\/code> for the status to become green<\/code> (if it is not the case yet). Under the hood, client.admin().cluster().health(...)<\/code> returns ActionFuture<?><\/code> so we have to call one of the actionGet<\/code> methods to get the response.<\/p>\n
Here is another, slightly different way to use Elasticsearch<\/a> Java API, this time employing the prepareXxx<\/code> methods family.<\/p>\n
final ClusterHealthResponse response = client\n    .admin()\n    .cluster()\n    .prepareHealth()\n    .setWaitForGreenStatus()\n    .setTimeout(TimeValue.timeValueSeconds(5))\n    .execute()\n    .actionGet();\n\nassertThat(response.isTimedOut())\n    .withFailMessage(\"The cluster is unhealthy: %s\", response.getStatus())\n    .isFalse();\n<\/pre>\n
Although both code snippets lead to absolutely identical results, the latter one is calling client.admin().cluster().prepareHealth().execute()<\/code> method at the end of the chain, which returns ListenableActionFuture<?><\/code>. It does not make a lot of difference in this example but please keep it in mind as we are going to see more interesting use cases where such a detail becomes really a game changer.<\/p>\n
And finally, last but not least, the asynchronous nature of any API (and Elasticsearch<\/a> Java API is not an exception) assumes that invocation of the operation will take some time and it becomes the responsibility of the caller to decide how to deal with that. What we have used so far is just calling actionGet<\/code> on the instance of ActionFuture<?><\/code>, which effectively transforms the asynchronous execution into a blocking (or, to say it the other way, synchronous) call. Moreover, we did not specify the expectations in terms of how long we would agree to wait for the execution to be completed before giving up. We could do better than that and in the rest of this section we are going to address both of these points.<\/p>\n
Once we have our Elasticsearch<\/a> cluster status all green<\/code>, it is time to create some indices, much like we have done in the previous part of the tutorial but this time using Java APIs only. It would be good idea to ensure that catalog<\/code> index does not exist yet before creating one.<\/p>\n
final IndicesExistsResponse response = client\n    .admin()\n    .indices()\n    .prepareExists(\"catalog\")\n    .get(TimeValue.timeValueMillis(100));\n\t\t\nif (!response.isExists()) {\n    ...\n}\n<\/pre>\n
Please notice that in the snippet above we provided the explicit timeout for the operation to complete, get(TimeValue.timeValueMillis(100))<\/code>, which is essentially the shortcut to execute().actionGet(TimeValue.timeValueMillis(100))<\/code>.<\/p>\n
For the catalog<\/code> index settings and mapping types we are going to use exactly the same JSON<\/a> file, catalog-index.json<\/code>, which we had been using in the previous part of the tutorial. We are going to place it into src\/test\/resources<\/code> folder, following Apache Maven<\/a> conventions.<\/p>\n
@Value(\"classpath:catalog-index.json\") \nprivate Resource index;\n<\/pre>\n
Fortunately Spring Framework<\/a> simplifies a lot the injection of the classpath resources so not much we need to do here to gain the access to catalog-index.json<\/code> content and feed it directly to Elasticsearch<\/a> Java API.<\/p>\n
try (final ByteArrayOutputStream out = new ByteArrayOutputStream()) {\n    Streams.copy(index.getInputStream(), out);\n\t\t\t\n    final CreateIndexResponse response = client\n        .admin()\n        .indices()\n        .prepareCreate(\"catalog\")\n        .setSource(out.toByteArray())\n        .setTimeout(TimeValue.timeValueSeconds(1))\n        .get(TimeValue.timeValueSeconds(2));\n\t\n    assertThat(response.isAcknowledged())\n        .withFailMessage(\"The index creation has not been acknowledged\")\n        .isTrue();\t\t\n}\n<\/pre>\n
This code block illustrates yet another way to approach the Elasticsearch<\/a> Java APIs by utilizing the setSource<\/code> method call. In a nutshell, we just supply the request payload ourselves in a form of opaque blob (or string) and it is going to be sent to Elasticsearch<\/a> node(s) as is. However, we could have used a pure Java data structures instead, for example:<\/p>\n
final CreateIndexResponse response = client\n    .admin()\n    .indices()\n    .prepareCreate(\"catalog\")\n    .setSettings(...)\n    .setMapping(\"books\", ...)\n    .setMapping(\"authors\", ...)\n    .setTimeout(TimeValue.timeValueSeconds(1))\n    .get(TimeValue.timeValueSeconds(2));\n<\/pre>\n
Good, with that we are going to conclude the transport client admin APIs and switch over to document and search APIs, as those would be the ones you would use most of the time.\u00a0As we remember, Elasticsearch<\/a>\u00a0 speaks JSON<\/a> so we have to somehow convert books and authors to JSON<\/a> representation using Java. In fact, Elasticsearch<\/a> Java API helps with that by supporting the generic abstraction over the content named XContent<\/code>, for example:<\/p>\n
final XContentBuilder source = JsonXContent\n    .contentBuilder()\n    .startObject()\n    .field(\"title\", \"Elasticsearch: The Definitive Guide. ...\")\n    .startArray(\"categories\")\n        .startObject().field(\"name\", \"analytics\").endObject()\n        .startObject().field(\"name\", \"search\").endObject()\n        .startObject().field(\"name\", \"database store\").endObject()\n    .endArray()\n    .field(\"publisher\", \"O'Reilly\")\n    .field(\"description\", \"Whether you need full-text search or ...\")\n    .field(\"published_date\", new LocalDate(2015, 02, 07).toDate())\n    .field(\"isbn\", \"978-1449358549\")\n    .field(\"rating\", 4)\n    .endObject();\n<\/pre>\n
Having the document representation, we could send it over to Elasticsearch<\/a> for indexing. To keep the promises, this time we would like to go truly asynchronous way and do not wait for the response, providing the notification callback in a shape of ActionListener<IndexResponse><\/code> instead.<\/p>\n
client\n    .prepareIndex(\"catalog\", \"books\")\n    .setId(\"978-1449358549\")\n    .setContentType(XContentType.JSON)\n    .setSource(source)\n    .setOpType(OpType.INDEX)\n    .setRefreshPolicy(RefreshPolicy.WAIT_UNTIL)\n    .setTimeout(TimeValue.timeValueMillis(100))\n    .execute(new ActionListener() {\n        @Override\n\t  public void onResponse(IndexResponse response) {\n\t      LOG.info(\"The document has been indexed with the result: {}\", \n\t\t    response.getResult());\n        }\n\t\t\t\t\n        @Override\n        public void onFailure(Exception ex) {\n            LOG.error(\"The document has been not been indexed\", ex);\n        }\n    });\n<\/pre>\n
Nice, so we have our first document in the books<\/code> collection! What about authors<\/code> though? Well, just as reminder, the book in question has more than one author so it is a perfect occasion to use document bulk indexing.
 
<\/div> <\/div><\/p>\n
final XContentBuilder clintonGormley = JsonXContent\n    .contentBuilder()\n    .startObject()\n    .field(\"first_name\", \"Clinton\")\n    .field(\"last_name\", \"Gormley\")\n    .endObject();\n\t\t\nfinal XContentBuilder zacharyTong = JsonXContent\n    .contentBuilder()\n    .startObject()\n    .field(\"first_name\", \"Zachary\")\n    .field(\"last_name\", \"Tong\")\n    .endObject();\n<\/pre>\n
The XContent<\/code> part is clear enough and frankly, you may never use such an option, preferring to model real classes and use one of the terrific Java libraries for automatic to \/ from JSON<\/a> conversions. But the following snippet is really interesting.<\/p>\n
final BulkResponse response = client\n    .prepareBulk()\n    .add(\n        Requests\n            .indexRequest(\"catalog\")\n            .type(\"authors\")\n            .id(\"1\")\n            .source(clintonGormley)\n            .parent(\"978-1449358549\")\n            .opType(OpType.INDEX)\n    )\n    .add(\n        Requests\n            .indexRequest(\"catalog\")\n            .type(\"authors\")\n            .id(\"2\")\n            .source(zacharyTong)\n            .parent(\"978-1449358549\")\n            .opType(OpType.INDEX)\n    )\n    .setRefreshPolicy(RefreshPolicy.WAIT_UNTIL)\n    .setTimeout(TimeValue.timeValueMillis(500))\n    .get(TimeValue.timeValueSeconds(1));\n\t\t\nassertThat(response.hasFailures())\n    .withFailMessage(\"Bulk operation reported some failures: %s\", \n        response.buildFailureMessage())\n    .isFalse();\n<\/pre>\n
We are sending two index requests for authors<\/code> collection in one single batch. You might be wondering what this parent(\"978-1449358549\")<\/code> means and to answer this question we have to recall that books<\/code> and authors<\/code> are modeled using parent \/ child relationships. So the parent<\/code> key in this case is the reference (by the _id<\/code> property) to the respective parent document in books<\/code> collection.<\/p>\n
Well done, so we know how to work with indices and how to index the documents using Elasticsearch<\/a> transport client Java APIs. It is search time now!<\/p>\n
final SearchResponse response = client\n    .prepareSearch(\"catalog\")\n    .setTypes(\"books\")\n    .setSearchType(SearchType.DFS_QUERY_THEN_FETCH)\n    .setQuery(QueryBuilders.matchAllQuery())\n    .setFrom(0)\n    .setSize(10)\n    .setTimeout(TimeValue.timeValueMillis(100))\n    .get(TimeValue.timeValueMillis(200));\n\nassertThat(response.getHits().hits())\n    .withFailMessage(\"Expecting at least one book to be returned\")\n    .isNotEmpty();\n<\/pre>\n
The simplest search criterion one can come up with is to match all documents and this is what we have done in the snippet above (please notice that we explicitly limited the number of results returned to 10<\/code> documents).<\/p>\n
To our luck, Elasticsearch<\/a> Java API has full-fledged implementation of Query DSL<\/a> in a form of QueryBuilders<\/code> and QueryBuilder<\/code> classes so writing (and maintaining) the complex queries is exceptionally easy. As an exercise, we are going to build the same compound query which we came up with in the previous part of the tutorial:<\/p>\n
final QueryBuilder query = QueryBuilders\n    .boolQuery()\n        .must(\n            QueryBuilders\n                .rangeQuery(\"rating\")\n                .gte(4)\n        )\n        .must(\n            QueryBuilders\n                .nestedQuery(\n                    \"categories\", \n                    QueryBuilders.matchQuery(\"categories.name\", \"analytics\"),\n                    ScoreMode.Total\n                )\n            )\n        .must(\n            QueryBuilders\n                .hasChildQuery(\n                    \"authors\", \n                    QueryBuilders.termQuery(\"last_name\", \"Gormley\"),\n                    ScoreMode.Total\n                )\n    );\n<\/pre>\n
The code looks pretty, concise and human-readable. If you are keen on using static imports<\/a> feature of the Java programming language, the query is going to look even more compact.<\/p>\n
final SearchResponse response = client\n    .prepareSearch(\"catalog\")\n    .setTypes(\"books\")\n    .setSearchType(SearchType.DFS_QUERY_THEN_FETCH)\n    .setQuery(query)\n    .setFrom(0)\n    .setSize(10)\n    .setFetchSource(\n        new String[] { \"title\", \"publisher\" }, \/* includes *\/ \n        new String[0] \/* excludes *\/\n    )\n    .setTimeout(TimeValue.timeValueMillis(100))\n    .get(TimeValue.timeValueMillis(200));\n\nassertThat(response.getHits().hits())\n    .withFailMessage(\"Expecting at least one book to be returned\")\n    .extracting(\"sourceAsString\", String.class)\n    .hasOnlyOneElementSatisfying(source -> {\n        assertThat(source).contains(\"Elasticsearch: The Definitive Guide.\");\n    });<\/pre>\n
To keep both versions of the query identical, we also hinted the search request through setFetchSource<\/code> method that we are interested only in returning title and publisher properties of the document source.<\/p>\n
The curious readers might be wondering how to use aggregations along with the search requests. This is excellent topic to cover so let us talk about that for a moment. Along with Query DSL<\/a>, Elasticsearch<\/a> Java API also supplies aggregations DSL<\/a>, revolving around AggregationBuilders<\/code> and AggregationBuilder<\/code> classes. For example, this is how we could build the bucketed aggregation by publisher<\/code> property.<\/p>\n
final AggregationBuilder aggregation = AggregationBuilders\n    .terms(\"publishers\")\n    .field(\"publisher\")\n    .size(10);\n<\/pre>\n
Having the aggregations defined, we could inject them into search request using addAggregation<\/code> method call as is shown in the code snippet below:<\/p>\n
final SearchResponse response = client\n    .prepareSearch(\"catalog\")\n    .setTypes(\"books\")\n    .setSearchType(SearchType.DFS_QUERY_THEN_FETCH)\n    .setQuery(QueryBuilders.matchAllQuery())\n    .addAggregation(aggregation)\n    .setFrom(0)\n    .setSize(10)\n    .setTimeout(TimeValue.timeValueMillis(100))\n    .get(TimeValue.timeValueMillis(200));\n\nfinal StringTerms publishers = response.getAggregations().get(\"publishers\");\nassertThat(publishers.getBuckets())\n    .extracting(\"keyAsString\", String.class)\n    .contains(\"O'Reilly\");\n<\/pre>\n
The results of the aggregations are available in the response and could be retrieved by referencing the aggregation name, for example publishers<\/code> in our case. However be cautious and carefully use the proper aggregation types in order to not get surprises in a form of ClassCastException<\/a>. Because our publishers aggregation has been defined to group terms into buckets, we are safe by casting the one from the response to StringTerms <\/code>class instance.<\/p>\n
<\/a>3. Using Java Rest Client<\/h2>\n
One of the drawbacks related to the usage of the Elasticsearch<\/a> Java client API<\/a> is the requirement to be binary compatible with the version of Elasticsearch<\/a> (either standalone or cluster) you are running.<\/p>\n
Fortunately, since the first release of 5.0.0<\/code> branch, Elasticsearch<\/a> brings another option on the table: Java REST client<\/a>. It uses HTTP<\/a> protocol to talk to Elasticsearch<\/a>\u00a0 by invoking its RESTful API<\/a> endpoints and is oblivious to the version of Elasticsearch<\/a> (literally, it is compatible with all Elasticsearch<\/a> versions).<\/p>\n
It should be noted though that Java REST client<\/a> is pretty low level and is not as convenient to use as Java client API<\/a>, far from that in fact. However, there are quite a few reasons why one may prefer to use Java REST client<\/a> over Java client API<\/a> to communicate with Elasticsearch<\/a> so it is worth its own discussion. To start off, let us include the respective dependency into our Apache Maven<\/a> pom.xml<\/code> file.<\/p>\n
<dependency>\n    <groupId>org.elasticsearch.client<\/groupId>\n    <artifactId>rest<\/artifactId>\n    <version>5.2.0<\/version>\n<\/dependency>\n<\/pre>\n
From the configuration perspective we only need to construct the instance of RestClient<\/code> by calling RestClient.builder<\/code> method.<\/p>\n
@Configuration\npublic class ElasticsearchClientConfiguration {\n    @Bean(destroyMethod = \"close\")\n    RestClient transportClient() {\n        return RestClient\n            .builder(new HttpHost(\"localhost\", 9200))\n            .setRequestConfigCallback(new RequestConfigCallback() {\n                  @Override\n                  public Builder customizeRequestConfig(Builder builder) {\n                      return builder\n                          .setConnectTimeout(1000)\n                          .setSocketTimeout(5000);\n                  }\n            })\n            .build();\n    }\n}\n<\/pre>\n
We are jumping a bit ahead here but please pay particular attention to configuration of the proper timeouts because Java REST client<\/a> does not provide a way (at least, at the moment) to specify those on per-request level basis. With that, we can inject the RestClient<\/code> instance anywhere, using the same wiring techniques Spring Framework<\/a> is kindly providing to us:<\/p>\n
@Autowired private RestClient client;\n<\/pre>\n
To make a fair comparison between Java client API<\/a> and Java REST client<\/a>, we are going to dissect a couple of examples we have looked at in the previous section, setting out the stage by checking the Elasticsearch<\/a> cluster health.<\/p>\n
@Test\npublic void esClusterIsHealthy() throws Exception {\n    final Response response = client\n        .performRequest(HttpGet.METHOD_NAME, \"_cluster\/health\", emptyMap());\n\n    final Object json = defaultConfiguration()\n        .jsonProvider()\n        .parse(EntityUtils.toString(response.getEntity()));\n\t\t\n    assertThat(json, hasJsonPath(\"$.status\", equalTo(\"green\")));\n}\n<\/pre>\n
Indeed, the difference is obvious. As you may guess, Java REST client<\/a> is actually a thin wrapper around the more generic, well-known and respected Apache Http Client<\/a> library. The response is returned as a string or byte array and it becomes the responsibility of the caller to transform it to JSON<\/a> and extract the necessary pieces of data. To deal with that in test assertions, we have on-boarded the wonderful JsonPath<\/a> library, but you are free to make a choice here.<\/p>\n
A family of performRequest<\/code> methods is the typical way for synchronous (or blocking) communication using Java REST client<\/a> API. Alternatively, there is a family of performRequestAsync<\/code> methods which are supposed to be used in fully asynchronous flows. In the next example we are going to use one of those in order to index the document into books<\/code> collection.<\/p>\n
The simplest way to represent JSON<\/a>-like structure in Java language is using plain old Map<String, Object><\/code> as it is demonstrated in the code fragment below.<\/p>\n
final Map<String, Object> source = new LinkedHashMap<>();\nsource.put(\"title\", \"Elasticsearch: The Definitive Guide. ...\");\nsource.put(\"categories\", \n    new Map[] {\n        singletonMap(\"name\", \"analytics\"),\n        singletonMap(\"name\", \"search\"),\n        singletonMap(\"name\", \"database store\")\n    }\n);\nsource.put(\"publisher\", \"O'Reilly\");\nsource.put(\"description\", \"Whether you need full-text search or ...\");\nsource.put(\"published_date\", \"2015-02-07\");\nsource.put(\"isbn\", \"978-1449358549\");\nsource.put(\"rating\", 4);\n<\/pre>\n
Now we need to convert this Java structure into valid JSON<\/a> string. There are dozens of way to do so but we are going to leverage the json-smart<\/a> library, for the reason that it is already available as a transitive dependency of JsonPath<\/a> library.<\/p>\n
final HttpEntity payload = new NStringEntity(JSONObject.toJSONString(source), \n    ContentType.APPLICATION_JSON);\n<\/pre>\n
Having the payload ready, nothing prevents us from invoking Indexing API<\/a> of the Elasticsearch<\/a> to add a book into books<\/code> collection.<\/p>\n
client.performRequestAsync(\n    HttpPut.METHOD_NAME, \n    \"catalog\/books\/978-1449358549\",\n    emptyMap(),\n    payload,\n    new ResponseListener() {\n        @Override\n        public void onSuccess(Response response) {\n            LOG.info(\"The document has been indexed successfully\");\n        }\n\t\t\t\t\n        @Override\n        public void onFailure(Exception ex) {\n            LOG.error(\"The document has been not been indexed\", ex);\n        }\n    });\n<\/pre>\n
This time we decided to not wait for the response but supply a callback (instance of ResponseListener<\/code>) instead, keeping the flow truly asynchronous. To finish up, it would be great to understand what it takes to perform more or less realistic search request and parse the results.<\/p>\n
As you may expect, the Java REST client<\/a> does not provide any fluent APIs around Query DSL<\/a> so we have to fallback to Map<String, Object><\/code> one more time in order to construct the search criteria.<\/p>\n
final Map<String, Object> authors = new LinkedHashMap<>();\nauthors.put(\"type\", \"authors\");\nauthors.put(\"query\", \n    singletonMap(\"term\",\n        singletonMap(\"last_name\", \"Gormley\")\n    )\n);\n\t\t\nfinal Map<String, Object> categories = new LinkedHashMap<>();\ncategories.put(\"path\", \"categories\");\ncategories.put(\"query\",\n    singletonMap(\"match\", \n        singletonMap(\"categories.name\", \"search\")\n    )\n);\n\t\t\nfinal Map<String, Object> query = new LinkedHashMap<>();\nquery.put(\"size\", 10);\nquery.put(\"_source\", new String[] { \"title\", \"publisher\" });\nquery.put(\"query\", \n    singletonMap(\"bool\",\n        singletonMap(\"must\", new Map[] {\n            singletonMap(\"range\",\n                singletonMap(\"rating\", \n                    singletonMap(\"gte\", 4)\n                )\n            ),\n            singletonMap(\"has_child\", authors),\n            singletonMap(\"nested\", categories)\n        })\n    )\n);\n<\/pre>\n
The price to pay by tackling the problem openly is a lot of cumbersome and error-prone code to write. In this regard, the consistency and conciseness of Java client API<\/a> really makes a huge difference. You may argue that in reality one may rely on much simpler and safer techniques, like data transfer object<\/a>, value objects<\/a>, or even to have JSON<\/a> search query templates with placeholders, but the point is a little help is offered by Java REST client<\/a> at the moment.<\/p>\n
final HttpEntity payload = new NStringEntity(JSONObject.toJSONString(query), \n    ContentType.APPLICATION_JSON);\n\nfinal Response response = client\n    .performRequest(HttpPost.METHOD_NAME, \"catalog\/books\/_search\", \n        emptyMap(), payload);\n\nfinal Object json = defaultConfiguration()\n    .jsonProvider()\n    .parse(EntityUtils.toString(response.getEntity()));\n\nassertThat(json, hasJsonPath(\"$.hits.hits[0]._source.title\", \n    containsString(\"Elasticsearch: The Definitive Guide.\")));\n<\/pre>\n
Not much to add here, just consult the Search API<\/a> documentation on the format and extract the details of your interest from the response, like we do by asserting on the title property<\/code> of the document _source<\/code>.<\/p>\n
With that, we are wrapping up our discussion about Java REST client<\/a>. Frankly speaking, you may find it unclear if there are any benefits of using it versus choosing one of the generic HTTP<\/a> clients Java ecosystem is rich of. Indeed, this is a valid concern but please keep in mind that Java REST client<\/a> is brand new addition to Elasticsearch<\/a> family and, hopefully, we are going to see a lot of exciting features pumped into it very soon.
\n[ulp id=’lFK4fMZhpULqeQUl’]
\n <\/p>\n
<\/a>4. Using Testing Kit<\/h2>\n
As our applications become more complex and distributed, the proper testing becomes as important as never before. For years Elasticsearch<\/a> provides the superior test harness<\/a> in order to simplify the testing of the applications which heavily rely on its search and analytics features. More specifically, there are two types of tests which you may need in your projects:<\/p>\n