<data-source> in persistence.xml

[gavinking]

This changeset realizes the idea proposed in #864, namely, that it should be possible to declare and configure a DataSource in the persistence xml file.

For example:

    <data-source name="jdbc/library">
        <description>My example persistence datasource</description>
        <class-name>org.postgresql.Driver</class-name>
        <url>jdbc:postgresql://localhost/library</url>
        <user>gavin</user>
        <password>p0ny</password>
        <isolation-level>TRANSACTION_READ_COMMITTED</isolation-level>
        <max-pool-size>100</max-pool-size>
        <max-idle-time>10000</max-idle-time>
    </data-source>

Or:

    <persistence-unit name="Library" transaction-type="JTA">
        <description>My example persistence unit</description>
        <data-source>
            <description>My example persistence datasource</description>
            <class-name>org.postgresql.Driver</class-name>
            <url>jdbc:postgresql://localhost/library</url>
            <user>gavin</user>
            <password>p0ny</password>
            <isolation-level>TRANSACTION_READ_COMMITTED</isolation-level>
            <max-pool-size>100</max-pool-size>
            <max-idle-time>10000</max-idle-time>
        </data-source>
        <class>org.example.Book</class>
        <class>org.example.Author</class>
        <class>org.example.Publisher</class>
        <exclude-unlisted-classes/>
        <shared-cache-mode>ENABLE_SELECTIVE</shared-cache-mode>
    </persistence-unit>

[marko-bekhta]

added a few questions inline 🙂

[marko-bekhta]

what would happen if one passes any of the "predefined" properties through the properties element instead ?

[gavinking]

The exact same thing that happens as if you used @DataSrouceDefinition.

[marko-bekhta]

oh right, so we have some precedence expectations here, should we add the case from above for the predefined property ?

[gavinking]

As I said: I am reallly trying hard not to diverge from existing semantics of things that already exist.

I am aware that the existing semantics probably kinda blow. But it would be worse to deviate from them.

[marko-bekhta]

implementation vs vendor specific -- if I understand you correctly here, implementation is about the Jakarta Persistence implementation and vendor is about the database behind the datasource, so maybe it's worth to be more specific here so there's no possible confusion 🙂

[gavinking]

if I understand you correctly here

It's not me you're trying to understand. I copy/pasted all that text verbatim.

[marko-bekhta]

the way the persistence element is defined (a sequence) it would mean that it's any number of datasources followed by any number of persistence units (since sequence does not allow random order of elements)

[gavinking]

Yeah actually I dislike how everything in persistence.xml has a defined order, even though no such natural order exists. The order is not semantically meaningful nor relevant.

[marko-bekhta]

I think this complex type is reused for top level and for the PU child element, and for the PU we later have

datasource may be declared as a child of the persistence-unit element, in
which case it may or may not be bound to JNDI

soo should we be saying that DataSource to be registered with JNDI ?

[gavinking]

For reasons explained in the issue, I have removed the proposal for a DataSourceConfiguration object from this proposal.

[gavinking]

@scottmarlow @starksm64 @bstansberry I know we have already discussed this via email, but is there anything you would like to add here, or should I just move forward with this?

@njr-11 Anything to say from the Liberty side?

[njr-11]

@njr-11 Anything to say from the Liberty side?

I'm not in favor of duplicating <data-source> into persistence.xml when we already have it in web.xml and application.xml. I don't believe it adds value on the Jakarta EE app server side, and it introduces complexity there with how this merges or overrides definitions (and annotations) of the same name that are found in the existing locations. I can also see it being a likely outcome that Jakarta EE will de-emphasize/deprecate <data-source> in favor of something better once we have Jakarta Config.

[gavinking]

I'm not in favor of duplicating <data-source> into persistence.xml when we already have it in web.xml and application.xml. I don't believe it adds value on the Jakarta EE app server side

If we consider only Jakarta EE in isolation then I agree.

The problem is that web.xml and application.xml aren't available in the Java SE standalone case, and that creates various kinds of friction for testing and other scenarios where people are using the same persistence unit both in EE and SE.

I can also see it being a likely outcome that Jakarta EE will de-emphasize/deprecate <data-source> in favor of something better once we have Jakarta Config.

That's entirely possible, but there's no guarantee that Jakarta Config—if and when it arrives—will actually address Java SE programs or be something that people will embrace for usage outside of the EE platform. (And it also implies an additional dependency.)