►
From YouTube: Jakarta Tech Talk - Implementing Servlet 6.0 in Jetty
Description
Many of the benefits of the Servlet 6.0 API are in removing the kruft of many years, thus allowing better implementations of the specification. This presentation will show aspects of how Servlet 6.0 has been implemented by the Jetty server with reflections on how that will impact your existing and future applications.
Jakarta EE
Jakarta EE gives developers a comprehensive set of vendor-neutral, open specifications that are used for developing modern, cloud native Java applications from the ground up. With Jakarta EE, technology developers and consumers can be confident they have the best technologies for developing cloud native, mission-critical applications. And they can build on decades of Java developer expertise to move existing workloads to the cloud.
Learn more: https://bit.ly/3IPrxOq
Follow us on Twitter: https://twitter.com/home
Follow us on LinkedIn: https://www.linkedin.com/showcase/jakartaee/
Like us on Facebook: https://www.facebook.com/JakartaEE/
A
Hello,
everyone
and
welcome
to
another
jakarta
tech
talk.
My
name
is
serena
and
joining
us
today
is
greg.
Wilkins
who'll
be
presenting
on
the
topic
of
implementing
servlet
6.0
in
jetty.
If
you
have
any
questions
for
greg
as
we
move
through,
today's
presentation
feel
free
to
ask
it
in
the
chat
or
use
the
ask
a
questions.
Tab
before
we
get
started.
The
2022
jakarta
ee
developer
survey
is
now
open.
The
link
is
now
as
well
in
the
chat
for
you.
So
without
any
further
delay
greg
over
to
you.
B
Hi
everybody
thanks
for
joining
today,
I'm
going
to
start
off
with
an
apology,
I'm
glad
that
the
title
of
the
talk
is
implementing
in
the
continuous
tense,
because
we're
about
a
month
or
so
behind
in
the
development
of
our
server
six
version
of
jetty
gt12,
and
I
was
so
head
down
bum
up
in
the
implementation
of
it.
I
completely
forgot.
B
So
what
I'd
like
to
actually
do
is
just
give
you
a
a
little
update
of
the
motivation
of
of
why
servant
sticks
is
a
a
big
thing
compared
yeah
we've
had
obviously
five
iterations
of
the
servlet
spec
before
and
they've
all
been
very
incremental
and
haven't
been
revolutionary,
whereas
I
think
for
the
jetty
implementation
at
least
we're
making
this
a
little
bit
more
revolutionary
in
the
way
we
provide
a
server
container
and-
and
there's
several
reasons
for
that.
So
I
I
guess
jetty's
been
around
for
20
plus
years.
B
But
what
we've
come
to
realize
over
the
years
is
that
the
the
the
cost
of
implementing
the
service
spec
is
quite
significant,
especially
when
compared
to
http
servers
that
don't
bother
doing
servlets
and
in
order
to
be
competitive
in
the
server
space.
We
really
want
to
have
both
the
performance
of
a
non-servlet
container,
but
also
the
the
good
support
for
the
the
legacy
applications
and
the
the
knowledge
base
and
the
the
tools
and
the
skill
base
that
goes
with
servlets.
B
It's
like,
we
don't
want
to
give
up
servlets,
we
see
value
in
servlets
as
a
good
platform.
That's
continuing
to
be
developed
and
enhanced
going
forward.
So
we
we
wanted
to
have
a
bit
of
the
best
of
the
both
worlds,
but
we
we
very
much
acknowledge
that
service
spec
is
costing
us
in
the
performance
area
and
there's
lots
of
reasons
for
this.
There's
features
in
the
service
spec
that
have
a
very
high
price,
even
though
they're
very
rarely
used,
for
instance,
cross
context.
Dispatch
is,
is
a
big
one.
B
Very
few
applications
will
dispatch
from
one
context
to
another
context,
but
because
you
can
do
that,
it
meant
things
like
sessions.
Every
time
you
do
a
cross-context
dispatch,
you
use
the
same
session
id,
but
you
have
a
different
instance
of
the
session.
So
all
your
objects
that
you
know
are
dealing
with
sessions.
They
don't
have
to
deal
with
one
session.
B
So
the
target
could
downcast
the
request
to
your
wrapped
request
and
call
special
apis
on
that,
and
so
the
problem
with
that
meant
that
it
didn't
allow
the
container
to
wrap
over
the
top.
When
you
did
a
dispatch
to
a
new
servlet
which
would
change
the
servlet
path
or
the
the
part
info,
we
had
to
change
the
the
request
underneath
the
application
provided
wrapper.
So,
therefore,
our
requests
and
our
our
request,
especially,
were
mutable
objects
where
the
servlet
path,
the
path
info,
the
his
user.
B
Enroll
methods
could
change
their
behaviors
as
they
were,
dispatched
from
a
filter
to
a
servlet
from
a
server
to
another
servlet
or
from
a
server
to
another
context,
which
was
probably
fine
originally,
when
we
first
did
the
server
spec,
but
now
we're
trying
to
increasingly
do
asynchronous
applications
having
immutable
request.
Objects
is
really
not
optimal,
because
it
means
your
asynchronous
processors
could
look
at
them
any
time
and
they
could
change
back
to
or
change
values,
while
you're
looking
at
them
and
you're
immediately
into
a
race
position.
B
You
know,
difficulties
in
the
servant,
spec
is
that
it's
was
originally
blocking
and
then
over
the
years
we
developed
it
and
at
the
spec-
and
it
turns
asynchronous
so
now
you
can
use
it
asynchronous
or
blocking,
and
the
asynchronous
was
kind
of
tacked
on
on
there.
As
an
afterthought,
it's
got
some
nice
ideas
in
the
api,
but
it
meant
that
the
implementation
had
to
be
dragged
along
underneath
it
and
evolved
into
that,
and
it
was
neither
you
know.
B
The
implementation
we
ended
up
with
was
neither
really
well
suited
for
blocking
or
well
suited
for
asynchronous.
It
was,
you
know,
trying
to
do
both
and
had
problems
in
in
both,
and
so
the
I
guess,
the
the
final
thing
about
why
service
has
a
cost.
Is
that
it's
an
evolved
solution
that
we,
you
know
wearing
jetty?
Our
current
stable
version
of
jetty
is
a
gt11,
and
so
that's
11
iterations
of
jetty.
B
So
that
was
just
immediately
a.
It
was
a
simple
trivial.
You
know
you
know,
search
and
replace
to
change
your
code
from
server
five
to
seven
six,
but
it
meant
you
couldn't
be
binary
because
compatible
with
servlet,
one,
at
least
not
in
all
your
xml
config
files,
and
things
like
that.
So
that
was
a
bit
of
a
breaking
change
there.
B
Now,
in
five
to
six,
we've
done
two
significant
things
that
also
are
considered
breaking
changes.
We've
taken
out
all
the
deprecated
methods
that
were
in
service
five,
and
so
six
is
a
little
bit
fresher,
and
so
we've
taken
away
a
lot
of
that.
You
know
15
20
years
of
history,
which
does
have
a
cost,
so
getting
rid
of
that
means
the
code
base
is
smaller,
there's
less,
you
know,
ifs
and
buts,
that
you
have
to
do.
B
So
that's
the
scene
of
where
we
got
to
that.
We
we
recognized.
We
wanted
to
be
fast
implementation.
That
would
would
compete
equally
with
any
non-servlet
server
implementation
and
also,
actually
we
have
a
client
as
well.
So
we
want
fast
client
as
well
it
scales.
Well,
we
recognize
that
there
is
a
cost
of
the
servlet
spec
and
we
really
wanted
to
move
to
a
better
sort
of
no
taxation
without
representation
like
you're
not
using
a
feature.
B
We
really
don't
want
you
to
have
to
pay
the
cost
for
cross-context
dispatch,
blah
blah
blah,
so
we
decided
to
take
the
op,
oh
and
then
there's
the
the
breaking
apis.
So
we
now
have
you
know
old,
legally
apps
that
can't
run
on
a
server
six
container,
and
so
the
approach
that
we've
always
had
of
having
one
container
that
would
just
be
backwards
compatible
with
odd
ones,
is
not
going
to
work
anymore.
So
we
decided
to
take
this
opportunity
to
go
into
servant
six
to
be
a
fairly
major
re-engineering
of
of
jetty.
B
So
this
is
we
used
to
have
this
back
in
yeti,
3
or
something,
but
we
we
made
ourselves
dependent
on
the
server
api
in
those
early
days,
but
we're
going
to
go
in
we've
gone
independent
again
in
that
server
core
and
that
can
be
used.
You
know
in
an
embedded
mode
and
gives
very
high
performance.
It's
you
know,
there's
some
aspects,
a
servlet
like,
but
it's
it's
it's.
B
But
again,
that's
a
very
little
used
feature,
and
so
we've
moved
the
cross
cut
context,
dispatch
out
into
a
a
wrapping
style
architecture
so,
rather
than
mutating
the
requests
underneath
we're
going
to
be
able
to
wrap
over
cross
on
on
top
and
all
the
complexities
of
the
cross
context.
Dispatch
will
be
in
that
wrapper
and
will
be
therefore
paid
by
the
person
who's
doing
the
cross
cost
complex
dispatch
and
not
by
every
single
other
request.
The
99.999
request
that
don't
do
cross-context
dispatch.
B
So,
what's
the
the
key
change
in
in
the
core
of
jetty?
Well,
it's
almost
a
green
fields
build
up
of
a
pure
asynchronous
style
of
serving
hdp,
and
we've
always
had
a
fully
async
core,
but
it
was
always
a
little
bit
of
a
compromise.
The
way
we
would
represent
that
up
into
the
blocking
layers
of
the
servlet
layer.
B
With
all
the
data
that
you
just
read
all
the
data
you
just
passed
and
then
you
go
into
the
application
and
that's
all
sitting
in
it's
that
cpu
cache
and
you
get
a
lot
better
performance.
You
know,
I
think
we
we
saw
30
40
performance
improvements.
If
you
can
achieve
that
style
of
invoke
in
invoking
your
application,
which
means
the
thread
that
selects
the
io
is
the
one
that
reads.
B
But
now,
by
going
to
a
fully
asynchronous
server
where
we
can
know
the
invokable
nature
of
all
the
way
into
the
application,
when,
if
the
application
is,
is
seen
to
be
a
fully
asynchronous
application,
then
that
selector
thread
can
go
all
the
way
in
to
that
application.
Reading
parsing
calling
it
and
you
get
much
better
performance
that
way.
B
Now,
I'm
talking
about
how
wonderful
we
are
that
we're
fully
asynchronous
and
and
whenever
I
say
that
we're
fully
asynchronous
the
the
someone
always
you
know,
I'm
surprised,
no
one's
put
their
hand
up
and
said,
but
what
about
loom
isn't
loom
coming
along
and
we
never
have
to
be
asynchronous
again.
We
can
just
use
millions
of
loom
threads
and
we
don't
have
to
worry
about
it.
Well,
yes,
and
no
loom
is
an
interesting
technology.
It's
still
very
immature.
B
I
I
last
looked
at
it
probably
a
year
ago
and
tested
out
some
of
their
claims
and
what
I
think
the
issue
is
is
that
loom?
While
it
has
some
attractive
features,
it's
not
really
suitable
for
the
guts
of
implementing
something
like
a
a
web
server.
That's
going
to
scale,
it
may
be
a
mode
in
which
we
can
call
applications
and
give
them
all
their.
You
know
if
we've
got
a
thousand,
you
know
actually
a
thousand.
It's
not
probably.
If
we've
got
a
hundred
thousand
active
requests.
B
For
instance,
we
yeah
we
have
the
the
servlet
apis
for
getting
parts
from
a
multi-part
request
or
getting
parameters
from
a
a
form
and
those
apis
in
the
server
container
server
api
are
blocking
apis,
you
say
get
parts
and
it
will
block
until
all
those
parts
are
read
now
some
of
those
parts
might
be.
You
know,
multi
gigabyte
files
that
are
being
loaded
up
and
stored
on
disk,
but
you'll
have
a
thread
blocked
there.
Waiting
until
that
happens,
is
over
that
slow
link.
B
But
what
we
can
do
now
with
jetty
is
that
we
can
see
those
those
requests
coming
in
with
the
asynchronous
or
whatsoever
the
the
form
content
or
the
multi-part
content,
and
we
can
read
those
in
advance
for
you.
We
can
read
those
asynchronously,
because
we
know
that
you
know
that's
going
to
be
read.
The
the
servlets
are
annotated,
saying
that
they
want
to
have
the
use
the
parts
api.
B
So
we
don't
call
this
servlet
that
has
the
is
going
to
read
those
parts
until
we've
asynchronously
read
all
those
parts
stored
them
away
in
files
or
in
memory
or
wherever
yeah
is
optimal
to
do
it.
We
can
then
call
that
application,
potentially,
even
with
the
the
thread
that
did
the
selection
read
the
last
bite
of
the
multi-parts
and
go
straight
into
the
application.
The
application
will
then
try
and
read
the
moldy
parts.
Okay
get
parts
and
that
won't
block,
because
we've
read
them
they're
already.
B
B
But
we
can,
you
know
we
can
deal
with
that
by
giving
them
big
buffers,
so
they
can
write
in
those
big
buffers
and
if
they
don't
fill
up
the
buffers,
then
we
don't
have
to
block
once
they
finish
the
servlet.
We
can
then
flush
that
big
buffer
out
asynchronously,
so
it's
possible
that
you
can
actually
you
know,
write
a
blocking
application
but
running
it
in
gt12,
well,
already
actually
running
in
jetty,
10
or
11,
but
more
so,
if
you're
running
in
gt12
it
will
run
in
a
mode
where
it
never
blocks.
B
We
will
do
the
we'll
asynchronously
read
the
contents,
we'll
let
you
write
the
content
into
some
big
buffers
and
then
we'll
asynchronously
flush
that
out.
Of
course
you
can
can
also
use
the
server
asynchronous
api
for
for
asynchronous
reading
or
asynchronously
writing,
and
that
will
work
as
well.
But
you
know
I
guess,
if
you've
been
reading
about,
loom,
writing
async
is
difficult
and
you
know
if
your
applications
can
can
be
performant
without
having
your
application
developers
having
to
write
asynchronous
code.
B
B
You
know
the
the
core
is
working
very
well
and
we've
done
some
good
benchmarks
on
the
core
of
the
asynchronous
hp
container,
and
it's
just
to
be
honest.
It's
impressive!
We
the
when
we
first
started
in
the
benchmarks.
We
were
like.
Oh
no,
that's
too
good
the
benchmark's
wrong.
We're
not
seeing
it
right
we're
looking
on
the
wrong
machine
or
something
else
is
happening.
The
jits
optimizing
it
away,
and
so
we
spent
a
couple
of
days
checking
the
benchmarks
to
go.
Oh
no
yep
they
are
actually
it
is
doing
really.
B
B
We
have
both
server
5
and
server
6
running
on
top
of
that
core,
not
in
a
fully
fledged
way
we're
missing
some
of
the
features
like
the
multi-part
we're
still
turning.
We've
only
turned
half
the
parser
of
that
into
asynchronous.
It's
still
got
the
synchronous
parser
on
that,
so
we're
missing
some
of
the
features
and
cross
contracts,
dispatch
and
stuff
like
that.
But
we've
got
the
sessions
in
there
and
yeah
and
the
the
core
servlet
api,
and
so
that's
working
on
five
and
six.
B
B
B
So
we
hope
to
have
a
what
is
it
it's
april
early
may
we'll
have
an
alpha
release
out
and
we're
looking
for
a
you
know,
a
a
beta
or
an
early
access
release
in
june
or
july,
but
I
think
it's
next
month
that
we,
you
know
we'd,
expect
to
have
a
bill
that
you
could
get
down
and
actually
use
at
the
moment.
The
branch
is
there,
it's
out
the
public,
but
it
it
it
builds,
but
doesn't
pass
tests
and
half
the
time
doesn't
build
we're
actually
still
in
the
hackathon
branch.
B
So
we're
still
have
to
to
bring
that
back
to
the
main
branch
and
then
and
slow
down
development
with
pull
request
type
behaviors.
Now
that's
my
off
the
cuff
status
report.
I
can
actually
now
share
screen
and
show
a
little
bit
of
the
way
that
the
call's
working
it's
it's,
not
the
servlet
api.
So
if
you're
here
for
server
stuff,
I
think
I
think
it's
not
going
to
be
at
the
servant
level,
but
I
could
show
a
little
bit
of
what
we're
doing
below
the
covers.
B
B
Okay,
all
right
so
I'll
start
off
the
the
the
presentation
with
our
hello
handler,
which
is
our
base.
You
know
an
example
handler
of
what
you're
doing
if
you're
running
native
jetty
as
opposed
to
servlets,
and
you
can
see
that
the
the
main
method
we
have
to
override
is
process
and
which
I
guess
is
equivalent
to
the
server
service
request
and
we
pass
in
a
request
and
a
response
very
much
like
the
servlets,
but
also
a
callback
and
the
callback
is
showing
that
we
are
asynchronous
and
basically
you
can
process
the
requests.
B
I'll
read
the
request
read
the
response,
but
ultimately
somebody
has
to
call
success
or
fail
on
the
callback.
So
our
callback
in
interfaces
succeeded
or
failed.
Is
that
you
know
one
or
the
other
has
to
be
called
on
our
callback,
and
we
can
see
that
we
can
write
something
asynchronously.
Quite
simply,
here
we
can
set
the
response
status
200.
We
can
set
the
content
type
as
a
text,
plane
utf-8,
and
then
we
can
do
a
write
and
so
we're
doing.
This
is
an
asynchronous
write
method.
B
So
we
we're
passing
in
a
callback
and
what
I'm
doing
here,
because
I
know
I'm
only
writing
a
single
message,
I'm
passing
in
the
callback
I
was
passing
by
process,
and
quite
often
you
can
do
this,
you,
if
you
have
a
single
content,
you
can
say:
oh
I've
got
a
just
one
thing
to
write
or
I've
buffered
it
up
and
I'm
going
to
write
it
as
once.
So
I'm
going
to
write
it,
I'm
saying
true:
it's
the
last
content.
B
I'd
really
hope
that
writing
five
characters
out
would
wouldn't
block.
But
but
you
know
you
never
know
what
sort
of
network
you're
running
on
and
that's
how
you
you
start
off
with
nice,
something
simple
asynchronous.
If
you
wanted
to
go
blocking
in
here,
you
could
go
blocking.
I
think
I've
got
a
version
of
this
blocking
where
I
I
could
go.
B
I
could
say
hello,
it's
not
the
last,
so
I
got
it
here.
I'm
running
a
completable
future
there's
other
ways
of
doing
this,
but
that
you
know
that
at
least
I
can
block
on
that
until
it's
done
so
that
waits
until
I
make
a
call
back
from
the
future,
and
so
I
do
the
right
call
back
from
the
future.
That
sounds
kind
of
cool
and
I
block
here
waiting
for
it
and
then
I
can
write
something
else.
I
could
do
the
same
thing
again.
I
would
make
another
future.
B
B
B
And
I
probably
really
should
because
these
jets
can
throw
if
something
goes
wrong.
I
should
probably
you
know,
put
a
try
catch
and
if
I
catch
an
exception,
call
back
failed,
but
you
could
so
you
could.
You
know,
go
to
a
blocking
api
like
that.
But
what
we've
done
instead
really
is.
We've
got
a
whole
bunch
of
utility
methods
for
turning
our
our
content.
So
here's
our
content
flow.
B
B
If
you
get
back
now,
you
can
demand
content
and
passing
a
runnable,
and
that
will
call
you
back
when
there's
something
available
and
you
can
read
more
very,
very
similar
to
the
reactive
stream
style
of
api,
not
it's
actually
trivial,
to
turn
it
into
a
flow.
If
you
want
to
a
reactive
stream
flow,
so
we
actually
do
that
for
you
we
can
say
content
publisher.
B
So
if
you
want
to
treat
it
as
reactive
streams,
you
can
make
a
content
publisher,
passing
in
our
request,
object
and
then
you
can
subscribe
to
content
and
you
can
use
demand
one
blah
blah
blah.
So
it's
pretty
similar
to
that.
But
the
other
thing
we
can
do
is
you
want
your
request
as
an
input
stream,
so
you
could
just
easily
turn
it
into
an
input
stream.
So,
oh
sorry,
and
for
the
hello
handler
you
can
do
the
same
thing
for
our
output.
You
can
trivially
turn
it
into
an
output
string.
B
Do
I
have
an
example
of
that?
I
don't
but
anyway.
So
the
idea
is
that
you
can
use
the
request
and
the
response
asynchronously
if
you
wish
to
use
them
blocking.
You
can
do
your
own
blocking
management
here
or
you
can
turn
them
into
input
stream,
output
stream
or
you
can
turn
them
into
reactive
stream,
publishers
or
subscribers
providers,
either
way
and
use
them
through
those
apis.
B
B
B
So
if
you
want
to
asynchronously
process
the
form
rather
than
doing
asynchronous
io,
you
can
just
wrap
the
request
with
a
field
publisher,
which
you
then
subscribe
to
and
then
you'll
get
each
field
as
it
comes
in.
As
it's
read,
asynchronously
delivered
you
delivered
to
you
over
the
reactive
stream
style
api
flow,
or
if
you
wanted
to
wait
into
the
the
very
end,
then
we
have
a
what's
it
called
future
form
fields.
B
We
have
a
completable
future
which
will
give
you
all
the
the
the
fields
at
once,
and
so,
therefore,
you
can
basically
wrap
the
request
with
this
completable
future
and
then
you
can
do
where's,
it
where's
an
example.
I
think
I
did
here
until
forms,
so
you
basically
you'd
wrap
it
and
say
well.
If
it's
done
it's
all
there,
then
I'm
going
to
continue
processing.
B
B
This
is
what
I
was
saying
that
that
if
you
wish
to
delay,
we
delay
processing,
which
would
eventually
invoke
the
servlet
until
such
time
as
we've,
asynchronously
read
all
the
form
fields
and
so
and
we
just
use
you
know,
completable
features
here
to
to
do
that
and
again,
this
is
the
mechanism
we
put
underneath
the
server
api.
I
could
show
no
it'll
be
too
much
detail,
but
basically
we
have
our
servlet
request,
which
wraps
our
our
asynchronous
request.
B
When
you
say
you
know,
get
get
properties
get
parameters
which
one
it
is
when
you
want
to
get
the
field
content
it'll
go
off
and
it
used
to
go
off
and
read
that
in
a
blocking
read,
but
now
it'll
it'll
look
for
one
of
these
future
form
fields
which
may
have
already
been
completed.
So
if
you've
gone
through
one
of
these
delayed
handlers,
it
would
have
read
it
for
you
and
all
the
content
will
be
there
ready
for
you.
You
won't
block,
it
will
just
be
there.
B
B
B
We
don't
seem
to
be
seeing
a
lot
of
performance
there
or
we're
a
little
bit
wondering
how
that's
going
to
happen
unless
you've
got,
can
somehow
get
some
hardware
support
into
the
use
of
space
things,
but
we'll
yeah
we'll
see
it's
there.
It
works,
we'll,
follow
the
flow
and
then
okay,
here's
how
we
can
copy
input
from
the
asynchronous
request
to
the
asynchronous
response
again
passing
the
callback.
So
we
have
content
copies
that
will
do
it
asynchronously.
If
there
was
no
content,
we
just
succeeded.
B
If
we
really
wanted
to,
I
guess
we
could
do
it
blockingly,
so
we
could
have
done
a.
We
have
a
io
copy
method
which
takes
a
input
stream
and
an
output
stream.
So
we
can
do
that
one.
We
could
have
gone
content
as
input
stream
and
take
the
request
and
write
that
to
a
content
as
output
stream
clicking
the
response
and
that's
the
blocking
way
of
doing
it.
B
What's
it
whinging
about
that's,
probably
throwing
a
throwing
exception,
so
you
have
to
handle
exceptions
and
stuff
like
that,
but
so
that
shows
you
that
we
can
deal
with
things
asynchronously
or,
but
if
you
really
want
to,
you
can
deal
with
them.
Synchronously
and
again,
that'll
be
the
the
the
core
the
when
we
go
to
the
server
spec.
All
things
are
input,
streams
and
output
streams.
B
It
schedules
a
call
back
if
israel
returns
false,
it
schedules
a
callback
to
a
on
data
available
method.
So
it's
very
easy
to
implement
is
ready
with
this
style
of
semantics.
You
can
try
and
read
content.
If
you
get
that
content,
you
say
true,
you've
got
context
free
to
read,
you
get
back
null,
you
say,
demand
content
and
you
pass
in
a
runable
that
will
ultimately
call
on
on
data
available.
B
Well,
it'll
check
the
content
from
the
file
because
it
might
have
to
call
on
all
data
red,
and
I
think,
that's
probably
all
I
can
really
show
you
off
the
cuff
today
with
very
little
preparation
again.
My
apologies
for
being
a
little
bit
too
bum
head
down
bum
up
working
on
on
jetty
12
to
have
seen
this
coming.
I
would
have
liked
to
have
given
more
demonstrations
of
servlets
are
working.
I
can
I'll
run
requests.
There's.
A
B
Ask
a
question:
okay,
got
it
there,
okay,
so
jeti
itself
doesn't
have
ejbs
built
into
it.
We
do
have
good
integration
with
open
ejb.
The
transaction
manager
that
was
used
was
written
by
by
a
lot
of
ejbs
was
actually
one
of
the
developers
of
that
is
working
for
us.
There's
ejb
jpa
jta.
No,
we
don't.
We
don't
go
down
that
profile
at
the
moment.
Basically,
we
are
a
servant
container.
A
A
A
Also
we
we
are
looking
for
the
next
jakarta
tech
talks
that
to
book
another
jakarta
tech
talk
throughout
2022,
so
if
you're
interested
in
presenting
feel
free
to
fill
out
the
form
which
I
have
also
linked
in
the
chat
and
finally,
we
would
love
to
get
some
feedback
from
you.
So
once
we
close
this
up,
there
is
a
little
button
and
that
you
that
will
pop
up.
A
So
just
let
us
know
if
you
enjoyed
the
talk
and
I'm
just
gonna,
do
a
quick
look
in
the
ask
a
questions
again:
greg
just
to
make
sure
that
we've
covered
everything
yep.
So
there's
nothing
in
the
chat
and
and
jeff
just
said,
gave
you
a
plus
one.
So
we
are
good
there,
so
it
doesn't
look
like
there's
more
questions.
Thank
you
so
much
again,
greg
for
everything
and
thank
you
for
everybody.
Who's
joined
us
today
and
have
a
wonderful
day.