Repository navigation
Enable Implicit Persistence Unit from Data Source? #41
Description
Activity
Reported by reza_rahman
r_uchoa said:
I'm all in favor of a default convention. Most of the xml's configuration has been eliminated (marked as optional, that is): web.xml, ejb-jar.xml, etc.It's time for persistence.xml as well.
arjan_t said:
Good ideaTwo other things to consider:
A default persistence unit using the default data source.
If no data source is explicitly defined in the application and a persistence unit is injected, inject the default persistence unit.
Allow a data source to be defined within persistence.xml.
The rationale for the last is that increasingly a single JPA persistence unit is the only client of a data source. Especially for those new to the platform it's not always clear that a data source can be defined in web.xml, ejb-jar.xml or application.xml, but not at the location that sounds most logical, namely persistence.xml.
It may also make the connection between the data source and the persistence unit more obvious. Having the data source definition at one place and then having a persistence.xml that is nothing more than a name and a directive to auto generate the schema is not always entirely obvious.
This second point is maybe a bit the opposite of the implicit persistence unit, but hopefully still interesting enough to consider.
agoncal said:
I would like to be able to just do the following :@Tranactional public class MyService { @Inject private EntityManager em; // ... }This would inject the default datasource, without any persisntence.xml file
r_uchoa said:
Correct me if I'm wrong,But none of this would prevent the user from having to create actual data source inside the application server. There would just be a "default JNDI name" for it, thus eliminating the need for the persistence.xml file.
It this the direction we'are going?
arjan_t said:
I would like to be able to just do the following :
@Tranactional public class MyService { @Inject private EntityManager em; // ... }This would inject the default datasource, without any persisntence.xml file
This is indeed exactly what I referred to with the first point above, only I guess you mean that the default entity manager is injected and not the default data source, right?
arjan_t said:
But none of this would prevent the user from having to create actual data source inside the application server. There would just be a "default JNDI name" for it, thus eliminating the need for the persistence.xml file.
Defining a data source inside the application server is always a server specific process, and I guess by definition so is connecting the default data source's JNDI name (java:comp/DefaultDataSource) and any implicit usage of the default data source concept to any server specific data source.
In other words, I think that the Java EE spec can't say much about this, but definitely shouldn't prevent this either. It's up to a specific server what among others java:comp/DefaultDataSource exactly points to and whether it can be re-mapped at the AS side. E.g. for JBoss it's done in standalone.xml via the following tag:
<default-bindings datasource="java:jboss/datasources/ExampleDS />Other servers may or may not support this, but if they do will most likely use different syntax.
arjan_t said:
p.s. if the upcoming configuration JSR allows the element to be specified external from the application, then this would likely be an alternative for the server specific way to define a data source, but just with standardized syntax. It could be convenient then to also have a standard way to remap the default data source.reza_rahman said:
Definitely agree it should be possible to define a data source right in persistence.xml. JPA adoption seems to be going very well these days so there's no reason not to do this.This issue was imported from java.net JIRA JAVAEE_SPEC-41
With platforms like Ruby and Play! the underlying persistence engine is often automatically enabled when a data source is defined for the application (in fact these platforms often assume only one data source per application). More recently Spring Boot appears to have understandably adopted this convention as well, ironically utilizing the JPA bootstrap API. We should explore if this is the correct default convention for Java EE.
Specifically this would mean detecting an application defined data source (e.g. via @DataSourceDefinition), detecting JPA usage in the application (e.g. via entity manager injection) and auto-wiring/enabling a sensible persistence unit that the application can use as opposed to having an explicit persistence.xml for the "default case".
This particular convention can be potentially incorrect so we should weigh it carefully with community and expert group input. The problem is that as far as I have seen personally, developers often need to put in persistence.xml settings/properties for very common cases such as logging, debugging, caching and schema generation. This is particularly true during development and testing. This may mean that this particular convention may be a potential source of confusion instead of being helpful. Nonetheless, it is at least worth considering carefully and gathering feedback.
Please note that these are purely my personal views that may or may not reflect consensus at Oracle as a company.