Spring-boot: EndpointMBeanExportAutoConfiguration required a single bean, but 3 were found

[bitsofinfo]

My Application.java defines no such bean, but extends from RepositoryRestMvcConfiguration

This worked in w/ Spring 1.3.6 but when I upgraded to 1.4.0 I now get this

Constructor in org.springframework.boot.actuate.autoconfigure.EndpointMBeanExportAutoConfiguration required a single bean, but 3 were found:
        - objectMapper: defined by method 'objectMapper' in my.package.Application
        - halObjectMapper: defined by method 'halObjectMapper' in my.package.Application
        - _halObjectMapper: defined in null

https://jira.spring.io/browse/DATAREST-865

[ceefour]

Thanks @bitsofinfo , yes this is the exact issue as #6517 , which @snicoll marked as duplicate of #5984 (but I disagree, it's not a duplicate of #5984, but indeed related)

[snicoll]

@ceefour I asked you on #6517 to share a sample. If you disagree, please do that. And please do it on the issue you've created.

@bitsofinfo can you show your RepositoryRestMvcConfiguration extension? (a sample would be better).

I think @wilkinsona actually explained what the problem is on #5984 but maybe the effects are larger than we anticipated.

[bitsofinfo]

Just a class declared like this

public class Application extends RepositoryRestMvcConfiguration {
    ...

[lekant]

To me, seems a duplicate.
I had the same issue when upgrading to 1.4.0.
The work around described #5984 in worked for me

@Configuration
class MyMvcConfiguration extends RepositoryRestMvcConfiguration {

    @Override
    @Bean
    @Primary
    public ObjectMapper objectMapper() {
        return super.objectMapper();
    }

[bitsofinfo]

Either way, the documentation should be updated then that you have to do this workaround if you extend from RepositoryRestMvcConfiguration

[ceefour]

Note that manually extending RepositoryRestMvcConfiguration is not a requirement to trigger this bug. Compare @bitsofinfo's case with my case:

    - objectMapper: defined by method 'objectMapper' in class path resource [org/springframework/boot/autoconfigure/data/rest/SpringBootRepositoryRestMvcConfiguration.class]
    - halObjectMapper: defined by method 'halObjectMapper' in class path resource [org/springframework/boot/autoconfigure/data/rest/SpringBootRepositoryRestMvcConfiguration.class]
    - _halObjectMapper: defined in null

These are Spring Boot's own class.

[bitsofinfo]

I can confirm that this workaround "fixes" it but does not seem like something I want to pepper around my code anywhere i extend from RepositoryRestMvcConfiguration
https://github.com/spring-projects/spring-boot/issues/6529#issuecomment-237626677

[wilkinsona]

Strictly speaking, this isn't an exact duplicate of #5984, although it is very similar. Furthermore, it worked in 1.3 for the reasons already explained in #5984.

The difference here is that the problematic ObjectMapper isn't being declared directly in an application. Two ObjectMapper beans are declared in RepositoryRestMvcConfiguration which the application is subclassing. That subtle difference makes it harder to avoid the problem.

I am not a fan of Spring Data REST's approach of encouraging users to sub-class a configuration class that declares multiple beans. The configurer pattern used by Spring MVC is a more robust solution to the same problem. Spring Data REST has adopted this to a large extent (see DATAREST-621).

@bitsofinfo Why are you subclassing RepositoryRestMvcConfiguration? As noted in the documentation, you should use a RepositoryRestConfigurer bean if at all possible.

[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.

[bitsofinfo]

What requested information is outstanding? I've listed everything I'm doing and the results above.

[snicoll]

There's a question for you just above your comment

@bitsofinfo Why are you subclassing RepositoryRestMvcConfiguration? As noted in the documentation, you should use a RepositoryRestConfigurer bean if at all possible.

[bitsofinfo]

I am no longer subclassing it and am now using an alternate method.

If I should not subclass it it should be abstract.

I don't think the fact that I did originally subclass negates the issue.

[philwebb]

@bitsofinfo I think we're going to need a sample project that shows the problem in order to continue. It sounds like your comment above no longer stands.

[bitsofinfo]

Don't have the time to create another sample project for something like this, go ahead a close. Thanks

[Markitox]

Another workaround is exclude EndpointMBeanExportAutoConfiguration class from autoConfiguration. Of course this works if you don't need JMX for your app.

@EnableAutoConfiguration(exclude = [EndpointMBeanExportAutoConfiguration])
@SpringBootApplication
class DemoApp {

[kentoj]

This happened to me when I upgraded from 1.3.1.RELEASE to 1.4.1.RELEASE.

@lekant 's workaround works if changing the name of the method to super.halObjectMapper()

@Configuration
public class MyRepositoryRestMvcConfiguration extends RepositoryRestMvcConfiguration {

    public void configureRepositoryRestConfiguration(RepositoryRestConfiguration rrConfig) {
        rrConfig.exposeIdsFor(MyEntity.class);
    }

    @Override
    @Bean
    @Primary
    public ObjectMapper halObjectMapper() {
        return super.halObjectMapper();
    }
}

[michalrames]

For me the objectMapper obtained from RepositoryRestMvcConfiguration fails to serialize nested entitites because it has significantly fewer SerializationFeature configurations, than the one from default Spring Boot libraries.

Default Spring Boot objectMapper has the following features:
Serialization features: FAIL_ON_EMPTY_BEANS, FAIL_ON_SELF_REFERENCES, WRAP_EXCEPTIONS, FAIL_ON_UNWRAPPED_TYPE_IDENTIFIERS, FLUSH_AFTER_WRITE_VALUE, WRITE_DATES_AS_TIMESTAMPS, WRITE_DURATIONS_AS_TIMESTAMPS, WRITE_NULL_MAP_VALUES, WRITE_EMPTY_JSON_ARRAYS, WRITE_DATE_TIMESTAMPS_AS_NANOSECONDS, EAGER_SERIALIZER_FETCH

Deserialization features: FAIL_ON_INVALID_SUBTYPE, FAIL_ON_UNRESOLVED_OBJECT_IDS, FAIL_ON_MISSING_EXTERNAL_TYPE_ID_PROPERTY, WRAP_EXCEPTIONS, ACCEPT_FLOAT_AS_INT, READ_DATE_TIMESTAMPS_AS_NANOSECONDS, ADJUST_DATES_TO_CONTEXT_TIME_ZONE, EAGER_DESERIALIZER_FETCH

Is the RepositoryRestMvcConfiguration's ObjectMapper omitting these features by design? Is there a way to inherit the features from the "standard" objectMapper?

Thanks

[wilkinsona]

@michalrames This issue is closed and we prefer to use issues for bugs and enhancements only. Gitter or Stack Overflow are better places to ask questions.