Migrate to Spring Boot
Solution approach: Prepare the codebase such that the delta between what Steve does and Spring Boot as default provides is minimal. Afterwards, the actual change should be as non-event as possible.
What about the data layer? Move to Spring data or keep jooq?
i don't aim to rewrite controller, service or repository layers. the goal is to use spring boot's easy bootstrapping instead of hand-wiring. plus, jooq has enough/good spring boot interop.
@andortoth As you already did the job once, do you have any advice or feedback that can help?
@goekay Could you review this commit and let me know what should be backported? From what I understand, the main challenge in migrating to Spring Boot is the startup process involving configuration.
this is such a heavy commit. need to do it later (since it needs attention/time).
main challenge in migrating to Spring Boot is the startup process involving configuration.
yeah, but most of the config is coming from spring beans and @Configurations already. this does not change when we have spring boot. the main challenge should be the following.
currently, whenever steve starts (Application's main method), it starts a plain Jetty server(!). within that we start and configure spring (in SteveAppContext). so, spring's context is only living in a small world.
spring likes to be the mothership though. it should be the first thing to start, and everything else should live within that. so we have to change
- Application -> Jetty -> Spring
to
- Application -> Spring -> Jetty (implicitly, by spring boot)
as a scratchpad, i managed to migrate steve to spring boot in a really dirty testing-the-waters way, and then threw it away. spring boot owned everything, jetty was there, DB via jooq as well. app was starting successfully.
so, as i said, as long as we don't touch the layers and change business logic (this heavy commit also does other things), this should not be that hard.
to reduce complexity and keep the scope focused, i dont aim to touch the enum class SteveConfiguration and change it to a spring bean. not yet. not within this one.
@andortoth As you already did the job once, do you have any advice or feedback that can help?
our version was a major overhaul, because of some business requirements that might not suit the Steve library and its design philosophy, so we decided not to make a pull request of it
the biggest differences are that we needed to replace JOGL with JPA because we needed to use the library with Azure SQL, and we had to be able to support a multi instance environment in a Kubernetes cluster so I don't really recommend to use our solution unless you have the same requirements (that is database platform independence or multi-instance support), because merging Steve fixes is quite a bit of fun with this amount of changes
if I remember correctly migrating to Spring Boot was not such a big deal, basically it was adding a @SpringBootApplication class, and rewriting SteveConfiguration to access application.proeprties
@goekay
⚠️ “If possible, JSPs should be avoided. There are several known limitations when using them with embedded servlet containers.”
📄 Source: Spring Boot Reference Documentation – JSP limitations
Some other moves to consider:
- Replace Jetty with Tomcat (Spring Boot’s default embedded container)
- Replace JSP with Thymeleaf (Spring Boot’s default template engine)
@goekay Fyi, I replaced JSP by Thymeleaf here: https://github.com/juherr/evolve/pull/5 Feel free to cherry pick the changes if you like it.
... i dont aim to touch the enum class SteveConfiguration and change it to a spring bean. not yet. not within this one.
contrary to what i said earlier, i did it within the corresponding PR and with commit https://github.com/steve-community/steve/pull/1822/commits/ddf7e3a178c95b98924e940a8f6ca6fa02aba400. after moving some properties into spring boot native properties, whatever was left was so little such that the effort was little.