►
From YouTube: 2023-01-05 meeting
Description
cncf-opentelemetry@cncf.io's Personal Meeting Room
A
A
We
did,
oddly,
though
our
heater
went
kaput
for
completely
unrelated
issues,
so
I've
got
the
space
heater
going
right
now,
hey.
E
Yeah
this
was
just
something:
I
was
thinking
about
as
I
removed
the
stale
label
for
the
you
know,
I,
don't
know
the
a
couple
of
my
PR's
have
been
going.
Stale
and
I've
been
just
removing
the
label
consistently,
because
these
are
still
kind
of
things
in
progress.
We've
there's
been
two
kind
of
approaches
for
splitting
out
events
from
logs.
E
This
is
the
one
that's
more
popular
where
we
have
an
entirely
new
provider
for
events,
so
there's
an
event
provider
that
you
know
is
parallel
to
logger
provider
and
meter
provider
and
Tracer
provider.
One
thing
that's
a
bit
odd
about
this
is
that
the
the
log
SDK
implements
the
event
provider
and
yeah.
So
this
is
not.
This
is
not
part
of
the
spec,
as
you
all
know,
but
it
is
it's
what's
preferred
by
by
us
in
the
javasig,
so
I'm
curious.
E
What
your
thoughts
are
on,
whether
we
should
kind
of
go
forward
with
merging
this
approach
and
and
trying
to
trying
to
argue
that
the
specs
should
align
to
this,
or
you
know,
kind
of
Flipping,
The
Ordering
on
things
and
first
trying
to
get
the
Specter
aligned
to
this
and
then
merging
it.
B
E
I'm
not
actually
sure
if
this
one
wants
stale
I
think
the
the
I'm
not
sure
if
what's
the
tool
that
marks
things
as
stale
called.
A
Yeah
you
can
put
exempt
PR
labels,
so
I
think
we
could
add
that
am
I
sharing
my
window.
You.
B
Are
yeah
awesome
I
mean
we
could
also
stick
the
Prototype
label
on
it,
since
it
seems
to
be
already
there
yep
Although,
our
so
our
and
again
we're
getting
I'm
getting
way
off
topic
here,
but
our
draft
PR
is
also
Mark
stale
automatically.
E
That's
that's
what
I
wasn't
sure
about
I
think
I
might
have
been
ref
if
you
scroll
down
I'm,
not
actually
sure
you
should
be
able
to
see
in
history
whether
this
was
stale
and
yeah.
It
looks
like
it
was
okay,
so
draft
PR's
are
part
of
the
pool.
A
Well,
my
my
thought
is
as
much
as
I
like
this
approach.
I,
think
flipping
back
and
forth
like
introducing
it
and
people
starting
to
use
it
and
then
having
to
flip
back
causes
some
causes,
pain
so
and
I.
Don't
think
we
have
any
well
like
I,
don't
know
if
anybody's
locked
on
this
currently
yeah.
E
E
E
Trask
to
your
point,
so
yeah
churn
is
turn
is
not
good
and
we
don't
have
any
anything
kind
of
forcing
the
issue
on
this
yet
but
I
think
in
the
next,
hopefully,
the
next
month
or
or
two
the
we'll
be
getting
close
to
stabilizing
the
the
log
API
and
SDK,
at
which
point
we'll
need
to
have
some
sort
of
solution
for
peeling
off
events
from
that
and
we'll
be
forced
to
make
a
decision.
F
A
Does
this
PR
split
so
today?
Currently
we
still
have
the
event
emitter
stuff
in
the
log
API
and
this
PR
splits
that
out?
Yes,
so
it
does
it
unblocks
the
log
apis
stabilization.
B
B
E
B
Currently
the
we
have
a
logical
incompatibility
in
the
the
spec
right
that
we
specifically
say
we
don't
have
a
public
blogging
API,
but
the
event
API
is
part
of
the
logging
API
and
it
is
intended
to
be
public
and
therefore
like
clearly,
these
two
things
cannot
simultaneously
be
true,
so
right,
all
right
now,
public
isn't
the
right
word
end
user
facing
is
what
is
the
is
the
right
phraseology,
so
I
can't
imagine
that
we're
going
to
end
up
with
what
we
have
in
the
spec
right
now,
because
I
think
it's
just
incompatible
with
itself.
B
E
Well,
it's
in
the
spec
right
now,
just
just
it
is
it's
a
bit
nuanced,
so
you
have
to
pass
the
the
logger
provider
to
an
event
emitter,
as
like
a
as
like
a
Constructor
argument
and
so
yeah
like
while,
while
you
don't
directly
consume
the
well,
you
don't
directly
like
create
events
off
the
the
logger
provider
or
anything
like
that.
You
still
have
to
be
aware
of
its
existence
and
pass
it
as
an
argument.
So.
B
B
Yeah
I
think
I'm
I
mean
I'm
fine
with
it
I
mean
it's
in
an
alpha
module.
Anyone
who
uses
Alpha
modules
knows
what
they're
in
for
or
should
know
what
they're
in
for.
A
Eign
yeah
I
wouldn't
start
telling
our
customers
to
use
it
just
from
the
churned
perspective,
but
that's
fine
people
who
find
it
and
want
to
use
it.
It's
very
clearly
marked
Alpha
will
not
be
the
first
Alpha
artifact
that
we've
broken.
F
A
And
it
may
help
us
to
steer
the
spec
discussion
by
pointing
to
like
a
concrete
example
versus
just
a
PR.
That
has
an
example,
but
an
actual
something
that
people
could
download
and
use.
E
Yep,
so
why
don't
we?
Why
don't
I
open-
or
you
know,
switch
this
from
a
draft
to
a
proper
PR
and
I'll
hold
off
on
merging
this
for
the
release?
That's
tomorrow,
because
I
want
to
give
folks
a
chance
to
properly
look
at
it
and
there's
no
rush
but
yeah
we'll
we'll
do
that
sounds.
B
A
All
right
so
yeah,
so
there's
a
release
core
repo
released
tomorrow.
Instrumentation
release
on
next
Wednesday,
anything
that
anyone
wants
to
highlight
to
get
to
try
to
get
in.
B
B
Yeah
I
don't
know
if
this
is
finalized
on
that.
So
you.
B
E
It's
an
opr
for
that
yeah
or
did
it
get
closed
and
we
forgot
about
it.
B
A
C
I
mean
I'm
not
waiting
on
anything,
but
there's
like
five
PR's
that
I
creatives
and
I'd
be
very
grateful
if
somebody
reviewed
some
of
them.
C
Probably
I
don't
think
that
they
that
urgent,
but
would
be
nice,
maybe.
B
C
We
already
had
two
people
report,
an
issue
of
Spring
Security
Six,
some
kind
of
like
metric,
naming
that
there
is
a
white
space
inside
so
yeah
at
least
some
are
using.
It.
C
A
I've
definitely
seen
people
kicking
the
tires
because
we
have
the
older
with
the
prior
to
like
1.18
or
something
of
the
the
Java
agent.
A
A
So
basically,
like
our
worst
case
scenario
for
the
Java
agent,
where
we
just
completely
break
the
app
so
people
who
haven't
upgraded
the
agent
but
are
trying
out
spring
boot,
three
are
in
for.
B
C
Yeah
I
demoed
it
last
time.
That's
not
really
like
related
to
Spring.
That's
another
another
stop
another
piece
of
interesting
feature
in
case
you
don't
remember.
Do
we
have
had
a
couple
of
issues
where
our
users
wanted
to
redirect
the
I,
whatever
agent
prints
out
to
their
application
logs,
and
this
is
like
the
first
step
to
doing
that.
A
Jason
you've
taken
the
closest
look
on
our.
Are
you
done
reviewing.
C
It's
pretty
complex,
though,
and
it
kind
of
digs
deep
into
how
we're
implementing
blogging
in
the
agent,
so
I
think
it
would
be
good
if
somebody
like
could
spare
a
little
time
and
take
a
look
at
it.
A
I
I
Might
it
might
be
nice
to
have
it'd
be
nice
to
have
a
little
bit
of
guidance
around
how
to
filter
them
out
or
redirect
them
I
mean
I,
guess
this
is
an
slf
specific
concern
and
it's
maybe
not
up
to
us
to
document
it,
but
we
will
continue
getting
questions
from
users
who
are
like.
Oh
your
agent
logs
are
mucking
up
my
application
logs.
How
do
I
redirect
them
or
mute
them
right
so
having
a
working
example
might
also
be
nice,
but
it
certainly
doesn't
have
to
be
in
this
PR.
A
And
what
about
Doc?
Is
there
any
dock
that
we
need
for
this
definitely.
C
I
didn't
at
any
in
this
PR,
because
it's
already
pretty
huge,
it's
a
Thousand
Nights
of
code
and
I
think
it's
still
sort
of
Unfinished
I
mean
there's.
It
works
for
like
single
job
applications
except
spring
boot,
because
spring
boot
has
a
some
kind
of
particular
order
of
initializing
the
logging
system.
C
So
it
still
needs
at
least
like
two
other
fixes
before
I
will
be
satisfied
with
it
enough
to
add
some
like
public
facing
documentation
that
you
know,
people
don't
discover
and
try
using
it.
A
What
are
the
can?
You
add
the
like
every
ad
here,
what's
remaining
like
as
a
future
in
the
PRS
okay,
yeah.
C
A
F
A
Been
yes,
we
have
been
a
Ben
and
Robert
on
the
call.
Jack.
Do
you
wanna
and
maybe
there's
been
discussion
that
I've
missed
already
today,
but
I
thought
this
would
be
a
good
thing
to
chat
about
briefly.
E
Yeah
I
can
kind
of
summarize
this
issue
a
bit.
So
I
was
reviewing
Robert's
work
to
try
to
capture
the
existing
jvm
runtime
semantic
conventions
using
an
alternate
data
source
right
now,
they're
collected
via
jmx,
and
he's
done
some
work
recently
to
try
to
capture
the
same
metrics
and
the
same
kind
of
structure
using
JFR,
and
this
is
like
I
couldn't
help
getting
the
feeling
that
the
work
is
seemingly
repetitive.
E
E
Or
metrics
in
a
in
in
a
way
that's
more
complicated
than
what
we
already
have
through
jmx,
and
so
you
know
the
the
kind
of
conclusion
that
I
was
reaching
was
hey.
You
know,
while
you
can
collect
some
of
these
same
metrics
via
JFR,
maybe
we
shouldn't
it.
G
Let
me,
let
me
share
some
of
the
stuff
that
I
was
thinking
about
in
the
Autumn,
which
seems
like
a
very
long
time
ago.
Now,
basically,
my
my
sort
of
concern
here
is
that
I'm
not
actually
sure
the
extent
to
which
there's
any
appetite
for
continuing
to
develop
jmx
within
the
jdk
itself.
G
The
couple
of
folks
I
spoke
to
who
are
responsible
for
working
on
on
that
basically
seem
to
regard
it
as
a
century
moth
board.
You
know.
So
if
something
critical
comes
up
or
a
cve
or
something
they
might
patch
it,
but
they
don't
see
it
as
a
place
where
analytic
information
will
be
will
be
gone
and,
and
the
answer
I
got
in
in
a
couple
of
cases
was
well
that
data
should
come
out
JFR.
G
G
What
jmx
metrics
are
even
generated
for
them
and
I
certainly
don't
know
that
that
should
a
future
collector
be
be
developed,
that
that
would
necessarily
have
any
jmx
support
at
all,
so
so
that
that
was
sort
of
my
first
point
of
concern
and
then,
when
I
said
to
them.
Well,
you
know,
we've
been
doing
this
work
within
open,
Telemetry
and,
and
we
feel
like
there
might
be
some
gaps
and
some
missing
data.
G
They
said,
oh,
what
data
do
you
think
is
missing,
so
I
said:
well,
you
know
we're
trying
to
implement
the
spec
that
we
have
an
existing
implementational
for
jmx
we're
running
into
trouble
and
they
said.
Okay,
can
you
you
know
kind
of
figure
that
one
out
a
bit
more
for
us
please
and
then
and
then
talk
to
us
about
it.
So
so
that
was
the
point
at
which
saying
guys
Robert
to
try
to
to
implement
the
spec,
using
what
we
had
with
JFR
essentially
to
see.
G
Are
we
missing
any
data?
Is
there
anything
which
which
there
should
be
a
JFR
event
for
which
is
just
just
somehow
got
missed,
and
if
there
is
I,
think
there's
more
likely
to
be
appetite
to
accept
a
PR
in
the
jdk
to
add
in
any
new
event
types
to
plug
those
gaps
rather
than
continuing
to
use
shofar
and-
and
you
know
indefinitely
so
that
was
really
my
thinking
it
was.
It
was
really
just
about
future
proofing.
More
than
anything
else,
Jack.
E
I
I
I
think
it
does
I
just
you
know
so.
I
I
did
a
little
bit
of
analysis
and
I'm
gonna
post
a
link
in
the
the
chat
for
this
I
did
a
little
bit
of
analysis
on
what
we
get
from
jmx
in
terms
of
garbage
collector
and
in
memory
usage
metrics
for
for
all
different
garbage
collection,
a
bunch
of
different
garbage
collectors
are
run,
I,
think
all
of
them,
and-
and
so
this
is
this-
is
what
we'd
have
to
try
to
recreate.
E
All
of
these
different
label
sets
all
these
different
attribute
sets
for
all
of
these
garbage
collectors
in
in
JFR,
and
you
know
the
works,
the
work
that
Robert's
done,
it's
it's
showing
that
even
for
you
know,
for
a
single
garbage
collector.
It's
actually
quite
a
bit
of
code
to
you
know,
collect
the
data
in
this
shape
for
a
single
garbage
collector,
and
it
requires
quite
a
bit
of
expertise
and
quite
a
lot
of
code
to
you
know
to
to
do
it
to
cover
all
the
garbage
collectors.
So.
G
That's
the
love,
we're
talking
about
I
mean
brother
and
the
folks
that
that,
in
the
team
that
he
works
in
have
done
that
kind
of
work
before
so
so
we
are
prepared,
as
red
hat,
to
to
sponsor
work,
to
get
missing.
Jfr
events
upstreamed
providing
everyone's
agreeable.
To
that
you
know
the
Oracle
focus
and
so
forth.
G
E
Think
if
I
were
to
I
think
if,
if
we
were
to
do
that,
then
you
know
I
I
would
want
it
to
be
simpler
to
observe
this
type
of
data
from
JFR.
We
wouldn't
I,
wouldn't
want
us
to
have
to
jump
through
so
many
Hoops
in
order
to
consume
it
and
I
guess.
Maybe
the
way
to
do
that
would
just
be
to
like.
Would
it
be
useful
to
point
the
jdk
folks
to
the
semantic
conventions
and
say
these
are
the
things
that
are
we're
interested
in
observing?
G
I
mean
I
I
think
we
don't
need
to
to
involve
the
Oracle
folks.
I
I
would
say
that
that
Robert
and
I
would
would
go
back
and
make
a
case
to
the
the
red
hat
team
to
to
implement
them,
and
then
you
know
we'll
we'll
spawn
we
could.
If,
if
we
can
get
the
resourcing
to
do
it,
I
think
we
would
be
prepared
to
sponsor
a
patch
Upstream.
D
What
is
that
yeah?
There's
a
lot
of
data,
that's
missing
with
respect
to
JFR
events,
what's
available
currently.
F
D
Also,
the
way
it's
currently
organized
a
lot
of
like,
for
example,
one
metric
to
gather
the
full
set
of
possible
attribute
combinations.
D
Multiple
different
events
may
have
to
be
like
used
together
in
the
data
aggregated
so
that
we
can
have
the
full
set
of
possible
attributes.
So
if
we
like
reorganize
the
the
the
data
and
the
events
such
that
it
conforms
more
nicely
to
the
semantic
conventions,
wouldn't
that
cause
like
breaking
changes
for
anybody
else
that
like
uses
those
events
as
they
currently
are,.
G
D
So
then,
this
like
kind
of
like
has
Hazard
of
Hazard,
like
stringing
together
of
data
from
different
events,
would
still
have
to
be
done.
D
Like
what's
currently
The
Quirk,
that's
currently
done
still
have
to
be.
We
still
have
to
exist.
Well,.
E
D
Changed
the
existing
structure
of
existing
JFR
events.
G
Sorry,
what
do
you
mean?
Well
so,
if,
if,
let's
suppose
hypothetically
we've
got
these
new
summarized
event
types
into
JK,
21.
uh-huh,
what
you're
saying
is,
we
would
still
have
to
jump
through
these
hoops
for
11
and
17,
but
for
21
we
could
we
could
not.
We
wouldn't
need
to
do
that
and
we
could
use
the
summarize
events
instead.
Is
that
what
you
mean.
D
Yes,
but
but
also
I
mean
if
we,
if
we
do
have
those
like,
as
you
say
summarize,
like
events
that
neatly
contain
all
the
data
required
for
each
metric,
then
wouldn't
any
consumers
that
rely
on
the
existing
event
format
that
is
currently
implemented
in
like
11
and
17.
Wouldn't
that
cause
issues
for
them
as
well.
F
D
C
D
What,
if
what,
if
is
it
possible
to
use
both
jmx
and
JFR
like
is
that
kind
of
what
Jack
was
into
hinting
at,
or
is
that
something
different
like
because.
E
E
I
was
kind
of
suggesting
using
you
know
each
both
the
data
sources
for
what
each
is
good
at
so
using
jmx
for
the
things
that
it's
good
at
and
then
using
JFR
for
the
things
that
the
additional
data
that
it
provides,
that's
not
available
or
is
hard
to
get
at
Via,
jmx
and
I.
Think
you
know
to
summarize
kind
of
what
Ben's
critique
is.
E
Is
that
you
know
jmx
may
not
continue
to
publish
the
information
that
it
does
publish
today
for
future
garbage
collectors,
but
if
it
may
stop
being
a
good
source
of
data
in
the
future,
uh-huh.
D
But
if
we
kept
the
current
implementation,
the
jmx
implementation,
but
just
and
for
any
future
garbage
collectors
handle
them
with
JFR
events
or
data
from
JFR
events.
Wouldn't
that
solved
the
issue.
E
Assuming
that
JFR,
like
for
future
collectors,
published
events
that
would
allow
us
to
you,
know,
observe
the
the
type
of
data
we
needed,
then
yeah
I
think
so.
I
D
So
it
seems
like
there
are
two
paths
that
can
be
taken:
one
is
to
use
the
jmx
implementation
for
basically
to
cover
the
the
current
semantic
conventions
and
then
to
Beef
It
Up
with
data
from
JFR
events,
so,
basically
add
new
handlers
for
existing
events
and
for
any
additional
JFR
events
in
the
future.
Just
continue
adding
handlers
for
them.
So
even
if
JMS
is
not
updated,
we
can
continue
to
expand
this
into
conventions
if
we
want
to
and
then
the
second
option
would
be
to
kind
of
go
back
and
create
these.
D
A
So
Jack
as
far
as
you're
concerned
about
having
the
you
know,
kind
of
duplication
here,
having
two
ways
to
do.
The
same
thing
is
the
concern.
Just
the
I
mean
the
the
time
of
reviewing
and
that
sort
of
thing
because
I
I'm
not
we
could
look
at
this
as
like
a
proof
of
concept,
module
that
is
being
used.
Sort
of
to
you
know
for
these
potentially
future.
A
E
E
So
you
know,
there's
information
not
available
through
jmx,
like
contact
switches,
information
about
locks
and
information
about
Network,
reads
and
rights
so
that
that's
useful
net
new
that
we
don't
capture
via
jmx
today
and
you
know
kind
of
coupled
with
that
or
be
you
know,
there's
there's
additional
code
in
there
that
tries
to
recreate
the
existing
semantic
conventions,
but
in
a
way
that
is
it's
just
not
as
good,
because
there's
there's
really
obvious
gaps
in
the
attributes
that
are
we're
able
to
observe
or
in
the
the
the
set
of
metrics
that
we're
able
to
observe
you.
A
Know
work
to
split
this
into
two
modules,
one
that
is,
you
know,
net
new
stuff
and
one
that
is
literally
just
attempting
a
proof
of
concept
of
re-implementing,
the
jmx
stuff
using
JFR
events,
yeah.
E
I
think
so,
and
kind
of
an
idea
that
was
kind
of
going
around
in
my
head
was
that
for
this
to
actually
be
useful
to
users,
I
think
we
should
have.
E
You
know
configuration
options
to
turn
on
and
off
different
types
of
JFR
listeners,
and
so
what
you're
suggesting
would
kind
of
play
into
that,
like
you
know,
maybe
by
default
when
you
use
this
there's
a
set
of
handlers
that
are
turned
on
that
you
know
produce
the
metrics
that
are
net
new
and
maybe
there's
like
an
experimental
set
of
handlers
that
you
can
turn
on
if
you
want,
but
by
default,
they're
off-
and
you
know
the
experimental
set
or
the
the
things
we're
talking
about
where
we
try
to
recreate
the
existing
semantic
conventions.
G
Now
the
general
question
I
mean
this:
does
sort
of
somewhat
open
the
Pandora's
box
of
what
we,
what
we
mean
by
configuration,
because
not
all
of
those
handlers
are
going
to
have
the
same
runtime
cost
I
mean
the
the
first
round
allocation,
for
example,
is
going
to
be
expensive,
so
we
probably
need
to
give
some
daughters
to
how
we
would
actually
configure
this,
but
in
general,
I
agree
with
the
approach
Jack.
A
F
G
E
E
Each
Handler
listens
for
a
specific
event,
and
but
you
know
sometimes
multiple
handlers
work
together
to
kind
of
collect
the
data
for
one
logical
thing,
and
so
you
know
you
wouldn't
want
to
turn
on
one
of
those
handlers
and
leave
the
other
three
off,
if,
like
the,
if
all
four
of
them
need
to
be
turned
on
in
concert
to
be
useful,
and
so
you
know
you
need
to
you-
need
to
almost
group
The
handlers
together
into
into
into
into
feature
classes.
D
D
Same
time
as
it
currently
exists,
one
Handler
might
cover
two
different
metrics,
because
a
JFR
events
might
emit
data
that
is
important
for
two
different
ones,
so
it.
I
And
I've
been
touched
on
this,
but
I'm
not
sure
I've
fully
understood.
Are
we
suggesting
that
we
should
or
shouldn't
turn
off
the
event
generation
entirely
for
JFR,
or
are
we
just
talking
about
the
listeners.
G
E
I
think
this
is
a
little
bit
different
than
than
typical,
because
the
cost
of
observing
some
of
these
events
and
producing
those
metrics
is
is,
is
not
free,
so
you
might
not
want
to
pay
that
price
to
to.
You
know:
listen
for
an
event
that
allows
you
to
produce
a
metric,
even
though
there's
a
mechanism
with
views
that
allows
you
to
like
disable
that
metric,
so
we
might
want
to
basically
turn
it
off.
Upstream
of
the
views,
foreign.
A
So
Robert,
are
you,
do
you
feel
like
you
have
what
you
need
to
move
kind
of
forward
with
this.
D
D
That's
going
to
be
that's
going
to
I
guess
supplement
the
existing
semantic
conventions
that
are
implemented
by
jmx
and
the
other
one
is
going
to
be
kind
of
like
the
work
that
was
that's
currently
being
done
to
recreate,
what's
currently
implemented
in
JMS,
basically
just
re-implementing
the
semantic
conventions,
and
it
seems
like
the
way
to
do
that
would
basically
be
adding
new
JFR
events.
E
I
would
I
would
modify
that
a
bit.
I
would
try
to
organize
the
the
handlers
not
into
like
two
modules,
especially
not
too
too
Gradle
modules,
but
just
I
would
try
to
organize
the
handlers
into
classes
of
features
that
they
that
they
relate
to,
and
you
know
each
class
and
feature
would
have
some
sort
of
default
behavior
on
whether
it
was
on
or
off
and
I
see.
It
turned
on
or
off
a
particular
class
of
a
feature,
and
you
know
when
one
is
on.
E
D
E
I'm
personally
happy
continuing
to,
like
you
know,
review
those
how
we
have
and
merging
them.
You
know
as
we've
been
merging
them
and
then,
as
a
follow-up
step,
doing
this
kind
of
reorganization.
This
module
still
isn't
published.
So
it's
not
consumable-
and
you
know
I-
just
think
that
we
kind
of
do
this
reorganization
as
a
step
towards
publishing
this.
F
D
It's
not
just
reorganization.
It
would
also
be
like
how
these
handlers
or
information
have
to
change
as
well.
If
there
are
new,
like
I,
guess
summary
events
emitted
by
JFR,
that
kind
of
simplify
all
of
this
spiderweb
of
string
together
data
from
multiple
different
events
to
produce
one
whole
metric.
That's.
E
So
thanks
for
doing
this,
Robert
and
good
conversation.
A
Yeah
I,
don't
think
it's
red
hat
for
yeah
I
think
I'm
very
happy
for
open
Telemetry
to
be
like
a
community
or
area
that
you
know
to
use
to
prototype
this
kind
of
stuff
and
help
get
feedback
to
Upstream
to
the
jvk.
J
Hey
guys
yeah,
so
I
I
was
having
a
problem
with
the
current
version.
The
21.,
because
some
of
the
auto
configuration
like
metrics
logs
and
I
think
spans
were
were
relying
on
utility
class
to
check
if
some
cost
exists
on
the
class
path
and
when
you
try
to
build
with
the
native
image
that
blows
there,
because
unless
you
explicitly
add
that
it
won't
compile.
J
Fortunately,
I
found
out
that
and
I
think
Jack
for
that.
He
implemented
the
Implement
otlp
exporter
providers
that
load
things
through
the
SPI
and
I.
Think
that
will
solve
everything.
So
it's
not
a
pro
anymore,
but
just
to
to
highlight
that
every
time
that
we
do
some
class
get
get
name
or
for
name
and
things
like
that,
we
we
will
make
that
coding
compatible
with
with
Native
images.
E
Yeah
I
think
that's
definitely
the
case
there
was
until
very
recently
there
was
a
utility
class,
an
auto
configure
that
you
know
was
dedicated
to
checking
if
certain
classes
were
available
on
the
class
path
and
it
it
did
just
what
you
said
class
for
name
and
would
catch
the
exception
and
that's
been
removed
because,
as
you
mentioned,
we
implemented
the
the
exporters
via
the
SPI
interfaces.
Instead
of
you
know,
just
you
know,
detecting
if
they're
on
the
class
path.
E
I,
don't
think
that
that
was
the
only
place
in
the
code
base
where
we
did
class
for
name
and
so
I
think
in
order
to
really
solve
your
problem,
we'd
have
to
like
search
it
the
whole
code
base
and
make
sure
we're
not
doing
that
anywhere
else.
J
E
One
that
we
we
do
so
I'll
send
it.
A
Over
sure,
instead
of
looking
for
you
know,
those
places
by
hand
I
mean,
and
is
there
some
way
that
we
could
run
tests
or
run
all
of
the
tech
like
have
a
separate
configuration
that
runs
tests,
Native
compiles
things
and
runs
the
tests
under
native
mode
I'm,
just
wondering
if
there's
a
more
robust
way,
we
can
avoid
regression,
since
this
is
only
going
to
be
a
more
popular
option,
going
forward.
J
So
in
quercus
We
Do
It,
when
we
try
to
upgrade
we,
we
run
that
we
have
projects,
but
we
only
use
tracing
for
now.
So
it
doesn't
help
much
for
logging
and
metrics.
F
G
A
D
There's
the
native
image
tracing
agent,
that
documents
all
reflection,
use
cases
and
anything
else
like
proxy
classes.
D
A
Right,
but
that
that
is
to
generate
the
additional
metadata
to
feed
the
native
image
building
right
I
was
trying
to
think
if
there's
wondering,
if
there's
a
way
for
us
to
essentially
run
our
open
Telemetry
tests
in
Native
mode,
in
a
way
that,
if
we
ever
break
stuff,
we
would
those
tests
would
fail
like
if
we
ever
do
something.
That's
not
compatible
with
Native
mode.
F
A
F
A
A
J
All
the
tests
can
run
in
both,
but
quarkos
is
built.
Basically,
it's
built
to
to
get
out
of
the
way
classes
that
are
not
going
to
be
used
and
that
helps
in
building
on
Native
mode,
because
we,
we
know
all
the
classes
that
and
we
exclude
them
up
front
and
we
can
add
them
and
do
that
all
that
creative
work
for
for
the
apps.
J
So
there's
no
difference
between
the
the
test
that
we
run
in
both
modes,
but
for
a
normal
class,
for
example,
the
framework
that
we
used
for
tests.
If
it
uses
reflection,
it
will
give
us
problems.
A
Do
we
have
integration
any
like
integrate
things
that
we
would
consider
integration
tests
in
the
core
repo
that,
like
run
through
a
full
like
export,
to
collector
kind
of
a
thing.
E
Yeah
there
is
actually
so
there's
there's
there's
a
directory
in
the
top
in
the
root
of
the
project
called
integration
tests
and
one
of
the
main
things
in
it
is
that
it
spins
up.
You
know
the
SDK
and
it
the
SDK
exports
data
to
The
Collector
and
then
the
collector
exports
data
back
into
the
Java
process,
so
that
we
can
verify
the
end-to-end
flow
there's
also
a
directory
that
was
recently
added
for
Grail
yeah.
E
It's
specifically
trying
to
test
this
this
another
issue.
Somebody
came
across
where
there
is
a
there
within
JC
tools,
there's
a
what
does
it
use
it.
B
A
Oh,
but
this
is
a
unit
test
right
right,
not
really,
but
foreign,
okay,
yeah,
yeah,
I
I
know
it
will
be
a
lot
of
work
at
some
point
to
figure
all
that
stuff
out.
J
And
maybe,
if
just
one
small
application
that
does
small
things
and
make
sure
it
works,
it
will
already
help
because
it
would
give
a
smoke
test
a
container
like
quarkers
or
anything
else
would
be
trickier.
Because,
usually
when
we
release
we
do
breaking
changes
and
well.
J
E
E
And
then
there's
a
GitHub
action
that
specifically
runs
the
build
with
the
The
Grail
native
image,
and
so
basically
only
that
one
test
runs
when
you
do
that.
F
A
We
have
a
separate
crawling.
Oh
so
we
compile
it.
Oh
no.
We
just
print
the
version.
Oh
okay.
Oh
that's!
Really!
Cool.
A
E
A
I
know
that
yeah
we're
starting
John
and
I
are
starting
to
think
about
Native
image,
support
on
the
auto
instrumentation
side,
and
so
hopefully
we'll
get
a
better
feel
for
Native
image
stuff
over
the
coming
months.
Just.
C
Cool
because
it's
being
kind
of
dead
over
the
last
few
months-
and
it's
still
like
super
interesting
and
it
has
lots
of
potential
so
yeah
yeah
I'm,
looking
forward
to.
A
It
yeah
one
of
the
things
and
since
we
have
some
people
who
know
way
more
about
more
about
raw
here,
the
main
issue
that
I
think
that
we've
kind
of
identified
with
the
auto
instrumentation
stuff
and
the
the
ahead
of
time
is
in
Graw.
It
seems
like
there's
just
a
single
class
loader
like
where,
so
you
can't
have
multiple
class
loaders
and
everything
just
gets
sort
of
this
one
flat
class
loader.
H
Well,
it
has
been
a
while,
since
I
looked
at
growl
VM,
but
as
far
as
you
remember,
there
is
no
concept
really
of
class
loading
at
all,
so
you
can
refer
to
class
loaders,
but
these
are
just
facets
to
empty
functionality.
There
is
nothing
going
on
behind
that.
J
Class
loading
is
more
for
run
time
and
when
you
are
linking
all
the
the
codes
you
get,
the
output
there's
you
leave
after
you
compile
in
Native
mode.
You
live
on
a
closed
work
closed
world,
so
everything
that
needs
to
be
loaded
is
already
loaded.
A
H
No
I
think
this.
This
should
work
because,
but
it's
results
statically.
So
if
you
have
two
classes
with
the
same
name,
but
they
are
loaded
by
different
class
loaders,
they
will
load
during
the
compilation
time
and
be
resolved
to
different
classes,
because
you
don't
see
the
classes
either
you
see.
Well,
there
is
a
class
object,
but
you
cannot
do
much
with
it.
It's
again,
it's
it's
just
an
object
like
a
like
a
normal
object.
A
H
H
Well,
they
will
be
different
right
because
they
are
different
classes
yeah,
so
so
growl
tries
to
preserve
the
semantics
as
as
much
as
possible.
Obviously,
but
there
are
Corner
cases
that
do
not
work.
J
And
and
sometimes
more
in
the
old
days,
one
one
interesting
problem
that
you
would
get
was
that,
because
we
were
trying,
if
you
were
using
several
class
folders,
you
would
get
some
weird
problems
like
this
object
of
this
class
cannot
be,
cannot
be
cast
to
this
class
and
things
like
that,
because
that
they
were
coming
from
different
worlds.
A
All
right,
yes,
I'm,
still
very
confused
by
native
images
but
hope
to
I,
could
ask
your
questions
about
that
all
day.
I.
Anything
yeah
well
we're
three
minutes
over
time,
but
any
last
thoughts
comments,
questions.