#292 Migrated to Spring Boot 3 using OpenRewrite

[jimbethancourt]

Please note:

• Galapagos is now on Java 17 and Spring Boot 3
• SecurityConfig has been commented out since Keycloak is deprecated and not supported in Spring Boot 3 / Spring 6. Unfortunately I don't know how to implement OAuth 2 at this time either.

I can't seem to figure out how to run it locally - I get a 401 error when I try to run it from my IDE with the demo,democonf,actuator profiles:

Could not access or read /service_accounts workaround endpoint: Server returned 401 for /service_accounts

OpenRewrite configuration used to perform migration:

<plugin>
	<groupId>org.openrewrite.maven</groupId>
	<artifactId>rewrite-maven-plugin</artifactId>
	<version>5.2.4</version>
	<configuration>
		<activeRecipes>
			<recipe>org.openrewrite.java.spring.boot3.UpgradeSpringBoot_3_0</recipe>
		</activeRecipes>
	</configuration>
	<dependencies>
		<dependency>
			<groupId>org.openrewrite.recipe</groupId>
			<artifactId>rewrite-spring</artifactId>
			<version>5.0.2</version>
		</dependency>
	</dependencies>
</plugin>

[jimbethancourt]

Creating a separate work branch since SecurityConfig needs to be re-implemented may be the best approach

[albrechtflo-hg]

Hi Jim, thanks for your contribution!

The KafkaFutureDecoupler had not only the purpose of converting the Future, but also to really decouple the Futures from the Core Kafka Thread. Without this, concatenated calls like myKafkaRepo.save(o).thenCompose(x -> doSomethingElseWithKafka()) lead to deadlocks. So I think we will have to keep it, unfortunately. (We can also test if it is really needed, or if the Threading is more clean now inside the Core library, but that was hard to reproduce when we had these issues...)

I will have a look in replacing the Keycloak lib in Spring Security. I already did that in another project, so that should not be much of an issue.

The service_accounts workaround endpoint from Confluent is, fortunately, no longer required (since few weeks now). You can set ccloud.serviceAccountIdCompatMode to false (in the cluster-specific config), which should avoid these calls.

[jimbethancourt]

Hi Florian,
It's my pleasure! I think I see what you mean about the KafkaFutureDecoupler. That was one of the few manual changes I needed to make and can probably be undone. I'm not sure offhand how to best approach it - there was enough of a change that it didn't compile correctly after I applied the OpenRewrite recipe.

I'm relieved to hear that you've done the migration off of Keycloak before.

Thanks for letting me know about the service_accounts workaround as well!

I'm not sure exactly how much help I can be going forward. Unfortunately I'm busy the next few weeks focusing on other things, but hopefully I can try out any changes you make.

Thanks,
Jim

[jimbethancourt]

@albrechtflo-hg I've reverted changes to KafkaSenderImpl and calling classes and added an overloaded method to KafkaFutureDecoupler
The only change that needs to happen now is to re-implement OAuth2 😃

[albrechtflo-hg]

OK, it was not as simple as expected to replace Keycloak; mainly because Galapagos uses roles configured in Keycloak clients for authorization, and because the UI used lots of stuff from the Keycloak lib.

There are now some new properties to configure the required realm names to use from the JWT, and a whole new OAuth2 configuration file, replacing the keycloak.json. Added is also a migration guide for Galapagos 2.8, which will contain this change.