Hi,
I wanted to better understand if my prototype implementation of proposed Build Compatible Extensions on top of Portable Extensions has any issues in practice. I turned into my favorite example, SmallRye Fault Tolerance, and reimplemented the existing Portable Extension with the new API. You can find it here if you're interested:
https://github.com/Ladicek/smallrye-fault-tolerance/commits/cdi-lite It passes the entire MicroProfile Fault Tolerance TCK, and it passes the entire SmallRye Fault Tolerance test suite with a single exception (a test that uses Portable Extensions).
When I was prototyping the Build Compatible Extensions API on top of Quarkus, I did the same thing, so I can now compare.
In short: good progress is being made and the current Build Compatible Extensions API proposal seems pretty decent, though more work is needed. Long version follows.
I found 2 important things:
1. Portable Extensions don't allow transforming annotations on annotations (= you don't get `ProcessAnnotatedType` for annotation types). This is possible in Quarkus. To address that, I created a new extension point `MetaAnnoations`, which can be used to turn existing annotations into qualifiers, interceptor bindings, stereotypes or scopes (scopes were already there in the form of `Contexts`, the rest is new). This is close to what Portable Extensions allow in `BeforeBeanDiscovery`.
2. Sometimes, the extension runs some initialization code and stores state that other parts of the integrated framework want to access. That is a non-issue with Portable Extensions, because you can store the state in the extension instance and access it directly. With Build Compatible Extensions, we raise a barrier between the extension code (which can potentially execute during application build!) and the rest of the integrated framework. To cross that barrier, it is possible to use synthetic beans. Synthetic beans have to provide a creation function, which can run the initialization code (that would previously be in the extension). The synthetic bean instance would then store the state (and other parts of the framework would inject this bean instead of the extension instance). And since beans are instantiated on demand, it is possible to create a synthetic observer of the `@Initialized(ApplicationScoped.class) Object` event, which will trigger instantiation of the synthetic bean, thereby forcing the creation function to run.
The 2nd point is somewhat intricate, but once it clicks, it's fine. At least that's my experience. It also raises some questions:
1. Is there a portable way to run some code during application startup? The `@Initialized(ApplicationScoped.class) Object` event is fired during container initialization, which can be during application build, so that's not it. I propose CDI standardizes an `AfterStartup` event (symmetrically to existing `BeforeShutdown`), which is guaranteed to be fired during application startup. I personally find `AfterStartup` and `BeforeShutdown` a lot more natural than `@Initialized(ApplicationScoped.class) Object` and `@Destroyed(ApplicationScoped.class) Object`. (Though to be perfectly honest, `BeforeShutdown` seems misnamed and, since all CDI contexts are invalid at that point in time, also quite useless.)
This is easy to implement in a fully runtime environment, so I took the liberty of adding that to StillDI, even though it isn't part of the extension API.
2. The in-extension part of initialization code (complemented by synthetic beans, as described above) often needs to know the full set of beans in the application. The `AppDeployment` API provides access to that, but there's currently nothing in the API that would let you know "all beans have been processed". Even though the API is push-based, both implementations I currently have (in Quarkus and on top of Portable Extensions) are actually synchronous, so I was able to make it work, but there's clearly something missing. At this point, I'm thinking we'll probably have to add something similar to Portable Extensions `ProcessBean` and `ProcessObserver`. That would be before the `@Synthesis` phase, and `@Synthesis` would then serve as the "all beans have been processed" point. I really wanted to avoid this, but it seems inevitable. Another option is to add a "all done" callback to the `AppDeployment` API.
I currently have a huge TODO for this in the SmallRye Fault Tolerance implementation about this. Suggestions welcome.
LT
