Spring Boot configures Hibernate Validator in a way that the latter looks up the components it needs to instantiate via the Spring container. That in turn then creates prototype instances of the types requested. This means, implementations of e.g. ConstraintValidator do not need to be explicitly marked as Spring beans, but could still declare dependencies to other Spring beans. If such a dependency crosses a module boundary, we currently fail to detect that implicitly established module dependency.
This is now fixed by considering ConstraintValidator implementations Spring beans implicitly in out bootstrap dependency analysis.
We now explicitly exclude classes generated by Spring AOT in the architectural model. For technical reasons, they might introduce dependencies to application components considered module internals otherwise. Also, proxies generated do not need to be considered either.
We now propagate potentially occurring exceptions in CompletionRegisteringAdvisor to make sure the standard exception handling facilities kick in, both for synchronous and asynchronous listener invocations.
We now register a BeanFactoryInitializationAotProcessor to generate the actuator endpoint content representing the application module structure at AOT processing time. That file is then preferred over bootstrapping an ApplicationModules instance when bootstrapping the endpoint.
We now skip configuration classes for observability-related proxying as it's hard to detect those during the ProxyFactory setup to configure target class proxying. Also, configuration classes are usually no targets of inter-module communication and thus don't need to be observed at all.
We now skip infrastructure role beans during the processing of beans that could be subject to inter-module interaction observability. Previously, we could accidentally trigger a dependency cycle if the ModuleTracingBeanPostProcessor triggered the initial creation of AutoConfigurationPackages as that would then trigger the PostProcessor in turn which would try to lookup the ACP bean again to determine whether it should post process that to apply observability.
Prior to this commit, the lookup for an ApplicationModule would find modules solely depending on the reference string starting with the base package. That means that a module with base package com.acme.foo, a request for com.acme.foobar would've resulted in a positive match, which of course is wrong.
We now match against either the module's base package or against the reference starting with the base package followed by a dot.
