Allow users to provide custom UriToEntityConverter

[ptahchiev]

• [x] You have read the Spring Data contribution guidelines.
• [x] You use the code formatters provided here and have them applied to your changes. Don’t submit any formatting related changes.
• [-] You submit test cases (unit or integration tests) that back your changes.
• [-] You added yourself as author in the headers of the classes you touched. Amend the date range in the Apache license header if needed. For new types, add the license header (copy from another file and set the current year only).

[mp911de]

Care to elaborate what type of customization you're looking for the UriToEntityConverter as you want to use your own instance. I generally wonder whether it would make sense to define UriToEntityConverter as bean and look it up from there. Thoughts, @odrotbohm?

[ptahchiev]

In my company we are extending hibernate and spring-data jpa so that we can build JPA entities as interfaces so that we can extend from multiple other interfaces. Thus a JPA entity looks something like this:

@Entity(CustomerEntityDefinition.NAME)
public interface CustomerEnttyDefinition extends AbstractNameable, AbstractDescriptionable, AbstractPicturable {
      String NAME = "user";
}

and the corresponding repository looks like this:

@Repository(value = CustomerRepository.NAME)
@RepositoryRestResource(itemResourceRel = CustomerEntityDefinition.NAME, path = CustomerEntityDefinition.NAME)
public interface CustomerRepository extends AbstractRepository<CustomerEntityDefinition, Long> {
    String NAME = "customerRepository";
}

We need a custom UriToEntityConverter because the one provided by spring-data works with PersistenEntities and ours work with Repositories. This issue is closely related to: https://github.com/spring-projects/spring-data-rest/issues/2276

As a general rule I view spring and the whole ecosystem as a framework that users should be allowed to extend and plug-into, not like a library that one is supposed to just use and not touch at all. It would be a nice idea if it a bean with a @ConditionalOnMissingBean annotation or some other way to allow users to change it if they need to.

[odrotbohm]

I think we have to take a step back from suggesting changes to the implementation immediately and get on the same page what the problem is that we need to solve. I see a couple of fundamental issues with the suggested changes (as well for #2279).

1. Repositories and PersistentEntities are entirely different concepts that are hardly related to each other. The former represents all repositories and allows accessing metadata about the aggregate types that are handled by those. The latter represents all entities known to the system. That's why we cannot simply exchange one for the other in classes that refer to PersistentEntities as they are likely to expect to see all types.
2. Converter implementations becoming beans can significantly affect fundamental Framework functionality. Especially if the converters make quite strong assumptions about the source values, such as, in case of UriToEntityConverter, the URIs handled. The converter is not a general purpose one to convert from URI to identifier types (e.g. Long). That's why we also do not register them in the global ConversionService but rather create our own one, so that we can control which Converters are registered and in which context that particularly configured instance gets used. Registering UTEC as a bean would make it get applied globally in a Spring Boot context, which is likely to create havoc.
3. We moved off RepositoryRestMvcConfiguration as primary vehicle for extension years ago.

I would like to start with a outside-in sample project that shows what's intended to work from a user application perspective to showcase what exactly is not working as expected. We can then debate how to best approach the problem.