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.
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
