►
From YouTube: 2020-05-15 Java 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
B
No,
there,
hello,
hey
Jonah,
I'm,
not
sure
if
we've
met
no
I
do
not
believe
so
Jonah
Cowell
I'm,
with
logs
IO,
how
you
doing
hey,
welcome
well
I've,
been
on
a
couple
of
calls,
but
mostly
just
listening
and
sort
of
getting
the
lay
of
the
land
is
this
some
did
we
hijack
somebody
out?
Are
you
here
for
the
java
context,
API
discussion,
no
I,
wonder
if
we
hijacked
somebody
else's
zoom
meeting
yeah
I
thought
this
was
for
the
logging
one,
but
let
me
see-
and
maybe
my
zoom-
it's
not
accurate.
B
B
C
C
D
E
E
Would
like
to
discuss
a
bit
more,
what
we
can
do
in
terms
of
having
third-party
library
having
our
own
API,
backed
by
different
implementation,
and
how
we
do
we
interact.
I
mean
we
should
start
from
from
two
things
is
one
is
whenever
somebody
uses
this
in
the
library
like
GRP
see
when,
when
it's
embedded
as
I,
think
in
that
party
library
versus
when
somebody
just
does
something
like
interceptor
pattern
or
something
I
did
so,
they
don't
have
a
dependency.
G
E
E
B
F
B
B
Get
to
the
bottom
there's,
but
a
lot.
A
lot
of
judges,
so
kind
of
where
we
left
off
with
the
discussion
on
Friday
was
whether
we
wanted
scope
manager
like
not
having
static
not
being
accessed
statically
about
having
a
scope,
manager,
instance
or
I
mean
something
else,
rename
it
something
else,
but
that
gives
access
to
the
current
the
thread:
local
context
from
a
spring
injection
perspective
and
you're,
asking
Bogdan.
Why
that's
needed
and
honestly
I,
don't
really
know,
but
it
is.
B
G
B
B
B
E
B
E
B
E
Mean
I
don't
think
they
have
anything
are
related
to
their
network
connection
thing
and
if
they
have,
maybe
that's
sure,
but
what
I'm
trying
to
say
is
I
have
a
hard
time
seeing
every
library
exposing
us
in
their
public
API,
because
we
become
part
of
their
public
API
in
the
same
problems
that
we
are
now
saying.
Oh
gee,
RPC
context
is
bad
because
it's
whatever
part
of
our
public
API,
they
will
have
exactly
the
same
arguments
against
us
being
part
of
their
public
API
right.
E
B
E
So
far,
if
you
look
at
all
his
issues
that
he
filed
against
general
PC
in
the
budgeting,
he
wants
to
make
everything
not
exposing
any
of
this
API
and
not
even
taking
a
dependency
on
this
API
so
coming
from
from
spring.
His
idea
is
everyone
should
expose
an
interceptor
pattern
and
everyone
should
be
an
interceptor.
No,
nobody
should
make
a
dependency
on
on
us.
B
B
E
But,
but
by
not
having
the
static
piece,
you
are
forced
to
expose
the
dependencies
by
having
the
static
pieces,
you
are
avoiding
exposing
dependencies
because
you
call
the
static
pieces,
so
it
which
means
you're,
not
you
are
not
gonna
get
an
instance
from
flowing
from
the
caller.
You
can
get
whatever
you
need
from
the
static
method.
I
think
they
are
very
tied,
in
my
opinion,
that.
E
So
so,
by
not
having
any
any
of
these
static
things,
the
world
should
look
like.
Everyone
should
should
put
some
dependency
and,
except
this
instance,
coming
from
the
color
and
the
problem
is
were
just
one
third-party
library.
Imagine
if
anyone
comes
with
this,
how
that
is
gonna
work.
Also
I
do
not
see
a
lot
of
these
problems.
That
Adrian
is
mentioning,
for
example,
in
the
logging
libraries.
All
of
them
follow
the
the
static
method.
Nobody
passes,
bloggers
around
in
Java.
B
E
E
B
G
E
E
What
exactly
do
we
try
to
achieve
with
this
bi
I
mean
there
are
a
couple
of
good
things
that
were
identified
like
the
hotel's
class
may
not
be
easy.
To
use,
may
not
be
named
correctly
may
be
hard
to
good
to
use,
that's
a
problem
and
that's
something
that
we
chose
without
changing
the
behavior.
Both
of
them
are
now
study.
You
just
have
another
static
thing:
it's
not
changing
anything
about
scope
in
there
or
anything
yeah.
B
B
D
E
B
H
By
the
way,
if
we
happen
to
I
mean
at
the
moment,
we
only
support
like
spanning
the
context
what
the
specification
defines
the
span
context,
also
in
the
context,
so
I'm
not
sure
we
are
going
to
actually,
you
know,
support
that,
but
if
we
ever
support
that
we
will
need
to
add
the
same
for
a
span
context
just
for
your
information.
Okay,
we.
E
H
E
B
G
And
this
actually
is
I
think
that's
an
interesting
question,
because
all
of
the
this
I've
been
kind
of
just
thinking,
while
we're
discussing
all
of
this,
and
if
we,
if
we
want
a
model
like
a
logger
like
if
we
think
a
tracer
is
like
a
logger
or
if
we
want
a
mod,
we
want
to
want
to
kind
of
put
forth
in
our
API
acts
a
lot
like
a
logging
API
then
like
we
were
saying
earlier.
When
you
get
a
logger,
you
keep
it
static
instance
to
it,
and
then
you
just
use
the
methods
direct
line.
G
The
longer
you
don't
need
anything
else
right.
You
just
need
the
logger.
You
get
all
the
functionality,
although
if
you
need
the
map
doing
a
diagnostic
context,
maybe
you
need
to
ask
the
logger
for
it.
I,
don't
remember
exactly
how
this
API
is
work,
but
I,
wonder
whether
whether
having
like
feels
like
we
need
to
choose
a
guiding
principle
and
if
our
guiding
principle
is
that
tracer
is
kind
of
like
X.
Api
was
like
a
log.
G
G
E
Have
an
answer?
That's
one
example.
The
other
one
is
so
so
I
think
I
think,
based
on
the
picture
that
we
at
least
I
I,
remember,
I
saw
somewhere
it's
context,
is
it's
an
independent
package
correct
and
doesn't
matter
how
it
is
implemented
for
the
moment,
and
how
do
we
inject
that
thing,
but
one
assumption
that
we
have,
and
maybe
that's
wrong-
is
that
context.
E
The
context
also
is
a
kind
of
a
global,
not
a
global
thing.
Look
at
this
way.
The
other
problem
that
I
see
here
is
the
following.
If
you
allow
to
inject
things,
how
do
for
me
for
me
if
we
want
to
inject
things,
even
between
two
instances
of
the
tracer?
How
do
we
ensure
that
they
can
communicate
via
this
third
party.