Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[cdi-dev] CDI.Next

Hi,

With CDI 4.0 now being done, I wonder if we could start looking at the roadmap and wishlist for CDI.Next.

As many may remember, originally we had general improvements for CDI in scope and in particular improvements that could help other specifications in Jakarta EE. Because the work for CDI Lite / Build Time took over essentially most of the discussions, not that much focus was put on these other concerns.

I'm particularly looking forward to getting the following done:

https://github.com/eclipse-ee4j/cdi/issues/459

This is a very important issue for every specification that provides "build-in" beans, such as Jakarta Faces and Jakarta Security, and likely Jakarta REST in the near future. The problem now is that a user can't decorate any build-in beans without the implementation (such as Soteria , Mojarra or Jersey) tying itself to a specific CDI implementation (such as Weld).

Some low hanging fruit is getting Interceptor bindings in a standard way:

https://github.com/eclipse-ee4j/cdi/issues/592

This is important for again Jakarta Security, but also for Jakarta Transactions. The current implementations have to look at the class level annotations, which will fail if an interceptor is dynamically added.

There's a couple of other things, such as obtaining the "previous bean with type X" from a producer of type X, and providing a synthetic InjectionPoint for a programmatic bean lookup (as some producers require an InjectionPoint to be available).

Thoughts?

Kind regards,
Arjan Tijms



Back to the top