Re: [jakartaee-platform-dev] [External] : Re: [cdi-dev] Discussion: The

[Ondro Mihályi <mihalyi@xxxxxxxxxxx>]

Hi

> and if:

> @Inject EntityManager em

> and this is something 
> where persistence spec - or better 

> persistence providers as such cannot 
> do much.

The persistence spec could simply require providers to implement a CDI producer for EM, would that be a problem? 

On platform level, servers could override the producer and inject an EM provided by the server. 

Thr whole problem is that the Platform spec doesn’t cover these integration points well, not with spec wording and certainly not with TCK. That’s why I think it’s better to have this directly in individual specs like Persistence. We did it in JTA with @Transactional, in concurrency with the @Asynchronous interceptor, I don’t see why other specs can’t do that too.

But the main point in this thread is to move things that are nit core DI to be outside of the core CDI spec. CDI is already so much more than plain DI, with interceptors, events, etc. But it definitely shouldn’t define which resources are injected (e.g. HTTP request or EM). In my opinion, even having Request and Session scope in CDI is wrong, they should have been in Servlet spec.

Ondro

On Mon, 20 Nov 2023 at 23:44, Lukas Jungmann via jakartaee-platform-dev <jakartaee-platform-dev@xxxxxxxxxxx> wrote:

On 17.11.2023 20:05, Arjan Tijms via jakartaee-platform-dev wrote:
>
>
> On Fri, 17 Nov 2023 at 18:30, Scott Stark via jakartaee-platform-dev
> <jakartaee-platform-dev@xxxxxxxxxxx
> <mailto:jakartaee-platform-dev@xxxxxxxxxxx>> wrote:
>
>     The problem has been that components specs do not want to do this.
>     JPA does not want to do it.
>
>
> How does that work with Jakarta Persistence already doing it?
>
> https://jakarta.ee/specifications/persistence/3.1/jakarta-persistence-spec-3.1#entity-listeners <https://urldefense.com/v3/__https://jakarta.ee/specifications/persistence/3.1/jakarta-persistence-spec-3.1*entity-listeners__;Iw!!ACWV5N9M2RV99hQ!IWjFVd9CTkciAETfu5YyxF_OdlOBcg50-1ycveap7UI4QpsdK0kT3gx1PffGqVEEEMYVc5X15ZOGpQKpi_K4JQAdD_IS2VYc$>
>
> Has everyone simply forgotten Jakarta Persistence already depends on /
> uses CDI, or am I missing something?

Let me share my point of view on this:


Why is this dependency there and it is written the way it is? I have to
admit that I wasn't on the persistence spec in 2.1/EE7 time frame, so I
may easily be wrong - feel free to correct me. My understanding so far
is that EntityListeners (and AttributeConverters) are components managed
by Persistence providers from the very beginning of their existence and
since it is persistence providers' responsibility to fully manage the
lifecycle of these components, it is obvious that the only one, who can
perform injection into these components, is the persistence provider.
OTOH EMF (and EM) are - from the persistence spec point of view -
components fully managed by 3rd party - that can be user (app managed),
EE/some runtime (container managed), cdi managed (? - why cannot be CDI
treated as another type of a "container"/"runtime" and provide already
defined container managed EMFs/EMs?)

When going through the Persistence spec more carefully, on can observe
that sections about entitylisteners and attributeconverters are the only
ones in the persistence spec being explicit about CDI, even the
algorithm to perform the injection is a copy of the one from the
Platform spec (section 5.24), very likely for the matter of consistency
with the platform. The rest of the spec intentionally avoids the term
CDI and uses the term Dependency Injection (DI) - ie "A
container-managed entity manager is obtained by the application through
dependency injection or through direct lookup of the entity manager in
the JNDI namespace.", so there already is a dependency on the DI. Does
that really need to be updated to CDI? Wouldn't that be an incompatible
change requiring major update? If there is anything required, can it be
done within the boundaries of DI?


Now, let's switch to the platform spec for a while and take a look at
existing section 5[1] called "Resources, Naming, and Injection":

* section 5.2.5 contains among other things:

"The component classes listed in Component classes supporting injection
with support level “Standard” all support Jakarta EE resource injection,
as well as PostConstruct and PreDestroy callbacks. In addition, if CDI
is enabled—which it is by default—these classes also support CDI
injection, as described in Support for Dependency Injection, and the use
of interceptors."

* section 5.24 is quite explicit about which component is responsible
for handling injection in the Jakarta EE compatible runtime:

"In Jakarta EE, support for dependency injection annotations as
specified in the Dependency Injection for Java specification is mediated
by CDI."

...this, I think, already connects DI from Persistence spec and the CDI
in the EE runtime

* sections 5.13 and 5.14 describe injection and overrides for
@PersistenceUnit/EMF and @PersistenceContext/EM respectively


Having gone through this, I tend to think that if:

@Inject @PersistenceContext("SomePU") EntityManager entityManager;

does not work in some existing Jakarta EE runtime, then it
either requires an update of section 5.24 of the Platform spec (+ TCK test)
or is bug in the runtime

and if:
@Inject EntityManager entityManager;

does not work, then probably section 5 needs some update explicitly
allowing and requiring this to be supported - and this is something
where persistence spec - or better persistence providers as such cannot
do much.


thanks,
--lukas


[1]:
https://jakarta.ee/specifications/platform/10/jakarta-platform-spec-10.0#a567


>
> Kind regards,
> Arjan Tijms
>
> _______________________________________________
> jakartaee-platform-dev mailing list
> jakartaee-platform-dev@xxxxxxxxxxx
> To unsubscribe from this list, visit https://urldefense.com/v3/__https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev__;!!ACWV5N9M2RV99hQ!IWjFVd9CTkciAETfu5YyxF_OdlOBcg50-1ycveap7UI4QpsdK0kT3gx1PffGqVEEEMYVc5X15ZOGpQKpi_K4JQAdD2Fcfjgc$

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