| Re: [cdi-dev] Lifecycle events in Extension |
To understand how it is meant you have to go way back to the CDI-1.0 and 1.1 specifications. Because over there it was way more clearer how it was originally intended: ------- 12.2 Application initialization lifecycle [initialization] When an application is started, the container performs the following steps: • First, the container must search for service providers for the service javax.enterprise.inject.spi.Extension defined in Section 11.5, instantiate a single instance of each service provider, and search the service provider class for observer methods of initialization events. • Next, the container must fire an event of type BeforeBeanDiscovery, as defined in Section 11.5.1. Contexts and Dependency Injection for the Java EE platform 112 / 114 • Next, the container must perform type discovery. Additionally, for every type discovered the container must fire an event of type ProcessAnnotatedType, as defined in Section 11.5.6. • Next, the container must fire an event of type AfterTypeDiscovery, as defined in Section 11.5.2. • Next, the container must perform bean discovery, and abort initialization of the application if any definition errors exist, as defined in Section 2.9. Additionally, for every Java EE component class supporting injection that may be instantiated by the container at runtime, the container must create an InjectionTarget for the class, as defined in Section 11.2, and fire an event of type ProcessInjectionTarget, as defined in Section 11.5.8. • Next, the container must fire an event of type AfterBeanDiscovery, as defined in Section 11.5.3, and abort initialization of the application if any observer registers a definition error. • Next, the container must detect deployment problems by validating bean dependencies and specialization and abort initializa- tion of the application if any deployment problems exist, as defined in Section 2.9. • Next, the container must fire an event of type AfterDeploymentValidation, as defined in Section 11.5.4, and abort initialization of the application if any observer registers a deployment problem. • Finally, the container begins directing requests to the application. ------- This wording got moved around and spread out and is now cluttered with maybe parts of the original intent gone missing. The original specification defined some strictly sequential lifecycle events (e.g BeforeBeanDiscovery clearly must be called before AfterDeploymentValidation). And other parts where the original spec indicated a type by type processing (ProcessInjectionPoint, etc). Think as a programmer. If you have a language (kind of python-like) which looks like for every discovered class: * fire ProcessBeanAttributes * fire ProcessInjectionPoint * fire ProcessInjectionTarget Then it really means the later option you mentioned. And that's what we find in the spec to this day. Even if it's now cluttered into different places all over the spec paper.. A _new_ test in the TCK suite now assumes a different order it seems. But this is not backed by the spec. > Not sure I understand, you can have a disabled bean before you get to PBA. There is even an ancient old CDI ticket about this problem. (Which likely got bulk closed like so many other valid tickets in both the spec and tck.) The point is that the spec declares that PBA must ONLY be fired for enabled beans. But by changing the BeanAttributes etc it can essentially become not-enabled. LieGrue strub
|