Allow two phase bootstrap approach to creating the EntityManagerFactory

[lukasj]

Introduce a standard two phase persistence unit bootstrap and require that certain services are not accessed until the second phase. This will improve how JPA/CDI + JPA/@DataSourceDefinition work together.

In a perfect world, the first persistence unit bootstrap phase should not use the datasource or the CDI bean manager (instead wait for the second phase). Class enhancing/rewriting should also occur in the first phase (before application classes have been read).

This will help avoid use of the CDI bean manager too early (which otherwise can cause application entity classes to be loaded before they are enhanced/rewritten).

This will help avoid use of a datasource that is being deployed with the application (@DataSourceDefinition) but may not be available for use yet.

Also see discussion at https://java.net/projects/jpa-spec/lists/jsr338-experts/archive/2013-06/message/0.

[lukasj]

• Issue Imported From: https://github.com/javaee/jpa-spec/issues/70
• Original Issue Raised By:@glassfishrobot
• Original Issue Assigned To: Unassigned

[lukasj]

@glassfishrobot Commented Reported by smarlow

[lukasj]

@glassfishrobot Commented @arjantijms said: +1!

This will also help or even be the solution for JAVAEE_SPEC-30

One question though; the two phases are thus needed for @DataSourceDefinition, but what about data sources that are defined in web.xml, ejb-jar.xml or application.xml.

Can't they be scanned and processed first without requiring the two phases?

[lukasj]

@glassfishrobot Commented smarlow said:

One question though; the two phases are thus needed for @DataSourceDefinition, but what about data sources that are defined in web.xml, ejb-jar.xml or application.xml.

Data sources that are defined in web.xml, ebj-jar.xml or application.xml should also benefit by the change to bootstrap the persistence unit via two phases.

Can't they be scanned and processed first without requiring the two phases?

It will vary between application server implementations, when the data sources are available. On application servers that can start the data source earlier, supporting the two-phase pu bootstrap will also improve CDI injection in entity listeners (creating the bean manager will not prevent entity class enhancement).

[lukasj]

@glassfishrobot Commented This issue was imported from java.net JIRA JPA_SPEC-70

[gavinking]

@scottmarlow what is the status of this issue? Is it still relevant?

[scottmarlow]

@scottmarlow what is the status of this issue? Is it still relevant?

WildFly + Hibernate implementations have already solved this. I think we could close this and reopen it if other implementations are still interested in having a standard way for bytecode enhancement to work consistently without contending with the CDI need to rewrite application classes.

WebSphere/WebLogic teams expressed interested years ago (just missed the JPA 2.1 release train in 2013) but I haven't heard any feedback recently.

@lukasj @Emily-Jiang have either of you heard any recent feedback on whether this issue is still relevant?

[gavinking]

@scottmarlow I would love to hear what you think of the discussion on #460, which seems at least vaguely related to what's described here.

So my knee-jerk is that I have a strong preference for the JPA spec to not impose requirements on the Jakarta EE container lifecycle. But I'm not a Jakarta EE container implementor, so perhaps my intuitions on this are bad ones.