0

I'm working on a Spring Boot project for digital signature where I want to create some REST controllers using the classic Spring Web syntax (@RestController, @XMapping, etc.). Looking for some libraries to carry out the signature work I found this one, which includes working REST controllers made with the JAX-RS spec. So I thought that simply exposing them in my app would get the job done with the minimum possible code. Initially I thought about creating the controllers myself and delegate the work to the lib, but as soon as I found about these already existing controllers, I thought that I could even skip that and keep the code very small.

I managed to successfully do that by adding the org.springframework.boot:spring-boot-starter-jersey dependency and registering them in Jersey's ResourceConfig. But I think that this might be incompatible with org.springframework.boot:spring-boot-starter-web and/or org.springframework.boot:spring-boot-starter-data-rest because as soon as the JAX-RS API from the lib became callable, the endpoints that data-rest creates automatically from the @Repository classes disappeared.

I've been looking for a way to integrate these two things together in Spring Boot and I'm not sure if it is even possible, or a good idea all together. To be honest I wouldn't really mind coding my controllers with the JAX-RS spec, I've worked with it in the past and I like it as well. What I don't want to lose is the automatic creation of controllers for @Repository classes that spring-data-rest does, as I really like that feature.

Am I trying something really stupid, or is there any way to do this?

Jendoliver
  • 51
  • 6
  • Why would you want to make your life more difficult by attempting to use a JAX-RS compatible library to create REST controllers when Spring MVC (which integrates perfectly with Spring) can get the job done for you? – allkenang Jul 08 '21 at 08:31
  • What do you mean with "Spring MVC can get the job done for you"? Can I expose JAX-RS endpoints without using Jersey / a JAX-RS implementation, with just Spring MVC? If that's the case that would solve my problem for sure, but I don't know how to do that. What I would want is to avoid rewriting the same code that this library already has implemented in their REST controllers, the problem is that I don't know how to expose them from my app, and the only way I managed to do so is by adding Jersey into the mix, which I didn't like neither. I'm now trying to use `spring.jersey.application-path`... – Jendoliver Jul 08 '21 at 08:44
  • ... since I've read that by default Jersey is auto-configured as a servlet listening in `/*`. Changing this value made the Spring generated endpoints available again, so I think this may be the way. – Jendoliver Jul 08 '21 at 08:46

1 Answers1

2

You can use Jersey and Spring MVC at the same type, but you need to configure Jersey to allow you to do so.

First, Jersey should be configured to work as a filter rather than as a servlet. To do this, set spring.jersey.type to filter in your application.properties file.

Second, Jersey must be configured to forward requests that it can't handle itself. This allows the request to reach Spring MVC's DispatcherServlet from where it will be dispatched to your Spring MVC controllers, Spring Data REST endpoints, etc. To do this, set the FILTER_FORWARD_ON_404 property in your ResourceConfig:

@Component
public class JerseyConfig extends ResourceConfig {
    
    public JerseyConfig() {
        // Endpoint registrations
        property(ServletProperties.FILTER_FORWARD_ON_404, true);
    }

}
Andy Wilkinson
  • 108,729
  • 24
  • 257
  • 242
  • Thank you very much! While you were answering I solved it in a different way: by using a fixed `@ApplicationPath` in `JerseyConfig` and having all the library endpoints exposed under this path. I initially believed that there was some sort of incompatibility but the problem was Jersey listening at `/*` by default and thus hiding the endpoints created by Spring MVC. But I think your solution is cleaner and can work in more cases. Thanks again! – Jendoliver Jul 08 '21 at 09:07