| Re: [jakartaee-platform-dev] Retire EJB-Lite from web profile? |
In case it helps others, a recent description of what
is included in EJB-Lite is here.
Personally, I think we should evaluate the gap of CDI replacing EJB and try to provide the alternative solution via different specs, mostly CDI. We should start evaluating whether EJB Lite can be covered by other specs in the web profile and then make it optional and then remove it from the web profile. Once EJB is replaced by others, we can remove EJB from Platform as well. To start with, listing all useful functionalities in EJB and then finding the alternatives is a good starting point.
There are some overlapping features in other technologies that could probably be considered as to whether to replace or deprecate/remove them. The Jakarta Persistence extended persistence context is one such technology that only currently works with Stateful session bean. I know that some implementations (e.g. WildFly) have been supporting deep inheritance (multiple level) of extended persistence context since JBossAS 5.0 and starting in WildFly 7 also supports shallow extended persistence context inheritance (e.g. single level).
If we move stateful session beans to CDI, that impacts the
Jakarta Persistence specification for ^ and in general for
managing container manager persistence contexts.
So already, I think that refactoring the EJB-Lite technologies
includes more than just refactoring EJB-Lite.
Scott
ThanksEmily
On Mon, Aug 8, 2022 at 10:55 PM arjan tijms <arjan.tijms@xxxxxxxxx> wrote:
_______________________________________________Hi,
On Mon, Aug 8, 2022 at 5:14 PM Steve Millidge (Payara) <steve.millidge@xxxxxxxxxxx> wrote:
First if this is a road people wanted to go down then it would first have to be deprecated from Web profile as it is a major breaking change so Jakarta EE 11 is too soon.
It would be deprecated in EE 11 indeed, not yet removed as a requirement for that profile.
Second there isn’t currently a CDI mechanism for doing every thing that is done with EJB-lite. Therefore I think we need to have CDI equivalents for capabilities of Session beans. These could be spread between different specifications e.g. @Pooled into concurrency.
Indeed, there's a handful of features / services not readily available yet. Reza Rahman enumerated them all the way back in 2012, and that list can still be used as a tracker. Essentially this one at the time was created in response of Reza's list: https://github.com/omnifaces/omniservices
It indeed contains the @Pooled. After 9 years (7 since commit) it could be updated a little bit, but not that much as the underlying CDI APIs didn't change much. That one can be used as a prototype.
Our friend Rudy did an initial PoC for @Locked/@Singleton: https://github.com/atbashEE/CDI-locked
Both these could be used as a starting point to define a spec based version on.
Finally use of the @RunAs, @RolesAllowed etc. needs to be normalised across specs to ensure behaviour would be equivalent on a CDI bean as it would be on an EJB in all specifications.
True. This had been on the radar for Security 3.0, see https://projects.eclipse.org/projects/ee4j.es/releases/3.0 Unfortuantely it just didn't happen, but it's there. The bar for just emulating how EJB does it is fairly low, but we'd likely want to give it a little more of a kick in a CDI version. For instance, especially for Jakarta REST / JAX-RS and potentially Servlet we probably want an option to have an authentication mechanism invoked when the caller appears to be not authenticated. We might use our experience with the @RolesAllowed interpretation in MP/JWT there.
Ultimately it may be possible to replace @Stateless with a stereotype that includes a bunch of other relevant interceptor annotations to get the same behaviour as a Stateless EJB on a CDI bean.
A partial, or even complete EJB-Lite "emulation" that way is an option too. I happened to do a PoC of exactly that here: https://github.com/omnifaces/omnibeans
Kind regards,Arjan Tijms
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
--
Thanks
Emily
_______________________________________________ jakartaee-platform-dev mailing list jakartaee-platform-dev@xxxxxxxxxxx To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev