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 <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/application-development/java-ee-8-high-performance> Le mar. 28 févr. 2023 à 00:06, Jean-Louis Monteiro <jlmonte...@tomitribe.com> 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<Charly>, the TCK expects > that we re-evaluate the "for each enabled bean" and then fire PBA<B> 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<A> event) {} > public void b(@Observes ProcessBeanAttributes<B> event) {} > public void c(@Observes ProcessBeanAttributes<C> 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<A> event) { > System.out.println("A:" + event); > } > public void bravo(@Observes List<B> event) { > System.out.println("B:" + event); > } > public void charly(@Observes List<C> 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 >
