| Re: [jakarta.ee-community] @DataSourceDefinition |
+1 There are quite a few parts of @DataSourceDefiniiton which are totally depending on the runtime requirements and thus shall not be defined inside the annotations. Actually almost all except the 'transactional' attribute. I pretty much never used it. As some feeback on twitter suggested they are using it with EL like placeholders. Well, that's afaik not defined anywhere in the spec, right? And thus it's afaik not portable. Having secrets checked in to your SCM is imo an utter bad practice. Except probably if it's just a test DataSource. That might be fine, although even there I usually like to switch between h2 (in-memory or file based db as default in most of my projects) and the real DB (PostgreSQL or Oracle, etc). So not even for tests it's good enough for my use cases. LieGrue, strub > Am 22.06.2018 um 01:09 schrieb Reza Rahman <reza_rahman@xxxxxxxxx>: > > 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: >> >> >> El mié., 20 jun. 2018 a las 21:43, Bill Shannon (<bill.shannon@xxxxxxxxxx>) escribió: >> 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. >> Interestingly, password aliasing was already discussed for Java EE 7 (https://github.com/javaee/javaee-spec/blob/master/download/password-aliasing-ee7-proposal.pdf). I wasn't there at that time. Does anybody know what happened to it? >> >> _______________________________________________ >> 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 > > _______________________________________________ > 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
Attachment:
signature.asc
Description: Message signed with OpenPGP