spring-data-rest: RepositoryRestMvcConfiguration can no longer be subclassed

Despite the class documentation states that “To customize how the exporter works, subclass this and override…”, that that is no longer possible. The restHandlerMapping() method returns a DelegatingHandlerMapping which has been made package private in commit d7f36b118060157e208aa044eb5c1c038b2c1dc2 related to DATAREST-1540. When subclassing RepositoryRestMvcConfiguration for customisation, I now get the following exception:

Caused by: java.lang.IllegalAccessError: failed to access class org.springframework.data.rest.webmvc.config.DelegatingHandlerMapping from class au.com.onyxtech.horus.config.RepositoryRestConfig$ExtendedRepositoryRestMvcConfiguration$$EnhancerBySpringCGLIB$$186fd9d8 (org.springframework.data.rest.webmvc.config.DelegatingHandlerMapping and au.com.onyxtech.horus.config.RepositoryRestConfig$ExtendedRepositoryRestMvcConfiguration$$EnhancerBySpringCGLIB$$186fd9d8 are in unnamed module of loader 'app')
	at au.com.onyxtech.horus.config.RepositoryRestConfig$ExtendedRepositoryRestMvcConfiguration$$EnhancerBySpringCGLIB$$186fd9d8.restHandlerMapping(<generated>)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:566)
	at org.springframework.beans.factory.support.SimpleInstantiationStrategy.instantiate(SimpleInstantiationStrategy.java:154)
	... 89 common frames omitted

About this issue

  • Original URL
  • State: closed
  • Created 3 years ago
  • Reactions: 8
  • Comments: 20 (6 by maintainers)

Most upvoted comments

I managed to workaround this by using a BeanPostProcessor to replace the beans I wanted to override, instead of subclassing RepositoryRestMvcConfiguration

3 might just have been solved with this ticket as RIF actually uses Repositories to look up the repository to invoke eventually.

Yes it is. Confirmed using 2021.1.0-SNAPSHOT

We need to customize:

  1. The linkCollector because the default link format doesn’t work for us

I have raised #2042 for this point

We need to customize:

  1. The auditableBeanWrapperFactory

I have raised #2040 for this point

3 might just have been solved with this ticket as RIF actually uses Repositories to look up the repository to invoke eventually.

I get a 404 on the ticket’s link, this one works.

We need to customize:

  1. The auditableBeanWrapperFactory
  2. The linkCollector because the default link format doesn’t work for us
  3. The repositoryInvokerFactory because the default one is unaware of entities managed by a polymorphic repository
  4. The persistentEntityJackson2Module

None of these components were intended for customization, which is one of the reasons we moved away from the broad exposure of RRMC. Would you folks mind creating tickets for the individual customization requirements, or maybe find already existing ones for us to prioritize? Depending on what those needs look like, there might be a different way to achieve what you want already, or we can introduce better, less low-level means for that.

3 might just have been solved with this ticket as RIF actually uses Repositories to look up the repository to invoke eventually.