- impacts new functionality
- impacts public API.
Consider the following configuration for a top-level heap:
Here we define a client handler, a local decorator (timer) and a global decorator (audit). Both decorate the client handler.
Now we create a route. Routes inherit their configuration from the parent heap, in this case the global configuration:
Users might be surprised to discover that the client handler has the audit handler enabled, but not the capture. Global decorators only apply to declarations within the same heap and sub-heaps. Users will expect that decorators declared in the manner above should apply to references such as the handler, not just declarations. But if that were the case, how would global decorators be declared?
Now let's add a second route:
Here SomeHandler will be audited due to the global decoration in the global heap. Unfortunately, I have no way to decorate the referenced client handler.
It's a shame that if I want to decorate objects defined in parent heaps I am forced to either:
- decorate at the point of declaration which causes all sub-heaps (routes) to inherit the decoration which might not be appropriate
- duplicate the declaration inside my route and decorate it there, but duplication is brittle (e.g. a client handler may have quite a complex config involving key stores, etc).
This solution solves some problems:
In the sample above "decorator" decorates only the referenced handler (SomeHandler). It is not a global decorator and does not decorate objects declared elsewhere in the heap.
The "globalDecorators" field lists global decorators and is equivalent to the support that we have today.
However, we are still not able to decorate components referenced inside the heap. In the above example there is no way to decorate the referenced "ClientHandler" except using global decorators, but those will decorate all objects, not just ClientHandler.