Re: [jakartaee-platform-dev] : Re: [cdi-dev] Discussion: The new structu

[Ondro Mihályi <mihalyi@xxxxxxxxxxx>]

I just wanted to clarify the EJB vs. CDI relationship. The EJB spec says EJB's are "CDI-enabled". That doesn't mean they are true CDI beans. It only means that other CDI beans can be injected into EJBs and that initialization methods like @PostConstruct should be called after injection completes. See https://jakarta.ee/specifications/cdi/4.0/jakarta-cdi-spec-4.0#fields_initializer_methods_ee

EJBs have to be turned into true CDI beans, then it's possible to get rid of the EJB specification, or simplify it to just define extensions over core CDI to keep the EJB functionality for backwards compatibility (e.g. Stateless as a stereotype)

Ondro

On Mon, Dec 11, 2023 at 3:17 PM Arjan Tijms via jakartaee-platform-dev <jakartaee-platform-dev@xxxxxxxxxxx> wrote:

Hi,

On Tue, 21 Nov 2023 at 23:04, Tracy Burroughs <tkb@xxxxxxxxxx> wrote:

Regarding Option 3:

3.  Fold Interceptors as we have it today into CDI, then rebase EJB formally on CDI (state in the spec that every Enterprise Bean not just integrates with CDI, but *IS* a CDI Bean). Prune the existing Interceptors.

The EJB specification already states that EJBs are CDI beans in EJB section 2.8:
https://jakarta.ee/specifications/enterprise-beans/4.0/jakarta-enterprise-beans-spec-core-4.0#a195

I wonder if we don't still need to take this a step further. If they were truly *real* CDI beans with features added solely via things like CDI Extensions, we could do away with for instance https://jakarta.ee/specifications/enterprise-beans/4.0/jakarta-enterprise-beans-spec-core-4.0#a2004

As CDI beans already detail how to integrate with Interceptors, and if EJB beans would be fully CDI beans, we don't need that chapter, do we?

However, my take is that the point of option 3 is to recommend we prune some of the legacy EJB features where duplicate or improved capabilities exist in CDI.  This would indeed reduce and simplify some of the Jakarta EE Specifications, though would prevent many older applications from moving forward without significant changes.

+1 for that.

Kind regards,

Arjan Tijms

 

Tracy Burroughs  (tkb@xxxxxxxxxx)

WebSphere Application Server Development

IBM Rochester, Dept AAW, Bldg H315/050-2

2800 37th Street NW, Rochester MN 55901-4441

 

From: jakartaee-platform-dev <jakartaee-platform-dev-bounces@xxxxxxxxxxx> On Behalf Of Arjan Tijms via jakartaee-platform-dev
Sent: Tuesday, November 21, 2023 7:09 AM
To: jakartaee-platform developer discussions <jakartaee-platform-dev@xxxxxxxxxxx>
Cc: Arjan Tijms <arjan.tijms@xxxxxxxxxxx>
Subject: Re: [jakartaee-platform-dev] [External] : Re: [cdi-dev] Discussion: The new structure of EE integration sections

 

On Tue, 21 Nov 2023 at 08: 45, Ladislav Thon via jakartaee-platform-dev <jakartaee-platform-dev@ eclipse. org> wrote: There are a few specifications that are even more fundamental than CDI: Common Annotations, Dependency Injection (part

 

 

On Tue, 21 Nov 2023 at 08:45, Ladislav Thon via jakartaee-platform-dev <jakartaee-platform-dev@xxxxxxxxxxx> wrote:

There are a few specifications that are even more fundamental than CDI: Common Annotations, Dependency Injection (part of the CDI project), Interceptors. (To be honest, the Interceptors spec, having to serve both CDI and EJB, is a strange beast and doesn't really serve CDI very well. If I could, I would fold it into CDI.)

 

 

 Absolutely, I started a discussion about doing exactly this some time ago.

 

There's a couple of options we could consider:

 

1. Fold Interceptors as we have it today into CDI, keep the existing Interceptors around as legacy for EJB

2. Fold Interceptors as we have it today into CDI, also fold it into EJB. Prune the existing Interceptors 

3.  Fold Interceptors as we have it today into CDI, then rebase EJB formally on CDI (state in the spec that every Enterprise Bean not just integrates with CDI, but *IS* a CDI Bean). Prune the existing Interceptors.

 

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