| Re: [jakarta.ee-community] @DataSourceDefinition |
Hi,On Wed, Jun 20, 2018 at 9:46 PM Bill Shannon <bill.shannon@xxxxxxxxxx> wrote:Some of this is unspecified or weakly specified because there was no agreement
among vendors as to how it should work.Do you mean which actual properties, or how to separate the two sets of properties?The latter should be relatively easy.There's now a general:String[] properties() default {};
A simple solution would be to add a second attribute to @DataSourceDefinition:
String[] poolProperties() default {};
It's always seemed like a feature to me that you only have to deal with one
concept instead of two.It's indeed a feature too. If you don't need or want to deal with the two concepts it's great. However, when you do need the pool concept there's no way whatsoever to reach it from application code. I'm not yet entirely sure how this could be realised in an elegant way, but I'm sure that with the combined expertise of this group we should be able to find a solution.
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.It has more to do with a (simple) database being up and running by default, just like say a JNDI directory or a JMS broker is up and running by default. This database can be a simple embedded one, it just has to be there by default. In Payara we have such a database, and it's really relatively easy to implement by a vendor.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.They were at least mentioning it in the Twitter thread linked in the opening post.The addition of the Config API to Jakarta EE would help us address many of these
issues._______________________________________________Indeed, the Config API is one the pieces. The concepts of (config) staging is another one. It's essentially another JSF concept (which borrowed it on its turn from Rails) that probably should be available system-wide. Finally it's the configurable datasource (placeholders in the annotation/xml, or otherwise). You basically need all these three pieces for the best experience.Kind regards,Arjan
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