RR> Just using application.properties
is a good idea indeed.
RR> I am sure Ed and Jared will
respond, but I believe
the idea here
RR> is to allow both Jakarta EE and
MicroProfile to evolve
RR> independently in accordance with
their own needs and
also
RR> collaborate when best seen fit.
RC> A few comments inline. Thank you!
JA> This email is a follow up to the
discussion at the
2025-02-04
JA> Jakarta EE platform call.
JA> In that call, we discussed an
approach where Jakarta
EE 12 could
JA> effectively use MicroProfile
Config "as is" with
some important
JA> non-technical accommodations.
JA> 1. The APIs for Jakarta Config
would be the
MicroProfile Config
APIs,
JA> but with jakarta namespace. Yes, a
copy/paste.
RC> After the initial copy/paste, how
would things evolve?
My intention is that technical evolution
would take place in
the
MicroProfile Config project. In the event
of Jakarta specific
1. Cross that bridge when we come to it.
2. Try to come up with solutions that are
palatable to both
communities, Jakarta
3. If absolutely necessary, we would
define content in MP
Config that
would have the proviso such as "this
only takes effect in
Jakarta
EE environments". There is ample
precedent for such
approaches. See
what we did with Faces when Validation
was present (in EE)
vs. not
present (such as in Tomcat).
RC> Would Jakarta keep the APIs
in-sync?
Yes. Every time Jakarta needed a new
version, they would
pick up a
chosen release of MP config to give the
copy/paste treatment
to.
RC> What restricts Jakarta from using
the API as-is?
1. A technical problem regarding
introducing circular
dependencies.
2. A non-technical problem where Jakarta
specs may not make
dependencies on MicroProfile
artifacts.
JA> 2. The implementation may delegate
to the MicroProfile
Config implementation.
JA> 3. The Spec document would be
one-line: see the
corresponding
JA> MicroProfile config spec
document. May need
additional text to
JA> talk about the difference in
namespace and adding
in
JA> jakarta-config.properties until a
new MP Config version
added that
JA> to its specification. See #5
below.
JA> 4. The TCK would be a copy/paste
of the MicroProfile
Config TCK
JA> and updating the name space and
adding
jakarta-config.properties
JA> 5. Need to introduce a new line in
the ConfigSource
(MicroProfile
JA> Config API) “Some configuration
sources are known as
default
JA> configuration sources. These
configuration sources
are normally
JA> available in all
automatically-created
configurations, and
can be
JA> manually added to manually-created
configurations as
well. The
JA> default configuration sources are:
JA> 1. System properties, with an
ordinal value of 400
JA> 2. Environment properties, with an
ordinal value of 300
JA> 3. The
/META-INF/jakarta-config.properties
resource, with an
ordinal value of 200
JA> 4. The
/META-INF/microprofile-config.properties
resource, with an
RC> How about dropping
microprofile-config.properties
(keep it for
RC> compatibility) and
jakarta-config.properties,
and use
RC> application.properties? This one
is already used by
many popular
RC> runtimes like Spring, Quarkus, and
Micronaut, to name a
few.
Roberto, that's a rad idea. I like it.