Note to self: In order to check out a pull request from either Codeberg or GitHub to the local machine, first get the number (ID) of the PR (look it up in the Web UI) and then create a branch and check it out (BRANCHNAME):

$ git fetch origin pull/$ID/head:$BRANCHNAME
$ git checkout $BRANCHNAME

Update 26.07.2026

Another solution which allows to fetch updated PRs:

Add the following to the .git/config file in the checked out repository (the last line is new):

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. In this article I name the one cluster the default cluster and the other the secondary cluster.

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. And as I am using Python only occasionally, I decided to do this script in Python.

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.
• Adjusted the theme and its settings until I had it to my liking.
• Went through my pages and posts to clean up links that had the full path to my site in them (they will when deployed with Hugo, but that should not be in the code). Adapted the code snippets to the highlighting that Hugo uses. This was some time consuming stupid work.
• Created the deployment of my site with hugo
• Uploaded the public directory to my Hoster into a new directory servde from a test subdomain.
• Checked that all works.
• Changed the DNS settings to point to the new site.

And here we go. No more PHP version updates, Wordpress or plugin security updates, database and file backups.

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. This means that when searching, the entity type must be specified. In Spring Data Repositories this is the type specified in the repository definition, when using the ElasticsearchOperations interface, the search function required a parameter specifying the class to return.

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 != null) {
11        System.out.println(t.getClass().getCanonicalName());
12        t = t.getCause();
13      }
14    }
15  }
16
17  private static int divide(int divident, int divisor) {
18    return divident / divisor;
19  }
20}

In this example we call a function to divide two numbers and pass in a divisor with value 0. This of course leads to an ArithmeticException which we catch and set as the cause for a new IllegalArgumentException. We then catch this new exception and print out the cause-chain . Running this program gives the expected result: