I don't think CDI "suffers" from the problem. I'd rather say CDI avoids this problem altogether. CDI is initialized from the web container. The web container sets java:comp per web application
(or, for the one and only application in various EE runtimes). And that's it.
Every CDI bean has access to the one and only java:comp namespace in the application it's a part of, exactly because of what you say; it simply runs in the context of the web container.
Those are the basic, and perhaps most common scenarios for CDI.
However, CDI beans may be defined in EJB Jar files, Library files, and WAR files. If a CDI bean is injected into an EJB, and if that CDI bean uses `@Resource` to inject a resource ref from `jav:comp/env` then what is injected is based on the java:comp
of that EJB. EAR files may also include multiple WAR files. So, even though WAR files have a single `java:comp`, an application may still have multiple `java:comp` name spaces even without EJB.
The CDI bean would need to use the `java:comp` for whichever WAR it was being used from.
As long as the Jakarta EE Platform continues to support EAR files with multiple modules, there will be multiple java:module and java:comp name spaces per application.
CDI does and will need to continue supporting the various namespaces.
Maybe look at Jakarta Faces as a reference. How is Jakarta Faces able to use "java:comp/ValidatorFactory" without Jakarta Faces or CDI needing to indicate anything to the Container to make “java:comp” available?
There are some things in java:comp, such as ValidatorFactory that will be common for all java:comp name spaces.
For these well-defined bindings, yes, an implementation such as for Jakarta Faces may take advantage of that,
as long as they don’t need to access java:comp during application start.
However, there are other thing in java:comp, such as java:comp/UserTransaction, which will not be consistently available in all
java:comp namespaces.
My bigger concern with using java:comp in JPA is that it likely will not be available to JPA implementations during application start.
The JPA implementation must be called very early during application start, prior to any application classes being loaded,
in order to allow the JPA implementation to register class transformers.
Once a class is loaded it cannot be transformed. Today, Jakarta EE Container implementation may load application classes to look for injection annotations, such as `@Resoruce` to determine how to create java:comp namespaces (i.e., all `@Resrouce`, `@EJB`,
`@PersistenceContext`, etc. annotations are bound in `java:comp`).
Thus, it may be quite common that java:comp namespaces for an application have not been created prior to calling JPA to start an application.
Am I saying that a JPA implementation cannot use things like “java:comp/ValidatorFactory”… No, I’m saying we could change the JPA specification to allow and or even require this…
as long as it is not done during application start.
However, I’m not sure such a change is useful.
When the Container starts JPA, it passes many things… so if we remove ValidatorFactory and BeanManager and indicate the JPA implementation should obtain those from java:comp (at a later time), that doesn’t really change the fact that
there are many other things the Container passes that are not available in java:comp.
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: Arjan Tijms <arjan.tijms@xxxxxxxxxxx>
Sent: Tuesday, November 21, 2023 5:14 PM
To: Tracy Burroughs <tkb@xxxxxxxxxx>
Cc: jpa developer discussions <jpa-dev@xxxxxxxxxxx>; Scott Marlow <smarlow@xxxxxxxxxx>; Emily Jiang <emijiang6@xxxxxxxxxxxxxx>
Subject: [EXTERNAL] Re: [jpa-dev] Jakarta Persistence container responsibilities and impact on management of a transaction-scoped persistence context...
Hi, On Tue, 21 Nov 2023 at 21: 52, Tracy Burroughs <tkb@ us. ibm. com> wrote: However, during application start when all the PersistenceUnits are being processed….
which java: comp JNDI name context is used? Do we really need to obtain the
However, during application start when all the PersistenceUnits are being processed…. which java:comp JNDI name context is used?
Do we really need to obtain the validation factory at that point in time?
Per the Jakarta EE specification, every EJB has a different “java:comp” JNDI context, and different things may be bound into each.
Maybe one extra reason to abandon classic EJB as soon as possible, and/or rebase it on CDI? Quite a number of problems that we have seem to center around the existence of EJB and a number of its archaic programming constructs.
Similarly, CDI suffers from the same problem. CDI beans are not defined as Jakarta EE Components in the Platform specification, at least not like servlets and EJBs. That is, CDI bean
do not have a defined “java:comp” JNDI context. Instead, CDI bean just happen to always run in the context of either a servlet or EJB, so either the Web Container or EJB Container will have established a “java:comp”
that CDI can access.
I don't think CDI "suffers" from the problem. I'd rather say CDI avoids this problem altogether. CDI is initialized from the web container. The web container sets java:comp per web application (or, for the one and only application in various
EE runtimes). And that's it.
Every CDI bean has access to the one and only java:comp namespace in the application it's a part of, exactly because of what you say; it simply runs in the context of the web container.
Since we are discussing the integration of CDI and Jakarta Persistence, it seems rather odd to rely on “java:comp”, which isn’t defined for either. I’m not saying it wouldn’t work,
but if we were to go with this approach, then the two specifications (and perhaps the Platform specification) should be updated to indicate that the “Container” needs to make some “java:comp” JNDI context available to CDI and Persistence during application
start, and what needs to be available in that context.
We do indeed need a better specification of ordering and how everything in Jakarta EE starts up, including the web container, CDI, Jakarta Persistence and various other things. But I don't think CDI or Jakarta Persistence have to be updated
specifically here.
Maybe look at Jakarta Faces as a reference. How is Jakarta Faces able to use "java:comp/ValidatorFactory" without Jakarta Faces or CDI needing to indicate anything to the Container to make “java:comp” available?
