Jakarta data provider configurable through properties or server.xml

[vincent-nagy]

Describe the use case that you want to enable:
Currently it is only possible to configure jakarta data provider specific properties through a persistence.xml. An example is eclipselink.jdbc.batch-writing. While it is possible to point the @repository to a persistence unit, it is undesirable clutter. This should be configurable using a microprofile property or in the server.xml

Describe why this is important to you:
The value of this proposition is a cleaner codebase where repetition is reduced since every repository needs to be configured to point to the same persistence unit. The configuration is extracted from the code and is centralised with other configuration.

Additional context
The current workaround is documented at https://openliberty.io/docs/latest/data-store-configuration.html#elpersistence

[njr-11]

This aligns with what I would like to see as a future direction for Jakarta Data where the Jakarta Data specification would standardize the use of Jakarta Config (expected to be the largely identical Jakarta EE equivalent of MicroProfile Config) to map repositories to configuration that would be an alternative to persistence.xml. The application would only need to define repositories and Jakarta Config properties would take care of everything else. Unfortunately, Jakarta Config has not yet been included as Jakarta Platform/web profile specification, so this is delayed.

It was discussed within the Jakarta Data specification group whether to standardize the use of MicroProfile config in the interim, but some specification participants had concerns over Jakarta EE depending on a MicroProfile specification when currently dependencies are in the other direction with MicroProfile depending on Jakarta EE. Other participants had concerns about the possibility that a future Jakarta Config would not be configured fully identically to MicroProfile config, leading to version to version incompatibility across specification levels. Given this outcome, the Open Liberty development team felt that in the long term it would be confusing to introduce our own set of MicroProfile config properties for Jakarta Data ahead of standardization.

In addition to the current approach of configuring a persistence unit reference (in Data 1.1, this is being simplified to additionally allow the use of a persistence unit name without a reference), Open Liberty in the interim allows repositories to point at the id of a databaseStore config element that offers a small subset of capability of persistence.xml including createTables and dropTables:
https://openliberty.io/docs/latest/data-store-configuration.html#databasestore

Regarding future standardization of config properties within the Jakarta Data specification, we would definitely welcome your feedback on what you would like to see the config properties look like once this becomes possible to add to the specification.

[vincent-nagy]

Thanks for the explanation, it seems this will be addressed in the future and the in between step of only providing a persistence unit name will already be an improvement.

Since most of the properties are related to the provider, i would expect them to be structured as such:

jakarta.data.provider=eclipselink
jakarta.data.provider.eclipselink.jdbc.batch-writing=JDBC
jakarta.data.provider.eclipselink.jdbc.batch-writing.size=100
jakarta.data.provider.eclipselink.logging.level.sql=FINE
jakarta.data.provider.eclipselink.logging.parameters=true