Re: [jpa-dev] Jakarta Persistence container responsibilities and impact

[Scott Marlow <smarlow@xxxxxxxxxx>]

On Tue, Nov 21, 2023 at 6:14 PM Arjan Tijms <arjan.tijms@xxxxxxxxxxx> wrote:

Hi,

On Tue, 21 Nov 2023 at 21:52, Tracy Burroughs <tkb@xxxxxxxxxx> 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 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.  

EJB components do have access to java:comp, it is other components that might not have access to java:comp.  Since passing the validation factory to the persistence provider is requirement for the platform, it doesn't matter exactly how platform implementations pass the validation factory as long as the Jakarta EE Platform implementation passes the "jakarta.persistence.validation.factory" property with the value set to the ValidatorFactory to the persistence provider as per the Persistence contract.

Scott

 

 

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?

Kind regards,

Arjan Tijms