With Spring 6 having RFC 7808 support, will this library be continued?

[joshiste]

I don't know wether this is the right place to ask this (so sorry if it's not):

What is your take on Spring 6 wich has support for RFC 7808?

Will there be support for Spring 6 (and will you integrate with this support or co-exist)? Or will this library be discontinued?

[PascalSchumacher]

Is this libary still "alive" or is the situation similar to https://github.com/zalando/logbook/discussions/1379 ?

By the way: Thank you very much for providing it for all these years!

[whiskeysierra]

Similar response here, yes. I no longer have the necessary privileges to create new releases of this library.

Additionally I'd argue in favor of discontinuing this project in favor of Spring's official support for RFC 7807. (I agree with @eugenp on this one: https://www.baeldung.com/spring-boot-3-spring-6-new#smaller-changes-in-spring-web-mvc)

[PascalSchumacher]

@whiskeysierra Thank you very much for the quick response! 😃

Sadly it seems that Springs official problem+json support is really basic compared to problem-spring-web. E.g. for a bean validation violation it does not give any hint what was wrong (at least when using spring-webflux):

{
    "type": "about:blank",
    "title": "Bad Request",
    "status": 400,
    "detail": "Invalid request content.",
    "instance": "/URL"
} 

[whiskeysierra]

The way I see it, this library used to do the following things:

1. Provide infrastructure to generate Problem JSON responses
2. Default behavior for some Spring-specific exceptions
3. Default behavior for some general purpose Java exceptions (e.g. UnsupportedOperationException)
4. Default behavior for some 3rd-party exceptions (e.g. ConstraintViolationException)

Now that Spring comes with its own support for Problem JSON, I'd argue to abandon 1. and 2. in favor of Spring's standard. The remaining 3. and 4. might still be useful enough to warrant a library (not sure), but in case there is a desire, then they should be written on top of Spring's ProblemDetail.

[MALPI]

Thanks for you suggestion @whiskeysierra. Makes sense. Unfortunately this is not how it got implemented with the pending PR but I think we can rework that.

I was in general wondering if you still want to actively contribute to the projects @whiskeysierra?

[HJK181]

Hi @MALPI any appraisal if you are going to proceed with the library? As far as I could see it still provides lots of value as the Spring build-in problem handling is limited to spring-web. I couldn't find problem handling for security, constraint violation, and some other stuff this library handles. We are migrating to Spring Boot 3 and I'd like to know if I should wait for this library to be compatible with Spring Boot 3 or copy missing stuff from the library to our projects to finish the migration?!

[whiskeysierra]

I was in general wondering if you still want to actively contribute to the projects @whiskeysierra?

Want yes, but probably won't have time realistically.

[MALPI]

hey @HJK181, yes we are going to proceed with it. We are forming a working group right now in order to onboard more maintainers to it.

[danielrohe]

Over the next weeks we will analyze the similarities and differences between the handling of exceptions of this library and spring's problem-web. We will use this issue to create a PR with which we first remove default behavior for Spring-specific exceptions and then with a second PR build on top of Spring's infrastructure.

[bocytko]

@danielrohe @MALPI can you update us on the plans? There were some PRs merged that went into the direction of supporting Spring 6, but there is no formal release of the library.

[MALPI]

So, we just released 0.28.0 which supports spring 6. We will see how in particular the library is going to evolve in future.