Do you own a dev service? Here’s what to do about the new dev services model. (TLDR, nothing … for now)
Holly Cummins
Hi all,
One side effect of the big test classloading rewrite is that augmentation for all tests is front-loaded at the beginning of the test run. Dev services start during the augmentation phase, which means that all the dev services for a test run start at the beginning. This isn’t noticeable when there’s only a single profile in a project, but when there are multiple profiles or test resources, it starts to become messy. Starting all the dev services at once can trigger port conflicts and startup failures. Even in the best case, it causes excessive resource usage.
Our plan for the problem was to delivery the classloading rewrite, and then move on to fixing the dev services lifecycle, so that dev services no longer start during augmentation. Ozan Günalp and I have been working on this as part of working group #49, and we’ve defined a new dev services model. In the new model, dev services are specified during augmentation, but the actual starting of the process happens during a post-augmentation pre-startup phase. As well as working better with test classloading, we’re hopeful that the new dev services model makes it easier to write dev services, and centralises common concerns like checking if a compatible dev service is already running. It should make it easier to specify and reason about the re-use semantics for a service.
A first version of the new API was included in 3.25, and we’ve done a first increment of migration. The Redis, Kafka, and Lambda dev services are converted. As part of the new model, we’ve marked the old `RunningDevService` API as deprecated. A few of you have spotted the deprecation and, very sensibly, started to convert to the new model. But then you discovered that it was really hard, because there was no documentation! Sorry about that. :)
So why is there no documentaion? I’m drafting a blog explaining how to convert dev services to the new model, but I haven’t shared it yet, because I’m not sure the new API is finalised. I didn’t want to spend lots of time writing docs and then have to spend more time re-writing them, and I definitely didn’t want dev service owners to spend lots of time converting their services and then have to do further changes.
Each service that we’ve converted has exposed extra requirements that the new API has to handle. If I’m honest, I’m also finding the new API is still a bit verbose and a confusing in places, and that’s the exact opposite of what it’s supposed to be! So I’m hoping we can figure out some further simplifications and maybe tweak some method names to improve clarity.
To summarise:
- Dev services using the old model will continue to work for a long time. Even in Quarkus core, most of the Quarkus dev services are still using the old model.
- The new API is available for use, but it’s experimental and might change a bit more
- Unless your extension is being hit by “all dev services start in augmentation,” wait few releases before converting to the new model
- If your extension doesn’t have a dev service, you don’t need to worry about any of this (but you should add a dev service if it makes sense for your extension)