►
From YouTube: Jakarta Servlet: A New Twist on an Old Favorite | JakartaOne Livestream - September 2019
Description
Speaker: Ed Burns
Servlets are the oldest technology in Jakarta EE. This talk shows how Servlets are fundamental to the success of Jakarta EE by demonstrating the new features in Servlet 4.0. I will show how the new features, including HTTP/2.0, enable modern competitive web applications with Jakarta EE.
///GET SOCIAL!
Subscribe: https://www.youtube.com/user/EclipseFdn
Follow us on Twitter: https://twitter.com/JakartaEE
Follow the conference: https://twitter.com/JakartaOneConf
Like us on Facebook: https://www.facebook.com/JakartaEE/
Become a member of our Jakarta Tech Talks Meetup: https://www.meetup.com/jakartatechtal...
Join us on LinkedIn: https://www.linkedin.com/groups/13597...
Tag us: #JakartaEE #JakartaOneLivestream
A
Here's
our
agenda
for
today
I
will
be
giving
the
first
and
most
interesting
information
at
the
beginning
beyond
servlet,
for
the
plans
for
what's
next,
such
as
they
are,
then
I'll
talk
about
how
servlet
4
might
fit
into
contemporary
developer
context,
such
as
micro
services
architectures,
the
middle
of
the
presentation,
I'll
dive
into
the
new
features
that
are
in
servlet,
4
and
I'll.
Close
with
the
summary
some
information
about
myself.
A
I
am
qualified
to
give
this
talk
as
I
was
the
spec
lead,
a
co
spec
lead
for
servlet
and
also
the
coast
bike
lead
for
JSF.
These
are
two
parts
of
Jakarta
ee8
specification,
family
I'm,
a
frequent
International,
Conference,
speaker
and
I've
written
for
enterprise,
Java
related
books
from
the
Rahil,
including
JSF,
to
dotto
the
complete
reference.
A
Let's
talk
about
current
plans
such
as
they
are
well.
Unfortunately,
it
is
what
it
is.
The
current
for
the
servlet
for
current
plan
is
just
bug
fixes.
Only
I
would
like
to
report
some
great
progress,
though,
that
the
Jakarta
team
has
done
with
servlet,
for
you
can
check
out
these
links
here.
The
project
home
page
and
today's
release
is
403.
They've
got
the
Java
Docs
set
up
there.
The
project
leads
are
greg,
wilkins
and
stuart
douglas.
A
A
So
all
of
the
spec
documents
were
just
written
in
frame
because
that's
how
all
of
our
documentation
team
did
the
work,
and
this
was
a
you
know.
We
had
these
specs
that
were
written
before
asciidoc
was
even
invented.
So
once
you
write
a
300-page
thing
and
frame-maker,
it
would
require
some
significant
economic
investment
of
time
to
convert
that
over
into
this
more
maintainable
format.
A
So
oracle
never
found
it
economical
to
do
that
and
neither
did
sun
before
so
that
is
one
of
the
bigger
tasks
is
converting
all
that
stuff
over,
but
they
do
have
placeholders
in
place.
So
if
you
look
at
the
and
build
the
jakarta
eee
servlet
project,
now
you
get
this,
you
know
nice
little
PDF.
That
is
really
just
a
stub,
unfortunately,
but
it
is.
It
shows
that
it's
there
and
you
know
it's
a
matter
of
time
and
effort
to
fill
it
out
with
the
content
from
the
frame-maker
documents.
A
When
we
finally
get
that
the
problem
is,
of
course
you
have
to
have
a
frame
maker
license
to
read
it
and
that's
something:
that's
not
free,
so
I'm
not
sure
how
they're
going
to
deal
with
that,
but
that's
a
significant
problem,
but
it's
not
a
hard
problem.
Just
takes
time
and
effort.
I
did
do
a
little
bit
of
polling
of
some
of
the
thought
leaders
on
what
they
thought
would
be
a
an
important
next
for
the
servlet
API
in
terms
of
new
features,
and
they
uniformly
said.
A
You
know
what
this
API
is
pretty
solid,
pretty
good
for
what
it
is
and
what
it
does
so
mark
Thomas,
who
was
the
main
guy
on
Tomcat?
You
know
said
when
they
ran
the
TCK
against
tonka.
They
found
some
bugs
in
the
TCK
that
they
would
like
to
fix
and
re-enable
those
tests
test.
Exceptions
were,
you
know,
done,
and
it's
better
to
have
a
test
suite
that
exercises
lots
of
things
rather
than
simply.
Oh,
the
test
doesn't
pass.
Let's
just
exclude
that
test.
A
That's
the
kind
of
thing
you
have
to
do
in
a
resource-constrained
environment,
but
hopefully
going
forward.
We
won't
have
that
problem
as
much
greg
did
specifically
call
out
the
need
to
implement
the
will
of
the
project
team
with
regard
to
package
renaming
and,
finally
wanting
to
do
some
bug
fixes
and
clarifications.
For
my
part,
I
really
would
like
to
see
us.
Do
the
AL
pn
thing
right?
I
will
get
into
the
detail
on
this,
but
the
long
and
the
short
of
it
is
when
we
developed
servlet
4.
A
A
So
I'd
like
to
ask
you
know
they
asked
the
question:
how
is
servlet
relevant
in
the
context
of
a
micro
services
architecture?
In
order
to
ask
that
question,
we
have
to
have
a
definition
of
what
a
micro-services
architecture
is
and
to
the
best
of
my
ability.
This
is
a
pretty
reasonable
definition
here,
small
loosely
coupled
I,
you
know
each
of
the
services
are
isolated
from
each
other.
They
are
highly
internally
cohesive.
A
They
do
just
one
thing:
they
can
be
managed
to
ployed
and
developed
independent
of
others,
and
each
service
is
responsible
for
handling
its
own
data.
So
I'm
going
to
take
j2ee,
servlets
and
ask
hey:
is
that
an
example
of
an
early
Java
micro
services
platform?
Let's
look
at
each
of
these
concerns
in
turn.
A
Okay,
is
it
a
small
you
know?
Is
it
possible
to
write
each
servlet
in
microservices
architecture
of
small?
Yes,
well,
there's
nothing,
stopping
you
from
keeping
your
servo
its
small,
but
in
practice
it
was
very
easy
to
allow
them
to
get
pretty
big
chains
of
servlets
and
filters
because
it
was
just
such
an
easy
programming
model,
so
I'm
gonna
give
that
a
maybe
loosely
coupled
can
be
composed.
Well,
filters
do
compose
very
well
and
the
filter
chain
concept
is
expressly
designed
to
support
composing
so
long
I
give
that
a
yes.
A
Is
it
possible
to
write
servlets
such
that
they're
isolated
from
each
other?
That
is
generally
not
how
people
use
servlets
and
an
outage
in
any
specific
servlet
would
prevent
the
entire
rest
of
the
call
flow
from
continuing.
That's
got
to
be
a
no.
Is
it
possible
to
have
each
servlet
be
highly
internally
cohesive?
Yes,
it
is
generally
serve
it.
So
uses
controllers
or
act
as
filters
that
act
on
an
HTTP
request
and
either
pass
it
on
to
some
other
service
or
send
a
response.
So
I
will
give
that
a
yes.
A
A
Servlet
generally
don't
have
much
in
the
way
of
data,
but-
and
this
was
always
handled
by
other
parts
of
the
job
in
monolith,
but
whatever
data
a
servlet
does
have
it's
generally,
not
shared
with
other
parts
of
the
system.
I'll
give
that
a
yes,
so
on
the
whole
I
would
say
kind
of
sorta.
It
is
possible
for
you
to
look
at
servlets
as
a
very
early
Java,
my
croissant,
to
take
this
opportunity
to
point
out.
A
One
of
the
defining
characteristics
of
a
monolith
versus
a
micro
services
architecture
is
how
much
complexity
is
in
the
overall
system
as
a
whole
and,
unfortunately,
the
complexity
has
to
live
somewhere.
So
in
a
model,
if
you
know
the
complexity
is
all
present
in
one
big
glob
of
stuff,
whereas
in
the
micro
services
architecture,
complexity
is
spread
out
a
lot
more.
A
So
you
have
to
be
very
careful
when
you
do
this
monolith
decomposition,
because
you
know,
if
you
want
to
get
some
gains
from
it,
you
have
to
do
the
architecture
such
that
it's
not
just
taking
existing
complexity
and
blowing
it
up
all
over
the
place.
So
it's
harder
to
track.
You
can
achieve
the
gains
of
deployment
and
agility,
but
you
have
to
have
very
close
attention
to
managing
the
complexity
and
making
sure
your
concerns
are.
A
You
know:
orthogonal
e
partitioned
out
all
right,
I'd
like
to
take
a
time
to
mention
the
power
of
JCP
here,
which
is
very
good
at
incorporating
industry
trends
and
maintaining
compatibility.
So
servlets
because
they've
been
around
for
so
long,
have
adapted
and
incorporated
new
features
from
industry
trends
and
best
practices
all
along.
So
you
know
the
packaging
concept
of
you
know
long
before
there
was
docker
containers
that
would
allow
a
application
and
its
dependencies
to
be
packaged.
You
could
have
a
war
file
which
would
you
know,
keep
the
class.
A
You
know
webbing,
Flibe
and
webbing
classes.
That's
how
you
would
package
your
dependencies
asynchronous
programming.
That
was
not
really
possible
when
servlets
first
came
out,
but
as
non-blocking
I/o
and
other
kinds
of
reactive
programming
models
came
along,
it
was
possible
to
do
that
with
servlet,
so
we
adapted
and
add
those
things
to
servlet
in
servo
3.1,
for
example,
dependency
injection
that
did
not
exist
to
the
beginning
and
the
concept
of
inversion
of
control
and
dependency
injection
came
along
and
then
you
know
the
JCP
adapted
and
said
hey.
A
You
know,
let's
have
jsr
250
and
that
was
dependency
basic,
the
@
resource
annotation,
and
it
since
has
expanded,
of
course,
with
the
context
and
dependency
injection,
CDI
and
servlet
takes
great
advantage
of
that
as
well,
and
the
most
recent
example
that
I'll
be
talking
about
some
detail
today
is
the
introduction
of
HTTP
to
servlet
being
the
lower
level.
Network
API
for
the
jacquard
ee
platform
is
where
you
would
say:
hey,
there's
an
HTTP
2
requirement
and
that's
what
servlet
floor
brings
to
the
table.
A
So
there
might
be
some
possible
reasons
to
use
servlet
for
greenfield
development
in
a
microservices
style.
It's
let's
talk
about
migration.
Here,
teams
might
be
a
risk
averse
to
trying
a
whole
new
way
of
doing
things
in
terms
of
architecture
and
a
whole
new
set
of
tools
and
in
terms
of
how
to
implement
that
architecture.
So
if
you
would
like
to
take
a
more
incremental
approach,
you
could
adopt
the
microservices
architecture,
but
keep
the
old
stack
the
servlet
way
of
doing
things.
A
So
this
is
a
more
common
case
where
you
have
a
collection
of
ears
with
wires,
and
then
you
separate
them
into
individual
water
files.
Then
you
stand
up
breast
services
in
five,
the
wores
and
then
eventually
you
have
the
West
rest
services
absorbed
the
functionalities
of
the
wores,
and
once
you
have
this
big
collection
of
rest
services,
then
you
know
you
can
pretty
much
get
close
to
having
a
full
market
services
architecture.
A
First
thing
I
want
to
point
out
is
my
colleague,
manfred
green,
has
moved
over
the
Java
EE
examples
into
jakarta,
ee
examples
and
there's
great
examples
in
there
for
all
of
the
new
features
that
I'll
be
talking
about
here.
So
if
you
want
to
have
sample
code
that
shows
how
to
use
these
things,
you
can
go
and
get
it
there
and
drop
it
into
your
projects
and
modify
it
and
keep
going
that
way.
So.
A
A
But
let's
take
a
look
at
the
actual
first
abstract
of
the
HTTP
2
RFC
RFC
75
for
0
I
believe
that
it's
a
great
manifestation
of
the
notion
that
perception
is
reality,
especially
with
web
browsers.
So
you
can
see
here
that
we
want
to
have
reduced
perception
of
latency
with
using
header
field
compression
and
enabling
multiple
concurrent
exchanges.
A
A
A
So
this
is
what
the
request
response.
Multiplexing
looks
like
you.
Have
your
browser
on
the
left
and
your
server
on
the
right
here
and
both
sides
of
the
this
connection
can
introduce
or
initiate
content.
Generally.
Of
course,
the
browser
starts
it
out
by
making
a
request,
but
once
that
stream
is
established,
you
can
have
you
know,
request
and
response
headers
flowing
back
and
forth.
A
The
odd-numbered
headers
are
reserved
for
coming
from
the
client
to
the
server
and
the
even-numbered
headers
are
reserved
for
coming
from
the
server
to
the
client,
and
once
you
break
down
the
communication
into
frames,
you're
able
to
interweave
the
logical
streams
over
a
single
TCP
connection,
so
you're
able
to
get
more
throughput.
That
way.
A
This
is
what
the
individual
specification
of
the
frame
looks
like
in
terms
of
actually
bits.
You
have
a
24-bit
length,
followed
by
a
type,
an
8-bit
type
field
and
8
bits
of
flags,
a
single
byte
or
bit
of
reserved
field,
and
then
you
have
this
stream
identifier,
which
is
a
31
bit
integer,
and
then
the
frame
payload,
the
actual
data
of
the
frame,
for
example,
in
a
body
frame
that
would
be
the
HTML
for
example.
A
Now
the
type
field
can
be
any
number
of
things.
We
have
data
and
getting
your
actual
content
that
I
mentioned
headers
your
HTTP
request/response
headers,
a
priority
frame
which
indicates
how
the
client
is
to
deal
with
this
process.
It
with
respect
to
all
of
the
other
frames
that
are
coming
in
reset
stream
is
a
signal
type
that
says:
okay,
we're
going
to
close
this
stream
settings
frame,
which
enables
you
to
change
aspects
of
the
communication
back
and
forth.
Push
promise
is
a
frame
that
comes
from
the
server
to
the
client.
A
Saying
I'm
gonna
promise
to
be
pushing
you
something
ping
is
important
to
keep
the
connection
open,
because
if
you're
gonna
keep
this
one
live
TCP
connection,
you
have
to
keep
sending
some
kind
of
heartbeat
to
enable
the
TCP
network.
Routing
algorithms,
to
optimize
things
correctly
go
away.
Is
the
frame
that
sent
when
the
server
wants
to
close
connection
window,
update
and
communication
or
to
lower-level
networking
aspects.
A
I
also
wanted
to
mention
header
compression,
so
perception
is
reality
and
we
were
perceived
that
HTTP
was
going
slower
than
it
needed
to,
because
we
were
spending
a
lot
of
time
and
a
lot
of
network
bandwidth,
sending
the
same
set
of
headers
back
and
forth
all
the
time
you
know
host.
It's
always
the
same
thing:
user
agent.
You
know,
given
one
browser
talking
to
a
server,
it's
not
going
to
change
this
user
agent
during
the
course
of
its
interaction
with
the
server.
A
So
why
send
them
every
time
what
they
decided
to
do
was
have
the
server
and
the
client
keep
tables
of
headers
a
state
machine
and
then
to
send
references
and
updates
to
the
tables.
Furthermore,
they
defined
pseudo
headers
for
the
most
common
things
you
wouldn't
have
to
spell
them
out.
These
are
just
and
numbers
kind
of
like
an
enum
stream.
A
Prioritization
I
mentioned
that
you
have
a
number
of
different
streams
in
a
connection,
so
you
can
have
individual
priorities
for
each
of
these
streams,
and
so
that's
an
additional
40
bytes
in
the
frame,
which
is
the
stream
ID
and
a
weight
and
an
exclusive
bit.
This
is
just
advisory.
You
know,
there's
nothing
that
says.
Clients
must
do
this
so
they're
invalid
HTTP.
They
could
simply
not
even
deal
with
the
prioritization
and
treat
everything
the
same.
A
It's
just
that
it's
possible
to
achieve
and
squeeze
out
more
performance
if
the
client
and
the
server
both
do
this
correctly.
So
here
are
some
examples:
if
we
have
stream
B
and
stream
C,
depending
on
stream
a
we
have
assignment
of
4
to
stream,
be
an
assignment
of
12
to
stream
a
it
says.
Well,
we
should
give
a
proportionally
higher
number
of
resources
to
processing
C
than
we
do
to
be.
A
D
should
be
given
higher
priority
treatment
from
the
client,
so
you
can
assign
a
exclusive
bit,
which
will
mean
that
it
is
the
only
thing
that
depends,
so
it
basically
moves
it
up
a
level
in
the
hierarchy,
so
it
will
be
giving
giving
all
of
the
treatment
before
anything
from
this
level
that
doesn't
have
the
crew
so
that
set
all
right.
We'll
talk
next
about
server
push
one
of
the
HTTP
1.0
and
1.1
have
stood
the
test
of
time.
A
There's
no
question
about
that,
but
it
has
enabled-
or
it
has
caused
web
designers
to
come
up
with
lots
of
funny
techniques
for
optimizing
their
performance.
So,
for
example,
browsers,
would
limit
the
number
of
TCP
connections
that
could
be
open
to
a
specific
server.
So
if
you
had
a
server
that
was
optimized
and
just
you
know
had
tons
of
network
connections
attached
to
it,
its
TCP
stack
was
tweaked
so
that
the
max
sockets
was
way
up
high.
A
What
would
what
servers
would
do?
What
web
authors
would
do?
Is
this
thing
called
domain
sharding,
which
is
a
way
to
have
several
different
dns
names
that
actually
point
to
the
same
server
so
that
when
you
write
your
web
page,
you
reference
your
inline
resources,
not
your
inline
resources,
your
dependent
resources
using
the
different
DNS
names,
so
the
browser
thinks
oh
well.
I
can
open
up
eight
sockets
to
this
guy
and
then
eight
sockets
to
that
guy
and
eight
targets
to
this
other
guy,
but
they're
all
the
same
server.
Really
that's
one
trick.
A
Another
trick
that
was
done
to
increase
performance
was
resource
inlining.
So
this
is
where
you
have
a
you
know:
a
base64
encoded
image,
the
the
bytes
of
which
are
actually
in
the
page
rather
than
having
the
browser
issue.
Nate
issue
a
separate
request,
and
this
was
done
because
it
would
allow
priority
treatment.
It
would
allow
faster
rendering
of
the
page,
for
example,
so
with
server
push,
we
don't
need
that,
because
you
know
what's
going
to
happen,
is
the
server
knows
what
the
browser
will
need
before
it
asks
for
it?
A
So
it
just
will
start
giving
the
browser
what
it
needs
before
the
browser
even
knows
it
needs
it,
there's
no
corresponding
JavaScript
API,
but
you
can
combine
this
thing
with
a
server
sent
events
sort
of
take
advantage
of
it
where
the
server
pushes
stuff
into
the
browser's
cache.
That
is
not
going
to
be
in
the
page.
When
the
browser
I'm
sorry,
then
the
server
uses
sse
to
tell
the
browser
to
go
and
fetch
it.
But
when
the
browser
goes
to
fetch
it,
it
will
already
be
in
the
cache,
because
we
already
pushed
it
there.
A
So
how
do
we
get
you
know
and
when
the
browser
is
making
connection
to
the
server?
How
does
it
determine
whether
it's
appropriate
to
use
HTTP?
Well?
The
first
case
is,
if
you're
using
HTTP,
you
don't
need
to
worry
about
it,
because
the
protocol
negotiation
happens
inside
of
the
TLS
negotiation.
So
when
opening
up
the
TCP
socket
and
establishing
the
SSL
connection,
there
is
a
application
layer,
protocol
negotiation
technique
that
will
specify
a
protocol-
header,
not
header,
but
a
sort
of
statement.
A
A
So
most
of
what's
great
about
h-e-b
2
comes
for
free
and
using
servlet
4.
So
all
of
this
binary
framing
stream,
multiplexing
header
compression-
that's
just
you
know
you
get
that
for
free,
it's
not
exposed
in
the
servlet
API
push,
on
the
other
hand,
is
exposed.
So
let's
take
a
look
at
you
know
them.
It's
specifics
of
push
in
the
normal
case.
The
browser
will
make
a
request
to
the
server
and
then
get
a
resource
back
and
then
we'll
part
the
page
and
determine
it
needs
to
get
these
follow-up
resources
with
serverpush.
A
We
have
a
bit
of
a
different
thing,
but
it
only
works
with
methods
that
are
cacheable
and
safe,
so
that
is
essentially
read-only
methods
that
don't
have
you
know
or
methods
that
don't
have
a
request
body,
so
that's
basically
get
and
head.
So
you
can't
do
push
with
post
options
or
trace.
You
can
do
it
with
getting
head
the
api,
the
greg
wilkins
suggested,
which
is
what
we
did
put
in
servlet
for
have.
A
Has
you
asking
the
server
request
for
a
push
builder
and
then
you
can
add
headers
and
methods
and
all
the
other
things,
the
the
string
that
you're
pushing
and
then
you
call
push
so
here's
what
a
flow
diagram
looks
like
with
that.
So
the
browser
calls
get
on
the
servlet
container,
which
invokes
the
servlet
service
method
and-
and
let's
say
the
servlet
service
method
discovers
that
the
browser
will
need
these
new
additional
resources
in
the
case
of
JSF.
A
A
So
this
is
the
stock
faces
servlet,
that's
in
JSF
2.3,
which
is
a
part
of
Jakarta
ee8
and
the
face
of
servlet
service
method,
which
I
just
showed
there.
It
determines
if
this
is
a
resource
request.
So
there's
two
different
kinds
of
requests
in
JSF
standard,
page
requests
and
resource
requests
and
the
resource
request
is
for
handling
script
and
images
and
stylesheets.
And
if
we
determine
that's
a
resource
request,
we
tell
the
resource
handler
to
go
ahead
and
handle
it.
Otherwise
we
do
the
jsf
request,
processing
life
cycle.
A
Now,
here's
what
the
encode
resource
URL
looks
like
it
was
referenced
in
that
handle
resource
request,
which
will
actually
ultimately
call
encode
resource
URL.
We,
this
is
actually
code
from
the
JSF
implementation.
We
obtain
the
reference
URL
to
the
resource
and
we
push
it
and
then
we
encode
the
response
URL
there.
So
this
enables
JSF
users
to
take
advantage
of
server
push
without
having
to
rewrite
any
of
their
code.
So
that's
kind
of
Handy,
something
else.
A
That's
new
in
the
h-e-b
2
specification
is
the
way
we
do
trailers
now
trailers
were
an
HTTP
one,
but
they
weren't
exposed
than
any
servlet
API
until
now.
So
the
point
of
trailer
is
when
the
sender
desires
to
send
metadata
at
the
end
of
the
message
after
the
response.
So
it's
basically
headers
that
come
after
the
body
you
might
ask.
Why
would
I
want
that?
All
that
would
be
useful
for
message
checksum,
for
example,
and
digital
signatures.
So
here's
what
a
trailer
looks
like
you
have
your
in
one
dot,
one
that
is
so.
A
This
is
a
200
response.
We're
saying
the
content
type
is
text
plain.
You
must
say
the
transfer
encoding
is
chunked
and
you
specify
a
header
whose
name
is
trailer
and
the
value
of
the
header
is
the
name
of
the
trailer.
So
this
way
the
client
knows
when
the
data
is
done.
The
request
is
done
that
it's
supposed
to
read
this
trailer
called
foo
and
H
should
be.
There
is,
as
I
said,
before
this
concept
of
pseudo
headers,
you
may
not.
A
You
must
not
put
su
headers
in
his
trailer
values,
so
that's
just
a
proviso
and
some
use
cases.
A
digital
signature
message,
integrity,
tech,
also,
G
RPC,
makes
use
of
trailers
when
it
runs
its
transport
over
HTTP
to
GRP.
C
requires
HTTP
to
so
that
was
another
reason
why
it
was
important
to
have
servlet
4
supports
a
HTTP
2,
so
we
had
enabled
G
RPC
based
applications
to
interact
with
servlet.
A
A
The
trailers
that
you
can
read
when
you're
sending
a
response
you
ask-
or
you
tell
the
response
here
here-
are
the
trailers,
you
pass
it
a
supplier
and
that
allows
the
implementation
to
call
and
get
them
when
they're
ready
and
if
you
need
to
interact
with
the
trailer.
So
you
can
deal
with
the
supplier
by
getting
the
trailer
fields
and
the
supplier
is
a
JDK
streams,
Java
SE,
8
interface.
That
was
added.
A
So
this
is
what
it
looks
like
in
a
flow
diagram
and
here's
an
example
of
a
test
servlet
that
interacts
with
the
trailer
feature.
So
we
are
doing
a
post.
So
in
the
do
post
we
are
adding
header
saying
this
is
transfer
encoding,
chunked
we're
adding
a
header
that
is
trailer
with
two
different
trailers
and
we're
saying:
okay,
set
trailer
fields
and
we're
passing
this
closure.
A
Another
new
feature
that
we
added
was
mapping
discovery.
This
has
nothing
to
do
with
HTTP
too,
but
it
does
allow
for
some
new
sort
of
made-up
programming.
That's
now
possible
with
servlet.
It
allows
for
the
servlet
to
discover
how
it
was
invoked.
Now
it
turns
out
that
all
of
the
servlet
locations
already
had
to
do
this.
A
So
there's
quite
a
few
different
ways
that
a
server
can
get
invoked.
It
turns
out
requestdispatcher
forward
request.
Dispatcher
include
async
context,
dispatch
get
name
dispatch.
These
are
all
the
different
ways
that
servlets
can
get
vocht
or
filters,
and
there's
also,
this
required
request
attribute.
That
is.
A
We
also
did
some
improvements
regarding
encoding.
The
request
encoding
was
to
be
specified
as
utf-8
now
I'm,
when
he
provided
XML
elements
for
specifying
the
request,
character,
encoding
and
response
character
coding.
These
were
basically
ambiguous
for,
sir.
What
for
and
now
we've
firmly
said,
okay,
it's
you
df8,
and
you
can
explicitly
specify
it
as
well.
A
We
added
some
java
SE
8
default
methods
for
implementing
things,
to
make
it
a
little
bit
easier
to
implement
servlets.
We
added
a
generic
filter
and
an
HTTP
filter
that
took
advantage
of
these
default
methods,
and
so
we'll
close
with
the
summary
now
h.
Servlet
4
brings
HTTP
2
to
the
java
ee
platform
and
has
significant
improvements,
incremental
improvements,
and
it
maintains
the
backwards
compatibility
problems
for
which
Java
EE
is
famous.
So
thank
you
very
much
and
I
hope
you
enjoy
the
rest
of
the
Jakarta
EE
livestream.