►
From YouTube: 2021-07-13 meeting
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
B
B
C
D
D
B
B
B
Yeah,
I
think,
because
there's
the
main
goal
of
being
able
to
substitute
in
our
project,
I
think
the
possibility
of
dependency
conflicts
that
can
be
worked
around
somehow,
even
with
shading.
So
that's
not
as
big
a
video,
but
if
we
have
no
way
to
substitute
in
the
project
dependencies,
I'm
not
sure
if
it
can
work.
B
C
Okay,
because
because
so,
if
we
actually
don't,
how
can
I
say
if,
if
we
don't
actually
recommend
our
end
users
to
apply
that
code
generation
plugin
but
apply
java,
instrumentation
plugin,
which
nevertheless
applies
that
dependencies?
So
that
may
be
not
not
a
big
deal.
B
C
But
but
for
example,
in
even
even
in
our
project,
we
have
this,
which
was
that
just
a
second,
I
believe
that
was
tasting,
coma
yeah.
B
B
B
C
Dependencies
can
be
substituted
but
and
okay,
I
can
understand
that
guava
and
what
else
there
is
some
other.
But
okay,
I
wanted
to
ask
that
open,
telemetry
java
edges
extension.
Api
still
should
be
dependency
direct
dependency.
But
that's
exactly
your
your
concern
with
substitution.
Okay,
I
will
check.
I
will
check
the
substitution.
C
Okay,
but
the
the
next
pro
problem
which
works
against
me.
If
you
have
runtime
dependencies,
if
then-
and
if
we
publish
that
plugin
now,
then
that
runtime
dependency,
what
version
will
they
have
right
now?
It
would
be
1.4
snapshot,
which
is
bad,
so
you
have
one
more
chicken
and
egg
problem.
If
you
have
runtime
dependency
in
our
plug-in,
which
we
use
in
our
project,
how
do
we
have
all
all
published
dependencies
to
be
stable,
so
that
may
be.
E
B
C
But
but
but
we
don't
want
on
every
release
to
make
to
make
that
dance,
I
mean
we
cannot
release
plug-in
against
okay,
we
substitute
I'm
trying
to
think
in
what
order
do
we
do
we
release
what
artifact
yeah.
B
B
B
D
C
B
B
Does
the
plugin
directly
used
extension
api?
I
thought
it
just
caused
the
body.
C
For
example,
instrumentation
module.
It
directly
calls
instrumentation
instrumentation
module
well,
not
directly
through
type
description.
Okay,
I
have
to
check,
I
mean
it
does
use
it,
for
example,
implements
type
transform
from
extension,
api.
E
B
C
C
C
E
E
C
B
C
C
Foreign,
where
my
share
about
intelligent
yeah
here
it
is
so
we
have
this
class.
E
E
E
C
B
C
But
if
we
introduce
new
features
into
extension
api,
I
cannot
be
right
away
like
publish
a
new
version
of
extension,
api
publish,
a
new
version
of
the
plugin
and
then
publish
the
new
version
of
the
main
project
I
mean
in
development.
We
still
can
try
to
use
gradle
composite
build,
so
we
can't
develop,
but
we
publish
like
in
the
correct
order-
and
we
are
good.
B
Like
would
we
be
able
to
develop?
That's
what
I'm
not
because
so
muzzle
would
generally
not
allow
us
to
use
any
new
api.
We
added
to
the
extension
api
unless
it
was
using
the
new
stuff,
and
so
I
feel
as
if
like
we
wouldn't
be
able
to
develop
anything
based
on
that
thing
until
the
next
release
so
always
delay
implementation
of
any
extension
by
a
release.
E
B
Yeah,
I
think
we
have
our
problem.
Whatever
the
best
solution
is,
we
should
just
take
it.
I
don't
know
if
something
that
doesn't
involve
the
substitution
can
work
better,
but
if
there's
something
that
can
work
better,
of
course,
I'm
good
with
anything
that
works,
but
I
definitely
what
what
I
don't
think
works
is
happens
to
wait
until
the
next
release
to
use
a
new
extension
api
stuff
and.
E
B
C
C
Another
problem,
while
we
are
here,
is
that
I
discovered
when
trying
to
apply
that
that
gradle
plugin
in
splunk
repository
that
I
have
in
the
in
our
module,
which
uses
a
module
from
instrumentation
repo
like
93.8
implementation
known.
So
I
have
to
add
that
open
telemetry
module
to
codegen
plug-in
of
our
modules.
C
B
B
B
E
No,
I
think
that
compile
class
path
should
probably
be
fine,
but
that's
no,
that's
just
more
or
less
of
a
guess.
E
C
So
I
actually
not
sure
that
that
changes-
substitution
question
anyhow,
okay,
actually,
but
but
that
may
solve
that
separate
problem
yeah
I
will.
I
will
try
to
compile.
E
E
Yeah,
so
we
don't
run
any
muzzle
or
any
latest
previous,
that
tests
for
our
open,
telemetry
api,
open,
telemetry,
annotations
modules,
and
this
actually,
there
was
actually
a
bug
yesterday
that
occurred
in
the
span
attribute
pr
that
was
miraculously
and
totally
accidentally
found
by
the
smoke
test,
which
used
open,
telemetry
annotations,
one
zero
that
didn't
have
this
manatee
with
annotation
and
yeah.
So
we
should
probably
do
something
about
it,
because
sooner
or
later,
and
probably
sooner,
we
will
have
a
lot
of
matrix
code.
E
E
But
once
it's
published
it's
like
any
other
any
other
library
that
we
depend
on
so
no
changes
needed
for
motherboards
or
anything.
E
C
D
D
D
But
yeah,
if
I
think
of
anything
I
hope
host,
but
I
think
it's
yeah,
it
seems
like
a
great
idea.
I
can't
think
of
anything.
E
Yeah
wait
a
minute:
oh
what
how
no?
There
is
one
problem
to
it.
I
just
thought
about
it
now,
so
we
just
switched
to
1.4.0
right
and
there's
no
one
that
for
the
zero
shaded
artifacts
publish
anywhere
assuming
we
published
it
since
the
start
so
muzzle
muzzle,
doesn't
pick
up
snapshots
and
if
we,
even
if
we
published
all
those
previous
versions,
if
we
run
muzzle
now
it
wouldn't
pick
up
the
one
for
zero
version,
because
the
the
shade
that's
like
it's,
not
it's
not
released
yet.
D
E
B
D
B
E
D
D
Yeah
I
know
like
I
have
smoke
test
running
against
one
zero
zero
api,
so
that
seems
to
still
be
passing,
but
I
haven't
updated
to
one
four
zero.
So
what
was
I
missed?
The
the
span
after
the
problem.
E
B
And
so
then,
this
sort
of
brings
my
other
topic.
I
guess,
and
that,
if
muzzle
is
an
all-in
thing,
how
are
we
going
to
keep
on
supporting
these
new
features
going
forward
like?
Do
we
always
have
to
use
reflection?
Hacks,
like?
Is
that
the
correct
thing
to
do,
or
do
we
need
a
new
mechanism
that
can
allow
somehow,
like
these,
for
example,
span
attribute,
is
scoped
to
some
code,
that
is
muzzled,
but
not
the
entire
instrumentation.
B
D
C
D
Because
they
put
open
tracing
in
the
bootstrap
class
loader
as
their
bridge-
oh
they
don't
have
a
bridge
likely
to
do
now.
They
do
now.
E
D
E
D
C
Yeah
so
as
we
plan
to
have
1.4
this
week,
am
I
correct,
or
sometime
very
soon,
time
flies.
I
wanted
right
after
release
of
1.3,
to
write
a
proper
documentation
for
extension,
mechanics
how
to
use
it
and
whatnot
I
didn't
do
I
didn't
do
that,
but
so
my
question
is
when
and
how
do
we
want
to.
D
So
for
this
part,
I
think
we
discussed
this
last
week
and
said
that
it
doesn't
help
us
for
the
extension
mechanism
to
be
stable
before
everything
else
is
stable.
C
C
C
C
D
I
would
support
deprecating
both
of
these
in
one
four
zero
and
if
we're
deprecating
them,
I
think
we
would
want
to
rename
that
at
the
same
time,
right.
E
C
I
think
my
preference
would
be
to
already
rename
that
to
make
that
stable,
like
say
yes,
hotel
extension
jar
is
the
new
pro
new
way
to
go.
It's
supported.
We
will
not
remove
that.
That's
it.
A
D
Oh,
I
wanted
to
ask
get
your.
I.
C
B
I
don't
remember
what
I
mean,
but
I
think
we
were
thinking
of
something
like
providing
the
sdk
and
no
other
classes
from
the
agent
class
loader,
so
yeah,
not
so
isolated
from
the
agent
class
leader,
not
only
from
each
other.
We
had
some
ideas
about
that
for
nettie,
those
sort
of
version
conflicts
or-
I
guess
grpc
specifically.
B
B
B
D
C
C
C
C
C
If
sometimes,
we
start
isolating
and
they
all
of
a
sudden
start
using
the
round
grpc
version
that
will
break
only
if
they
have
like
compile
time
and
run
time.
D
Yeah
now,
what
would
it
just
kind
of
curious
through
briefly,
what's
the.
D
C
D
D
Yeah,
I
was
wondering
which
I
forget,
which
method
you
have
to
override
but
basically
find
class
instead
of
calling
super.
C
Yeah,
that's
that's
exactly
the
another
one,
I'm
just
finding.
E
D
D
What
I
was
hoping
we
could
do
is
something
like
parent
first,
but
only
look
in
certain.
C
E
C
C
E
C
D
Ideally
yeah,
I
mean
right
like
it's
okay,
if
we
I'm
okay,
if
we
want
to
cut
that
cut
corners
there
and
just
document
document,
it.
C
D
It
out
either
the
prefix
or,
if
there's
some
kind
of
allow
list
of
packages
that
I
I
was
just
hesitating
on
this
part,
because
I
know
that
data
dog
folks
have
said
a
few
times
that
if
they
didn't
need
that
support
they
would
they
wish
that
they
could
remove
it.
D
All
right,
this
is:
let's
move
this
to
the
end,
because
that's
not
even
our
repo.
D
D
D
In
this
case,
I
think
it's
even
easier,
potentially
easier.
The.
D
D
So
anyway,
not
not
one.
A
more
important
topic
I
did
want
to
try
to.
There
were
a
few
pr's
hanging
out.
This
one
was
the
materials,
the
instrumentation,
specific
bootstrap
classes
and
basically
kind
of
the
remaining
question
there
was
where
to
aggregate
those
bootstrap
classes.
D
Originally,
there
were
aggregated
in
this
module
then,
but
it
felt
a
little
bit
weird
because
we're
using
the
bootstrap
module
to
build
other
things
and
then
putting
them
back
in
this
aggregator
module.
So
the
question.
E
C
Yeah-
and
that
is
bad
in
my
opinion,
as
soon
as
we
start
you
separating
instrumentations
into
country
people,
we,
we
will
need
to
have
a
functionality
to
take
just
an
instrumentation
and
put
that
into
our
java
agent,
and
that
then,
that
instrumentation
aggregation
is
like
duplicating
the
same
work.
So
we
don't
need
that.
D
So
can
we
move
the
material
if
we
move
this
aggregation
into
java
agent
would
is
there
any
place
that
needs
to
be
duplicated.
E
It
no,
I
I
think
it
would
work,
because
we
we
don't
we're
not
using
any
instrumentations
in
the
testing
world
interesting
java
agent,
so
it
would
be
just
moving
things
from
one
place
to.
D
Another
yeah,
I
don't
have
I
I
don't
personally
object
to
the
copy
paste
copy
pasta
that
much
I
I
would
be
fine
if
it
helps
to
clean
up
the
structure.
E
Okay,
so
I'll
try
to
move
all
the
dependencies
and
all
the
aggregation
into
the
generated,
module
and
copy
what's
needed
to
the
testing
the
agent.
D
Yeah,
do
you
want
to
merge
this
first
then?
Do
that
as
a.
D
B
D
To
you,
you
have,
you
have
two
approvals,
so
feel
free
if
it's
easier
to.
If
you
want
to
revert
part
of
this
and
merge,
and
do
that
as
a
separate
pr.
E
D
E
D
Did
I
put
this
one
on
oh
yeah?
I
wanted
to
merge
this,
but
I
wasn't
sure
if
the.
C
D
C
C
So
but
back
to
the
point,
I
think
that
we
before
merging
that
snapshot
example
pull
request.
We
have
to
agree
how
do
how
do
we
proceed
with
the
tags
and
versions
and
snapshots?
C
Then
the
answer
will
be
easier.
We
build
snapshots
always
against.
We
built
examples,
always
against
snapshots,
except
for
version
tag
which
uses
specific
version.
A
D
All
right
this
one
materiash-
you
didn't
sound
very
convinced
about
this,
so
convince
us.
E
Yeah,
it's
because
I
mean
both
of
these
make
sense,
so
it's
kind
of
like
a
stylistic
issue
so
actually
internally
for
every
task
that
spring
batch
3
is
this
chunk,
which
is
basically
equivalent
to
a
database
transaction.
E
So
the
the
previous
version
was
essentially
correct
that
we
use
the
chunk
as
the
span
name,
but
it
might
be
confusing
for
people,
because
it's
not
a
public
knowledge
that
spring
but
creates,
creates
a
tank
for
everything
because
in
their
documentation
they
advertise
like
two
distinctly
separate
modes
of
processing
that
you
have
either
the
item
change,
oriented,
item,
processing
and
separately.
You
can
have
the
taskbar
processing,
which
is
basically
you.
You
insert
your
custom
code
and
it
does
what
you
want
and
there's
hardly
any
mention
of
creating
a
chunk
for
a
task
clips.
E
So
I
understand
how
it
can
be
confusing
for
string
but
instrumentation
users
that
they
were
using
tasked
but
they're
getting
the
change
and
that
that's
not
what
the
docs
said,
even
though
it
doesn't
really
reflect
the
internal
in
the
internals
of
spring
batch.
It's
it
kind
of
makes
more
sense
from
the
user
perspective
closer
to
the
users.
D
This
is
the
spec
issue
about
the
nested
client
spans,
and
so
the
the
reusing
requests,
as
we
saw
most
of
the
instrumentations
actually
do
in
java,
do
support
that
kind
of
reuse.
So
it's
it's
a
at
least
it's
a
real
issue.
D
D
There's
two
reasons
to
I
that
we
want
that.
I
that
I
could
that
I've
seen
in
the
discussion
so
far,
one
is
to
avoid
overriding.
The
trace
parent
from
an
outer
client
span
and
the
other
is
to
by
default,
suppress
the
nested
client
span
but
or
conditionally
suppress
the
nested
client
span,
depending
on
user
preference,
and
then
so
I
was
trying
to
kind
of
split
it
into
one.
D
What
that
the
need
is-
and
the
other
is
the
different
ways
to
accomplish
that
so
one
is
which
was
in
sort
of
ludmila's
initial
proposal-
was
she
was
trying
to
keep
it
simple
and
was
like
well,
we
could
we
don't
need
a
new
api
if
we
can
check
the
presence
of
the
trace
parent
header
and
that's
how
we
could
know
if
we're
in
a
nested
client
span.
D
D
You-
may
not
be
able
to
check
that,
and
this
requires
clearing
the
trace
parent
at
the
end
of
the
request,
if
reuse
is
supported
so
that
you
can
rely
on.
D
The
next
time,
one
other
option
is
some
kind
of
marker
in
the
context
essentially
similar
to
what
we
do
in
the
with
the
client
span
so
yeah.
So
I
was
trying
to
kind
of
break
it
like
how
to
move
forward
on
this.
One
is
trying
to
get
agreement
from
everybody
that
we
really
do
need
a
way
to
identify
if
we're
in
a
nested
client
span.
D
B
D
Yeah,
it's
sort
of
all.
I
is
coming
from
this
one
spun
off.
D
D
Because
john
noticed
that
successive
calls
are
supposed
to
clear
the
fields
first,
because
the
in
this
one
was
where
ludmilla
was
proposing
to
use
that
trace
parent.
B
B
B
D
Oh,
oh,
I
switches
in
if
it
already
I
see
so
like
a
downstream,
you
make
a
http
client
out.
It
goes
through
envoy.
We
need
to
give
on
voice
some
rules
on
when.
B
B
B
D
B
C
D
And
one
other
for
that
context.
Key
any
thoughts
on
whether
like
it
was
storing
the
span
in
the
context
similar
to
what
we
do
in
the
instrumentation
versus
just
a
boolean
flag.
D
The
only
thing
I
could
think
of
the
only
advantage
to
this
as
an
object
was
just
I
think
the
server
span
has,
although
we
don't
have
that
concept
yet
in
open
telemetry,
we've
found
it
useful
in
instrumentation
to
call
update
name
on
for
the
routing,
so
this
sort
of
has
some
symmetry
there
if
it's
client
span
and
server
span,
but
I
don't
think
our
instrumentation
currently
does
anything
other
than
check
if
the
client
span
exists,
so
I
think
a
boolean
flag
would.
D
C
B
D
Well,
it's
good.
I
think
I
chatted
with
lingoa,
so
I
think
we're
gonna
try
to
put
together
some
kind
of
context,
key
based
proposal.
D
I
think
she's
she's
on
board
with
that
just
she
was
hoped.
I
think
she
was
hoping
to
get
something
simple
which,
as
we
know
with
the
specs,
is
never
possible.
D
All
right
anything
anybody
else
wanted
to
touch
on
today,
one
of.
B
D
Okay,
yes,
yes,
yes,
approve,
feel
free
to
do
what
you
want
to
with
my
two
comments.
D
The
type
parameter
type
names
the
I
personally
like
to
have
some
different
convention
for
parameter
types
from
type.
D
C
C
B
D
I
find
it
very
like
short
of
the
like,
if
I'm
reading
it
reviewing
the
code
in
github
like
I
find
it
very
helpful
to
know
if
it's
a
type
parameter,
because
otherwise
it's
so
it's
so
different.
If
I
know
it's
a
generic
versus
a
specific
type.