Community
Participate
Working Groups
Gemini JPA allows to configure an EMF using JDBC connection properties only. in some cases, however, it wouldbe preferable to pass in a preconfigured data source. I am suggesting to accept a data source using the standardized property javax.persistence.nonJtaDataSource. E.g. DataSource dataSource = ... EntityManagerFactoryBuilder emfBuilder = ... Properties props = new Properties(); props.put("javax.persistence.nonJtaDataSource", dataSource); [...] EntityManagerFactory emf = emfBuilder.createEntityManagerFactory(props); (A challenge could be to correctly track the life cylce of the data source).
I actually don't believe any longer that Gemini JPA would need to track the life cycle of a data source handed in to the EMFBuilder.createEMF method (as proposed above): The JPA Service Specification (OSGi Enterprise 4.2) Demands that the life cycle of the data source factory must be tracked for EMFs registered for complete persistence units (§127.4.7). But in the case of the EMFBuilder.createEMF method beeing used, the persistence unit would be incomplete and the hence Gemini JPA would not need to track the data source factory. So tracking the life cycle of the data source and hence of the EMF created by the EMFBuilder.createEMF methd would we the task of the caller of this method.
Created attachment 196630 [details] patch proposal I have created a patch that implements Adrian's proposal and also includes the test for this case.
Hoping to see this in 1.0.
Sure, as long as people are okay with the caveats to this feature: The usual JDBC prop checking that EMFBuilder does against successive createEMF calls is not going to happen if no properties are passed in. This means that one could potentially make a first call and pass in a data source, then make a second call and pass in an entirely differently configured data source and the second call will appear to work even though it is using the first data source. (This case is supposed to fail.) The reverse may also be true (although much less likely), that if the properties exist and do not equal each other the second call will fail even though the data sources passed in were exactly the same on both calls. (One could easily argue that this should be an error in any case.) The data source tracking is entirely up to the caller since the caller is assuming the responsibility of obtaining and passing it in. The flip side is that there is no graceful way for Gemini JPA to stop providing the EMF service should the data source go away, since it has no way to discover or determine its disappearance. In any case, thanks for the suggestions. I have merged in some changes, including the attached contribution.
Added in RC2
Marking as fixed
