I am using Elasticsearch v7.10, and in the javadoc, is the following interface
org.elasticsearch.client.Client
but not the following two classes:
org.elasticsearch.client.RestClient
org.elasticsearch.client.RestHighLevelClient
I am not looking for descriptions of what these classes do, but only want to know whether or not RestClient and RestHighLevelClient have been deprecated in v7.10 (current version)?
Thanks
For people also searching for this, please be aware that at the time of writing the RestHighLevelClient seems to be deprecated. From the documentation this class became deprecated in favor of the Elasticsearch Java API Client
Related
Currently we are on spring-data-elasticsearch 3.2.6 + elasticsearch 6.8.
We are moving to new elasticsearch 7.x. Do I have to update spring-data-elasticsearch to 4.x? We only use ElasticsearchRepository in spring-data-elasticsearch. And we don't need to use any new feature in elasticsearch 7.x.
If we are moving to elasticsearch 8.x in the future, do I need update spring-data-elasticsearch ?
Update:
What Elasticsearch client does Spring-Data-Elasticsearch use under the hood?
All methods in the `ElasticsearchRepository` are deprecated. What should do I use?
I found some discussions in above threads. Here is my summary.
Operations with Templates:
ElasticsearchTemplate implements ElasticSearchOperation. It uses TransportClient(which is deprecated in ES 7 and has been removed in ES8)
ElasticsearchRestTemplate implements ElasticSearchOperation. It uses high level client(which is deprecated in ES 7.16.0. It will be removed in future. #Deprecated(since = "7.16.0", forRemoval = true) )
ReactiveElasticsearchTemplate implements ReactiveElasticsearchOperations. It uses Reactive Client.
Repository
ElasticsearchRepository uses TransportClient as default. All methods in the ElasticsearchRepository are deprecated now.
Reactive Elasticsearch repository builds on ReactiveElasticsearchOperations.
Due to underlying TransportClient or HigLevelRestClient has been deprecated, can I conclude that the correct way is to use Reactive Client(ReactiveElasticsearchTemplate or Reactive Elasticsearch repository) ?
The new Elasticsearch would be 8.
Val already put the link to the compatibility matrix in his comment.
Version 3.2.6 is pretty outdated (March 25 2020) and out of support since October 2020.
The first thing you can try is to see if your application works with a 7 cluster - although I doubt that, I can't tell you exactly what had changed in the API, but there was quite some stuff.
What you should not do is putting newer Elasticsearch libraries on the classpath than the ones that Spring Data Elasticsearch was built with, this will in most cases make problems.
But I'd recommend to upgrade your application anyway and keep it regularly up to date.
As for future upgrade to version 8: It is possible to send a compatibility header in your requests (this can be done in Spring Data Elasticsearch 4) and the Elasticsearch cluster should respond in a format that is compatible with a client expecting version 7. I wrote should, because it does not conform to this in every case - I reported one case that is fixed now. But I wouldn't rely on that.
Again, please update your application and keep it up to date, not only because of Spring Data Elasticsearch, but also because these updates always include bug and/or security fixes.
I was reading https://www.elastic.co/blog/deprecating-rivers which stats that ES rivers (plugin) are getting deprecated. i.e. any plugin directly integrated with ElasticSearch server will no longer work beyond ES 3.x onwards.
Couchbase plugin is one of those kind.
I searched all the documents of couchbase plugin at http://developer.couchbase.com/documentation/server/4.5/connectors/elasticsearch-2.1/elastic-intro.html but could not find if they are using deprecated way or not?
Does anyone know? Should we keep using couchbase plugin or should start planning to write data directly to ES using our application.
We have couchbase data getting replicated to ES using couchbase plugin and XDCR.
I'm the maintainer of the Couchbase ES transport plugin. As Roi mention in his answer, the plugin doesn't use rivers, so it won't be deprecated. It currently supports any version of ES from 1.3 to 2.x, and I'm working on adding support for 5.x. It's taking a bit longer, because ES 5.x broke some configuration sharing features in unexpected ways.
I'd suggest always looking at our github repo for the latest plugin releases:
https://github.com/couchbaselabs/elasticsearch-transport-couchbase
The Couchbase plugin is not using Rivers, there is another River plugin which is not longer valid.
take a look here: https://github.com/couchbaselabs/elasticsearch-transport-couchbase
Where is this class "HttpContext" exist in glassfish jersey 2.9 . I was using jersey 1.17.1 to use HttpContext where it was exist in package com.sun.jersey.api.core.HttpContext.
But i did't find it in jersey 2.9.
The direct replacement for HttpContext is not available in Jersey 2.x versions and unfortunately, this breaking change detail hasn't been mentioned anywhere in the migration guide. Instead of searching for direct replacement, if we dig deeper into the interface HttpContext, based on the following method summary refer
we can infer that instead of using HttpContext, we can simply use the following out-of-the-box alternatives.
Instead of HttpContext#getRequest use #Context ContainerRequestContext crc
Instead of HttpContext#getResponse use #Context ContainerResponseContext crc
Instead of HttpContext#getUriInfo use #Context UriInfo uriInfo
Instead of HttpContext#getProperties use ContainerRequestContext#getProperty
Jersey 2.x had a lot of breaking changes, which partly caused by the fact that JAX-RS standard incorporated a lot of things in Jersey 1.x.
To quote https://jersey.java.net/documentation/latest/migration.html#mig-1.x
This chapter is a migration guide for people switching from Jersey 1.x. Since many of the Jersey 1.x features became part of JAX-RS 2.0 standard which caused changes in the package names, we decided it is a good time to do a more significant incompatible refactoring, which will allow us to introduce some more interesting new features in the future. As the result, there are many incompatibilities between Jersey 1.x and Jersey 2.0. This chapter summarizes how to migrate the concepts found in Jersey 1.x to Jersey/JAX-RS 2.0 concepts.
The migration chapter does not indicate what happened to HttpContext, but it no longer exists in its old form.
We used Nest.Dsl.Factory add-on to NEST library with earlier versions of NEST. Now that it's approaching version 1, it looks that Nest.Dsl.Factory is no longer supported. I wonder if NEST has now similar functionality built into the core package.
The DSL Factory DSL has indeed been dropped, after it was donated it became unmaintained.
See the release notes for 0.11.7.0
https://github.com/elasticsearch/elasticsearch-net/releases/tag/0.11.7.0
You should now switch to the fluent lambda syntax or use the new object initializer syntax.
Fluent syntax:
http://nest.azurewebsites.net/nest/core/search.html
http://nest.azurewebsites.net/nest/writing-queries.html
Example initializer syntax:
See this unit test
The object initializer syntax is something we are rolling out for all the API endpoints for the 1.0 release but is currently only available in our continuous builds on myget.org
https://www.myget.org/gallery/elasticsearch-net
I am very new to Spring JDBC and working on a given task, looking at the codes we already have my teammates have used RowMapper, but I was doing some Googling and saw some tutorials are using ParameterizedRowMapper , so I was wondering if there is any benefit or good practice in using one rather than the other one and your technical thoughts behind that...
thanks.
Right from the javadoc of ParameterizedRowMapper:
Extension of the RowMapper interface, adding type parameterization. As
of Spring 3.0, this is equivalent to using the RowMapper interface
directly.
Prior to Spring 3.0, most APIs did not use generics because Java 1.5 wasn't a requirement. As a result, there was a RowMapper, that didn't support generics and ParameterizedRowMapper that did support generics by extending RowMapper and adding the generic parameter. As of Spring 3.0, most APIs were updated to support generics. If you actually look at the current (3.0 or greater) definition of ParameterizedRowMapper, it just simply extends RowMapper and adds nothing to the definition to allow for backward compatibility. Therefore, you can pretty much use RowMapper either parameterized or not and no need to use ParameterizedRowMapper.