Sure. My main concern is that duplicating the same features with different specs. As we did the same fault in CDI (Every spec started to provide its own annotations as JSF is one of them via MaangedBeans...)
It is logical to remove EJB lite and replacing with CU.
Gurkan
Hi Gurkan, But Jakarta Concurrency provides a bunch of basic capabilities that can be used by other specs in the platform so for example we could have 1 @Asynchronous annotation that could be reused and deprecate the others. Also asynch processing in other specs could be redefined to utilise the underlying user defined ThreadFactory, ManagedExecutors etc. Adding Jakarta Concurrency to Web Profile could then enable removal of EJB lite if desired. I think this would make the platform more unified. Steve From: cu-dev <cu-dev-bounces@xxxxxxxxxxx> On Behalf Of Gurkan Erdogdu Sent: 22 April 2021 10:46 To: cu developer discussions <cu-dev@xxxxxxxxxxx> Subject: Re: [cu-dev] Thoughts on attempting to move Jakarta Concurrency into Web Profile. Hi Steve I am not favor of adding another spec to Web or Core profile. It already includes EJB lite container which provides the similar features. For me, we can even remove the EJB lite from web profile.
I’m thinking of raising an issue on the platform project to get Jakarta Concurrency included in the Web Profile for Jakarta EE 10 and maybe also Core Profile if it is available in EE10 timeframe. First I’m not sure why it isn’t there now as it is pretty principle and therefore would be of benefit to “Web” applications and REST services. Second some of the things we are proposing could then be usable by other specifications @Asynchronous, @Lock and @Schedule Third it would then pave the way of providing some of the capabilities of Session Beans to all CDI beans and therefore driving @Stateless to be more of a stereotype.
_______________________________________________cu-dev mailing listcu-dev@xxxxxxxxxxxTo unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cu-dev
|