override-with-generic-response shouldn't shallow copy

Is your feature request related to a problem? Please describe :

Hi

I’m using v1.6.6 of docapi.

I’ve noticed that org.springdoc.core.GenericResponseService#getGenericMapResponse is making a shallow copy of the generic responses.

It’s bugging me while I’m trying to write a customizer :

Its purpose is to add extra examples entries to the contents of already existing 4xx and 5xx generic entries.

Those generic entries are 500 and 400 ones, automatically build by Springdoc, out of my centralized @ControllerAdvice.

Those default entries are fine to report exceptions that could occur either from :

• 500 : the lower layers, such as database connexion troubles
• 400 : the client side, whenever Spring received a problematic request and throw an exception before the controllers been called

But I also have domaine related exceptions, that are reported in the throw part of my controller’s signature.

Because each of those domain exceptions are coming along with a @ResponseStatus, the point of my customizer is to use their associated informations to add extra examples to those 400 and 500 entries, whenever the status code match, of course 😉

But because of the shallow copy, when my customizer add an extra example to one controller endpoint’s Content part, it’s also adding it to all other ones … 😛

Do you have a clue how to workaround this trouble ?

Describe the solution you’d like

Either :

• have org.springdoc.core.GenericResponseService#getGenericMapResponse performing a deep copy instead of a shallow one
• or if it’s not possible, have an access to a clone function, in order to manage this replication myself in my customizer

Describe alternatives you’ve considered

None

[Mumeii]

Ha ! Ok, didn’t understood what HelloController was all about 😝

I’ll try to do it tonight so.

[Mumeii]

yup, the test is running fine when trying it on my side, and as long as they are no huge performance constraints associated to the GenericResponseService#getGenericMapResponse method, the objectMapper.readValue(objectMapper.writeValueAsString()) trick is nice.

Thanks for this evol !