The problem When starting an Elasticsearch instance in version 8 (the current version being 8.7.0) for the first time, the Elasticsearch server is by default automatically configured with a random generated password and a self signed certificate to secure the connection between clients and the Elasticsearch server.
The password and the fingerprint for the certificate are shown in the output of the server on the first start (output truncated for brevity):
The problem In Elasticsearch (the the current version at the time of writing this post is 7.12.1) every index holds exactly one type of data. This type is defined by the index mapping which describes the fields of the index and their types.
Spring Data Elasticsearch (the current version is 4.2) automatically maps between a Java class – the entity type – with its properties and the data in the Elasticsearch index.
The release of Spring Data Elasticsearch in version 4.0 (see the documentation) brings two new features that now enable users to use geo-distance sorts in repository queries: The first is a new class GeoDistanceOrder and the second is a new return type for repository methods SearchHit<T>. In this post I will show how easy it is to use these classes to answer questions like “Which pubs are the nearest to a given location?
After working on Spring Data Elasticsearch for nearly a year now, I’m proud that I will have a talk “Next Level Elasticsearch Integration with Spring Data Elasticsearch” at Spring I/O 2020 in Barcelona!
Edit: Spring I/O is postponed to October 2020 due to Covid-19.
Edit 2: Alas the conferebnce was cancelled.
Intro In this post I show how to combine some language / frameworks and libraries / tools to build a web-based scalable chat application. I chose the following combination of tools:
Kotlin as implementation language Vaadin for the web-based application Apache Kafka as the message backend Spring-Boot to get all together and running As I am bad in creating cool names for projects I just put together the first letters of the used tools and named this whole thing kovasbak.
When a Spring-Boot application is deployed on OpenShift, it can be reached both with a HTTP URL and a HTTPS URL. This is because OpenShift runs a proxy in front of the application which in case of HTTP just routes the request to the application. If a request comes in via HTTPS, the proxy does all the encryption handling with the client and then passes the decrypted request on to the application – on the HTTP channel – and encrypts the response before sending it to the client.
Note to self: When using Spring-Boot, use application.conf as a base configuration for the needed values. Configuration values for the specific profile go into the application-<profile>.config file.
Profiles are activated by using either the -Dspring.profiles.active=<profile> VM flag or --spring.profiles.active=<profile> commandline arg.
This post describes how to create and deploy a Spring-Boot application to RedHat OpenShift (version 2) when the application is using Java 8.
Edit 2015-10-04: In this newer post I show how to not install a custom JDK. So you should first read this post and then the linked one for additional information.
Normally deploying a Spring-Boot application on OpenShift is not too much pain and is explained in the Spring-Boot documentation.
This post describes how to build a REST service with Spring-Boot that uses Basic-Authentication for several users and that uses the username of the authenticated user to do it’s work. Warning: A service using basic authentication should always use HTTPS as transport protocol, either by running behind a web server proxy or by setting up HTTPS by itself. I’ll cover the latter in a later post.
This might be a setup for a service, where for each user, data is stored in a database, so it not only is necessary to authenticate the user to use the service, but it is also necessary in the service to know which user is accessing the service.
When writing a Spring-Boot application it is possible to use your own custom configuration classes which are injected by spring into your application and which are configured in the application.properties file. There is even support for autocomplete support in the properties file editor in IntelliJ IDEA (I suppose there is something similar in Eclipse or NetBeans, but I haven’t tried that). This post shows how to achieve this.
Basically this is used for auto configuration of Spring-Boot components, but can be used in the Spring-Boot application as well.