ProcessSyntheticBean: why not fired immediately?

[ljnelson]

The CDI specification says, in part:

addBean() fires an event of type ProcessSyntheticBean containing the given Bean and then registers the Bean with the container

(It is not immediately clear whether "addBean()" here means AfterBeanDiscovery#addBean() or AfterBeanDiscovery#addBean(Bean). I don't know if that makes a difference.)

(It also does not appear to say anything special about beans added via configurators, though the specification language is a little less robust in these sections.)

I believe we are seeing that Weld batches up and fires ProcessSyntheticBean events from all portable extensions after all portable extensions' AfterBeanDiscovery phases have completed. This does not appear to be what the specification says. Why does it work this way?

[manovotn]

(It is not immediately clear whether "addBean()" here means AfterBeanDiscovery#addBean() or AfterBeanDiscovery#addBean(Bean). I don't know if that makes a difference.)

IMO it stands for both as the same bullet point then goes on to explain the other variant. Both are, after all, just the means to the same end.

I believe helidon-io/helidon#10291 (comment) that Weld batches up and fires ProcessSyntheticBean events from all portable extensions after all portable extensions' AfterBeanDiscovery phases have completed. This does not appear to be what the specification says. Why does it work this way?

I don't see what in the specification states otherwise? The spec just says what events are fired, not exactly when.

I vaguely recall other similar issues where one extension action attempts to wait on another within the same event.
That smells of bad design to me; an extension can freely consume events from previous phases but to my knowledge there isn't anything in the spec that would state you can expect to be notified of changes other observers made within the same event. In fact, in a bigger application, you might not even know what other extensions are there, much less rely on the other that they are executed in - which in turn could lead to different results in different executions. Plus I wonder if you could even create some sort of cycle if you allowed that? 🤔
The OM notification part of spec states that you determine the whole set of methods and then synchronously notify all of them - which is exactly what is happening here.

A way around it is to have the whole logic in a single extension which can (as a stateful object) remember what beans were registered. Alternatively, you can for instance move some bean registrations to earlier phases and add them as annotated types (I didn't go deep on the Helidon issue, not sure if it is applicable there).

[ljnelson]

Sorry, I guess I wasn't clear.

The specification says "addBean() fires an event of type ProcessSyntheticBean containing the given Bean and then registers the Bean with the container". It makes it sound like, during the lifetime of an addBean() invocation, both things are supposed to happen. The specification statement, in other words, is a statement about what addBean() must do while it is "running".

You seem to be saying that no, that's not true. You seem to be saying: this statement is correct in its phrasing and its phrasing—in a way that I don't understand—somehow says explicitly that events of ProcessSyntheticBean are fired at some other lifecycle phase. Or, in other words, you are saying this phrasing means that addBean() can complete without firing an event of type ProcessSyntheticBean.

I understand that is what actually happens in Weld. I'm trying to understand what the justification is of this behavior given the phrasing of the specification, which seems pretty clear to me.

[manovotn]

The specification says "addBean() fires an event of type ProcessSyntheticBean containing the given Bean and then registers the Bean with the container". It makes it sound like, during the lifetime of an addBean() invocation, both things are supposed to happen. The specification statement, in other words, is a statement about what addBean() must do while it is "running".

Ok, thanks for your patience, now I see where you are coming from.
I did not read it that way at all :)

Now that you mention it, we should perhaps improve it on the specification side.

For I still stand behind my opinion that you should not intertwine notifications of all ABD events with ProcessSyntheticBean events. One situation I can think of as problematic with your reading of the spec goes like this:

• Two CDI extensions, let's call them ExtensionA a ExtensionB
  • They have no ordering of events nor do they know about each other (which is pretty common and perfectly fine in bigger apps)
• ExtensionA always unconditionally registers a bean with type Foo (and no qualifiers) as a synthetic bean during ABD event
• ExtensionB monitors ProcessSyntheticBean<Foo>, make note of its presence/absence and then in ABD attempt to add a synthetic bean Foo if it was missing

Now, since CDI imposes exactly no rules on ordering of extensions, two situations can occur.

First one:

1. ExtensionA is notified first and registers synth bean Foo
2. ExtensionB gets the ProcessSyntheticBean event delivered, makes note of it and in its own execution skip the registration of the bean
3. Your app runs fine

Second one:

1. ExtensionB is notified first; as there is no Foo bean yet, it registers it
2. ExtensionA then registers the bean as well
3. You now have ambiguous dependency resolution

Also CCing @mkouba and @Ladicek in case they can think of other reasons we might have seen over the years as to why intertwining these events can lead to unexpected scenarios.

[ljnelson]

I am not for or against where ProcessSyntheticBean events happen. I just want to make sure that when the specification says one thing, using plain language, and an implementation does something that does not seem to adhere to that language, that one or the other (spec or impl) is fixed properly.

[Ladicek]

I cannot really comment on portable extensions and their ordering, as this has never been properly specified. What I would like to comment on is this particular use case -- it seems very common and I believe CDI should really support it natively. I would hate to call it default beans though. The term alternative that CDI uses is unfortunately relatively ambiguous as to whether it has a lower or higher precedence, but when I looked at synonyms, standby looked quite OK to me.

[manovotn]

All, I have created the following issues under CDI where we can get a broader audience and determine what action should we take:

• Clarify specification in ABD#addBean jakartaee/cdi#872
• Introduce a concept of a "default" bean jakartaee/cdi#871