Root cause

CGLIB based wrapper mentioned in MAGNOLIA-7618 uses Decorating proxying which expects the decorated classes to have a null-arg c-tor, which is typically not the case with module instances. However, a singular decoration of a module works since the wrapping is triggered by DefinitionProvider#get API, while the ModuleConfigurationRegistry recreates the module instance in its eagerlyUpdateModuleConfig and makes the latter available to injection (by-passing the #get API). It is only on the second time of decoration, when the result of the first decoration is to be used as a fallback, the DP#get API is invoked and triggers a failure.

Solution

Replace the CGLIB impl with bytebuddy + objenesis:

• objenesis allows to instantiate the wrappers regardless of c-tor complexity
• bytebuddy let's us implement efficient, cacheable interceptors

Example with REST module

An error arises if you try to decorate the same file (config.additionalProviders.yaml) from different modules.
I have tested all the decorations separately and they work fine.
If you merge them all into the same file, the decoration also works as expected.

Steps to reproduce

1. Apply two different decorations to the rest-integration module. Find in the  module-data.zip 3 different light-modules with 3 different decorations to apply to config.additionalProviders.yaml
2. If multiple decorations are applied, you will get an error on startup startup-error-message.log
3. Open admincentral and try to access the Defintion's app, you will get a second error definition-app-error.log and the Definition app is unusable
   

Expected results
We should be able to apply more than one decoration with no issues
 
Actual results
We get 2 different errors and the Decoration App becomes unusable.
 
Notes
Right now the customer has the workaround of having all decorations in the same file but this is not good enough as they stick to the modular approach. And have modules with different functionalities. Every module only holds the logic that is used within the module.

The idea of modularization is to create logical containers which can be modified, replaced or exchanged. For example, if our customer decides that he does not want to use module X anymore, we can simple remove the module with little effort. A bad example would be to have a monolithic module that contains the whole CMS adaptions of the customer.