[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [jakarta.ee-community] @DataSourceDefinition
|
Thanks for bringing this here and out of Twitter limbo. This is actually bigger than just data source. All resource definitions need this capability. In addition we need a unified strategy to manage "stages". Today we have disjointed and underspecified efforts in CDI and JSF. This is one of the things I had long hoped the original proposal for the configuration JSR would address properly. It hasn't happened yet sadly.
Can this finally be fixed with Jakarata EE?
Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone
-------- Original message --------
From: arjan tijms <arjan.tijms@xxxxxxxxx>
Date: 6/19/18 4:12 PM (GMT-05:00)
To: Jakarta EE community discussions <jakarta.ee-community@xxxxxxxxxxx>
Subject: [jakarta.ee-community] @DataSourceDefinition
Hi,
As suggested by Reza, a continuation of
https://twitter.com/fe_amoraes/status/1004184072795586560
There's a couple of things that were being discussed there, but configurability of the annotation was the prime concern.
Mark Struberg additionally remarked several aspects where underspecified.
It was mentioned that Payara and JBoss/WildFly already support placeholders inside the @DataSourceDefinition annotation and XML variant. Liberty doesn't support that yet, but appeared to be interested.
Together with a concept of "stage", to select between known in-archive config sets, the ability to provide an external config set, additionally password-aliasing, and finally the ability to replace a data source fully via server mechanisms (admin console, etc) it's possible to setup a quite comprehensive and workable system.
However, none of that is standardised yet.
Specifically the fact that @DataSourceDefinition does not distinguish between properties intended for the pool and and properties intended for the data source itself, can be troublesome.
Maybe it would be an idea if @DataSourceDefinition (or a modern replacement thereof) moved to the JPA spec, to that a more consistent trio of connection pool, data source and persistence unit can be easily defined.
Kind regards,
Arjan Tijms
