Upgraded Steve implementation to Standerd 2.7 SpringBoot application

[nikhilkandari77]

Hi , I have successfully upgraded the current Steve implementation of ocpp 1.6j to SpringBoot 2.7 . And with Standerd SpringBoot auto configuration there is no need of jetty server and now we can easily move to Microservices architecture without any manual configuration. I know the letest version of SpringBoot is 3... With is built on jakarta servlet api .we have to wait for transition from Javax to jakarta.

[juherr]

What is the problem with jetty? You can use it with spring boot too.

You are not the first to make the move to spring boot (see https://github.com/parklapp/steve-pluggable) but would you like to make a pull request with the changes?

[nikhilkandari77]

Hi, there’s no issue with the Jetty server—we can indeed use any server based on our requirements. I’m currently working on the migration, and I’ll make a pull request once it’s ready.

[goekay]

congrats.

couple of remarks:

• the fact that you are using spring boot does not mean there is no server. steve uses jetty explicitly (i.e. manual impl), whereas spring boot uses tomcat by default implicitly. there is still a java server that serves http requests.
• steve can be treated like a microservice as is. migrating to spring boot does not mean you enabled "microservices architecture".
• i migrated steve to the latest spring major version 6.x with migrate to jakarta and upgrade spring, jetty, cxf #1519. spring 6.x made the transition from javax to jakarta. so, you can move to spring boot 3.x as well.

benefits of making steve a spring boot app is twofold:

• mindshare/momentum of online community: most tutorials and documentation target spring boot rather than plain spring. therefore, adding/chaning things might get easier.
• less manual impl: as you implied with "without any manual configuration", some classes which steve implements can be dropped since spring boot comes with these things.

[nikhilkandari77]

Hi, we are working with a microservices architecture and encountered several challenges in setting up a Eureka client with the current Steve implementation. Despite configuring it, we’re still facing some issues. That’s why I decided to migrate the existing Steve implementation to Spring Boot.

We also noticed that documentation and resources are much more readily available for Spring Boot compared to traditional Spring applications. Setting up microservices with Spring Boot is quicker and more straightforward, allowing us to focus on solutions rather than configuration. I believe we can create a parallel Steve implementation with Spring Boot, which will help us evaluate the best option moving forward.

[goekay]

Despite configuring it, we’re still facing some issues.

can you tell what these are/were?

[nikhilkandari77]

While registering the client with the Eureka server, it attempts to connect over localhost instead of the specified IP address, despite being configured to use the IP. Additionally, after registration, other clients are sometimes unable to locate or create an instance of the Steve client service, even though it appears as registered on the server.