Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakartaee-platform-dev] Retire EJB-Lite from web profile?

My 2cts would be that not multiplying profiles is good and web profile was targetting standard http+persistence apps so it makes sense to drop ejblite from there since it is no more the recommended way (jta fully replaced it for WP target, rest of EJB is useless for that target).

Not removing legacy specs also means profiles keep growing so at some point must be replaced by another one and so on. It does not work well in time and for consumers (libs, apps) to pick a sane stack for them IMHO.

So whatever EJB is kept or not there is space for some homework anyway on profiles and more projections on their future shape IMHO.

Le ven. 12 août 2022 à 20:25, David Blevins <dblevins@xxxxxxxxxxxxx> a écrit :
On Aug 12, 2022, at 6:54 AM, Steve Millidge (Payara) <steve.millidge@xxxxxxxxxxx> wrote:

We have Core profile where implementations are free to ship Core profile(+) if they want to have a Jakarta EE compatible “legacy free” runtime.


Exactly.  I'm not sure what problem we're solving that isn't already solved by the Core Profile and the ability to add on top.  One could argue we should actually encourage implementations to use the Core Profile for exactly this kind of pursuit -- that is what it's for.

Btw I don’t agree with the messaging that EJB is legacy as there is no current replacement. Jakarta EE developers out there are still building new applications using @Stateless as it just works and is simpler than the current alternative.  I agree CDI needs to become the foundational “bean” component for the platform but it isn’t there yet.


Also completely agree.  We see many people using @Stateless, @Schedule, @Startup as well as the remote capabilities (though not part of EJB-lite).  There is no equivalent in other specs.


My likely less popular opinion is that since this topic always finds its way to listing functionality EJB provides that we should keep and get working on CDI, it does somewhat validate that much of what EJB provides is valid and we do want/like the functionality, we just don't like the brand.

Here's our current status:

 - We don't legally have an EJB spec to remove, we have Jakarta Enterprise Beans
 - Every Jakarta EE release has featured us removing something from Jakarta Enterprise Beans (CMP/BMP, CORBA, legacy Home/Remote interfaces, JAX-RPC ties, use of deprecated Security APIs, etc)

The only thing left is the good stuff and that good stuff isn't legally "EJB".  How much work do we want to put into moving the good stuff into yet another spec not called EJB?

If we want the good stuff to also work on CDI, let's do that and make this easy on ourselves.


-David



_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev

Back to the top