Oliver Trosien

The AllArgsConstructor is not as useful in xtend as in java, I agree (because we have the with-initilizer => [] ) the lombok versions feature the possibility to be used...

Inside the UI. The docs mention filtering ( https://kubernetes-operational-view.readthedocs.io/en/latest/user-guide.html#filtering-pods ) , either make it part of the query string, but then one would have to come up with a syntax...

I would prefer leaving the query syntax for label selection, and a drop-down for the namespace selection.

I would also like to see something in that direction. I implemented a proof-of-concept that I can use spring-statemachine alongside with jpa and spring-data-rest here (https://github.com/otrosien/spring-statemachine-jpa), but a lack of...

Just to be on the same page: I'm not talking about predicting the future state of the machine. To simplify things, it does not even necessarily have to take guards...

Implemented as you suggested for a simple (non-nested) state machine here: https://github.com/otrosien/spring-statemachine-jpa/blob/master/src/main/java/com/example/ContextObjectResourceProcessor.java

JDK17 finally removed the possibility to allow illegal access to private fields.

I'm totally in favour of using Reactor types instead of native gRPC types. But, I would question that this is the responsibility of a spring-boot-starter.

As @sdeleuze said, make it a separate artifact then, and don't mix it with the spring-boot-starter.

First disclaimer: we haven't tested the es-operator with xpack security, so we're probably not adding the necessary credentials to the API calls. Despite that the problem you're facing is unrelated...