►
From YouTube: 2020-08-12 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
D
Hey,
I
I
got
mad
at
you
in
our
group
chat.
A
So
my
my
problem
with
those
two
pull
requests
translating
decorators
to
tracer
is
that,
from
one
point
of
view,
that's
very,
very,
very
useful
job
and
I'm
very
grateful
that
somebody
is
doing
that.
D
D
A
A
See
yeah,
so
my
my
other
comment
was
probably
we
shouldn't
use
http
trace,
http,
client
razer,
but
but
the
main
idea
is
that
instrumentations
should
have
as
much
those
attribute
manipulation
as
possible.
That
should
be
in
the
tracer.
It
may
be
some
specific
aws
sdk
tracer,
which
is
somehow
specific.
D
So,
but
are
you
okay
with
because
the
problem
the
conflict
there
comes
in
that
there's
we
can't
make
it
just
start
span,
start
scope
and
span
there.
A
There's
yeah,
my
philosophy
is
that
is:
tracers
should
expose
public
api,
which
is
exactly
like
life
cycle.
Api
in
most
cases
is
simple,
start
span,
start
scope
and
if,
in
this
particular
case
that
life
cycle
is,
is
more
complex
like
before
marshalling
before
execution
after
response,
then
okay,
that's
the
public
api,
but
it's
still
like
public
api
form
for
four
life
cycle
methods
and
everything
is
hidden
over
there.
A
D
But
in
the
future
trying
to
phrase
your
response
more
kind
to
yeah,
unless
it's
you
can
say
that
to
me
an
honorar.
D
No,
no!
No!
No
I'm
just
kidding
yeah,
though
I
have
made
several
contributions
to
the
apache
maven
to
the
apache
shade
plug-in.
Yes,
me
and
shading
go
way
back.
Yes,
they
step
back
and
why?
Why
do
we
shade.
D
That
we
shade-
maybe
I
can
summarize
so
we
shade.
Obviously
we
shade
well
third-party
libraries
that
we
put
in
the
bootstrap
class
loader.
We
have
to
shade
so
they
don't
conflict.
D
One
nice
thing
with
the
agent
class
loader,
which
was
different
than
glow
root,
for
example,
didn't
glow
root.
I
just
put
everything
in
the
bootstrap
class
loader
and
shaded
every
all
the
dependencies.
D
So
the
other
stuff-
that's
in
actually
now
with
the
instrumentation
api
and
not
the
auto
api,
but
the
instrumentation
api
is
the
auto
api
and
instrumentation
api
are
also
going
in
the
bootstrap
class
loader.
D
Right
so
the
auto
api,
we
don't
shade
because
nobody
else
uses
that
it's
only
instrumentation,
auto
instrumentation
the
instrumentation
api
we
shade,
so
that
we
don't
conflict.
If
people
have
library
instrumentation
on
their
class
path.
A
D
Oh,
I
know
sorry,
there's
one
more
one
more
thing
that
we
shade,
which
is
the
java
util
logging,
which
we
chatted
about
last
thursday
in
the
sig
meeting.
D
We
have
that
patch
logger
and,
of
course
we
don't
actually
shade
the
java
util
logging
class
because
that's
in
the
jvm,
but
we
shade
references
to
that
to
then
refer
to
patch
logger,
so
that
and
that's
for
a
different
reason,
and
that
we
do
even
inside
of
the
agent
class
loader
dependencies,
because
we
well
for
two
reasons.
We
do
that
one.
The
most
important
reason
is
so
that
we
don't
touch
the
java
util
log
manager
too
early,
which
then
fails.
D
You
know
jboss
wildfly
and
then
the
other
reason
is
actually
then
those
third-party
dependencies
that
we
have
in,
like
the
will
that
use
java
util
logging,
for
example,
open
telemetry,
now
sdk
will
go
through.
We
wedge
it
through
our
slf
for
j
shim
and
we
basically
get
everything
to
go
to
the
same
place.
So
we
can
control
the
full
agent
logging
story.
A
D
A
Okay,
so
now
I
think
my
most
interesting
for
me
question
is
why
exactly
do
we
say
open
telemetry,
api.
D
What
do
we,
oh,
so
that
if
a
application
has
open
telemetry
api
on
their
class
path,
if
they
say
even.
C
A
D
C
D
If
you're,
so
in
the
so
the,
how
would
we
know
like
I
mean
you're
saying
if
the
agent
is
always
more
recent
than
the
app
yeah
so
yeah?
So
that's
something
that
I'm
not
sure
we
can
guarantee
that
the
agent
is
always
more
recent
than
what
the
user
brings.
D
C
D
If
they
don't,
if
we
don't
change,
package
names,
say
so
kind
of
the
back
story
there.
A
little
bit
is
datadog
did
that
with
open
tracing
api,
they
put
the
open
tracing
api
in
the
bootstrap
class
loader
and
unshaded
and
went
that
route,
and
so
they
got
pinned
in
on
a
particular.
They
got
stuck
on
a
particular
version
of
open
tracing,
because
open
tracing
was
not
maybe
was
not
was
breaking
had,
did
have
breaking
changes.
D
But
potentially,
if
we
coordinate
and
like
one
of
the
things,
we've
chatted
with
bogdan
chatted
with
bogdan
on
the
the
friday
sig
calls
a
couple
times
around
like
the
context
api
or
if
we
had
a
part,
you
know
a
couple
of
classes
like
that.
The
span
id
trace
id
like
classes
instead
of
having
to
shade
them
bridge
them
right.
The
way
we
have
to
do
the
bridging.
D
If
we
have
particular
classes
that
we're
sure
we're,
never
gonna
break
right,
then
we
could
pin
those
in
the
bootstrap
like
and
that
could
save
us.
The
shading
problem,
in
particular
cases.
A
D
Yeah
to
we
would
have
multiple
open,
telemetry
api
kind
of
the
way
we
support
multiple,
like
apache
http.
D
D
D
D
And
this
will
load
up
eventually,
I
just
switched
branches,
so
give
it
a
second,
but
so,
for
example,
the
azure
sdks
are
using
an
open,
telemetry,
zero,
two
four
currently,
and
so
I
have
maintained
in
our
distribution.
D
I
am
supporting
both
I'm
still
supporting
zero
to
four
plus
the
latest
and
muzzle
does
all
that
work
for
us.
It
will,
because
it
looks
at
the
the
shape
the
library
shape,
that
it's
getting,
that
is
being
instrumented.
D
A
Now
now
the
my
next
question:
any
application
can
have
different
libraries,
which
libraries
already
using
open
telemetry
api
from
different
versions:
how
how
will
any
application
and
and
us
to
to
work?
In
that
case,
I
have
an
application
in
my
application.
I
use
some
third
party
library
we,
which
was
instrumented
with
open
telemetry
api
1.0,
my
application
currently
using
open
elementary
api
1.1
for
manual
instrumentation.
Then
we
have
our
auto
instrumentation
agent.
A
A
A
A
D
A
A
What
what
what
what
I
am
thinking
is
that
if
there
is
a
mechanism
during
startup
to
detect
which
version
of
open
telemetry
api
is
used
by
the
application,
and
we
can
make
sure
that
our
version
is
compatible
with
that
in
semantical
in
this
similar
sense
of
work.
So
if
we
are
later
or
not
older,
at
least.
A
D
A
D
D
So
the
confusion
aspect,
I
think
I
think
you
had
some
good
suggestions
and
for
naming-
and
you
know
there's
yes,
it
is
confusing
still,
but
I
think
we
can
improve
that
somewhat.
D
The
performance
implications
are
more
compelling
to
me
to
you
know
to
push
that
envelope,
see
if
we
can
do
you
know
if
we
could
do
that.
I
don't
I
don't
know
how.
But
that
is
that's
a
real
concern
there.
All
that
all
the
bridging
we
have
to
do.
C
D
Yeah,
I
I
mean
I
put
a
really
high
value
on
doing
no
harm.
D
But
well
I
guess
that
would
be
part
of
doing
no
harm,
but
yeah
not
crashing
and
just
based
on
I
mean
the
one
thing
that
makes
me
feel
a
little
bit
better
about
it
in
open,
telemetry
world.
Is
that
we're?
You
know
we
have
both
of
these
projects,
the
instrumentation
and
the
sdk
under
the
same
project
umbrella.
D
B
D
That
was
that
was
me,
the
okay.
So
the
reason
I
put
that
in
was,
I
didn't
want
people
calling
open,
telemetry,
get
tracer
and
then
casting
it
to
a
tracer
sdk,
an
sdk
tracer,
because
back
to
the
do
no
harm
rule.
D
Our
bridge
tracer
is
going
to
break
their
app
they're,
going
to
get
class
cast
exception,
so
I
put
in
the
office
gate
so
that
they
can't
cast
they
can't
they
can't
call
opentelemetry.gettracer
and
they
can't
they
can't
cast
that
to
the
sdk
tracer
it'll
fail
before
they
put
the
agent
on
it'll
fail
after
they
put
the
agent
on,
because
what
I
what
it
does
now
is
it
returns
this
obfuscat
this
a
wrapper
around
the
trace,
the
tracer
that
basically
prevents
you
from
then
casting
to
the
original
to
the
tracer
sdk.
D
Now,
yes,
you
could
call
you
can
cast
it
to
this
obfuscated
class
and
call
unobfuscate
right,
but
that's
like
that's
like
calling
unsafe
methods
in
java
or
something,
but
that
the
sdk
does
need
that
right.
The
open,
telemetry
sdk
class,
open
telemetry
sdk,
get
tracer,
it
does
currently
and
I'm
hoping
that
that
setup
stuff
in
the
sdk
goes
forward.
At
some
point
where
I
know
there
was
some
talk
about
maybe
having
some
improvements
around
the
setup.
D
But
right
now
the
open,
telemetry
sdk
get
tracer
gets
the
tracer
from
opentelemetry.gettracer
from
the
api.
The
spi,
the
service
provider
interface,
is
just
at
the
api
level,
so
the
sdk
actually
goes
to
the
api
to
get
its
own
sdk
back
its
own
sdk
tracer
back,
and
so
it
does
have
to
make
that
call
to
an
obfuscate,
okay.
C
A
D
D
We
shade
the
api
within
the.
So
let's
look
at
the
sdk,
the
shaded
okay,
we've
got
two
shaded.
Am
I
still
sharing
intellij
yeah?
Okay?
So,
let's
start
with
sdk
beta
shaded
for
instrumenting.
So
this
this
does
shade.
D
D
D
So
it
is
just
being
used
for
test.
Is
it
called
for
testing
shaded
sdk.
D
Shaded
for
testing,
which
oh
no,
this
is
the
real
sdk.
This
is
a
different
purpose:
okay,
so,
okay,
I
do
know
why,
whether
it's
a
great
answer
or
not?
Okay.
So
let's
start
with
this
one
sdk
shaded
for
testing.
D
D
C
A
D
Sdk
yeah,
it
is
only
shaded,
and
so
I
think
this
is
a
misnomer.
This
is
poorly
named.
I
think
this
is
also
shaded
for
testing
but
shaded
in
a
different
way
for
testing
for
a
different
purpose.
B
C
I
I
agree,
do
you
think
you
could
have
that's
right
would
have
been
possible
to
shade
in
that
project?
That's
using
it
do
you
think
it
had
to
be
a
separate
budget.
D
Shading
in
the
project
is
it's,
I
guess
it
also
is
a
pain
out
when
it's
shaded
outside,
I
think
partly
the
way
I
shaded
outside
was
so
that
then
I
could
build
that
and
then
it
would
reference
right.
I
wouldn't
have
these
invalid
imports
everywhere,
but
of
course
that
requires
actually
building
this
first,
whereas
in
the
project
I
see
so
the
trick
in
the
project
is
we
need
for
the
tests.
D
We
need
to
be
able
to
reference
both
the
application,
open,
telemetry
api
and
all
that
we're
instrumenting,
and
then
the
embedded
agent
open,
telemetry
api
for
so
that
we
can
bridge
between
those
two
different.
So
we
need
two
different
name
spaces
there
and
right
now,
they're
called
unshaded
and
normal
meaning.
Unshaded
is
the
applications
which
will
in
our
instrumentation,
which
will
then
be
reshaded
or
which
the
unshaded
will
be
extracted
yeah.
It's
I
I
liked.
I
thought
that
there
were
some
really
good
suggestions
on
cleaning
up
that
naming.
A
And
so
essentially,
every
vendor
should
know
which
exactly
shadow
jar
configuration
to
use
which
more
or
less
copies
our
our
configuration.
So
if
that
change,
they
they
somehow
has
have
to
follow
that,
for
example,
I
just
see
that
I
have
copy
pasted
that
vendor
distribution
from
anorak-
and
I
have
just
just
now-
noticed
that
it
still
used
io,
open,
telemetric,
concrete
out
annotation
relocation,
which
already
is
extension.
D
D
Totally
pain,
yeah
yeah,
and
if
we're
going
to
be
promoting
this
concept
of
custom
distros
for
people
to
add
like
a
custom,
sampler
or
some
kind
of.
A
C
C
Unfortunately
they
do
yeah.
I
think
someone
indicator
actually
did
mention
me.
Then
right
so
that'll
be
annoying,
but
it
is
what
it
is.
I
guess.
D
Yeah,
I'm
okay
with
having
a
nice
solution
for
gradal
and
having
a.
D
A
Yeah
someone
who
uses
maven
can
contribute
yeah.
I
think
that's
okay,
by
the
way
why
we
don't
why
we
don't
have
here
right
on
the
trust
screen.
Relocation
of
that
I
opened
element:
telemetry
extension
with
with
v-span
annotation.
D
Because
the
no
we
shouldn't,
I
think
we
used
to
let's
see,
show
history
with
span.
Yes,
we
used
to,
but
we
don't
actually
want
the
annotation
in
the
bootstrap
class
loader,
so
it
shouldn't
even
be
a
dependency
getting
pulled
into
the
java
agent
to
the
bootstrap
class
loader.
D
D
A
A
A
A
But,
but
but
that
later
cancer,
okay
and
we
classes
are
loaded
lazily.
A
B
A
A
A
D
No,
I
mean,
I
don't
think
it
has
to
be
that
tricky
right
like
we
instrument
that
at
we
see
their
in
their
api
loaded
and
they
call
open
telemetry
get
tracer
right
at
that
point,
we
inject
our
bridge-
oh
no,
but
we're
talking
about
not
trying
to
get
away
from
the
bridge
if
we
were
doing
the
bridge
injecting
the
bridge.
At
that
point
right,
we
could
create
proxies.
We
can
manipulate
the
byte
code
of
that
that
bridge
class
that
points
to
the
then
to
the
bootstrap
class
loader
api.
A
A
But
so
you,
you
just
said
before
that
we
have
a
problem
because
user
goal
you
user
get,
gets
our
class
from
bootstrap
class
loader,
which
implements
some
api
interface,
and
it
may
happen
that
that
class
doesn't
have
methods
which
defined
on
api
and
when
they,
those
methods
are
called.
We
get
an
error,
they
get
an
error,
but
but
what?
If
we?
A
A
D
But
the
api
class
itself
like
say
the
the
in
the
user's
code.
They
reference
span
that
interface
is
going
to
be
that's
going
to
be
what
we
put
they're
going
to
get
our
span,
that
we
put
class
that
we
put
in
the
bootstrap
class.
A
A
B
D
D
So
don't
what
if
we
don't
put
hotel
api
into
bootstrap
class
loader?
So
there's
one
thing,
but
I
think
it's
solvable,
which
is
we
do
need.
I
mean
we
still
want,
still
need
a
shaded
hotel
api
in
the
bootstrap
class
loader,
for
example.
For
you
know
our
instrumentation
apache
http
client
instrumentation,
to
talk
to
right.
We
want
some
way
for
it
to
get
over
to
the
agent
class
loader.
A
D
B
C
D
D
A
C
I
gave
my
presentation
about
the
agent.
I
was
quite
convinced
to
myself
that
the
shading
is
important
unless
we
use
the,
I
mean
having
something
a
bootstrap
cluster
is
important
and
with
semantic
versioning
and
believing
in
it,
it
should
still
be
possible
to
not
shade,
but
that
has
its
own
risks,
but
bootstrap
class
loader
seemed
required.
D
D
D
Potentially,
what
can
you
do
brought
by
the
oh,
the
class
again
the
class
loader,
because
we
could
pass
around
a
reference
in
the
context,
for
example,
to
something?
D
D
D
Consumer,
pointing
instrumentation
would
be
able
to
look
up
the
bridge,
but
again
you
have.
This
doesn't
get
rid
of
the
bridge
like
that
you're
back
to
the
bridge.
It
does
help
with
the
idea
of
maybe
having
better
interop
with
like
the
if
the
user
configures
the
sdk
programmatically
potentially,
but
it
doesn't
get
rid
of
the
bridge
and.
D
A
Okay,
then,
let
me
ask
that
question:
can
we
at
all
detect
that
you,
if
we
don't
shade,
if
we
have
the
unshaded
api
in
bootstrap
class
loader,
we
don't
trade
anything.
Can
we
at
all
detect
that
user
has
brought
incompatible
api
with
in
his
application.
D
We
can
detect
it,
but
I
think
it's
too
late
we're
going
to
crash
their
app.
A
A
A
D
A
D
We
force
it
to
go
to
the
bootstrap
class
loader
to
basically
force
it
to
do
parent
first
for
our
classes,
and
at
this
point
you
know,
once
we
have
the
class
loader,
we
can
pretty
much
detect.
I
mean
for
most
all
class
loaders
that
we
care
about.
We
can
detect
what
classes
are
in
there,
because
that's
how
we
do
the
whole
class
matcher
trick
trick
or
optimization
the.
D
Class
loader
matcher
yeah
when
we
implement
this
in
all
these
places,
we
say
this
is
how
we
tell
it.
Okay,
we
know
that
the
for
a
particular
class
loader
it
we
check
if
it
has
this
class
in
it,
and
if
it
has
this
class
in
it,
then
we
just
say
nope,
don't
it's
an
optimization
to
say
we
don't
even
need
to
do
the
type
matcher
and
the
trans.
You
know
any
of
that.
A
Yeah,
my
idea
was
that
when
we
detect
that
there
is
in
some
class
loader
open
telemetry
api
with
incompatible
version
for
some
definition
of
incompatibility,
then
we
somehow
prevent
loading
open,
telemetry
classes
from
bootstrap
class
loader.
A
A
D
D
We've
already
instrumented,
like
executor,
services
and
http
url
connection
and
potentially
other
class
loaders.
A
But
we
even
can
like
fire
away
oops
redefine
again
only
this
time.
Don't
add
our
our
bytecode
transformers.
C
D
C
C
D
C
A
D
Yeah,
so
we
would
want
to
put
in
like
in
the
in
the
the
api,
some
kind
of
version.
Breakage
detection
like
I've,
seen
some
reports
or
build
things
that
will
ensure
that
we
don't.
A
In
this
case,
I
think
it's
it's
well,
it's
it's
quite
easy.
We
can
have
java
jars
like
api,
sdk
and
whatnot.
Have
api
version
class
file.
D
Api
version
file-
oh,
I
was
just
thinking
from
in
the
api
repo
in
the
sdk
repo.
If.
A
D
I
saw
it
in
the
I
saw
it
in
the
data
dog
reaper.
C
Yeah,
if
you
do
the
latest
dipper
yeah
muzzle
effectively,
does
do
that.
So
that's
one
way:
if
you
muzzle
versus
your
older
versions
or
something.
D
So
if
and
then
so
as
long
as
so
it's
okay
to
add
methods,
oh
well,
we
would
back
off
and
say:
hey
you
need
to
update
your
agent
right,
which
is
I'm
I'm
that's
acceptable,
telling
somebody
they
have
to
update
their
api
version.
I
don't
find
acceptable
because,
but
the
agent
is
easy
to
swap
out.
C
C
C
C
D
Yeah
I
mean
there
were
significant,
open
tracing
breakages.
I
think
they
were
stuck
on
0.32
and
couldn't
upgrade
internally.
They
couldn't
upgrade
the
open,
telemetry
api.
They
were
using
internally
because
customers
were
using
that,
depending
on
that
being
in
the
bootstrap
customers
couldn't
use
a
more
recent
version,
because
datadog
was
pinning
that
so
it
was
a.
They
had
a
really
bad
experience.
A
C
D
D
A
D
If
there's
a
2.0,
we
want
to
use
2.0
in
the
agent,
which
means
we're
going
to
pin
2.0
in
the
boost
trap,
class
loader,
but
then
somebody
using
1.1,
that's
they're
suddenly
going
to
there.
We
can
back
off
right
like
this.
We
can
do
that
back
off
thing,
but
all
of
a
sudden
they
had
an
app
that
was
generating
telemetry
and
now
it's
not
and
the
only
way,
because.
A
D
I
don't
I
don't
that's
not
a
good
option.
Why.
A
D
But
they
should
always
be
able
to
take.
I
want
them
to
always
be
able
to
take
the
latest
agent
with,
because
that's
where
it
fixes
they
should
always
get.
A
C
C
D
We
do
that
interesting.
D
C
A
D
A
D
C
Through
a
bridge
yeah,
so
anyways
I
mean
2x,
I
these
are
implementation,
details,
not
api
anyways,
so
we
don't
have
to
decide
right
now.
Right
1x
is
the
more
important
decision.
D
Yes,
I
just
I
need
to
make
sure
that
we
have
a
story,
though,
for
when
we
do
get
to
2-0,
because
I
mean
and
just
to
I
mean
some
context
for
why
it's
it's
important
for
me,
for
the
agent
to
always
be
able
to
apply
the
latest
agent
and
not
break
somebody's
code
is
think
about
from
a
cloud
provider
we're
just
gonna,
auto
upgrade
we're
gonna.
You
know
put
that
in.
D
A
A
C
And
also
like
to
confirm
that,
even
if
we
do
get
stuck,
then
we
just
shade
in
the
bootstrap
class
literally
what
we
do
right
now.
We
can
always
revert.
C
D
A
D
Yeah,
I
agree
that
that
sounds
like
we've
got
two
really
good
options
there
for
hitting
203.
If
you
include
renaming
the
package
which
nikita
doesn't
want
to
do,
which
is
fine,
I
don't
I
don't
want
to.
I
don't
want
to
I'd
rather
not
tell
the
the
sdk
group
that
that
would
be
something
we
would
need
right.
I'd,
probably
yeah.
D
Oh,
that
was,
I
thought
that
that
could
be
some
good
stuff.
A
C
D
Yeah,
no,
no!
I
I
would
be
happy
to
take
on
that
that
work.
A
Unfortunately,
not
it's
not
really
p1,
it's
p2,
I
agree
but
well,
and
when
some
of
our
builds
fail
because
we
cannot
instrument
classes
or
cannot
modify
classes
during
compile.
D
Yeah,
you
guys
are
doing
some
really
great,
build
work
and
those
smoke
tests.
I
really
like
those
looking
forward
to
I've
got
a
whole
bunch
of
smoke
test
apps
from
the
application
insights
side.
You
know
like
well
like
a
jms
kafka
spring
kafka,
a
bunch
of
things
that
I
want
to
bring
over
once
we
have
a
good
once
we
have
that
in
place.
D
I
gave
I
gave
you,
I
mean
I
had
some
comments
that
worth
looking
at,
but
I
wanted
to
approve
so
that
you
could
address
them
and
merge
at
your
leisure
tonight.
Today,
okay,
yeah.
D
Cool,
I
will
see
if
I
will
try.
I
will
give
this
some
thought
tomorrow,
because
I
will
present
sort
of
the
idea
on
the
thursday
sig,
because
that
will
be
a
good
opportunity
to
get
tyler's
feedback,
because
I
know
he
will
think
we're
crazy
for
doing
it.
So
he'll
have
some
good.
You
know.
He'll
have
some
good
feedback,
so
I'll
try
to
put
something
together
to
to
talk
about
that.
C
D
Oh,
I
said
yeah
yeah
nikita.
Do
you
wanna
chat
for
just
a
minute
about
your
context,
prop
doc
pr
we
can
or
we
can
chat.
You
know,
let's
check.
D
D
Okay,
okay,
so
did
this,
I
don't
know
if
you
even
had
a
chance
to
see
my
comment.
A
D
Okay,
is
this
your
honor?
Oh
it
is
you
okay,
so
in
this
example,
so
when
I,
when
I
read
it,
I'm
wondering
why
and
let's
there's
a
better
way
to
view
this
right,
rich
diff,
yeah,
okay,
so
the
idea
is,
this
is
not
executor
service.
This
is
not
java,
concurrent
instrumentation
here,
right,
yeah.
D
A
A
So,
for
example,
let
we
have
instrumentation
for
servlet
api.
A
A
D
D
A
A
D
A
A
A
D
I
see
you're
saying
that
that
that's
just
how
it
then
delegates
work
like
it's
done
until
that
thread
is
done.
So
it's
just
gonna
try
to
pick
something
up
right
away
on
the
same
thread
or
something.
A
D
D
A
D
I'm
wondering
for
the
doc
docking
it
if,
if
it
could
be
closer
to
a
real,
because
I
don't
know
I
I
this
was
hard
for
me
to
fall
to
understand
and
so
just
trying
to
think.
If,
if
it
was
closer
to
the
tomcat
like
the
async,
you
know
kind
of
using
the
async
termina,
the
the
servlet
async
apis
even
and
the
tomcat.
D
A
D
A
D
D
I'm
going
to
go
and
approve
it.
Now,
all.
D
But
yes,
we'll
get
this
yeah
cool,
then
we'll
have
this
done
by
thursday's
sig
meeting.
Also,
oh,
what
happened
that
that
was
a
really
interesting,
the
micro
profile
stuff.
Did
you
look
at
that
at
all.
A
Nope,
I
just
read
the
the
comment,
but
I
haven't
take
a
look
at
the
actual
yeah.
What
they
do.
D
No,
I
mean
I
exit
that
yeah.
I
think
it's
more
interesting.
Actually,
from
the
sdk's
perspective,
I
might
try
to
join
friday's
sdk
meeting,
maybe
ping
john.
Did
you
see
that
honorag.
D
D
Yeah
yeah,
and
of
having
of
focusing
better
to
focus
on
bridging
whatever
and
it
sounds
like
they've
done
that
and
they
had.
I
mean
I
didn't
read
through
it,
but
they
had
quite
a
impressive
doc
site
and
it
looks
like
they've,
given
you
know
a
good
bit
of
thought
to
it,
so
that
would
be
very
looked
very
promising
for
maybe
for
us.
D
D
Everything
yeah
shade
it
use
it
shade
it
yeah
expose.
C
C
A
All
right,
I
have,
I
have
one
question
for
traffic
if
you
are
still
alive.
Yes,
are
you
I,
okay
with
me
spending
quite
a
lot
of
time
on
our
building,
build
process
built
in
front
like
that,
because
well,
that's
not
actively
moving
us
to
ga
and
clothing.
A
lot
of
issues.
D
I'm
great
with
it
I
I
honestly
I
mean
I
I
I'm
not
that
worried
about
our
ga,
because
we
can
you
know
we
can
ga
sort
of
anyway
yeah
I'm
I
I
I
I
don't
yeah.
No,
you
guys.
You
guys
have
both
been
like
this
huge
breath
of
fresh
air
into
the
project
because
you've
been
working
on.
You
know
bringing
new
stuff
like
that,
and
you
know
I
can
fix
bugs
and
do
shading
and
stuff
like
that.
But
I'm
really.