[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
[cdi-dev] This is StillDI
|
Hi,
over last weeks, I've heard many people expressing a concern that what
we're up to with CDI Lite, and especially with the new extension model,
is "no longer CDI". I'm 100% sure that isn't anyone's intention, it
certainly isn't mine.
On one of the recent CDI calls, I realized (again thanks Tomas Langer
for the initial idea) that it's probably possible to implement the
proposed Build Compatible Extensions API on top of existing Portable
Extensions, proving that indeed this is still CDI, and indeed this can
still be made a strict subset of CDI with a little help.
Here goes: https://github.com/Ladicek/StillDI
Note that the README isn't really meant to be end-user documentation.
It's meant for CDI experts and mainly serves as a brief overview and a
comparison between the 2 extension APIs.
As part of the work, I discovered a few discrepancies that we need to
resolve, and fortunately, they are all really small. Specifically:
1. The proposed Build Compatible Extensions API allows adding all
subtypes of a given type to be scanned during bean discovery. Portable
Extensions don't have that, and I think we should just remove this. The
method to add one concrete type is obviously not an issue.
2. The proposed Build Compatible Extensions API allows setting a
priority of a synthetic bean (together with its "is alternative" flag).
I propose we add this to Portable Extensions.
3. The proposed Build Compatible Extensions API provides access to the
"current" injection point when creating an instance of a synthetic bean,
when its scope is @Dependent. This is possible with producer methods, so
I don't see why it shouldn't be possible with synthetic beans. I propose
we add this to Portable Extensions.
Other than that, I don't see anything that can't be losslessly
translated between the 2 extension APIs, even though they are somewhat
differently structured at certain places. (We might also want to align
that structuring more, that is all open for debate.)
I'd be grateful for any kind of comments, preferrably here on this
mailing list I guess (but don't really mind).
Thanks,
LT