►
From YouTube: 2021-02-26 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).
B
A
A
E
That's
unfortunately,
saying
that
I
don't
normally
sound
clear.
E
All
right,
you're
gonna,
keep
two
of
me.
Oh,
I
know.
B
E
D
D
D
Yeah,
okay,
and
so
I
said
man,
I
don't
know
of
a
good
way,
there's
probably
something
clever
that
I
don't
know
of,
but
you
could
always
resort
to
looking
at
the
command
line
options.
D
C
D
Of
course-
and
I
can't
remember
his
use
case-
it
was
something
to
do
with
spring.
Let
me
see
if
I
have
more
detail
on
my
history
here.
Oh.
F
E
C
D
C
F
E
Yeah,
so
what
we
want,
what
we've
discussed
but
not
implemented,
is
we
want
the
agent
to
we
want
that
logic
to
be
in
the
agent
like
the
the
library
instrumentation?
E
C
C
C
E
Which
is
maybe
what
john
is
thinking
of
from,
but
from
the
library
instrumentation
side
of
having
that
awareness
of
checking.
If
the
agent
is
running
yeah.
C
E
The
other
is
our
that
john
brought
up
is
sort
of
the
server
span.
Contact
client
stand
in
the
context
which
we
haven't
implemented.
A
A
E
Yeah,
so
this
would
potentially
be
a
good
starting
point
for
what
john
is
looking
at,
because
without
this
interrupt.
E
Okay
and
if
I
recall
honorable,
you
had
sort
of
made
that
pretty
nice
to
bridge
things
that
were
in
the
context.
G
D
D
D
C
D
Lot
of
people
use
it,
so
it's
yeah,
they
point
pool
to
it
all
the
time.
My
next
one
kind
of
leads
into
that.
So,
if
we're,
if
we're
ready
to
move
on,
I
am
thinking
about
customers
who
users
who
might
have
some
of
their
own
functionality,
whether
it
be
like
add-on,
instrumentation
or
something
that's
kind
of
telemetry,
related
or
hotel
related,
but
isn't
part
of
any
distro,
and
they
don't
want
to
roll
their
own
distro,
for
whatever
reasons
like
they
might
just
have
some
stuff
sitting
in
a
jar.
D
The
way
that
new
relic
handles
this,
I'm
not
sure
about
datadog,
but
the
way
the
new
relic
handles
it
is
that
they
watch
a
directory
and
if
they
see
a
jar,
there's
an
un
documented
api
there
about
loading
jars
and
running
code
from
it.
Basically,
I
think
they
look
for.
D
I
think
they,
I
think,
they'd
look
in
the
manifest
for
agent
main
or
pre-main
or
whatever
the
other
one
is,
and
then
they
just
run
that
class,
and
so
it's
a
good
extension
point
for
people
that
just
want
to
bootstrap
stuff
in
a
seemingly
seemingly
smooth
way
without
having
to
change
user
code.
That's
another
big
requirement
right
so,
and
they
also
don't
want
they
don't
want
to
add
this.
Is
I
guess
this
is
where
it
gets
a
little
bit
silly?
Is
they
also
don't
want
to
add
another
java
agent
command
line
switch?
E
Have
you
seen
this
one,
the
hotel,
initializer
jar?
A
E
E
E
No,
I
don't
think
so.
I
think
it
really
does
only
add
yeah.
All
really.
All
it
does
is
add
your
jar
to
the
agent
class
loader,
okay,
and
so
then
you
can
use
the.
A
E
So
spi
like
this,
for
example,
I
think,
is
a
good
one,
because
then
you
can
even
add
like
a
span
exporter,
for
example,.
D
D
E
Oh,
this,
like
you,
could
create
an
spi
class
for
this,
and
we
would
call
it
from
the
agent
and
you
could
use
that
just
as
a
hook
to
get
to
execute
some
code.
C
E
D
E
So,
like
you
could
implement
a
property
source
again,
there's
probably
nothing.
That's
really
truly
like
a
no-op
yeah.
That's
that's
almost
what
I'm
asking
for,
but
it's
just
such
a
weird
use.
There
you
go
this.
D
D
Perfect,
I
like
that
answer
and
that's
all
I
had
other
than
just
again
in
person
or
face
to
face
to
say
thanks
for
honor,
for
jumping
on
that
log
for
j
thing,
which
was
pretty
wacky.
C
Like
so,
I
did
want
to
talk
a
bit
about
in
general,
I
mean
so
I've
been
at
like
I
care
a
lot
about
the
safety,
and
so
this
was
the
worst
possible
outcome
where
we
ruined
the
user's
logs
the
only
way
to
have
avoided.
This
was
first
one
of
us
to
ran
into
this
problem
before
and
proactively
knew
about
it
to
fix
it.
There's
yeah
yep.
F
F
C
D
Pretty
exciting
yeah
I
mean,
I
guess,
there's
a
discussion
maybe
to
be
had
about
how
much
of
a
habit
we
want
to
get
in
of
fixing
library
bugs
in
instrumentation.
But
in
this
case
it
was
so
small.
Yeah
bits
are
huge
that
I
think
it's
worth
doing,
but
I
think
it
should
come
with
a
big
asterisk.
C
B
C
E
I
guess
yeah,
it's
tricky
yeah.
I
guess.
If,
if
there
really
wasn't
a
good
way
for
us
to
resolve
it,
then
I
guess
they're.
You
know
we
can
only.
E
Yeah
yeah,
I
still
feel
like
that's,
you
know,
sort
of
goal.
Number
one
is
not
to
break
users
apps.
E
Okay,
it
is,
I
mean
it
is
a
you
know,
it
is
a
risk,
as
we
try
to
do
more
use
library
hooks
more
right,
like
that's
part
of
what
yep.
E
And
you
know,
but
we're
we're
sort
of
already
down
that
path
of
things
like
wrapping
handlers
like
wrapping
callbacks
like
having
you
know,
introducing
our
own
types
sort
of
into
the
users
flow
which
potentially
they
could.
E
Cast,
I
guess
callback
handlers
are
pretty
safe,
though,
because
that's
you're
just
passing
one
way
down
into
the
library
yeah.
C
Okay
and
yeah,
we
can't
see
any
way
to
have
avoided
this
log
problem.
This
is
when
we
just
have
to
hit
the
mind
and
fix
it,
and
if
that's
the
case,
that's
fine
just
wanted
to
do
one
small
retrospective,
I
guess
testing
and
but
yeah,
like
I
think
in
this
case.
It's
just
like
it's
such
a
weird
corner
case
where
you
have
to
not
have
servlet
on
your
class
path,
have
to
be
the
specific
that.
E
Is
so
weird
yeah
like
yeah,
because
one
thing
I've
thought
about
is
you
know
we
we
test
latest,
but
potentially
we
could
test
more
version.
We
could
run
our
tests
against
more
versions.
Unfortunately,.
C
B
E
Yeah,
that
was
a
yeah
yeah,
but
it
like
hit
all
of
our
worst
possible
cases,
yep
yeah,
and
so
in
those
cases
you
know
my
my
fallback
will
be
hey.
You
know,
that's
why
we
build
a
big
community
and
have
lots
of
people
using
it
so
that
you
know
we
can
all
benefit
from.
You
know
one
person
running
into
this
yeah,
okay,.
E
H
I
was
thinking
if
discussion
about
the
plan
for
tomorrow
and
what
do
we
do
for
or
tomorrow
evening.
I
think
it's
tomorrow
evening,
release.
H
We
have
couple
of
couple
of
issues
marked
as
one
zero
and
I
wanna
see
if
we
want
to
fix
them
or
we
push
them.
C
H
C
E
C
E
It's
an
amazing
piece
of
code.
It's
been
around
for
a
long
time
too.
It's
some
really
cool
stuff
and
drove
a
lot
like
some
of
the
java
8
type
annotation
stuff.
H
One
one
other
thing
is:
if
you
go
to
the
issues,
so
that's
okay,
so
we
can
move.
Can
you
can
you
move
the
java,
though,.
C
H
H
Okay,
then
there
is
the
other
one
that
I
filed.
So
you
know
we
had
to
change
the
the
extract.
H
G
H
C
H
And
so
yeah,
ideally
is
to
not
put
span
in
valley
span
valid.
If
you
fail
to
parse,
you
either
put
something
valid
or
or
don't
change
the
incoming
context.
Anyway,
that's
the
the
contract
that
we
want
to
have
here,
and
I
think
we
need
to
verify
that
it's
I
made
an
umbrella
issue,
the
other
last
one
that
I
know
of
on
the
java
repo
is
that
trace.
Flag
thing
on
the
pr's
is
a
pr
from
me,
which
I
I
dropped.
The
ball.
H
I
didn't
have
time
to
look
into
it,
but
on
the
prs
there
is
that
flag
trace
flags
yeah
that
that
one?
I
don't
know
what
to
do
with
this
one.
Do
we
want
to
merge
it?
Do
we
want
to
drop
it
fine,
but
we
need
to
kind
of
make
a
decision.
H
H
C
H
Okay,
so
yeah,
that's
that's
the
implication
that
I
did
not
know
how
to
handle
and
what
to
do
with.
With
that,
that's
why
I
I
was
postponing
a
bit
on
this
anyway.
I
think.
For
me,
these
are
the
only
remaining
issues
or
or
things
that
we
we
have,
if
you
think
about
anything
else,
but
the
the
verification
of
the
propagators
can
happen
after
the
thing.
It's
not
going
to
be
a
breaking
change.
It's
going
to
be
a
bug,
fix
sure
we
can
do
a
patch
release.
We
can.
H
I
think
the
even
the
the
returning
of
the
list
could
sorry
can
happen
after
it's
it's
a
bug.
If,
if
we
do
that,
I
I'm
not
sure
about
these
trace
flags
thing.
If
it's,
if,
after
one
zero
will
be
a
behavior
change,
that
will
be
very
bad
for
user,
I
I'm
not
gonna,
I'm
not
sure.
That's
what
I
mean.
H
B
H
Why
that's
why
I
know
exactly
we
are
in
a
very
blurry
area.
Let's
put
this
is
not
an
api
breaking
change,
it's
not
an
abi
breaking
change,
but
it's
kind
of
a
behavior
breaking
change
in
a
way,
and
we
kind
of
have
to
make
a
decision
on
this
one
returning.
No,
I
I
got
what
we
don't
want
to
have.
That
was
an
initial
proposal,
but
but
we
need
to
to
make
a
decision.
C
C
I
C
C
I
C
H
H
H
H
My
my
idea
was
that
I
want
to
to
tell
users
that
an
alternative
implementation
may
throw
you
npe.
If
you
are
passing
the
null
here,
that's
why
we
don't
have
a
nullable
annotation,
so
you
need
to
be
aware
that
okay,
the
sdk,
may
not
do
it,
because
we
document
the
sdk.
We
should
not
do
it,
but
an
alternative
implementation
from
the
api
perspective
can
throw
mpe.
C
Like
I
mentioned
once
in
one
in
christian's
issue
on
the
spec
republic,
soon
that
the
less
scary
words
we
can
have
in
our
api
the
easier
it
is
to
get
frameworks
at
amazon
or
whatever
instrumented
yeah
so
like,
and
then,
if
the
sdk
being
introduced,
causes
problems,
at
least
that's
not
on
the
framework
owner's
side,
that's
the
end
user
side,
so
the
framework
owner
is
less
scared,
that's
the
experience
I've
had
so
I
want
don't
want
to
be
too
scary
in
the
api
if
we
can
avoid
it
like
it
should
like,
and
someone
who's
using
the
apn.
C
H
I'm
trying
to
not
document
anything
to
just
but
also
not
document.
We
we
remove
all
the
throws
and
pe
no
longer
says
throws
in
key
because
that
would
have
been
a
contract
and
we
didn't
want
to
have
that
as
a
contract
in
our
api.
But
so
far
we
don't
see
anything.
Maybe
maybe
we
just
put
a
package
level
comment
that.
H
Invalid
input
may
be
here
for
invalid
input
may
be
undefined
or
undefined.
H
Fine,
okay,
I'm
fine
with
that.
As
long
as
you
say,
if
a
user
comes
and
tell
me
that
hey,
I
got
an
npe
here,
I
can
tell
them
back
sure.
We
documented
here
that
it's
possible,
if
you
pass
me
null
that
an
implementation
will
throw
you
mpe,
I'm
fine,
okay,
so
maybe
we
can
close
that
pr
and
start
a
new
one.
We
just
document
the
package
level.
C
E
Yes,
good
work,
good
everyone
that
was
a
that
was
a
long
what
you
started.
What
like
may
like
almost
two
years
ago
now.
I
H
C
E
H
H
Don't
get
me
wrong,
but
I
think
this
is
the
reason
why
it
took
way
longer
than
expected,
because,
because
of
the
the
new
set
of
people
that
we
we
we
reached
to
via
the
new
the
the
new
project
like
new
relic
as
well,
I
don't
think
new
relic
was
implied
in
any.
It
was
was
part
of
any
of
the
previous
projects.
I
mean
they
pretended
to
use
open
tracing
here
and
there,
but
I
I
didn't
see
a
very
active
work
from
them
in
open
tracing
work.
H
So
there
are
a
bunch
of
examples
like
that
where,
where
I
think
now,
with
the
new
unified
project,
we
we
have
a
way
bigger
community
way
bigger
than
the
two
combined
like.
If
you
just
simply
combine
the
two
communities
is
half
of
the
current
size
of
one
tournament.
C
H
But
I
think
it's
a
good
thing
because
we
would
have
not
have
you
from
the
beginning.
Probably
a
lot
of
people
upset
about
some
of
the
decisions,
some
of
the
design
choices
and
they
would
not
be
happy
to
use
it
and
we
would
have
had
yet
another
standard
and
probably
yet
another
margin.
H
So
I
I
think
it's
much
better.
The
way
how
we
did
it
anyway,
I'm
very
happy
with
the
result
and
very
happy
for
all
the
work
that
you
guys
and
everyone
did
on
this.
But
these
are
my
thoughts
about
this.
C
E
Oh,
oh,
I
think
I
accidentally
hit
some
buttons
on
my
phone.
Oh
my
god,
this
is
going
to
be
great
yeah.
C
D
F
A
E
E
H
Yeah
other
gossip,
did
you
see
how
much
progress
we
made
on
metrics?
We
just
added
support
for
histograms,
adding
support
for
views
for
for
filtering
labels
tracking
from
baggages.
We
do
a
lot
of
crazy
stuff.
Yeah
seems
like
full
speed
ahead,
pretty
cool
pipes,
but
prototypes,
but
still
very,
very
clean
and
and
well
it's
working
really
good.
E
So
that
ties
into-
and
actually
this
will
be
good
to
have
your
thoughts,
bugged
and
also
on
so
the
instrumentation
api
artifact.
So
this
is
those
tracers
we
have
that
we
want
to
rename
as
instrumenters
and.
E
So
the
I
guess
the
high
level
question
is:
do
we
can
we
stabilize?
Can
we
release
one
zero
stable
of
this
api
instrumentation
api
before
metrics.
H
What
why
do
do
you
expose
publicly
anything
about
metrics,
not.
E
Yeah
talk
to
nikita,
he
was
voting
against
renaming
it
to
instrumental
this
morning.
What
but
we'll
get
there
there's
layers
to
this
discussion?
Okay,
so
you
so
we
have
start
span.
E
You
pass
in
your
parent
context,
you're
kind
of
your
stuff,
that's
important,
where
we
pull
out,
extract
data
from
and
and
then
later
on.
You
call
end
and
pass
in.
E
You
know
the
context
again
and
potentially
a
response
and
exceptionally
same
so
the
the
thought
I
think
we
had
discussed
with
you
previously
also
was
sort
of
turn
this
into
like
start
operation,
and
we
in
here
we
could
start
the
span
and
also
start
the
metric
timer
and
we're
already
kind
of
capturing
a
lot
of
the
dimensions,
probably
that
we
would
want
to
put
on
that
metric.
J
E
Which
is
I'm
keeping
tracer
keeping
this
the
way
it
is
and
introducing
http
client
meter
and
having
these
having
the
two
pillars,
stay
separate
at
this
layer
not
have
a
you
know,
I
mean
potentially
then
wrapping
something
on
top
of
that.
H
But
but
this
is
a
util
class,
it's
not
the
the
instrumentation
api.
I
expect
the
instrumentation
api
to
be
an
interface
where
I
pass
an
open
telemetry
instance,
and
it
returns
me
some
kind
of
plugin
or
automatically
installs
the
plugin.
Something
like
that.
I
that's
how
I
expect
to
be
that
interface,
that
you
make
it
one
zero,
because
that's
the
one
that
users
will
use
to
instrument
their
app,
so
so
I
would
start
focusing
from
there.
These
are
helper
classes.
H
For
me,
in
my
mind,
these
are
kind
of
helper
things
that
we
build
for
for
instrumentation
and
for
others
to
do
other
instrumentation,
but
is
not
the
final
user
which
consumes
an
instrumentation,
that's
a
different
api,
and
I
think
that
one
should
not
be
on
meter
on
things.
You
should
accept
an
open,
telemetry
object
instance
and
return
me
a
plugin
or
automatically
start.
The
plugin
depends
on
whatever
you.
However,
you
want
to
do
it
am
I
right
and
am
I
off.
E
No
I'm
so
that's
a
good
yeah.
So
if
we
go
that
route,
then
we
could
potentially
move
like
these
classes
under
a
dot
internal
package.
Yeah.
H
Yeah,
that's
how
I
see
things
for
the
moment,
and
I
want
you
to
just
expose
me
the
final,
like
thing
that
I'm
it's
like
more
or
less
like
a
configuration
class
that
when
I'm
passing
you
the
instance
that
you
want
me,
I
want
you
to
use
during
this.
I
may
be
able
to
pass
some
options
like
with
trace
with
metrics
bullets.
If
I
want
or
not
traces
or
if
I
want
or
not
metrics
to
be
things
I
may
want
to
to
also
maybe
even
give
you
the
propagators
will
be
in
the
instance.
H
Maybe
even
the
meter
I
can
put
the
knob,
so
I
don't
have
to
have
a
width
matrix
with
trace,
because
I
can
construct
the
instance
of
the
open
telemetry
that
has
a
no
op
for
for
this.
If
I
want
to
disable
the
metrics
or
the
traces,
what
else
do
I
want
I
want?
Maybe
probably
I
need
you
to
return
me,
some
kind
of
object
that
it's
the
plugin
that
I
need
to
put
in
grpc,
for
example.
H
E
Yeah,
that's
a
really
that
it's
a
good
way
of
looking
at
it
from
honorable
from
you
know,
trying
to
get
the
some
of
our
instrumentation
to
a
one,
zero
stable
spot
is,
I
mean,
and
it
would
not
be
as
configurable
right
I
mean
some
of
our
ideas
have
been
around.
H
Or
or
anyway,
right
right.
So
what
I
want
is
that
class
that
I
was
talking
about
instrumentation
or
whatever.
We
call
it
to
be
able
to
be
extended
in
the
future,
but
let's
start
with
something
from
there
and
then
we
can
see
how
we
extend
that,
but
give
us
the
minimal
api.
That
is
public,
and
that
should
be
the
only
public
api
that
we
expose
for
the
moment,
because
I
don't
think
people
need
more,
then
then
people
will
start
coming
and
asking
for
more
and
we'll
define
how
we
give
you
the
options
and
stuff.
H
E
Sort
of
I
mean
we
could
potentially
rename
instrumentation
api
to
instrumentation
internal
commons.
Internal
is
sort
of
what
it
would
become
then
for
now.
E
One
problem
we
have
is
the
sleuth
folks
have
have
taken
a
dependency
they
wanted
this.
They.
H
Because-
and
you
know
they
use
it
because
they
saw
it
here
and
if
it's
easy
to
use
it,
they
will
use
it,
but,
but
usually
I'm
always
challenging.
Why
do
you
need
things
like
why?
Just
the
the
public
things
that
we
have?
I
mean
this
was
public,
but
what
I'm
proposing?
I
think
this
should
not
be
public
for
the
moment.
This
should
be
internal
for
the
moment.
H
That's
one
thing
that
I
would
say
and
yeah
so
just
make
these
things
internal
and,
as
I
said,
give
me
an
interface
that
all
the
plugins
that
you
have
implement
so
then
I
can
consume
it
in
a
very
classic
way
for
everyone
and
that's
it.
C
Yeah
I
mean
this
is
yeah
like
leaving
the
instrument
instrumentation
api
as
an
implementation
detail
for
now
releasing
instrumentation
first
right.
Yeah
I
mean
that
seems
fine,
so,
in
our
like
it
would
mean
instrumentation
is
released
without
the
alpha
suffix.
Well,
instrumentation.
Api
still
has
the
alpha
suffix
right.
B
H
The
common
we
do
have
resource
and
couple
of
things
that
are
public,
but
we
have
an
internal
thing.
That
is
not
public.
E
Because
if
it's,
if
we
leave
it
as
dash
alpha,
I
mean
it's
still
a
transitive
dependency.
We.
H
C
H
Problems
yeah,
but
but
with
the
bombs,
if
you
put
it
in
common,
and
that
was
our
idea,
if
we
put
common
but
under
internal
directory,
we
can
mark
the
artifact
as
stable,
even
though
it
doesn't
have
any
stable
public
api.
It
has
only
stable
internal
apis
which
which
allows
us
to
put
it
in
the
bomb.
But
people
cannot
use
anything
from
the
package.
Only
us.
H
C
H
So
so
what
I'm
trying
to
say
the?
What
was
the
name
of
that
http
client
critical
for
for
this,
you
are
allowed
to
have
a
of
an
example
like
our
meria
client.
Tracer.
Extends
that
as
long
as
these,
you
can
have
extends.
H
C
H
That
that
just
accepts
some
options
and
returns,
you
returns
you
the
armenia,
interceptor
or
plugin.
I
don't
know
how
it's
called
things
like
that.
That's
how
I
envision
super
super
minimal
public
api.
That's
it!
No,
don't
give
users
nothing
public!
Everything
else
is
protected.
Okay.
I
think
that
should
work.
Okay,
yeah
and
it's
very
nice
as
well.
If
we
have
come
up
with
an
interface
like
that,
because
people
can
then
say,
I
have
a
hundred
things
that
implement
all
of
them.
These
can
build.
H
C
E
Yeah,
so
I
think
that
as
long
as
sort
of
that,
this
is
just
a
step
on
the
on
the
road
like
to
have
a
stable
ins
like
to
have
library,
instrumentation
releases
and
that
we
will
continue
to
work
on
making
the
tracers
instrumenters
good
and
stable
and
expose
those.
At
some
point.
E
E
For
pavel,
in
particular,
since
he's
inside
of
a
java
agent,
I
mean
he
can
do
whatever
you
can
take
hard
dependencies
on
those
still.
H
H
C
H
Everything
will
be
way
faster
because
you,
you
just
have
to
come
up
with
that
simple
interface
that
I'm
talking
about
with
some
options
and
stuff
and
that
should
not
take
a
trace
provider
or
a
meter
provider
should
take
the
entire
telemetry,
which
has
propagators,
has
everything
and
then
once
we
add
meter
there,
you
will
just
come
easily
in
that
object.
So
nothing
breaking
change.
No,
no!
Nothing!.
H
When
we
make
that
publicly
available
and
other
libraries,
if
they
really
want
to
exclude
their
stuff,
they
can
play
the
same
trick
with
bombs
and
stuff
and
and
include
that
dependency
and
force.
That
dependency,
I
mean
there
are
solutions
so,
but
we
don't
expose
that
publicly.
That's
that's
the
thing.
A
E
Yeah
yeah,
that
was,
that
was
great,
a
great
insight
that
we
were
missing.
E
Nikita
was
asking
I
mean
brought
up.
I
mean
this.
This
topic
comes
up
every
couple
months
of
continue.
Do
we
continue
to
pile
everything
into
a
single
repo
and
we
continue
to
have
the
same
answer,
which
is
we
don't
know
and
we
kicked
the
decision
down
the
road
a
little
bit
longer
yeah?
E
What's
the
experience?
What's
your
experience
in
the
collector.
H
To
be
honest,
it's
not
the
best.
Let's
put
this
way,
it's
not
the
best
biggest
problem
that
I've
seen
so
far,
also
also
by
the
way,
one
of
the
things
that
may
be
possible,
if
you
can
do
it,
is
limit
the
dependency
when
you
have
an
instrumentation
or
something
limit
the
dependencies
that
you
bring,
I
mean
for
for
a
collector.
H
A
bunch
of
people
wrote
their
exporter
by
depending
on
a
previous,
whatever
fat
library
that
they
had
for
for
as
a
client
library
or
something
instead
of
depending
only
on
the
proto
that
they
want
to
send
and
generate
a
small
grpc
client
and
just
send
them
to
the
to
the
back
end,
so
they
they
bring
in
the
entire
world
that
they
have
constructed
around
around
as
a
client.
So,
for
example,
it
was
this
case
for
lucky
logs
thing:
they
brought
they
brought
initially
a
dependency
like
100
megabytes
or
something
like
where
the
heck
guys.
H
Then
we
copied
only
the
protos
from
there.
Indeed,
it's
not
ideal
to
copy
the
products,
but
but
I
think
this
is
one
of
the
problem
that
we
have
and
maybe
maybe
you
will
face
the
same
problem
with
the
with
dependency
and
transitive
dependencies
and
inability
to
upgrade
things
and
and
so
on
and
so
forth.
E
Yeah,
it's
kind
of
different,
the
instrumentation,
our
experience,
because
it's
not
so
much
like
all
these
different
vendors
like
contributing
their
own
stuff.
I
think
it
helped.
I
think
the
experience
in
the
instrumentation
reposal
been
a
little
bit
better
since
it's
a
smaller
group
of
people
who
are
just
pulling
in
the
instrumentation.
E
H
The
problem
that
you
may
face
in
the
future
because
of.
E
H
H
I'm
pretty
confident
you'll
get
popular
once
you
put
one
zero.
I
can
tell
you
that
we
can
count
from
monday
how
many
downloads
we'll
have
on
maven
when
we
put
one
zero
on
the
api
and
sdk.
E
E
E
Oh,
the
number
of
dependencies
got
it
so
not
download
stats
but
yeah
dependencies.
E
H
C
E
We
accidentally
packaged
the
entire
kotlin
runtime
inside
of
the
java
agent.
E
E
H
Money
again
bunch
of
dependencies
by
the
way
couch
base
is
using
us.
H
E
G
E
E
E
H
Yeah
so
anyway,
that's
that's
what
I'm
trying
to
say
minimize
the
the
initial
api
public
api
and.
C
C
Just
have
one
small
question
in
the
end
for
instrumentation
should
muzzle
be
it
muscle
should
be
using
the
runtime
class
path,
not
to
compile
class
pathway.
C
A
E
C
Yeah,
this
might
provide
the
answer.
So
it's
like.
Why
didn't?
Why
does
muscle
only
feel
at
run
time?
E
But
it's
so
what
was
happening
was
in
the
in
the
app
muzzle
was
suppressing
it
because
it
was,
I
think
it
was
looking
for
something
yeah
never
mind.
Doesn't
that
mean
we
have
a
dependency.
E
B
C
E
C
Anyways
yeah,
so
here
we'll
probably
revert
back
to
the
reflection
that
was,
it
jason
good
watch.
I
forget
that
they
tried
like
that,
for
we
got
it
to
work
with
the
everything
was
working,
so
it
was
okay
until
we
actually
tried
in
practice
it
wasn't
okay
and
that's
just
because
we
assumed
that
muzzle
would
have
caught
it.
But
of
course
it
wouldn't
because
it
was
on
the
compile
class
path.
E
A
E
I
had
a
question
to
so
when
I
was
putting
these
so
the
config.get,
so
aws
sdk
22,
the
library
instrumentation
like
if
I
call
config.get
there.
Of
course
everything
is
false
all
the
time
it
doesn't
read:
the
system,
properties,
environment,
variables,
okay,.
E
Oh
well,
because
we
also
read
the
property
source
stuff
from
the
spi
and
the
file,
the
dot
properties
file.
C
C
Right
right,
but
we
would
need
the
class
loaders
thing
as
like.
I
guess,
if
it's
supported
in
both
library
and
agent
agent
would
need
to
be
able
to
pass
in
a
class
letter
to
read
the
spi
from
oh.
E
C
C
E
Yeah
yeah
cool
anything
else.
J
I
I
copy
paste
if
you
want
to
have
a
fun
before
going
to
bed.
H
One
of
the
guy
was
using
a
long
array
with
one
size
because
of
lambdas,
so
he
he
needed
a
reference
to
a
long
mutable
long.
So
he
was
doing
this
trick.
I
I
saw
the
atomic
long
as
well
used
as
as
a
trick
for
this,
and
he
was
explaining
to
me
that,
oh
because
of
lambdas,
I
cannot
do.
I
have
to
use
a
tummy,
and
I
said.
B
E
Streamers
and
I'm
still
struggling,
I'm
still
struggling
to
read
like
honorable,
said
the
pr
last
last
one.
E
E
Both
nikita
and
I
both
were
like,
we
can't
what
are
you
doing
to
us.
E
Hey
I
haven't,
this
is
a
good
trick
for
a
mutable
log
I
haven't
seen
I
I
never
thought
of
that.
I
always
write.
I
always
write
a
little
tiny,
mutable
long
class.
C
H
E
All
right,
good
night
bagdan
have
a
good
have
a
good
friday
honorary
and
a
good
weekend.
H
And
the
release
is
saturday
morning
your
time,
yeah,
you're,
probably
gonna
press
the
button
you'll
have
the
hunter
to
press
the
button.
So
we'll
count
on
you.