Motivation In Spring Data Elasticsearch recently a issue was raised to include to possibility to use Elasticsearch SQL . While it is easy with Spring Data Elasticsearch 5.1 to use this directly from within an application, the integration into Spring Data Elasticsearch is more complicated, as the returned values (column definitions and rows) cannot easily and automatically be mapped on to the entities that Spring Data works with, and the response might not only contain column definition, row values, but cursor information as well.

Motivation In the Spring Data Elasticsearch issue tracker recently someone asked if it is possible to access two different Elasticsearch clusters in an application that is using Spring Data Elasticsearch. The reason they needed this weas because that application should do some migration - I assume that data from one cluster should be transferred to a second cluster. In this blog post I will show how this can be set up.

Why? When developing and testing code for Spring Data Elasticsearch I often use the OWASP ZAP proxy to monitor the data that is sent to and returned from Elasticsearch. I now had the situation that I needed to check how the library behaves when the server returns a code 429 (too many requests) status. Rather than trying to set up a test that tries to flood my local Elasticsearch instance, I decided to add a script to ZAP that automatically for a given percentage of requests returns that status.

The Problem It recently came to my mind that it might be handy to have a list of all the accounts that I follow on Mastodon. I can surely see them on the web or in any decent client, but as a backup it would be great to have a list to store somewhere. As I already played a little with the Mastodon API I decided to write a short script that downloads a list of user@instance values.

Note to self: In order to see which commands (latest on top) were used to create a docker image run: docker history --no-trunc --format 'RUN {{.CreatedBy}}' <image>

Yesterday and today I migrated my web site / blog from Wordpress to Hugo . It was less effort and pain than I had anticipated. It was done with these steps: Install Hugo (I am running on macOS using macPorts, so: sudo port install hugo) In my wordpress installation, I aded the “Wordpress to Jekyll Exporter” plugin and exported the blog posts to a local zip file. After unzipping this file I ran hugo import jekyll jekyll-export hugo-sothawo to create the initial Hugo setup for my site Added this as git repository to a git repository hosted at my web hoster Cloned the Mainroad theme from GitHub and pushed my clone to a private git repo as well, as I have some adjustments to the theme.

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.

A Throwable in Java can have a cause which in turn is a Throwable as well. This cause can have a cause and we can have a chain of Throwableobjects which we can follow until a Throwable has no cause. Let me explain this with a small example: 1class Scratch { 2 public static void main(String[] args) { 3 try { 4 try { 5 int division = divide(4, 0); 6 } catch (Exception e) { 7 throw new IllegalArgumentException("got exception calling divide", e); 8 } 9 } catch (Throwable t) { 10 while (t !

Just playing with https://artillery.io/ . If you need to see which requests are sent during setting up your test script, set the DEBUG environment variable: DEBUG=http:request,http:response,http:full_body $(npm bin)/artillery run test.yml