Skip to main content

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

Hi Arjan,

This definitely looks important to me, especially if there is more work like I have been hoping to make some of the features still tied to EJB redundant in favor of more CDI centric equivalents in places like Concurrency, Security and Messaging.

I am planning to do some work to modernize Mail using CDI myself later in the year. I imagine these changes might be important there too. I hope there is interest from the CDI implementers in moving this work forward.

Reza Rahman
Jakarta EE Ambassador, Author, Blogger, Speaker

Please note views expressed here are my own as an individual community member and do not reflect the views of my employer.
 

From: cdi-dev <cdi-dev-bounces@xxxxxxxxxxx> on behalf of arjan tijms <arjan.tijms@xxxxxxxxx>
Sent: Monday, May 16, 2022 6:03 AM
To: cdi developer discussions <cdi-dev@xxxxxxxxxxx>
Subject: [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:


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:


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