| Re: [cdi-dev] About parsing beans.xml files in Lite/CDI-Lite naming |
Hello,
Regarding point 2, my suggestion would be Compiled CDI, as all I
can see of the point of the proposal of CDI-Lite is that is can be
done at compile time for the likes of GraalVM.
Jonathan Coustick
2 kind topics in the same thread here:
1) Related to initial thread topic : Beans.xml. Beyond bean archive and discovery, I think that the issue here is the lack of a global configuration for CDI in the deployment. This topic has been discussed during CDI 2.0 specification work and was not retain. Now that we see more and more CDI usage where bean archive concept is not very relevant (CDI SE and future “CDI Lite”) we could think about a global configuration again
2) Regarding other points- Naming : CDI Lite is not a final name. If you have a suggestion please share it
- Portable extensions : they are not going anywhere or being deprecated. so I don’t really get point that imply that it is the goal. It’s not
- Meeting Feedback on the ML. I agree it could be improved. We’ll see what we can do about this. ML would also be easier to follow if topics wouldn’t be mixed up : it’s not very expensive to start a new thread- CDI Lite content : nothing important is yet decided. If you read the meeting minutes [1], you’ll see that we agreed on a few things until now. Discussion is still open. As an effort of being more asynchronous we could relaunch workshop doc like we did I for CDI 2.0
Antoine
[1] https://docs.google.com/document/d/1LJgN9UZlSwYASnE-IpaFVw9D7spJoK2J1vlys7AyNG4/edit--
Le mar. 26 janv. 2021 à 09:18, Ladislav Thon <lthon@xxxxxxxxxx> a écrit :
Here's my take at "one defining feature", though it really is the same as what Jason wrote: decouple the "initialization" phase (where beans are discovered, extensions executed etc. etc.) from the "runtime" phase (where the application just runs) so that these 2 phases can be executed in 2 different JVM instances.
Note that I already wrote this here on the list at least once. At this point, I feel like we're running around in circles, attacking the same strawman over and over and over and over. That is not productive. How come we got from a very specific quesion on which everyone's opinion would be very much welcome, to debating "what is CDI Lite", again?
_______________________________________________
LT
On 25. 01. 21 22:25, Jason Greene wrote:
Hi Manfred, response inline:
-snip-On Jan 25, 2021, at 2:29 PM, Manfred Riem <m_riem@xxxxxxxxxxx> wrote:
To clarify if you say subset do you mean that everything that works in this version of CDI would also work in the “Full” version of CDI?As that is what subset means to me.
If you are a CDI API user (e.g. a typical EE developer) then yes.
If you are an integrator extending CDI by distributing an extension then it depends on if the Full implementation chooses to implement the build-compatible extension SPI. In an ideal world we would have one extension SPI, but the problem is that we can’t change/evolve the existing extension SPI without impacting compatibility. Full implementations expect to continue to offer that compatibility so we effectively arrive at two extension SPIs.
-Jason
_______________________________________________ cdi-dev mailing list cdi-dev@xxxxxxxxxxx To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdi-dev
cdi-dev mailing list
cdi-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdi-dev
Antoine Sabot-Durand
_______________________________________________ cdi-dev mailing list cdi-dev@xxxxxxxxxxx To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdi-dev