|
Password aliasing was dropped due to lack of time/resources. It's
another thing that should be solved with Jakarta EE.
On 6/20/2018 4:15 PM, Guillermo
González de Agüero wrote:
arjan
tijms wrote on 06/20/18 09:05 AM:
> Hi,
>
> There's not necessarily a problem with
@DataSourceDefinition being in the
> Common Annotations spec, although there is the
mentioned issue with
> configurability and the generic attributes that the
@DataSourceDefinition
> takes without specifying whether and how they should go
to the pool vs the
> data source.
Some of this is unspecified or weakly specified because
there was no agreement
among vendors as to how it should work.
>
> I'm a great fan of @DataSourceDefinition, but it has
always been a bit of an
> issue that it essentially merges two other concepts in
one; the data source
> and the connection pool. Many other proprietary
mechanisms (like for example
> GlassFish) have two separate definitions for that.
It's always seemed like a feature to me that you only have
to deal with one
concept instead of two.
I'm with you. I have always used the GlassFish connection
pool+resource with a 1:1 relationship.
>
> Additionally, a small data storage spec might be
orthogonal to the
> requirements of evolving @DataSourceDefinition, but
these two efforts might be
> combined. Although it's just a proposal, I was half
thinking about a
> replacement @DataSourceDefinition that does have the
separate pool and data
> source concept, together with an actual available
(embedded) database. As you
> know all too well (you closed my issue for it back then
:P) Java EE doesn't
> really have a runtime available database, even though
it's generally thought
> it has one.
I'm not sure what you're referring to since Java EE has
always required that a
database be part of every configuration. We can't guarantee
that the database
server is up, that the network cable is connected, the disk
isn't full, etc.,
but it has to be possible for the customer to address all
these "availability"
problems and then use the database.
>
> At the same time, our friends from Apache/TomEE, Mark
Struberg and Romain,
> have been crying for over a decade now that
@DataSourceDefinition is
> absolutely bad and can't be used for anything. While I
respectfully disagree
> with that (we've used @DataSourceDefinition for tons of
real life projects),
> it might be interesting to finally get to the bottom of
what these two are
> actually complaining about, and see if we can address
that.
If they've been standing on the street corner and shouting
into the wind, I
haven't heard it. If there are real issues, I very much
would like to hear them
and hopefully they can be addressed in Jakarta EE.
The addition of the Config API to Jakarta EE would help us
address many of these
issues.
_______________________________________________
jakarta.ee-community mailing list
jakarta.ee-community@xxxxxxxxxxx
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jakarta.ee-community
_______________________________________________
jakarta.ee-community mailing list
jakarta.ee-community@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jakarta.ee-community
|
