I am currently building an application with a REST interface, using Spring Boot, Hibernate and Spring-HATEOAS. My data model is defined as beans with @Entity
annotation and I am using Spring's feature to automatically set up a Hibernate repository (Creating an interface extending PagingAndSortingRepository
). My application is completely annotation-driven, i.e., I have no web.xml
but configure everything with the Spring annotations like @Configuration
, @Bean
etc., and start the application from my main
method with the help of SpringApplication.run(MyApp.class, args);
This works fine, but with this approach, a RepositoryRestHandlerMapping
and EndpointHandlerMapping
is created. These create a bunch of resources I neither need nor want. I implement my own controllers because they need to do more than the standard logic.
How can I prevent this default behaviour and disable these mappings?
Exclude RepositoryRestMvcAutoConfiguration in your main class.
Kotlin
Exclude Specific resource: To exclude only a specific Repository use the code below in the specific interface, the mapping in the Controller will still work.
Entirely: To exclude entirely, use the Kotlin version of the previous answers in the main class:
use below dependency
instead of
I need the other REST functions, like
@RestController
annotation. But I found a feasible solution myself now:RepositoryRestHandlerMapping
should not be disabled, but it is possible to disable exporting of repositories by annotating them with@RepositoryRestResource(exported = false)
. I did this with all my repositories and now, the wildcard resources are still installed, but no repositories are registered to resolve against them, making them effectively disappear. Trying to access such a resource gives a404
as expected.Same for
EndpointHandlerMapping
, which comes fromspring-boot-actuator
and installs some endpoints like/info
,/metrics
etc. This is handy and should be present in a REST application; when I register my application with an Eureka server, it automatically generates links to some of these. To use this correctly, the endpoints can for example be configured via@Bean
, like this:The
info
above is constant info, if there were info which is subject to change, one could overrideInfoEndpoint
and supply a custom implementation ofgetAdditionalInfo()
.