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

Re: [DISCUSS] CDI Compliance and breaking changes

[Romain Manni-Bucau]

Hi,

Think there are multiple points there and we should absolutely avoid a
compliance flag in owb-core/se modules until it is requires and we ack the
change.
For other changes (the one we dont want, we can just use our spi mecanism
and change the behavior in an owb-compliancy module maybe.

For me the points are:

* Did the spec broke something for good -> add a toggle
* Did the spec broke without reason -> need to check if intended, if so
compliancy module else ignore
* Is the spec clear about the impl it expects (for ex it is not for
container events) -> if yes then impl else discuss and if no compromise
then compliancy module

Side note: if the toggle is a one liner the compliancy module just enables
it in openwebbeans.properties, no need to split the impl in multiple parts
or add a SPI if simple.

Overall my fear right now is core become bloated because each version of
the spec adds what is already there but in a new package or way so I hope
we can keep a core light and be compliant in a module marked as "they did
it wrong but you can get it too".

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



Le lun. 27 févr. 2023 à 20:58, Jean-Louis Monteiro 
a écrit :

> Hello guys,
>
> I've been spending a couple of days trying to figure out what the spec says
> or does not. I also looked at the TCK tests we currently do not pass as
> well as what OWB/Weld do in both situations. I've also augmented the TCK
> tests to understand and test some other edge cases.
>
> *Important note*: I created a couple of challenges already and PRs to fix
> the spec/TCK and I'm happy to create more challenges. Mind that the process
> to create challenges is very well defined
> https://jakarta.ee/committees/specification/tckprocess/
>
> In essence, a challenge cannot be filed if we don't agree with the spec or
> if the spec is stupid, or else. We can only fill a challenge, if the TCK
> does not match something in the spec, if it's more restrictive, etc.
>
> << Good or bad, the spec is as it is now. The past/future does not matter
> >>
>
> I'm not sure about the history and if the spec evolved in the past and we
> did not follow, or if the spec introduced things we did not agree on and
> decided to not implement. As of now, we need changes if we want to ever be
> compliant.
>
> I'd like to discuss how to handle the breaking changes. I do think if we
> claim to implement CDI we must implement it all and correctly.
>
> I'm ok if we have a "compliance" flag if we don't want to break backward
> compatibility. But to me, it's a major version and jakarta namespace is
> already a huge backward compatibility issue. So for sure it's preferred we
> catch up with all breaking changes now and participate in the spec so we
> avoid future backward compatibility issues. If we don't do it now, of
> course it will be harder to do it later for our users and it means we'll
> never be able to claim compliance.
>
> It is obviously not a vote. But I think it's an important discussion.
> What do you think?
>
>
> --
> Jean-Louis Monteiro
> http://twitter.com/jlouismonteiro
> http://www.tomitribe.com
>

[DISCUSS] CDI Compliance and breaking changes

[Jean-Louis Monteiro]

Hello guys,

I've been spending a couple of days trying to figure out what the spec says
or does not. I also looked at the TCK tests we currently do not pass as
well as what OWB/Weld do in both situations. I've also augmented the TCK
tests to understand and test some other edge cases.

*Important note*: I created a couple of challenges already and PRs to fix
the spec/TCK and I'm happy to create more challenges. Mind that the process
to create challenges is very well defined
https://jakarta.ee/committees/specification/tckprocess/

In essence, a challenge cannot be filed if we don't agree with the spec or
if the spec is stupid, or else. We can only fill a challenge, if the TCK
does not match something in the spec, if it's more restrictive, etc.

<< Good or bad, the spec is as it is now. The past/future does not matter >>

I'm not sure about the history and if the spec evolved in the past and we
did not follow, or if the spec introduced things we did not agree on and
decided to not implement. As of now, we need changes if we want to ever be
compliant.

I'd like to discuss how to handle the breaking changes. I do think if we
claim to implement CDI we must implement it all and correctly.

I'm ok if we have a "compliance" flag if we don't want to break backward
compatibility. But to me, it's a major version and jakarta namespace is
already a huge backward compatibility issue. So for sure it's preferred we
catch up with all breaking changes now and participate in the spec so we
avoid future backward compatibility issues. If we don't do it now, of
course it will be harder to do it later for our users and it means we'll
never be able to claim compliance.

It is obviously not a vote. But I think it's an important discussion.
What do you think?


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