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
Hello

I will try to answer to the best of my knowledge but note that I was the author of the test so that kind of implies what you're going to hear :)
Below, I'll also provide some links below because this was discussed previously.

> 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

This is how I believe it should behave.
The reason for that is the spec wording saying that those actions are taken for every type in the set of discovered types combined with the fact that each action (or bullet in the spec) ends with and then.
So you can effectively read the spec as (cut for brevity):
  • ...
  • for every type in the set of discovered types, fire PIP
  • for every type in the set of discovered types, fire PIT
  • ...
Setting spec wording aside, assuming the action/event is processed for all types before moving to next action/event, then you can safely rely on having complete information from event A before you get to event B.
To use an example - doing it this way gives you more power in that (for example) by the time you get to ProcessBeanAttributes<Foo>, you will have gone through all ProcessInjectionPoint<?,?> and can now use gathered information to decide whether to veto() the Foo bean or not.

> The producer side seems to be mixing events from different types or am I wrong?
> 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)

That's intentional because of what I said above - the test deliberately verifies that all events of type A are fired before you move to events of type B (or in this case PIP for producers is fired before you move on to PP).
To achieve that, it uses two different producers.

Now, the promised links:
  • There was a TCK issue which will hopefully be public again in a day or two (JIRA seems to have gotten archived, working on it, sorry)
    • If I read this correctly the parties eventually agreed that the test asserts what the spec actually says
  • And based on the TCK issue, there was a CDI issue created challenging the spec expectations
    • Branches from the TCK issue but as far as I can tell, this wasn't accepted or acted upon

> 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"

Not sure I understand, you can have a disabled bean before you get to PBA. It's just that PBA is yet another point in which you can decide to disable the bean by vetoing.
For example you can have an interceptor that doesn't declare priority and hence isn't enabled. Same for alternative bean without priority.
Or do you mean something else?

Regards
Matej


On Wed, Feb 15, 2023 at 4:35 PM Jean-Louis Monteiro <jlmonteiro@xxxxxxxxxxxxx> wrote:
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