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
> The "enabled beans" before the "fire PBA" is also to clarify. From what you said in your first reply. It's only for enabled beans when we are processing the PBA events. If after the event is being processed, the bean moves from enabled to not enabled state, then that's ok. This is why we trigger PBA with a veto() method. Am I correct?

Yes, IIRC the PBA is for all beans that, at the time of firing, you deem enabled.
It is also the last point in which you can decide to disable the bean by calling veto().
Note that detecting enabled beans can also be tricky because you can have alternatives, decorators and interceptors that don't use Priority annotation but instead rely on per-archive enablement via beans.xml.

Matej


On Tue, Feb 21, 2023 at 4:22 PM Jean-Louis Monteiro <jlmonteiro@xxxxxxxxxxxxx> wrote:
I created this thread because I needed more information on the use case, and what the test is meant to do and assert.

If I would be more or less sure I would have created an issue as a challenge. I don't have a strong opinion yet. I do believe we could probably improve the wording maybe in the spec for end users. As stupid as I am, if I can't have a strong opinion reading it, maybe there are more in the world in the same situation.

So I really appreciate the feedback and the fact we have all different readings of the spec shows again we could clarify the spec maybe.

I'd agree with you Matej that even though history and previous discussions are important to understand, we are at CDI 4 and I'm working on the related TCK. If there is something wrong, the past does not really matter. What's important is the current version of the TCK with the current version of the spec. Are they in agreement? Is there one more restrictive than the other? Are they some non-rewritten assertions? etc.

I also agree with you Matej that for single beans, the test and the spec are ok.
Reading the spec, there is the question I asked at the beginning when there are multiple beans, but this is not tested at the moment.

For producers, it was not clear because the type of the events in the @Observes are different and involve the 2 producer methods in the class.

The "enabled beans" before the "fire PBA" is also to clarify. From what you said in your first reply. It's only for enabled beans when we are processing the PBA events. If after the event is being processed, the bean moves from enabled to not enabled state, then that's ok. This is why we trigger PBA with a veto() method. Am I correct?

On Tue, Feb 21, 2023 at 2:54 PM Matej Novotny <manovotn@xxxxxxxxxx> wrote:
Looking more closely at the test, there isn't even anything that would assert the ordering of events for multiple beans/producers, so whether you fire 'all events for one type' or 'one event for all types' isn't being challenged - or am I missing something Jean-Louis? And I can understand that due to this not being ever tested, the impls can diverge and that's probably fine.

But the ordering of events for a single bean are IMO pretty clear in the specification (as was acknowledged in the TCK issue as well) - and this is what the test effectively asserts.

On Tue, Feb 21, 2023 at 2:08 PM Matej Novotny <manovotn@xxxxxxxxxx> wrote:
Using the 1.0 version of specification to justify behavior tested in 4.0 seems a bit off. After all, 1.0 was in 2013 (give or take a year?).
Plenty of changes, adjustments, clarifications and additional test coverage got into the spec in the meantime during those 10 years.

But even rolling with that idea, the wording in 1.0 is very similar (can be seen here) but obviously more barebones because that was the initial state of things.

> 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).

This is still specified in the spec today, see this chapter and it isn't what the TCK test in question asserts; it targets per-bean discovery events.
ProcessInjectionPoint is an interesting example for ordering, particularly because it doesn't seem to exist in 1.0 spec and only appears in 1.1 released later (which makes using 1.0 as an argument for 4.0 behavior even weirder?)
For sure it isn't mentioned in either Chapter 11 or 12 of CDI 1.0.

> A _new_ test in the TCK suite now assumes a different order it seems. But this is not backed by the spec.

As far as CDI 1.0 spec goes it indeed isn't indeed.
The issue for the test is CDITCK-590 (which is now browseable again) and it was added some time after TCK 2.0 (and CDI 2.0).
So this test has been _new_ for the last 5+ years (Jun 2017) and last time I checked, adding test coverage wasn't a crime either.

> 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 issue in question is linked to the TCK ticket above and I also mentioned it in the previous email.
Issues (all CDI JIRA issues) got bulk closed not because I'd just love the way it feels to slam the issue but because the project migrated under Jakarta which requires their projects to use GH for issue tracking.
That's also what those comments indicated, why are those issues still accessible and why they prompted users to re-create the ticket under GH if still applicable.
An example of such a comment/closure is here and there was also a GH issue tracking the whole process on the Jakarta side, link here.

Regards
Matej

On Mon, Feb 20, 2023 at 2:26 PM Mark Struberg <struberg@xxxxxxxxxx> wrote:
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

_______________________________________________
cdi-dev mailing list
cdi-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdi-dev
_______________________________________________
cdi-dev mailing list
cdi-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdi-dev
_______________________________________________
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