The way to move forward with Spring 6 / Spring Boot 3

[msdousti]

As part of a small group of volunteers who are currently maintaining Logbook, we had some discussions regarding how to support Spring 6 / Spring Boot 3.

Approaches:

We envisioned three approaches:

1. A radical move that drops support for Spring 5 / Spring Boot 2 in the main branch:
   Migrate to Spring 6 / Spring Boot 3 #1417
   (We plan to keep a protected branch for maintaining "occasional" support for Spring 5 / Spring Boot 2)

2. Keep support for Spring 5 / Spring Boot 2 and also add support for Spring 6 / Spring Boot 3, by copying and adapting Maven modules:
   [WIP] update to »SpringBoot 3« (w/ Spring Framework 6) #1375

3. Same as in 2, but without copying modules. An approach for Spring Boot is alluded to in this comment, which uses @ConditionalOnClass annotation. For non-Spring Boot modules, it should probably use the builder pattern for instantiating the right class. Since most of the changes are in terms of javax.* -> jakarta.*, one might also think of automatic code generation using something like Templating Maven Plugin Maven Shade Plugin.

Comparison:

• Approach 1 is the easiest to maintain. The PR itself is very small. If there's an immediate need to support previous Spring versions, we just commit to the protected branch. Two versions of Logbook, meaning 2.x and 3.x will have independent lifecycles.

  The bad thing about it is that most users use Spring 5 / Spring Boot 2 for the future to come. So, while it is easier to maintain on the surface, we may have a harder job of supporting the larger user base.

• Approach 2 is a , meaning we don't have to come up with clever tricks to make Logbook work for both setups. However, the PR is huge (~ 5000 lines of code added), as a lot of copy-paste happened. It's a code smell to have a huge part of code duplicated, and maintaining it is harder as any change might end up in two different places.

• Approach 3 requires several clever ideas, but if we pull it off, it will be the best of both worlds.

Next Steps

We have already the PRs for approach 1 & 2, but we want to give approach 3 a try.

We'd be happy to hear your feedback and especially any narrative from your experience. If I miss something or made any mistake in the comparison, please let me know. If there's another OSS library, whether in Zalando or outside, that has successfully made the decision, we'll be happy to hear about it.

/cc @whiskeysierra @agebhar1 @phejl @maciejwalkowiak @joshlong

[TiborVyletel]

Dear Logbook maintainers,
first of all thank you (and Zalando) for the library you donated to open source. A great help in several integration projects for me.

At the moment, I am also one of those who got stuck in spring-boot v3 upgrade because it is not possible to upgrade project's spring-boot stack without Logbook being part of the upgrade process. That's why I came across PR #1417 and this elaboration of the approaches to take. Any approach you decide to take, we'll have to way for it.

In this comment, I just want to share my view (2 cents) on this part of the support argumentation:

The bad thing about it is that most users use Spring 5 / Spring Boot 2 for the future to come. So, while it is easier to maintain on the surface, we may have a harder job of supporting the larger user base.

There is a 1 year support period for non-commercial users of spring-boot. Support calendar can be found here: https://spring.io/projects/spring-boot#support

With this support policy is it disputable how long the larger user base will actually be spring 5 / boot 2 related, IMO. I cannot judge what is the percentage of projects paying for commercial support. For projects not doing so, it is a necessity to upgrade, I would say.

Regards,
T.

[msdousti]

Thanks a lot for your interet in the library and the insight. We'll take all ideas into account, and hopefully provide the best decision for all users.

[maciejwalkowiak]

Thank you @msdousti for deep analysis and reaching out for opinions - true open source spirit!

On the high level it comes down to how much effort are you able to put into the maintenance and development of Logbook - maintaining support for both Spring Boot 2.7 and 3.0 will definitely cost more time for you and all contributors.

Spring Boot 2.7 will reach end of life on the 18 Nov 2023, which means that most projects should migrate to 3.0 over the next 9 months. Ones that will not will likely also not be looking for upgrading other dependencies (just an assumption).

Considering this, in my opinion, Approach 1. where support for Spring Boot 2.7 switches to maintenance mode (only bugfixes) and all the efforts go into main branch supporting Spring Boot 3.0 is reasonable.

Approach 2 is worth it with a positive ROI - Sentry Java follows it, I follow it with Just - but both of these are commercial tools.

Approach 3 - if I follow correctly what you have in mind, guarding with @ConditionalOnClass won't save you from copy & pasting code, except in autoconfiguration classes.

What may you save from copy & pasting in logbook-servlet module is Maven Shade Plugin that can generate an extra artifact with all references to javax.servlet changed to jakarta.servlet.

Something like this in logbook-servlet/pom.xml (although since you already use Shade plugin in the parent module, more tweaks will be necessary, but i hope you get the point):

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-shade-plugin</artifactId>
    <executions>
        <execution>
            <id>jakarta</id>
            <phase>package</phase>
            <goals>
                <goal>shade</goal>
            </goals>
            <configuration>
                <shadedArtifactAttached>true</shadedArtifactAttached>
                <shadedClassifierName>jakarta</shadedClassifierName>
                <createDependencyReducedPom>false</createDependencyReducedPom>
                <artifactSet>
                    <includes>
                        <include>${project.groupId}:${project.artifactId}</include>
                    </includes>
                </artifactSet>
                <relocations>
                    <relocation>
                        <pattern>javax.servlet</pattern>
                        <shadedPattern>jakarta.servlet</shadedPattern>
                    </relocation>
                    <relocation>
                        <pattern>org.zalando.logbook.servlet</pattern>
                        <shadedPattern>org.zalando.logbook.servlet.jakarta</shadedPattern>
                    </relocation>
                </relocations>
            </configuration>
        </execution>
    </executions>
</plugin>

in addition to logbook-servlet-2.15.0-SNAPSHOT.jar will produce logbook-servlet-2.15.0-SNAPSHOT-jakarta.jar.

With such in place, the autoconfigure module can use @ConditionalOnClass as @joshlong suggested. You would need 2 starters though, one that imports regular logbook-servlet for SB 2.7, and one that imports variant with classifier for SB 3.0.

I am not sure if my advice is 100% accurate because I only roughly looked at the codebase, but I hope it will help you to take better decision.

[msdousti]

Thanks for asking. I wasn't personally there due to some overlapping task, but the meeting summary includes the following: "Spring Boot 3 / Framework 6 work ongoing well."

[darrenskywalker]

@msdousti Do you know why this closed with no resolution? IE...no PR with an update or even opened yet(besides the ones that were also closed) to support Spring Boot 3?

[msdousti]

As I explained above, the team decided to go for option 3. The discussion is closed as we received enough feedback here.

[darrenskywalker]

As I explained above, the team decided to go for option 3. The discussion is closed as we received enough feedback here.

Yes I understand that. I was less concerned about being able to interpret the decision but more concerned about visibility with addressing the upgrade. Should there not be an open post or something in the README that describes that this upgrade is forthcoming especially in place of a non existent(yet) PR? (To answer a frequently asked question and to be informed etc..?)

[msdousti]

Probably it's best to be discussed here:
#1344