SpringBoot Enhancement for bean excluding

There are no easy ways to exclude a bean or a package from a context or make it non required(@Autowired(required = false)) using properties or annotations (something similar to spring.autoconfigure.exclude).

For some cases such as testing it is good to have easy way of excluding specific package without specifying each individual bean. Also, for example when using springdoc-plugin it starts an application to generate OpenAPI spec, sometimes application depends on a database. It requires to write boilerplate code to disable database beans using exclude filters or different profiles.

Suggestion is to create for example default ExcludeFilter which will allow:

Excluding beans from a context using properties:

spring.configure.exclude[0]=some.package.*            // Exclude all beans for some.package package
spring.configure.include[0]=some.package.Class       // As all beans excluded from some.package package, include only some.package.Class class
````

Sometimes it is not preferable to make all beans as `@Autowired(required = false)` in production code, but for testing it is needed to make it non-required if it was excluded from a context and other beans require that bean to be autowired.

Suggestion is to extend for example `QualifierAnnotationAutowireCandidateResolver.isRequired()`, and make beans as non-required:

Making beans as non-required using properties:

spring.configure.optional[0]=some.package.Class // Make beans as non-required only for some.package.Class class spring.configure.optional[1]=some.package. // Make beans as non-required only for some.package package spring.configure.optional[2]=some.package.* // Make beans as non-required for some.package package and all nested packages ````

Comment From: wilkinsona

Thanks for the suggestion. Unfortunately, I don't think this is something that we should add to Spring Boot.

There are already ways of controlling the beans that are included in an application. You've mentioned profiles. Additionally, the base packages used for component scanning can be customised. For more complex needs, @ComponentScans include and exclude filters can also be used. The filter-based mechanism may provide a foundation upon which you could build your property-based solution that meets your specific needs. I don't think it's something that we'd want to make generally available though.

I think allowing beans to be marked as optional could cause quite some confusion. If an injection point requires a dependency, the chances of an NPE occurring when null is injected due to a bean being made optional would be high.