arjan tijms wrote on 06/20/18 01:34 PM:
Hi,
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?
Both.
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 {};
Are you sure every vendor supports the same separation between data
source and connection pool?
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.
The only way to have any assurance that the database is always
available is to have an embedded database, but we felt that was
going too far. Most users will want to use a real, external
database.
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.
Twitter thread == standing on the street corner and shouting into
the wind.
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.
We never expanded support for "stages" because no one came up with a
testable specification of how things should behave differently in
different stages, or what the stages should be.
Having multiple sets of configuration is a different issue, and
allows the user to decide what needs to be different in each set.
|