Date:
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.
Indeed, doing that now.
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
accommodations, we would
1. Cross that bridge when we come to it.
2. Try to come up with solutions that are palatable to
both communities, Jakarta
EE and MicroProfile.
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?
As far as I know:
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> testing
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
JA> ordinal value of 100
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.
Ed
