Support for Spring without Spring Boot

[pvdbosch]

Lots of refactoring to enable support for Spring without Spring Boot dependencies.

• remove scanning (ComponentScan), use explicit @Configuration (application contexts) instead
• module structure changes:
  • a "-spring" module that can be used without SB. Only the parts that are needed can be imported
    • it includes support for both Jackson2 and Jackson3 alongside each other; allowing to delete the "-core" modules
  • added "-starter" to the name of the modules with autoconfiguration active, these have SB dependencies (except the "-spring-boot-3" one for backwards compatibility)
• renamed packages to add ".server" and ".client" where applicable
• avoid exposing abstract classes to Spring users:
  • add WebClientFilter extracting PROBLEM_FILTER from AbstractProblemWebClientCustomizer
  • add an interface ProblemResponseErrorHandler
• add an annotation @EnableProblemModule(beanValidation=true, swaggerRequestValidation=false, ...) to enable easy activation in non SB-environment

Other:

• NoResourceFoundExceptionHandler merged into RoutingExceptionHandler (the split was bc NoResourceFoundException was new in SBv3)
• changed packages of spring integration tests to add ".it" to avoid interference of their own component scanning with the rest-problem packages
• for configuration, changed to @Value instead of @ConfigurationProperties to cut dependency to spring boot

TODO:

• review by others
• update documentation
• investigate issue: using EnableProblemModule intellij shows issues that beans aren't found, while tests doe work
• add integration tests for server/client usage w/o starters

[pvdbosch]

@jpraet , could you review if the changes in the PR look good to you high-level?

I've tested it locally in a Spring (non-Boot) project using the @EnableProblemModule annotation.
If OK, we'll continue work on the remaining TODOs after which a more detailed review can be done.

[jpraet]

@jpraet , could you review if the changes in the PR look good to you high-level?

Looks good to me high-level. Thank you

[pvdbosch]

The PR is now ready for review.

I made following changes, on top of the previous ones:

• added an integration test for spring-only.
  • It uses spring boot to provide an application server, but with minimal starters/autoconfiguration.
  • RestTemplate isn't tested because needs invasive test refactoring and it's is on its way out anyway in Spring 8
• updated documentation
• modified how the belgif-rest-problem-it-common-jakarta module is generated (transform source instead of jar) to make it easier to debug integration tests
• remove abstract classes for customizers in spring module, bc they're spring-boot-specific functionality and have very little code

[jpraet]

from version

belgif-rest-problem-spring-boot-4 was renamed to belgif-rest-problem-spring-boot-4-starter,
while belgif-rest-problem-spring-boot-3 remains.

I guess because the spring-boot-3 module has been around for longer so the user impact is higher.

But maybe we can still do the rename, while also keeping the belgif-rest-problem-spring-boot-3 around for a while as deprecated (it would be empty and depend on belgif-rest-problem-spring-boot-3-starter).

[pvdbosch]

Yes, or we could set a relocation pom for the old artifact. I'll test if that would work

[pvdbosch]

relocation pom works, I've add this in a new commit.
For maven builds this works as expected; recent Renovate versions suggests the rename as well.
Only dependabot might not detect the new version (see dependabot/dependabot-core#1947 )

[sonarqubecloud]

Quality Gate passed

Issues
28 New issues
0 Accepted issues

Measures
0 Security Hotspots
92.2% Coverage on New Code
2.0% Duplication on New Code

See analysis details on SonarQube Cloud