I don’t think a JPA implementation (Hibernate, EclipseLink, etc.) could provide the same level of integration that is currently
provided today for the traditional Jakarta EE Containers (i.e., Web Container and EJB Container).
Sure, simple scenarios could probably be made to work, but Jakarta Persistence and Jakarta Persistence Implementations support many configuration options that seem to require some level of container integration.
Starting with the API the containers currently use:
EntityManagerFactory createContainerEntityManagerFactory(PersistenceUnitInfo info,
Map map)
I wonder how the JPA provider could provide an implementation that could determine the two seemingly simple parameters without a loss of function.
- PersistenceUnitInfo : the provider can parse a persistence.xml file to create one of these, but the real trick is how does the provider know how to locate
all of the persistence.xml files? The Jakara Persistence specification has very specific rules where persistence.xml files may be located within an EAR or WAR, which a provider could seemly implement… but what if a vendor wishes to
explode an EAR on disk when deploying an application; would a provider be expected to support the fact the files are not JAR’d into an EAR any longer at runtime?
The specification specifically supports this by providing PersistenceUnitInfo.getJarFileUrls(), and since the container is in control, it has the flexibility to place the application on disk however it chooses. Or would vendors just no longer be able
to provide this feature to their customers starting with Jakarta EE 11.
I guess more specifically, this would just not work with CDI @Inject.
PersistenceUnitInfo.getNewTempClassLoader() – How would the provider provide an implementation of this; only the container would know how to properly create a temporary classloader that can be used during bytcode modification (though perhaps no JPA providers
actually use this, and we should eliminate this method?)
PersistenceUnitInfo.getJtaDataSource()/getNonJTADatasource() – seems a provider could look this up?? But it is not quite that simple.
JPA has some bootstrapping issues around this… creation of
EntityManagorFactory instances must be done very early so that the JPA provider can register class transformers, however, that generally must be done so early that the JNDI names spaces haven’t been fully determined, especially for
java:comp. To accommodate this, container vendor must use “deferral” tricks to provide usable
datasources at a later time; I don’t expect that a JPA Implementation will be able to handle this.
Perhaps when using CDI @Inject, the specification could just indicate that
java:comp datasource references cannot be used?
Properties Map : Here are things a container/vendor may include :
- BeanManager : perhaps this is an easy one for modern EE APIs to provide
- ValidatorFactory : how would the Jakarta Persistence provide obtain the one provided by the container? The Jakarta Specification has different rules for when running in Java SE vs Jakarta EE. This is optional, so there may be container
vendor specific configuration options on when to make this available; how would a JPA implementation know that?
- TransactionManager : perhaps an old API vs new API thing, but in the past each vendor had different ways of obtaining this.
- Other container/vendor specific properties.
Container/Vendors may include various properties to control the default behavior when using their product… do they just lose this level of control?
For example, open-liberty configuration provides a way to configure enabling trace, and when that is specified, the container will pass through properties to the JPA provider to control that trace, so it is enabled appropriately and ends up in the same
trace logs as the rest of the product. How could this be achieved if the container is not the one creating the EntityManagerFactory?
- Customer configurable options – a container vendor may provide a configuration option to allow customers to specify any properties they want to be passed here in addition to
all of the above?
Would there be a new SPI to allow containers to continue to provide that set of properties to the JPA Provider?
Or a loss of vendor specific value add.
Finally, I guess I am not familiar with the requirement for there to be a “default” persistence unit, however, when a container supports multiple JPA implementation concurrently, then I expect it would be the container that would know which one is the default.
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: jpa-dev <jpa-dev-bounces@xxxxxxxxxxx>
On Behalf Of Arjan Tijms via jpa-dev
Sent: Thursday, November 2, 2023 1:15 PM
To: Scott Marlow <smarlow@xxxxxxxxxx>
Cc: Arjan Tijms <arjan.tijms@xxxxxxxxxxx>; jpa developer discussions <jpa-dev@xxxxxxxxxxx>
Subject: [EXTERNAL] Re: [jpa-dev] Jakarta Persistence container responsibilities and impact on management of a transaction-scoped persistence context...
Hi, On Wed, 1 Nov 2023 at 21: 04, Scott Marlow <smarlow@ redhat. com> wrote: For example, the first container rule described in [2] states: " The container creates
a new entity manager by calling EntityManagerFactory. createEntityManager
For example, the first container rule described in [2] states:
"
The container creates a new entity manager by calling EntityManagerFactory.createEntityManager when the first invocation of an entity manager with
PersistenceContextType.TRANSACTION occurs within the scope of a business method executing in the JTA transaction.
"
While the above rule applies to EJBs, it also applies to other components as well. It is not a difficult rule to implement but still it is the responsibility of the EE/Persistence container to perform. If an EE implementation does not
do this then the application would have to call joinTransaction() but shouldn't have to.
There might be a small confusion here.
In [1] it wasn't a question about whether the EntityManager was container managed or not. That is absolutely clear. It should be managed. The application doesn't need to call joinTransaction() or anything like that.
The question is just whether the responsibility of managing it should be with the application server code (Jakarta EE implementation / runtime, such as WildFly or GlassFish) or the Jakarta Persistence implementation code (Hibernate, OpenJPA,
EclipseLink etc).
I think placing the implementation code in the application server is historial; the APIs to manage the entity manager as per the contract weren't available then. Today Hibernate etc would be able to do this too using modern EE APIs.
