►
From YouTube: 2019-10-17 Java Auto-Instrumentation SIG
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
A
A
A
A
B
D
G
A
C
I
think
the
one
desire,
at
least
from
a
lowly
and
dynaTrace,
was
to
kind
of
hit
a
reset
button
around
like
what
are
the
requirements
for
the
saying
was
it
need
to
do
I
think
Allawi
was
gonna.
Deliver
a
rough
draft
to
that,
for
this
meeting
is
that
something
that
was
available?
I've
been
half-assedly
following
the
the
chatroom.
B
C
A
H
So
Tyler
and
I
had
discussed
previously
sort
of
following
the
original
guidance
of
the
open,
telemetry
body
to
port,
to
start
porting,
the
data
dock
agent
to
open
telemetry.
So
the
first.
The
first
thing
that
we
had
identified
is
that
we
didn't
want
the
agent
to
take
a
hard
dependency
on
open,
telemetry
API,
at
least
not
inside
of
at
least
we
didn't
want.
F
So
one
concern-
that's
at
least
LOA
was
expressing-
was
that
if
we,
if
we
approach
creating
a
intermediary
API
directly
to
to
to
fulfill
this,
this
desire,
so
that
we
don't
have
version
conflicts
with
open,
Solano,
tree,
api's
and
stuff
like
that,
then
basically
the
work.
That
would
be
the
effort
that
would
be
done
in
implementing
these
plugins
or
these
integrations.
They
would
be
specifically
made
for
data
dog.
Oh.
F
A
H
A
So
so
to
be
clear,
like
I'm,
not
so
what
I
think
we're
proposing
is
not
necessarily
to
not
use
the
open,
telemetry
API.
If
you
have
a
plug-in
that
you
want
to
install
manually
I,
it
could
still
use
the
open
telemetry
API
directly.
Instead
of
going
through
this
private
API,
that's
isolated
in
its
own
class
loader
and
not
used
by
non
instrumentation
stuff.
Would.
E
It
be
possible
to
get
something
like
a
drawing
there.
The
components
are
on
there
and,
where
it's
clear,
also
birth
date,
the
dog
starts
and
where
it
stops,
so
that
and
also
seeing
the
components
how
they
are
coupled
together
and
because
also
how
because
some
vendor
we
have
a
pluggable
SDK
for
instance.
Of
course,
some
someone
might
be
interested
also
to
have
a
pluggable,
auto
instrumentation,
or
something
like
that.
So
I
think
like
having
the
architecture.
Somehow
visually
would
help
I
guess.
E
Meanwhile,
just
let
me
share
in
the
chat
just
so
that
we
are
on
the
same
page
for
yet
because
for
note,
we,
for
some
reason,
was
probably
inherited
by
open
census.
We
have
this
plug
in
infrastructure,
where
it's
also
at
least
documented
how
you
can
write
your
own
plug
in
how
to
what
which
interface
you
implement
and
then
just
tuck
it
in
and
tell
you,
though.
Okay.
C
I,
don't
want
to
come
across
as
a
wet
blanket
because
I
see
you
guys
have
been
doing
work
on
this,
but
it
just
I
have
to
admit
it
does
strike
me
as
maybe
just
over
complicating
things
like
we
have
SDKs
that
usually
implement.
You
know
the
open,
telemetry
API
the
open
tracing
API
and
could
implement
the
data
dog
API,
so
it
I
guess
I'm
a
little
condemned.
C
A
So
if
there's
version
conflicts,
for
example,
like
one
problem
we
have
with
with
open
tracing,
is
we
can't
upgrade
directly
to
ot
33,
because
if
we
did,
it
would
break
anyone
that
was
using
ot
31
without
at
runtime,
not
a
compile-time
error,
because
we're
putting
stuff
on
the
bootstrap
and
that
overrides
whatever
open
tracing
classes
that
they're
using
so
by
decoupling
it?
We
remove
that
making
sure
that
the
agent
on
forcing
function
on
whatever
the
users
using
yeah.
C
Okay,
see
this
is
the
theory
that
the
you
know,
you're
versioning
within
the
agent
is
separate
from
the
versioning
that
an
end
user
might
be
doing
in
a
world
where
the
open,
telemetry
API
isn't
stable.
Yet
right
if
they
use
the
agent
and
it's
using
a
particular
version
of
open
telemetry,
you
might
smash
into
all
of
their
manual
instrumentation
I
see
okay,.
F
C
F
Also
guys
I
mean
so
I
I
get
it
now
too,
and
yes,
the
this
totally
makes
sense.
Of
course,
if
some
users
would
would
want
to
bind
to
ot
API
dot,
31.3
2.33
basically
provide
a
adapter
internally.
Somehow
that
would
be
able
to
not
squash
whatever
API
is
the
use.
So
this
is.
This
is
definitely
a
great
feature,
but
I
believe
it's
too
detailed
for
us
to
be
discussing
right
now,
because
this
is
kind
of
internal
to
the
agent
of
limitation
sort
of
question.
I
think
we
were.
F
H
H
H
The
agent
can't
be
something
that
customers
have
to
go
and
do
a
full
regression
test
on
their
app
to
confirm
that
they're,
not
using
you
know
the
Java
in
a
way
that
these
rappers
are
gonna
break
it
that
they're
not
using
the
version
that's
going
to
cause
conflicts.
It
needs
to
be
just
something
that
is
a
ops.
You
know
that
operations
can
drop
in
that
the
developers
don't
even
need
to
be
involved
in.
F
That
that
is
just
one
specific
use
case,
one
specific
situation
where
there's
just
a
difficult
way
to
create
a
sort
of
plugin.
That
would
be
both
manual
and
automatic,
specifically
in
the
jdbc
situation,
and
if
you
choose
to
use
JDBC
in
this
way
where
you
have
to
up
cast
your
JDBC
drivers,
your
specific,
my
sequel
or
Postgres,
or
whatever
a
driver.
It
is
then
in
that
situation.
Yes,
there
will
be
a
problem,
but
this.
H
F
H
Only
special
agent,
because
you're
trying
to
take
this
rapper
approach,
which
is
on
I,
mean
we
get
the
reason.
It's
a
good
reason.
It's
a
we
all.
We
all
back.
This
idea
of
reusability
of
these
rappers
would
be
awesome
right.
We're
not
saying
that!
That's
not
that
wouldn't
be
a
great
goal.
We're
just
saying
that
technically
we're!
We
don't
believe
that
that's
the
way
to
go,
because
it's
going
to
cause
problems
for
users.
It's
not
a
proven.
It
hasn't
been
proven
out
by
any
major
APM
vendors.
F
Run
and
yeah,
and
also
the
this
specific
situation
with
JDBC
you're
right.
That's
because
that's
the
way
that
the
JDBC
plugin
was
written.
However,
with
a
creative
other
approach,
I'm
sure
it
can
be
done
in
another
way
where
that
problem
would
not
be
surfaced
right,
like
I'm
just
saying
I'm,
just
trying
to
like
present
that
there
there
are
probably
creative
solutions
that
would
allow
us
to
have
this
kind
of
architecture
where
we
would
be
able
to
reuse
the
plugins,
both
dynamically
or
in
an
agent
Auto,
installed
sort
of
fashion
versus
a
manual
installed
fashion.
E
H
A
very
fundamentally
critical
issue
of
version
conflicts
and
class
cast
exception,
z'
that
before
we
commit
to
going
down
that
road,
we
need
to
feel
really
comfortable,
as
you
know,
as
vendors
that
were
not
going
to
be
on
inflicting
pain
on
our
users,
even
if
it's,
even
if
it's
only
one
out
of
a
hundred
users
right
I,
mean
I,
agree,
I
know
what
you're
saying
that
these
are
edge
cases
but
edge
cases
at
scale.
One
out
of
a
hundred
users.
B
So
we,
when
you
instrument
something
with
which
you
automatically
do,
then
it
needs
to
work
without
user
had
tested
it
before,
like
we
have
cases
like
people
put
our
agents
in
production
and
they
expect
it
to
work
right
away,
and
there
is
like
we
have
a
long
history
of
solving
edge
cases
for
customers
that
do
exactly
so.
We
that's
something
that
an
auto
instrumentation
agent
needs
to
be
aware
of
it.
B
That
being
said,
on
the
other
hand,
I
also
think
it
should
be
one
of
our
goals
to
have
that
to
reach
that
kind
of
reusability,
where
it's
possible.
Maybe
it's
not
possible
for
each
and
every
sensor
or
plugin,
but
where
it
makes
sense
I.
It
would
be
a
good
goal
to
have
reusability
of
plugins
to
use
them
manually
or
with
others,
wherever
that's
possible
agreed.
H
B
B
B
I
believe
that
most
of
the
sensor
code
is
the
same
for
like
the
auto
instrumentation
only
does
the
registration
of
the
listener.
On
the
other
hand,
you
do
it
yourself,
but
then
the
code
is
the
same
right
right.
If
you
have
no
such
thing
and
you'd
need
to
do,
bytecode,
instrumentation
or
rapping
yeah,
maybe
the
code
differs,
and
you
cannot
share
that.
E
We
ask
real
quick,
just
know
if,
like
user,
we
use
case
driven
question.
So
if
I
look
at
this
drawing
of
the
Ottomans
meditation
agent,
this
means
that
this
auto
instrumentation
agent
would
bring
with
it
the
SDK
and
also,
if
I,
understand
it
correctly,
now
an
exporter
right.
So
that
means
we
all
one
in
this
scenario.
H
H
Well,
if
you
wanna
plug
out
I
mean
so
this
would
this
is
going
to
go
through
sort
of
that
yeah
we
can.
Certainly,
you
know
accomplish
that
if
you
want
to
have
it
be
pluggable
as.
E
A
H
We
want
to
have
an
exporter
at
minimum
right
for
people
who
are
using
open
telemetry
without
auto
instrumentation
age
agent
and
then
with
auto
auto
with
Auto
instrumentation
agent.
We
would
package
up
our
exporter
here
and
deliver
this.
You
know
as
a
vendor
specific
agent
that
has
all
of
this
embedded.
Okay,.
E
Well,
if
I
understand
correctly
so
ultra
instrumentation
agent
would
then
there
would
be
then
Microsoft
version
of
this
odd
transmutation
agent
that
tears
all
dependencies
bong
in
there
with
despite
cold
instrumentation,
that
is
contributed
by
theta
dot.
If
I
got
to
get
this
right
right
right,
okay,.
G
Okay,
guys
just
you
know
like
its
organizational
point,
so
this
is
great
conversation
so
far,
just
to
make
it
a
bit
more
structure
it.
What
I
suggest
you
know,
let's
get
Trask
to
talk
through
the
boxes
and
like
those
writings
they
have
and
because
so
far
Daniel
you
are
you
pointed
out,
is
it
would
be
good
to
have
some
kind
of
a
around
like
the
data
flow
diagram.
G
So
we
currently
have
it
on
the
screen,
but
you
know
like
we
only
have
just
you
know
a
few
letters
of
age
books,
so
I
suggest,
let's
get
trust.
You
know
that
folks,
through
this
diagram
and
then
you
could
have
like
more
pointed
conversation,
so
we're
not
guessing
what
is
there
what's
possible?
What's
not,
but
you
know
just
understand
what
trust
get
in
mind.
H
Sure
so
this
the
idea
is:
here's
your
user
app.
That
may
or
may
not
be
using
open
telemetry
directly,
but
let's
say
they
are
using
open,
telemetry,
directly,
API
and
they're,
also
using
some
libraries
that
have
already
been
instrumented
with
open,
telemetry
API.
So
this
is
all
in
the
user
space.
This
is
all
in
the
user.
Classloader
the
agent
itself
would
bring.
H
H
So
this
bridge
would
have
to
be
injected
into
the
user
app
classloader
dynamically
so
that
it
would
resolve,
and
then
the
bridge
would
basically
just
read
checked
into
a
something
common
right.
We
need
something
common
to
be
shared
between
bytecode
instrumentation
and
the
bridge
and
the
the
users
open
telemetry
manual,
open
telemetry.
So
this
would
include
like
manual
wrappers
over
here,
and
so
that
way
you
know
all
the
correlation
takes
place
over
here
and
then
funnels
down
to
an
exporter
and
to
the
earlier
point
you
know
this
could
be
the
full
SDK.
H
Essentially,
you
know
again
a
hidden
hidden
means
hidden,
somehow
from
not
conflicting
with
the
user
app.
So
basically,
there's
I
mean
two
common
ways:
either
shading
or
isolated
classloader.
So
both
of
those
are
valid
options
here
and
I
think
these
would
probably
communicate
just
through
the
you
know
the
API
not
bound
directly.
H
They
don't
have
to
be
bound
directly
to
the
SDK,
so
that
would
allow
other
vendors
if
they
wanted
to
then
put
their
own
SDK
implementation
in
here,
but
for
the
standard
deliver
the
standard
downloadable
agent
from
open,
telemetry
would
then
pipe
here
and
then
I
think
we
would
need
some
way
to,
and
this
is
where
hidden
being
isolated.
Classloader
has
advantages
versus
shading,
because
if
we
have
fun,
if
we
put.
H
H
A
F
F
A
A
B
B
Okay,
the
to
the
user
F
has
the
telemetry
I
API
reference,
and,
it's
being
so,
the
the
classes
are
loaded
with
regular
class
frnd,
the
auto
instrumentation
agent.
It
has
these
plugins
and
they
currently
in
in
this
diagram
points
directly
on
to
the
SDK
now
I
understood
there
should
be
an
abstraction
between
that.
Why
can't
that
abstraction
be
the
open
today
metric
API
in
a
certain
version
that
we
will
also
inject
with
the
auto
instrumentation
agent
and
do
the
shadowing
over
the
existing
open,
crematoria
type
classes,
with
the
separate
I
think.
A
B
H
B
A
B
A
A
A
H
H
C
H
It
and
then
has
just
Java
source
and
then
compile
it,
but
I
mean
it's
certainly
doable
like
you
said.
If
you
have
just
a
shade
shade
at
once,
have
one
reference
API
that
is
shaded
that
then
you
could
build
against.
A
A
F
F
H
H
F
Sure
but
I
mean
the
point
I'm
trying
to
make
here.
Is
you
can't
we
can't
protect
every
from
everything
like
you
could
download
the
API?
You
could
put
it
on
your
system
class
path
and
you
could
actually
modify
the
API
and
put
it
on
your
class
path
and
obviously
that's
gonna
break.
We
can't
protect
people
from
do
it
from
doing
something
like
that
right,
and
it
would
be
silly
for
us
to
pretend
that
we
can
okay.
F
F
F
But
that,
then
that's
a
question
of
would
that
would
it
be
possible
for
you
to
obtain
those
pieces
in
in
those
different
versions
because,
like,
for
instance,
in
special
agents,
you
be
really
hard
to
do
that?
You
would
have
to
get
into
the
build
and
you
would
have
to
pull
out.
You
know
specific
modules,
though
the
way
that
the
special
agent
is
built
it
contains
within
it
all
of
its
own
plugins.
So.
A
A
B
E
H
Manual,
you
want
to
use
a
manual
instrumentation
over
here
in
user
land
or
you
want
to
provide
your
own,
auto
instrumentation,
that's
okay,
yeah!
So
each
one
of
these
bytecode
instrumentation
pieces
like
for
MongoDB
for
okay,
HTTP
they're,
all
built
separately,
so
we
would
want
I
know
for
us
as
a
vendor.
We
want
all
of
these
to
be
independent,
where
we
can
pick
and
choose
which
ones
we
want
to
bundle
into
our
official
agent
that
we
support,
and
so
you
know
that's
an
important
part
of
that
API
that
these
are
built
with
being
public
eventually.
H
H
C
G
G
Alright,
so
I
can
I
can
try
and
just
summarize
something
to
share
with
you
guys
my
vision
of
its
transition.
Shade
of
is
a
group
for
for
the
next
steps.
What
should
be
the
next
steps-
and
you
know
just
you
know-
to
put
some
some
sense
on
release
scheduled
on
the
eye
for
being
available
some
point
but
available
at
some
point
should
be.
You
know,
just
try
and
just
try
and
suggest
something
like,
for
example,
we're
going
to
have
something
by
December.
We're
gonna
have
something
by
January.
I.
A
G
That
is
true,
but,
like
today
we
were
just
discussing
like
a
different
ways
of
using
instrumentation
should
we
should
use
something
else,
Oh,
excellent
conversation
or
at
some
point
we
would
interest
to
say
hey
guys
like
me
here
in
order
to
ship
something
we
need
to
ship
something
and
we
are
making
in
a
some
decisions
and
going
forward
with
them.
For
that
you
know,
just
you
know
like
having
some
common
agreement
on
when
we're
trying
to
make
it
land
might
be,
might
be
good
idea.
G
G
What
I
guess
so
in
this
case,
let's
let
let's
postpone
you
know,
like
maybe
schedule,
discussion
until
the
next
meeting,
what
what
questions
so
today
we
discussed
you
know
like
in
general.
How
did
the
flow
could
look
like
you
know,
like
the
different
approaches?
Would
have
this
fermentation
say?
Well,
you
believe
you
were
planning.
You
know
just
to
present
something
next
meeting
about
creative
solutions.
We
could
have
no
is
rapid
implementation.
F
F
C
A
Can
do
that
yeah?
Do
you
mind
if
I
get
a
point
of
clarification
from
Christophe,
so
yeah
sure
one
of
the
things
that
I
forget
your
colleagues
name
at.
B
A
B
Abstracting
away
the
concrete
in
Swedish
library,
yes,
I
would
have
to
talk
to
them
and
I'm,
not
sure
what
the
concern
is
there
I
think
by
it.
Buddy
personally
I
think
fight.
Buddy
is
fine.
It's
a
little
bit
of
simplified
thing
over
ASM,
but
I'd,
hey,
I'm,
sorry,
I'd
have
to
get
back
to
them.
To
answer.
A
That
question
I'm
not
sure,
okay,
sorry,
my
main
concern
was
trying
to
abstract
that
too
much
is
this
going
to
complicate
the
the
instrumentation
process
significantly
and
you
know
just
slow
things
down
so
now.
My
preference
would
be
to
not
worry
about
abstracting
that
away
and
I
think
that
by
my
buddy
is
like
this
is
great,
so
mm-hmm
yeah.
B
Okay
point
taking
I
love
this
cause
with
Daniel
and
maybe
get
back
to
the
next
meeting.
Okay,
my
mind
in
my
biggest
concern
around
this
whole
thing
is
that
we're
starting
to
build
two
sets
of
instrumentation
libraries
or
sensors
or
plugins
or
whatever
you
want
to
call
it
like
one
that
is
only
for
auto
instrumentation
and
another
set.
B
A
In
cases
where
you
have
like
the
what's
called
like
a
helper
class
like
a
library
or
some
sort
of
listener,
that
gets
added
I,
don't
see
any
reason
why
you
couldn't
have
the
auto
instrumentation
depend
on
the
manual
inch
or
the
instrumentation
library
and
pulling
classes
and
reuse
them.
That
way,
that's
probably
gonna
be
the
the
way
that
would
make
sense
the
most
sense
to
me.
A
F
A
H
A
G
G
C
B
G
Right,
you
know
just
to
suggest
that
you
know
before
we
drop
off
I
suggest
you
know,
would
take.
The
next
steps
will
take
a
stop
at
the
design
document
so
alloys
he
started
design
document.
I
suggest
you
know
we
put,
they
have
more
diagrams
a
trance
Canaries
there.
We
put,
you
know
like
how
description
how
we
thinking
when
gia
mentioned,
is
going
to
evaporate
and
what
we
can
do
next
at
the
next
meeting
is
to
have
a
review
or
design
document
and
say
what
you
would
you
would
present.
G
G
A
Don't
I
don't
think
that
any
of
those
have
started
up
yet
my
understanding
is
that
with
no
js',
at
least
from
what
I
understand,
is
that
they're
already
doing
a
lot
of
the
auto
instrumentation
just
already
in
the
the
regular
node
sig?
They
have
it.
They
don't
they
don't
have
necessarily
a
separate
one.
Mm-Hmm
yeah.
G
It
is
steel,
you
know
like
a
question
of
how
you
could
apply.
You
know
that
instrumentation,
if
application
was
not
as
dramatic
lizard
and
in
particularly
so
if
you
look
at
data
flow
presented
by
Trask,
it's
all
very
interesting
problem.
Now
what
you're
gonna
do
if
a
customer
application
over
education
cementation
these
and
telemetry
sneaky?
How
is
it
an
idea
together
because
it
is,
it
is
like
interesting
topic.
So
if
the
key
is
already
present,
I
am
going
to
apply
I'm
gonna
apply
agent
or
not.
Are
you
going
to
be
able
to
consume?
G
G
If
it
can,
you
not
just
you
know,
as
I
said
about
other
languages
as
well,
if
it's
a
good
at
the
data
flow
for
other
languages
as
well,
but
I
think
like
from
there,
we
probably
just
you
know,
could
could
start
working
through
Bell
who
was
driving.
You
know
what
started
this
initiative,
and
just
you
know
great,
but
when
you're
working
groups
you
know
good
language
I
see
what
we
can
discuss,
how
we're
gonna
end.
It.
B
B
You
still
need
to
go
to
require
one
line
of
code
like
require
your
agent,
and
that
is
what
you
could
also
do
this
with
a
command-line
argument
to
your
note
process,
but
then
I
don't
know
what
the
girls
well,
if
it's
already
in
there
with
the
different
version
and
you
required
additionally
from
the
command
line.
That
is
what
I
don't
know.