[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [ee4j-community] Deprecating EJB in Favor of CDI Services
|
Good summary. The only thing I'll add is that I would love to move @Lock to Java EE concurrency as well. On Twitter, folks reminded me that EJB also has a concept of @Monitored. That's a valid point.
Depends on how we want to slice and dice it, but I count deprecating MDB in favor of something more CDI centric in JMS/JCA as part of this work too.
Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone
-------- Original message --------
From: arjan tijms <arjan.tijms@xxxxxxxxx>
Date: 10/16/17 11:03 AM (GMT-05:00)
To: EE4J community discussions <ee4j-community@xxxxxxxxxxx>
Subject: Re: [ee4j-community] Deprecating EJB in Favor of CDI Services
Indeed good to move it here ;)
To sum up, we'd like to completely deprecate EJB and have CDI compatible replacements in place for most or the most useful things, including a few related concepts.
This includes:
1. @Pooled
2. @Asynchronous
3. @Timer / @Scheduled
4. @RolesAllowed / @DenyAll, etc support (technically not EJB, but EJB is the only one that supports those now)
Possibly:
4. Passivation control (?)
5. JPA Extended Persistence Context
Possibly not (?)
6. @Remote / RMI support
Most of these would be at home in the security spec. @Pooled might go to the CDI spec as well, but the CDI EG has indicated it wants to focus more on the bean model itself, and less on actual services.
@RolesAllowed and friends is (of course) best at home in Java EE Security.
Speaking for OmniFaces I can say that donating our existing @Asynchronous and @Pooled implementations to the Concurrency spec is no problem.
Though I work for Payara, I can't officially speak for them, but I would not be surprised if we would like to take up some of the other work for this migration as well (but this is my opinion and doesn't necessarily reflect that of Payara).
Kind regards,
Arjan Tijms