►
From YouTube: Jakarta Config | JakartaOne Livestream 2021
Description
Jakarta EE gives developers a comprehensive set of vendor-neutral, open specifications that are used for developing modern, cloud native Java applications from the ground up. With Jakarta EE, technology developers and consumers can be confident they have the best technologies for developing cloud native, mission-critical applications. And they can build on decades of Java developer expertise to move existing workloads to the cloud.
Learn more: https://jakarta.ee/
Follow us on Twitter: https://twitter.com/home
Follow us on LinkedIn: https://www.linkedin.com/showcase/jakartaee/
Like us on Facebook: https://www.facebook.com/JakartaEE/
A
Okay,
so
welcome
back
to
the
studio
again,
you
are,
what
do
you
think
every
turn.
A
B
Okay
and
we
are
back,
I
hope,
you're
inspired
to
go
out
and
create
a
pizza
now
and
in
this
studio
we
are
going
to
talk
about
jakarta,
config
and
with
me
or
with
us
here
today
we
have
dimitri,
connell
and
thomas
langer,
so
please
introduce
yourselves
welcome.
C
Yeah
I'll
start
introduction.
My
name
is
dietrich
corniloff,
I'm
from
oracle.
I'm
one
of
jakarta,
config
spec
leads
in
otherwise
emily
from
ibm,
we're
quite
proud
to
provide
a
little
bit
of
information
and
about
chikata
config
and
possibly
encourage
people
to
participate
in
the
spec
or
distract
what's
going
on.
D
C
C
Okay,
so
I
skip
all
the
introduction
slides
in
this
case
because
we
already
introduced
ourselves
and
as
I
was
saying
that
by
this
short
studio,
talk
will
try
to
answer
your
questions
about
what
the
config
is
and
the
main
question
you
may
have
is
why
buy
to
the
neat
jakarta
config?
C
They
were
some
projects
implementing
configuration
like
delta
spy
config
like
bachita,
maya
and
others,
but
there
was
never
a
specification
in
java,
ee
or
jakarta
space
standardizing
that
apis
they've
got
many
efforts
to
do
that,
and
this
story
is
long
and
sometimes
painful,
and
here
I
have
a
slide
about
that.
C
So
in
2013
a
configuration
standard
for
java
ee
talk
was
presented
on
chapter
1
2013
by
mike
keith
and
remember
it
was
a
java
ee7
time
right
and
up
that
it
was
a
little
bit
quiet
and
I
took
it
over
and
in
2016
I
presented
star
configuration
for
java
ee
in
the
cloud
and
it
was
java
e8
time.
C
At
that
time
I
was
almost
ready
to
propose
a
jsr,
but
oracle
decided
to
cancel
java
e9
and
configuration
spec
was
targeting
ee9.
C
So
I
didn't
do
that,
but
mark
strubinker,
emily
jr,
took
over
that
the
fourth
and
actually
proposed
that
jsr
jsr
382
and
it
was
live
for
two
years
from
2017
until
2019
and
at
the
same
time,
the
same
people
introduced
micro
profile,
config
1.0
and
even
after
the
cancellation
of
jsr
configuration
specification,
continues
its
evolution
in
microprofile
and
this
year
you
know
everything
goes
in
circles.
We
are
introduced
to
config,
which
is
configuration
specification
for
chicago.
A
C
Oh
for
sure,
I'll
explain
it
a
little
bit
later.
Maybe
even
thomas
will
answer
that
question
a
little
bit
better
than
me,
and
let
me
continue
with
just
explaining
what
jakarta
config
is
right,
so
dust
bullet
is
actually
a
copy
from
our
scop
statement,
and
the
scope
statement
says
that
jakarta
config
is
a
core
framework
for
jakarta,
be
platform
allowing
applications
and
other
components
to
read
configuration
data
from
different
environment,
aware
sources
in
a
possible
way.
C
So
there
are
many
keywords
here
right:
it's
a
core
framework
right
means
that
we
are
going
to
be
first
of
all,
a
part
of
jakarta
core
profile,
which
is
upcoming,
some
point
right
and
we
don't
want
to
have
dependencies
to
other
specifications.
C
There
are
even
use
cases
where
cdi
is
not
welcome
in
the
projects.
C
C
This
is
basically
what
jakarta
ee
is
about
about
portability,
and
our
specification
is
going
to
provide
portability
too
about
microprofile
chicago
is
going
to
be
successor
of
micro
profile,
config,
it's
going
to
be
based
on
micro
profile
config,
but
not
exactly,
and
I
mean
not
exactly
because
jakarta,
ee
and
micro
profile
still
different
organizations,
different
working
groups
and
they
have
different
goals
right
so
jakarta,
ee
just
can't
accept
something
which
is
not.
C
Let's
put
it
this
way
accepted
by
all
jakarta
e
worker
participants
right
because
there
can
be
some
different
use
cases,
but
we
agreed
that
we
will
base
our
specification
micro
profile
config
and
fix
it
a
little
bit
to
satisfy
all
the
participants
talking
about
participants.
We
have
quite
a
lot
of
committers
from
different
organizations,
including
oracle,
ibm,
community
itself,
red
hat
the
appetite,
and
you
see
that
we
have
quite
a
good
diversity.
So
there
is
based
on
a
project
activity.
C
We
don't
have
one
major
commuter
organization
which
does
everything,
so
the
graph
is
very
diverse,
which
is
very
good
and
talking
about
what
they
are
trying
to
solve
and
what
kind
of
differences
between
javi
jakarta.
I'm
still
saying
micro
profile,
config
I'll,
give
a
ball
to
thomas
to
explain
thomas,
please.
D
Thank
you.
So
we
have
a
few
points
that
are
currently
the
most
important
ones
we
need
to
resolve
before
proposing
you
know
some
something
to
be
released.
So
first
point
is
immutability.
If
you
use
micro
profile
config,
it
allows
you
to
have
fully
mutable
config
sources
and
basically,
every
time
you
request
a
configuration
value.
D
You
get
the
latest
one
from
the
config
source,
and
this
is
one
way
how
to
handle
it.
It
has
its
pitfalls
that
we
are
trying
to
find
solutions
for
so
basically,
we
need
to
decide
whether
we
are
going
to
do
a
mutability,
a
similar
way,
with
some
form
of
checks
to
make
sure
that
you
have
consistent
data
or
if
there
will
be,
for
example,
an
even
based
mechanism
that
will
give
you
a
snapshot
and
allow
you
to
listen
for
changes
when
when
they
occur.
D
The
second
point
is
how
you
navigate
through
your
configuration.
So
obviously
there
is
a
simple
way.
You
can
inject
your
configuration
data
when
you
are
using
cdi,
for
example,
but
when
you
want
to
use
programmatic
approach,
there
needs
to
be
some
way
how
you
get
a
configuration
value,
and
there
are
two
approaches
to
this.
One
of
them
is
actually
the
existing
microprofile
way.
Where
configuration
is
consist
considered
to
be
a
flood
structure.
D
You
basically
have
a
map
of
keys
and
values,
as
opposed
to
that
there
are
other
implementations
of
configurations
that
are,
you
know,
proposing
the
tree
structure,
which
allows
you
to
navigate
your
configuration
as
a
tree.
So,
instead
of
saying
I
want
to
get
my
server.port,
you
can
say
I
will
server
and
from
that
server
you
can
get
a
port
which
has
each
of
these
approaches
have
different
benefits,
and
this
is
one
of
the
biggest
discussions
we
are
having
right
now.
D
So
you
know
again,
I
will
say
if
you
are
interested,
you
know
please
join
us,
you
know
if
you
have
some
really
good
reasons
why
one
of
them
is
better
than
the
other.
It
will
help
our
discussion
as
well.
D
Third,
big
point
is
ordering.
This
is
something
that
is
really
important
when
you
need
to
discover
a
configuration
value
from
multiple
conflict
sources.
How
do
you
decide
which
of
your
configuration
sources?
Is
the
right
one
to
pick
that
value
from
we
have
chosen
in
microprofile
config
that
actually
not
to
be,
but
in
micro
profile,
config.
D
It's
chosen
by
ordinals,
which
is
like
the
higher
the
number
of
the
configures,
the
more
important
it
is
other
config
configuration
implementations
may
have
chosen
priority,
which
is
inverse
in
in
most
wallet
cases
where
the
small
number
is
is
more
important
or
there
are
some
other
approaches
which
have
significance
depending
on
which
location
this
is
configured.
D
D
Another
is
conversion
of
values,
and
this
is
actually
related
to
tree
structure
and
flat
structure.
Because
with
flood
structure,
you
basically
convert
a
string
value
to
an
object.
D
If
you
want
to
convert
to
a
pojo,
you
need
to
have
some
kind
of
prefix,
plus
your
configuration
to
be
able
to
extract
it
with
three
values.
You
know
you
could
do
things
like
converting
a
tree
node
into
an
object.
So
we
are
discussing
this,
as
you
know,
related
to
the
tree
structure
and
flood
structure,
and
the
last
thing
that
we
we
need
to
resolve
because
we
are,
there
are
different
opinions
on.
That
is
how
we
override
values.
D
So,
regardless
of
whether
you
use
three
structure
of
less
structure,
you
want
to
be
able
to
override
a
value,
for
example,
using
an
environment
variable
or
system
property,
and
there
is
a
consideration
like
what,
if
you
want
to
remove
a
value-
and
this
is,
you
know,
quite
complicated,
because
you
know
how
do
you
tell
through
a
system
property
that
something
should
be
removed?
D
So
you
know,
that's
that's
the
last
decision
that
we
need
to
make
is
how
to
if
we
want
to
handle
it,
and
if
we
decided
yes,
we
want
to
handle
it,
then
how
to
do
it,
and
I
think
that
that
is
a
short
introduction
into
the
current
decisions
that
we.
A
A
Well
thanks
so
much
this
is.
This
is
great
yeah.
B
This
is
awesome
and
we
can
just
encourage
everybody
to
join
the
resources
that
is
being
displayed
on
the
on
the
screen
on.
B
The
mailing
list
join
the
project
violations
on
the
github
repository
join
the
weekly
meetings
and
I
think
we
are
out
of
time.
So
thank
you
very
much
dmitry
and
thomas
for
joining
us,
and
there
are
some
questions.
So
please
go
into
the
chat
and
see
if
you
can
help
the
listeners
with
some
answers.
There.