Re: [jakarta.ee-community] @DataSourceDefinition

[Werner Keil <werner.keil@xxxxxxxxx>]

Werner Keil | JCP Award Winner, JSR 385 Spec Lead | Eclipse UOMo Lead, EE4J Committer | Apache Committer | DWX '18 Track Chair, AdBoard Member

Twitter @wernerkeil | @UnitAPI | @JSR354 | @AgoravaProj | @TamayaConf | @OpenDDR | #EclipseUOMo

Skype werner.keil

On Wed, Jun 20, 2018 at 10:34 PM, arjan tijms <arjan.tijms@xxxxxxxxx> wrote:

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

Last time I followed the EG calls in more detail the Config JSR as such did not address staging of config values directly, but maybe e.g. in the annotations there's now room for that (https://github.com/eclipse/ConfigJSR/issues/26 suggests some approach, but the issue itself is not resolved)

It certainly must be more generic, either just additional string properties or similar, the JSF enum was a nice try, and Java annotations currently are not capable of using e.g. an interface as opposed to enum or String and likely a few primitive types (not sure, if any rapidly increasing JDK version might ever address that deficit?) so I understand it to some extent, nevertheless it is totally inflexible and nowhere near what modern DevOps and Cloud environments need.

DeltaSpike had a more flexible approach, so having many authors in common, I guess it should work out eventually. 

Werner

 

_______________________________________________
jakarta.ee-community mailing list
jakarta.ee-community@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jakarta.ee-community