Re: CDI TCK: Lifecycle container events

[Romain Manni-Bucau]

My main concern is to not break existing applications or at least not in a
way forcing them to be rewritten.
The default discovery got a toggle cause we can't do magic, for events it
is about ensuring if you got 3 events because inheritance was taken into
account, it should still be there (a bit like fastmatching toggle
probably?), for specialization I geuss spec is unclear cause there is no
specialization before events cause you can veto or change annotations.

So if it is the only issues no need of a module but maybe a new toggle and
challenge?

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le mar. 28 févr. 2023 à 00:06, Jean-Louis Monteiro 
a écrit :

> Hello guys,
>
> We have 3 issues I identified with lifecycle events in OWB.
>
> 1/ lifecycle container events order: we trigger the PBA in the first place.
> The spec is very clear with the order and PBA should come after PIP, PIT
> and before PB or POM
>
> I am aware of the specialization and the veto problematics. See 2/
> I don't see other options than moving the PBA event to the right place. The
> spec phrasing, unless I missed something, is quite clear.
>
>
> https://jakarta.ee/specifications/cdi/4.0/jakarta-cdi-spec-4.0.html#initialization_full
> and
>
> https://jakarta.ee/specifications/cdi/4.0/jakarta-cdi-spec-4.0.html#bean_discovery_steps_full
>
> 2/ "for each enabled bean"
>
> The spec says "for each enabled bean". I asked the mailing list, they
> mentioned it's when we process the beans. I'm planning to challenge
>
>
> org.jboss.cdi.tck.tests.full.extensions.lifecycle.processBeanAttributes.specialization.VetoTest
>
> But this is because after veto is called on PBA, the TCK expects
> that we re-evaluate the "for each enabled bean" and then fire PBA which
> became enabled because C was vetoed.
>
> There is nothing in the spec that mentions the order in which discovered
> beans have to be processed. And there is nothing that mentions that we need
> to reevaluate the beans after a PBA is a veto() is called on a PBA
>
> 3/ We have 3 beans
> C extends B extends A
> And we have 3 lifecycle observers
> public void a(@Observes ProcessBeanAttributes event) {}
> public void b(@Observes ProcessBeanAttributes event) {}
> public void c(@Observes ProcessBeanAttributes event) {}
> The notification order for observer methods within extensions follows the
> same ordering rule as defined in Observer ordering for non-extension
> observers.
>
>
> https://jakarta.ee/specifications/cdi/4.0/jakarta-cdi-spec-4.0.html#observer_ordering
> To my understanding, lifecycle events ordering are similar to "plain"
> application events.
>
>
> https://jakarta.ee/specifications/cdi/4.0/jakarta-cdi-spec-4.0.html#observer_resolution
> This part mentions container events such as lifecycle events.
>
> The TCK expects a(), b() and c() being invoked only once for the exact
> type. In OWB we notify a() 3 times, one for A, then B then C, we notify b()
> twice for B and C, and finally we notify c() for C.
>
> If we use A, B and C for an application observer libe
> @Dependent
> public static class ListObserver {
> public void alpha(@Observes List event) {
> System.out.println("A:" + event);
> }
> public void bravo(@Observes List event) {
> System.out.println("B:" + event);
> }
> public void charly(@Observes List event) {
> System.out.println("C:" + event);
> }
> }
> Looks like for application events, we do it the right way, but the spec
> seems to indicate lifecycle events are no different and we should treat
> them consistently.
>
> What do you think?
>
>
> --
> Jean-Louis Monteiro
> http://twitter.com/jlouismonteiro
> http://www.tomitribe.com
>

CDI TCK: Lifecycle container events

[Jean-Louis Monteiro]

Hello guys,

We have 3 issues I identified with lifecycle events in OWB.

1/ lifecycle container events order: we trigger the PBA in the first place.
The spec is very clear with the order and PBA should come after PIP, PIT
and before PB or POM

I am aware of the specialization and the veto problematics. See 2/
I don't see other options than moving the PBA event to the right place. The
spec phrasing, unless I missed something, is quite clear.

https://jakarta.ee/specifications/cdi/4.0/jakarta-cdi-spec-4.0.html#initialization_full
and
https://jakarta.ee/specifications/cdi/4.0/jakarta-cdi-spec-4.0.html#bean_discovery_steps_full

2/ "for each enabled bean"

The spec says "for each enabled bean". I asked the mailing list, they
mentioned it's when we process the beans. I'm planning to challenge

org.jboss.cdi.tck.tests.full.extensions.lifecycle.processBeanAttributes.specialization.VetoTest

But this is because after veto is called on PBA, the TCK expects
that we re-evaluate the "for each enabled bean" and then fire PBA which
became enabled because C was vetoed.

There is nothing in the spec that mentions the order in which discovered
beans have to be processed. And there is nothing that mentions that we need
to reevaluate the beans after a PBA is a veto() is called on a PBA

3/ We have 3 beans
C extends B extends A
And we have 3 lifecycle observers
public void a(@Observes ProcessBeanAttributes event) {}
public void b(@Observes ProcessBeanAttributes event) {}
public void c(@Observes ProcessBeanAttributes event) {}
The notification order for observer methods within extensions follows the
same ordering rule as defined in Observer ordering for non-extension
observers.

https://jakarta.ee/specifications/cdi/4.0/jakarta-cdi-spec-4.0.html#observer_ordering
To my understanding, lifecycle events ordering are similar to "plain"
application events.

https://jakarta.ee/specifications/cdi/4.0/jakarta-cdi-spec-4.0.html#observer_resolution
This part mentions container events such as lifecycle events.

The TCK expects a(), b() and c() being invoked only once for the exact
type. In OWB we notify a() 3 times, one for A, then B then C, we notify b()
twice for B and C, and finally we notify c() for C.

If we use A, B and C for an application observer libe
@Dependent
public static class ListObserver {
public void alpha(@Observes List event) {
System.out.println("A:" + event);
}
public void bravo(@Observes List event) {
System.out.println("B:" + event);
}
public void charly(@Observes List event) {
System.out.println("C:" + event);
}
}
Looks like for application events, we do it the right way, but the spec
seems to indicate lifecycle events are no different and we should treat
them consistently.

What do you think?


--
Jean-Louis Monteiro
http://twitter.com/jlouismonteiro
http://www.tomitribe.com