Re: [jakartaee-platform-dev] Retire EJB-Lite from web profile?

[Emily Jiang <emijiang6@xxxxxxxxxxxxxx>]

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.

Thanks

Emily

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