Allow disabling beans / packages via configuration

[alvarosanchez]

There are many situations in which a user may simply want to disable some beans in certain scenarios.

For the modules that we have built, we often make the configuration properties classes to implement Toggleable so that they can be enabled/disabled via configuration. In other places (such as other beans, or package-info.java) we use @Requires to make those beans conditional to the presence of some enabled configuration property, e.g.: @Requires(property="some.configuration.enabled", value="true", defaultValue="true").

Unfortunately, not all configuration properties or bean definitions have those built-in requirements. Therefore, it would be great if there could be a global way to enable/disable beans or packages via configuration.

Proposal:

micronaut:
  beans:
    disable:
      - com.mycompany.myapp.somepackage # Disables all beans in the com.mycompany.myapp.somepackage tree (including children).
      - com.mycompany.myapp.SomeClass # Disable all beans of that type.

[jameskleeh]

Currently those creating libraries have the assumption that a given bean will exist and allowing users to disable beans will cause issues that they cannot resolve. I think if a bean is designed to be disabled then it should be done via the mechanism the library author or we intend. It should also be possible to make it so a bean cannot be disabled. This relates to the @Infrastructure annotation.

1. Where it is already possible to disable a given bean this introduces multiple ways to do the same thing
2. This is a long rope for users to easily hang themselves on by changing the assumptions existing code makes about the presence of beans

[graemerocher]

some valid points. I think the specific scenario this problem is trying to solve is that you want to disable say the datasources for your tests.

In that case it is not possible to remove the micronaut-sql dependency for test scope. An alternative solution would be that we need a way to subtract configuration (right now configuration is only additive) so I can't define an application-test.yml file that removes the datasources configuration.

[dstepanov]

I don’t like the idea of disabling beans that aren't supposed to be disabled and might not be visible at all.

I would prefer to implement disabling of any conf that implements Toggleable like data source.

[jameskleeh]

@graemerocher I think for the datasource case we should just allow them to be disabled via config

datasources:
    foo:
        enabled: false

[RiccardoManzan]

Hi everyone, i just faced this need.

In my application i use only custom authentication fetchers. Micronaut security provides a TokenAuthenticationFetcher which does not have the @Requires annotation, though it is not disableable.
I know that not having provided any TokenValidator, this AuthenticationFetcher will never publish any authentication but it's execution at every request is just useless.

If i could disable that bean in a configuration or code way it would be very nice, regardless the option to add a @Requires directly in micronaut-spring code.

This functionality would never replace the @Requires annotation but it would be a nice way to have such feature when dealing with libraries which are out of control and miss the conditional functionality.

As an alternative, which may be more suitable as it would not be customizeable by app properties though by env, i would suggest some annotation like @ExcludedBeans(classes:Collection<Class>) which could be placed in main function/class.
Or we could have a BeanExcluder(clazz:Class) class, which, if present for a specific class, let's say BeanExcluder(TokenAuthenticationFetcher::class), it would disable the related bean.