[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [jakartaee-platform-dev] [External] : Re: [cdi-dev] Discussion: The new structure of EE integration sections
|
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$
