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

[arjan tijms <arjan.tijms@xxxxxxxxx>]

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