Jackson objectMapper from new webapps may cause duplicity in Spring context

[krkoska]

New webapps implementation is part of the cibseven-bpm-spring-boot-starter (2.0.0) dependency. It contains Spring config which creates Jackson objectMapper bean (defined in SevenWebclientContext configuration class). This approach interferes with quite common situation when the project, where SCIB Seven is used, already defines its own objectMapper.

The problem pops out during startup of the application when Spring context is being created:

Parameter 0 of method clientRestTemplate in uu.app.client.ClientContextConfiguration required a single bean, but 2 were found: - getJacksonObjectMapper: defined by method 'getJacksonObjectMapper' in class path resource [uu/app/serialization/SerializationContextConfiguration.class] - objectMapper: defined by method 'objectMapper' in class path resource [org/cibseven/webapp/SevenWebclientContext.class]

Right now, I can't see a way how to get rid of this problem. Is there a way to push CIB seven to use my own objectMapper? If not, will it be added?

[HellFire99]

Same kind of problem here. We are using the default Jackson objectMapper provided by spring boot which auto-registers modules when found on the classpath. After migrating from Camunda to CIB7 it seems the registreredModuleTypes only contains 1 type instead of a whole list of types as before the migration. It doesn't seem to discover any additional modules anymore.
The only way around it, as I see it now, is to provide de necessary modules from a @configuration.

[lucasbroennimann]

Just wanted to confirm that we have the same issue on our side, at least in modules where we define our own objectmapper (other modules still kept using the default jackson objectmapper as they should). Marking our own objectmapper as primary seemed to solve most of the issues, but I still would appreciate it if the CIB seven webapp could try to find way to get rid of the objectmapper configuration in the SevenWebclientContext class.