Automate JAX-RS root resource registration

[flangknecht]

Currently JAX-RS resources have to be manually enumerated in a ResourceConfig bean when using Jersey like in the following sample from Spring Boot Jersey Samples.

@Component
public class JerseyConfig extends ResourceConfig {

	public JerseyConfig() {
		register(Endpoint.class);
		register(ReverseEndpoint.class);
	}
}

I've found this to almost always be the only kind of setup done in those beans and therefore think that this is something that can be automated using Spring Boot's autoconfiguration approach.

The JAX-RS 2.1 spec, section 2.3.2 mentions that, when running in a Servlet environment, and

• "no Application subclass is present, JAX-RS implementations are REQUIRED to dynamically
  add a servlet [...] and to automatically discover all root resource classes and providers"
• "an Application subclass is present" and "both Application.getClasses and Application.getSingletons return an empty collection" then "all root resource classes and
  providers packaged in the web application MUST be included and the JAX-RS implementation REQUIRED to discover them automatically by scanning a .war file as described above"

Since (the last time I checked) Jersey's JAR - scanning doesn't seem to bode well with Spring Boot - repackaged JARs I think this behavior should be upheld by Spring means.

This would help deliver more of the "it just works" - feeling one has come used to associate with Spring Boot.

I propose to automatically provide a ResourceConfig similar to what's proposed in #11948.
Additionally any JAX-RS root resource classes and providers that are managed by Spring should automatically be registered in the absence of another ResourceConfig bean.

Did I miss anything and this sort of behavior is already possible using the tools we have today?

If not: Is this something you'd be interested in including in Spring Boot?
If anyone's interested I'd be willing to draw something up.

[wilkinsona]

While the JAX-RS spec refers to a Servlet environment, it isn't precisely defined. For example, one of the other requirements when running in a Servlet environment is that "the application MUST be packaged with a web.xml". Spring Boot has no such requirement (with or without Jersey). I say this only as a reason for not trying to adhere to the JAX-RS spec's requirements for a Servlet environment. It's not a reason to do nothing here.

Additionally any JAX-RS root resource classes and providers that are managed by Spring

I'm not sure that we'd want JAX-RS root resource classes to be managed by Spring. JAX-RS supports injection of types that I don't think we'd want the application context to know about.

I wonder if it would be better to scan for root resource classes separately and map those to ResourceConfig.register(Class) calls? A problem with may be that the scanning would be quite expensive as "resource classes are POJOs that have at least one method annotated with @path or a request method designator". That means that we'd have to scan every method of every class looking for @Path or a request method designator. We could limit to scanning to particular base packages to mitigate this.

Did I miss anything and this sort of behavior is already possible using the tools we have today?

You haven't missed anything.

If not: Is this something you'd be interested in including in Spring Boot?
If anyone's interested I'd be willing to draw something up.

I think we're interested, although the level of interest depends quite a lot on what form the proposed scanning would take. If you'd like to make a proposal (no need for code or an implementation at this stage) then we can take things from there. Thanks.

[wilkinsona]

If we do this, and have an auto-configured ResourceConfig (with which JAX-RS resources automatically registered), we should consider setting the jersey.config.server.response.setStatusOverSendError property with a value of true (see #12995).

[spring-projects-issues]

If you would like us to look at this issue, please provide the requested information. If the information is not provided within the next 7 days this issue will be closed.

[spring-projects-issues]

Closing due to lack of requested feedback. If you would like us to look at this issue, please provide the requested information and we will re-open the issue.