> The "blocker" is the current extension model which is incompatible with build time approaches and overreach that exists within the API (ConversionScope anyone?).
The conversation scope is not ingrained in the API let alone extension API. It's an extra scope that is shipped with CDI, but everyone agrees it should move to JSF. Just like everyone (except for this one Jetty guy) agrees that the responsibility for HttpServletRequest injection should move to Servlet.
> The hostility from some on this mailing list is actually not particularly surprising given vested interests but disappointing nonetheless.
Do you mean me? It's not about being hostile, it's about loving Java EE, finding it useful and doing real work with it. Read what I write with a big smile and a number of hearts ;)
I don't think naming names helps in this scenario, the overall tone of the various threads is very much people attacking other approaches rather than providing any actual useful insight or suggestions to move the conversation forward.
Think about how the Spring community would react if someone was going to change the core Spring Bean container in such a way Spring Boot and Spring Regular would not be compatible with it anymore, or using different names and interfaces and such ;)
You want to know why Spring won and is by far the most dominant framework in the Java ecosystem and CDI is still a footnote in comparison? Because the Spring team is immensely adaptable to evolving technologies and not held back by design-by-committee processes that are openly hostile to progress.
The Spring community has at multiple times altered and evolved Spring for new use cases with an eye to backwards compatibility but not constrained by "the new thing should support everything the old thing does".
In fact Spring Boot was an evolution of Spring whereby they made a conscious decision not to support Spring XML which was at the time the main way to configure Spring. They effectively dropped support for a primary way the framework worked because they knew the future was not around XML configuration and Spring Boot was the way forward. Today Spring Boot is the main way and they will probably drop support for XML all together, ie the community and the technology evolved to new and better ways to do things.
Their current efforts around Spring Native also allow you to in fact only run a subset of Spring applications so they have already created something that is not compatible anymore to support AOT.
Considering all of these aspects of how Spring has evolved with the times, I really don't see your point.
Regards,
Only speaking for myself, but static CDI is a cool extra feature, but it should be a cool extra feature. Not change names for the sake of changing them and doing things differently for the sake of doing it differently.
my perspective it is a
very important question to answer.
cdi-dev mailing list
cdi-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdi-dev
