| Re: [jakartaee-platform-dev] Retire EJB-Lite from web profile? |
Hi all,
Think the key point is to deprecate in next release(s) considering the side effects (impacts on other specs) at platform level.For the "missing features" the trend is to not use EJB anymore and there is no real feature which are missing these days (thanks a lot of causes like last JRE API additions). Pool is one good example - and microprofile proved it - it replaces concurrency handling as well as resource creation optimization/control so I guess this is not something desired "as this" anywhere else plus it is quite trivial to implement it with a plain JRE so it does not solve an user issue *anymore* so maybe just drop it after some deprecation time which would enable to identify something really needed if any and missed?
That is fine but there may be missing features that just aren't
known that they are missing yet, like the Jakarta Persistence
extended persistence context feature that I already mentioned.
I'm sure that some applications can use application-managed
persistence contexts instead of extended persistence context but
there is a learning curve to ensuring that application-managed
persistence contexts are not invoked from more than one thread at
a time (that could be dealt with via new Persistence SPEC changes
but the point is that other SPECs need to change also).
Le mar. 9 août 2022 à 15:17, Scott Marlow <smarlow@xxxxxxxxxx> a écrit :
_______________________________________________In case it helps others, a recent description of what is included in EJB-Lite is here.
On 8/9/22 4:19 AM, Emily Jiang via jakartaee-platform-dev wrote:
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
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
_______________________________________________ jakartaee-platform-dev mailing list jakartaee-platform-dev@xxxxxxxxxxx To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev