Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
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


Am 15.02.2023 um 16:35 schrieb Jean-Louis Monteiro <jlmonteiro@xxxxxxxxxxxxx>:

Hi all,

Decided to ask before creating a challenge because I'm not sure about this one, so I really need your expertise to understand.

The TCK in question is org.jboss.cdi.tck.tests.full.extensions.beanDiscovery.event.ordering.LifecycleEventOrderingTest

The goal is to test the sequence of "Bean Discovery Events". I'm referring to the following https://jakarta.ee/specifications/cdi/4.0/jakarta-cdi-spec-4.0.html#initialization_full which then says the container must perform bean discovery --> https://jakarta.ee/specifications/cdi/4.0/jakarta-cdi-spec-4.0.html#bean_discovery_steps_full

I do have some understanding issues. I apologize in advance if questions appear to be stupid.

The spec start with "For every type in the set of discovered types (as defined in Type discovery in CDI Full), the container must:"

If I simply it with a simple example, does it mean we have to fire first all event A for all types, then all events B for all types, then all events C for all types

OR

Does it mean, for bean 1, fire event A, then B, then C, then move to bean 2 and fire event A then B, then C.

The test above seems to be implemented from a bean perspective so it may not have an impact.

My other question is when the spec says "if the class is an enabled bean, interceptor or decorator, fire an event of type ProcessBeanAttributes, as defined in ProcessBeanAttributes event, and then"

I'm wondering how that is effectively possible. My understanding is that you can only decide whether a bean is enabled or not AFTER you fired ProcessBeanAttribute. Shouldn't the PBA always be fired (as soon as the bean is not vetoed of course)? If not then it gets complicated from a user perspective when you specialize a bean.


The producer side seems to be mixing events from different types or am I wrong?
For example, we are observing `ProcessProducerMethod<HighQualityAndLowCostProduct, PoorWorker>` ppm but we are on the other hand observing `ProcessInjectionPoint<PoorWorker, String> pip`

We have 2 producers in this class and I'm wondering what we are actually testing (hence the first question related to the scope, per bean, or global)

Thanks in advance

_______________________________________________
cdi-dev mailing list
cdi-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdi-dev


Back to the top