►
From YouTube: Jakarta Tech Talk-Jakarta EE & MicroProfile - Piranha Cloud - A new EE / MP runtime in progress
Description
This session will take a look at a new runtime that is aiming to become Jakarta EE and MicroProfile certified in the future. Piranha Cloud USP is supporting those platforms without being a traditional application server.
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
A
If
you
have
any
questions
for
arjun
as
we
move
forward
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.
I'll
also
include
the
link
in
the
chat
without
further
delay.
Arjun
over
to
you.
B
Oh
I'll
put
it
back
to
this
all
right.
There
we
go
so
it's
controls
here
are
a
bit
difficult
compared
to
some
other,
but
it's
okay,
all
right!
So
if
you
see
the
full
screen
now,
we
can
start
so.
Welcome
to
this
jakarta
tech
talk
it's
about
piranha
cloud!
It's
a
new,
jakarta
ee,
microprofile
runtime!
It's
in
progress!
B
Okay!
So
a
little
bit
about
myself,
I'm
a
40
years,
dutch
developer
from
the
amsterdam
region
in
the
netherlands-
and
I
got
my
master's
science
degree
in
computer
science
from
the
university
of
leiden,
the
netherlands.
So
you
see
me
there
on
the
picture
near
my
old
omnifaces
office.
So
these
are
the
projects
I'm
involved
with
only
faces
piranha
cloud
and
glassware.
So
we'll
talk
about
the
relationship
between
those
three
a
little
bit
later
on.
B
So
I
was
previously
a
jsf
insecurity,
expert
group
member:
I'm
a
project
lead
of
several
projects,
jakarta
phases,
chicago
security,
authentication
authorization
and
some
others,
and
I'm
maintaining
and
releasing
glassfish
in
addition
to
piranha
clouds,
I'm
also
the
co-author
of
three
books,
the
definite
guide
to
jakarta
phases
in
jakarta
ee10,
which
has
just
been
released
in
a
second
edition
pro
cdi
in
java
eea
needs
an
update
soon
and
the
definite
guide
to
jakarta
security.
That's
coming
quite
soon,.
B
B
It
typically
contains
an
http
server,
sometimes
other
servers.
So
this
essentially
means
it
listens
to
network
ports
for
incoming
connections
and
sends
responses
to
those.
Then
an
application
server
is
a
deployment
target.
So
that's
connected
to
the
fact
that
it's
separately
installed
means
you
send
applications
to
them,
typically
archives
via
archives
and
the
most
frequently
used.
But
there
are
some
others
like
egbr
guys,
not
that
much
used
anymore
and
air
archives.
B
Some
security
features
like
an
ldap
resource
stuff
like
that,
and-
and
that's
quite
important
for
this
target-
contains
full
stack
api
for
consumption
by
application
design.
In
case
of
jakarta,
surface
application
servers,
that's
the
jakarta,
ee
api,
of
course,
but
in
other
servers
or
older
ones,
that
could
be
other
ones.
So
the
really
old
things
like
netdynamics.
B
But
in
this
case
it's
the
jakarta
ee
api.
Okay,
then
we
have
some
optional
things,
but
they're
quite
typical
for
an
application
server
to
have
some
kind
of
guri
or
cli
to
administer
the
server.
So
you
typically
log
in
to
an
administer
panel,
and
this
allows
you
to
do
those
things
you
mentioned
before
so
set
the
resources
monitor
resource
usage
as
well.
B
B
All
right
so,
as
I
think
many
people
know,
there's
been
a
pushback
against
the
application
server
concept,
so
one
of
the
things
that's
most
visible
there
that
you
quite
often
see
is
that
an
application
server
partially
by
the
steam
effect
of
it
being
called
a
server,
is
maintained
by
ops
at
many
organizations
that
use
this
or
still
do
so.
The
ops
team
is
typically
in
charge
of
everything
having
to
do
with
server
organizations.
They
typically
install
the
network.
They
set
up
the
firewalls.
B
They
install
a
linux
system,
for
instance,
they
take
care
of
server
management,
maybe
includes
more
memory,
but
have
few
other
kinds
of
things,
and
the
application
server
is
typically
included
in
that,
and
this
means
that
the
developers
are
not
quite
allowed
to
access
it,
so
they
just
provide
a
var.
I
will
take
a
quick
look
at
that,
but
that
exactly
is
in
this
context,
but
they
they
don't
touch
they're
not
allowed
to
touch
the
application
server.
B
So,
just
as
they're
not
allowed
to
touch
the
network
settings
they're
not
allowed
to
touch
the
firewall
they're,
not
typically
allowed
to
touch
or
interact
directly
with
the
application
server,
and
this
is
problematic
for
various
reasons.
So,
there's
typically
a
tension
between
option
dev
here,
because
big
parts
of
the
application
server
are
actually
a
death
concern.
So
things
like
the
application,
server
libraries,
the
implementations
of
the
api
that
were
just
mentioned,
but
various
settings
as
well
security
configuration
it.
It
typically
very
much
hooks
into
the
application.
B
It's
not
that
much
of
a
separate
concern,
so
this
is
always
a
great
source
of
attention
between
those
two
groups.
So,
even
if
you
have
a
devops
organization
it's
better
than
but
that
is
still
problematic
to
some
degree,
because
it's
simply
not
the
thing-
that's
either
ops
or
death.
It's
always
a
bit
between
the
two.
B
So
another
point
regarding
the
application
server
is
that
some
of
the
features
it
offers
are
not
always
applicable
anymore.
So,
in
a
way,
the
application
server
was
ahead
of
its
time,
since
a
lot
of
the
features
is
offered
are
now
very
much
offered
by
other
things
and
quite
popular
at
that,
but
they
kind
of
originated
within
the
application.
Server
concept.
B
And
at
the
same
time,
maybe
partially
because
of
being
ahead
of
the
curve
there,
maybe
because
it
wasn't
always
that
suitable
in
a
technical
sense,
the
the
shared
hosting
or
the
multi-tenancy
capability,
so
the
fact
that
multiple
users
run
their
apps
on
the
same
application
server
that
has
always
been
a
bit
limited,
so
applications
were
shielded
against
each
other.
They
were
isolated,
but
not
that
well,
they
were
executed
within
a
single
process.
B
Isolation,
capabilities
of
a
single
process
were
managed
by
the
vm,
not
that
well
so
the
over
time.
The
demand
for
that
became
more
limited
and
at
the
same
time
you
see
those
other
things
coming
up.
Like
virtual
servers,
they
provide
a
very
strong
isolation
on
a
single
physical
server,
so
you
could
just
deploy
a
single
application
to
a
single
application,
server
on
a
single
virtual
server
and
have
extremely
strong
isolation
between
those
two.
B
So
then,
there's
this
other
development
containers,
mostly
in
the
form
of
daca.
They
provide
the
isolation
as
well,
not
as
strong
as
the
feature
server,
but
they
do
provide
it
based
on
processes
and
their
own
file
system
and
resources.
So
this
is
still
very
stronger
than
an
application
server
could
provide,
and
on
top
of
that,
docker
has
a
deployment
model.
So
you
could
deploy
your
image.
B
You
could
reference
a
central
repository
so
get
up
sorry,
the
docker
half
in
this
situation,
so
this
replaced
a
big
thing
of
the
application
server
and
then,
at
the
same
time
there
was
a
kubernetes
coming
up
and
that
replaced
a
lot
of
the
the
clustering
features
of
an
application
server.
So
taking
all
those
things
into
account,
application
servers
still
have
value,
but
their
value
can
be
diminished
because
of
all
those
things
mentioned
here.
B
So
the
last
thing,
the
application
server
contained
that
we
just
mentioned
are
the
apis.
So
in
this
case
the
jakarta
apis
and
they
have
been
it
seems
quite
valuable.
So
there's
a
lot
of
things
going
on
there.
There's
a
lot
of
development
in
the
jakarta
apis
they've
been
going
for
a
long
time.
They're
very
well
thought
out
that
also
they
also
have
a
natural
split
between
the
api
and
the
implementation,
meaning
that
the
surface
that
you
program
against
is
quite
small.
B
It's
quite
confined
and
clear,
as
opposed
to
other
products,
products
that
have
a
a
not
that
much
separated
api
and
implementation.
So
you
more
it's
easier
to
accidentally
use
a
implementation,
specific
thing
there
and
with
jakarta
ee,
this
is
far
less
the
case.
It
can
still
be
done,
but
it's
it's
not
that
that
often
that
this
happens.
B
Anything
is
that
jakarta.
Ee
does
not
imply
an
application
server,
so
a
lot
of
thought
is
perhaps
around
the
fact
that
they
naturally
have
to
be
an
application
server,
but
it
doesn't
quite
have
to
be
like
if
you
look
at
all
the
specifications,
all
the
documents
it,
it
doesn't
quite
say
that
jakarta
e
has
to
be
an
application
server.
B
Okay.
So,
let's
take
a
look
at
some
other
concepts
here
which
are
jars
so
what's
to
say
about
jars,
so
there's
very
variants
of
them,
especially
when
looking
at
the
ones
where
you
run
an
application
with
so
james
wagner
in
a
diesel
article
quite
expertly,
classify
these
so
there's
skinny
jars,
they're
stained,
there's
hollow
and
there's
fat
or
uber
jars
and
they
get
increasingly
more
complex.
So
a
skinny
jar
is
essentially,
it
contains
only
the
coats
that
your
application
consists
of
and
basically
no
nothing
else.
B
B
The
thin
jar
would
include
some
of
your
app
dependencies
like
gwath
or
something
or
patsy
commons,
then
there's
the
concept
of
the
hollow
jar.
So
that's
essentially
the
inverse
of
a
thin
jar.
It
contains
kind,
a
pre-packaged,
app
server,
so
this
can
like
be
very
literally
an
entire
application,
server,
just
packaged
as
a
single
jar
and
then
there's
finally,
the
fat
or
the
uber
jar,
where
you
have
essentially
a
single
jar
containing
everything.
So
you
just
run
the
jar
and
your
application
server
your
http
server
dependencies.
B
B
It
only
provides
your
application
codes
and
it
uses
only
provided
apis,
so
this,
for
example,
these
card
apis
here,
the
tin,
that's
mostly
a
var
file
as
well,
but
it
contains
some
non-provided
apis,
and
this
means
that
the
libraries
that
contain
this
code
are
included
in
the
lib
folder
of
the
bar
file.
In
this
case
and
a
var.
A
B
Essentially,
just
a
jar
file
as
well.
It's
just
a
another
extension,
but
it's
technically
a
jar
file,
okay,
a
hollow
example,
so
that's,
for
instance,
pr
micro.
So
that's
the
full
or
almost
full
pr
server.
That's
repackaged
as
a
jar
file
missing
some
features
that
are
explicitly
left
out,
but
it's
mostly
the
full
server
and
you
use
it
to
run
a
single
var
file
on
the
command
pane
and
then
the
spring
booth
is
perhaps
the
most
well
known
example
of
the
fed
uber
concept.
So
you
compile
your
application.
It
results
in
a
single
jar.
B
A
B
Held
on
a
results
results
in
a
jar
file,
but
the
haladon
jars
are
not
packaged
within
the
jar.
They
are
directly
referenced
on
the
file
system,
so
you
still
have
the
concept
of
a
ubijar,
so
you
just
say
java
minus
jar
and
then
the
name
of
the
application,
but
the
jar
files
are
not
technically
in
the
haladon
jar.
B
B
So
that's
where
the
bulk
of
the
development
started
and
one
of
the
things
we
we
focused
on
is
that
we
wanted
to
build
it
up
from
the
ground
to
support
jakarta
ee,
but
without
being
the
application
server.
So
essentially
the
most
minimal
support
and
still
run
jakarta.
Ee
applications
have
a
very
low
amount
of
glue
code,
a
very
low
amount
of
surface
and
management
code.
And
what
have
you
so
just
as
much
as
possible?
B
So
I
put
on
a
nano
here.
It
runs
on
a
flat
class
path,
so
you
just
include
it
in
your
main
application
and
it
presents
you
with
a
subset
of
the
servlet
api,
say
a
program,
pragmatic
data,
we'll
take
a
look
at
an
example.
There
then
embedded
builds
on
nano.
It
adds
a
little
bit
more
things
to
be
able
to
offer
a
full
server
api.
So
it
has
things
like
listeners,
a
http
session
which
are
not
present
in
nano,
but
it's
still
a
programmatic
setup.
So
you
add
it
to
your
main
application.
B
You
call
it
from
a
main
method,
for
example,
and
then
you
programmatically
set
up
the
thing
and
a
lot
of
stuff
with
it.
We
had
a
micro
m,
so
that's
a
minimal
version
of
micro.
That's
essentially
it's
just
a
bit
like
the
hollow
jar
product.
It's
the
single
jar.
It
runs
so
far
from
the
command
line
and
it
includes
the
http
server.
So
it's
functionally
quite
similar
to
something
like
piara
micro,
then
there's
one
version
on
top
of
that,
it's
micro,
a
it,
includes
all.
B
That's
where
the
a
comes
from,
and
this
one
is
an
isolating
class
loader
and
the
so-called
math
and
dynamic
component
loader.
So
this
sounds
fancy,
but
it
means
that
it
doesn't
include
all
the
libraries
that
make
up
under
microsoft,
things
like
sateria
or
but
it
just
loads.
The
string,
those
things
dynamically
via
maven
and
haven
can
have
them
installed
on
the
local
m2.
So
then,
this
is
just
loaded
locally
or
it
can
come
from
the
network
or
a
private
repo.
Or
what
have
you
so?
B
This
makes
it
quite
dynamic
and
we
were
using
haven
for
this,
because
people
have
now
that
library
is
typically
available
in
their
mail
when
they're
known
with
maven,
they
use
an
access
to
manage
their
dependencies.
So
this
was
quite
a
convenient,
almost
practical
file
system
thing
to
reuse,
so
we
did
that
and
then
finally,
we
have
put
on
the
server.
So
that's
the
thing
that's
most
most
similar
to
a
typical
application
server.
So
it's
an
install
thing.
B
You
can
deploy
and
undeploy
things
to
it.
You
can
start
to
stop
it.
You
can
have
multiple
apps
to
it
and
optionally.
You
can
have
some
stronger
isolation
between
the
apps,
although
this
does
come
at
the
cost
of
more
memory.
So
isolation
here
means
that
every
application
running
on
it
has
its
own
copy
of
the
server
libraries.
So
that's
obviously
takes
a
little
bit
of
memory.
B
B
So
we
only
show
micro
a
here
and
at
the
end,
but
it's
the
diagram
is
mostly
the
same
without
it,
and
then
we
see
that
they
all
build
on
top
of
each
other
and
then
eventually
that
the
archive
loader
from
icrow
uses
a
maven
string,
wrap
to
load
a
specific
set
of
jakarta
libraries
and
that
those
are
the
ones
in
orange
there
and
the
isolating
class
loader
means
that
everything
runs
within
its
own
class
loaders.
If
you
use
it
for
embedding
it
typically
or
almost
doesn't
touch
the
environment.
B
There's
a
few
exceptions
there,
but
it
typically
runs
fully
isolated
and
compared
to
other
embedded
solutions
like
glasses,
embedded,
it's
not
influenced
by
things
already
on
the
class
path,
so
it
won't
allow
initializers
or
that
doesn't
pick
up
beans.
It
doesn't
scan
other
things
on
the
class
path.
It's
it's
almost
like
its
own
mini
vm,
so
to
speak.
B
Fireman
so
right,
word
is
a
function,
type
of
thing
where
you
substantially
get
called
by
your
cloud
provider
server.
You
don't
deal
with
http
stacks
within
this
code.
You
just
get
a
request
in
and
piranha
doesn't
deal
with
this
either.
So
it's
just
a
a
small
facade,
so
to
speak,
to
give
you
a
familiar
server
environment,
but
still
within
the
confines
of
a
cloud
provider.
So
you
would
you
could
use
this
in
your
main
application
as
well,
a
local
command
line
application,
but
this
is
typically
used
for
functions
in
cloud
providers.
B
So
you
see
it
here,
building
up
a
request
to
a
server
that
you
have
and
then
executing
it.
Okay.
So
we
move
on
to
embedded
so
embedded
deals
more
with
libraries
they're
still
on
your
class
path.
It
gives
you
more
complete
servlet
environment,
but
it's
not
isolated.
So,
like
you
see
here,
we
initialize
it
via
a
initializer
class.
This
comes
from
the
class
part,
it's
just
a
thing.
It
comes
from
mahara.
Of
course
you
have
to
know
that
this
stitches,
but
it
doesn't
do
any
scanning.
It
doesn't
do
any
standalone
running.
B
B
Okay,
then
take
a
look
at
piano,
micro,
appearance,
icro,
sorry,
and
here
it's
used
as
the
embedded
in
the
embedded
version.
So
we
have
an
isolated
glass
loader
environment
here,
so
it
doesn't
pick
up
things
from
the
class
path,
so
we
give
it
a
thing
it
needs
via
mafen
coordinates,
so
it
needs
two
things
here
jakarta
faces,
which
is
the
hard
implementation
and
the
jakarta
website
api.
B
B
B
So
if
you
look
at
things
like
a
classface,
it
has
its
own
authentication
code
and
then
you
got
authentication
is
layered
on
top
of
that
on
the
surface,
even
beyond
that
they
have
an
authorization
system
themselves
and
everything
is
layered.
On
top
of
that
and
the
jakarta
apis
are
mostly
just
a
apis.
B
B
Okay,
so
one
of
the
things
is
obviously,
since
I'm
also
involved
with
the
glasses.
How
do
those
two
projects
relate
to
each
shutter,
so
piranha
cloud,
even
though
it
technically
doesn't
have
to
it,
can
run
with
whatever
components
you
give
it
in
practice,
all
the
default
distributions
that
we
have?
They
use
the
classvis
components.
So
this
is
done
on
purpose
so
that
the
two
projects
remain
quite
aligned
with
each
other.
B
B
So
one
of
the
things
we've
been
working
on
is
to
extract
these
components
from
classvis,
so
exercise
for
the
authorization
has
been
done
before
and
that's
now
used
by
both
glassfish
and
piranha,
but
to
other
projects.
Ilias
is
coming
up,
so
we
have
extracted
that
it's
not
yet
submitted
to
the
clip
just
a
project,
but
it's
already
used
by
piranha
and
glassfish
uses
the
original
code
still.
But
the
idea
is
for
classes
to
use
that
one
too
so
they're
actually
shared
and
the
transaction
manager
is
planned
for
the
same
thing.
B
So
one
specific
thing-
and
this
is
mostly
for
compatibility
with
glassfish-
is
the
concept
of
enterprise
beans,
so
enterprise
beans
have
a
kind
of
a
difficult
history.
So
the
original
version
was
not
that
good.
So
people
started
to
hate
it,
and
there
was
a
newer
version
coming
it's
already
a
long
time
ago
in
2005
enterprise
beans
in
jakarta,
especially
in
three
at
the
time
called
egb,
which
was
way
better.
B
But
it's
still
even
today.
It's
still
a
different
component
model
than
cdi.
So
there's
two
of
them,
which
makes
it
kind
of
difficult
enterprise
beans,
doesn't
have
that
much
the
fat
development
anymore.
So
there's
not
many
enhancements
going
in
there
or
actually
not
at
all,
there's
not
a
a
really
active
team
around
it,
but
still
a
lot
of
existing
code
makes
use
of
it
and
you
need
it
for
certification,
specifically
for
the
web
profile,
which
we
aim
to
certify
for
so
what
we
have
done.
We
started
a
new
jakarta
enterprise
beans.
B
B
B
B
A
B
B
A
B
Yeah,
so
I
briefly
touched
upon
that
in
the
last
slides.
So
specifically,
the
egb
compatibility
thing
was
related
to
that,
so
yeah
we
plan
to
be
profile
compatible.
This
would
be
the
first
thing
and
be
compatible
with
in
my
micro
profile
as
well,
and
probably
the
core
profile
too.
So
currently,
one
of
the
things
we're
working
on
is
the
servlet
compatibility.
That
would
be
the
first
step
for
us
to
tank
and
we're
quite
far
with
that.
B
So
that's
at
98
something
percent,
but
there's
a
few
small
issues
that
are
quite
difficult
to
to
do:
they're
quite
consuming.
So
once
we
have
surfled
compatibility,
we
could
quite
easily
go
beyond
that.
So
things
like
jax,
rs,
jakarta
rest,
you
got
the
faces.
They
run
on
that
we
use
the
existing
components
for
that.
So
then
compatibility
for
that
is
quite
easy
to
achieve,
but
enterprise
beans
is
difficult
for
the.
A
Perfect
and
then
there's
just
for
the
clarification
from
carlos,
so
he
says
what
I
mean
with
the
first
question
is:
if
a
developer
is
just
coming
to
jakarta,
ee
world
should
one
forget
about
traditional
application.
Servers
like
gf,
pariah
or
wildfly,
and
just
turn
to
things
like
piranha,
hildon
or
quercus,
because
of
doctor
plus
k8s
have
replaced
their
deployment
models.
B
B
If
you
come
new
to
the
jakarta
ee
world,
you
you
could
still
start
with
it.
It
doesn't
matter
that
much
so
the
the
most
important
thing
for
you
would
be
to
learn
the
apis
and
the
fact
that
you
have
several
deployment
options.
So
you
could
indeed
you
could
use
it
via
a
hollow
jar,
type
approach,
ebgr
type
approach
or
you
could
deploy
it
as
a
slim
jar,
but
you
would
just
have
to
know
that
you
have
these
options.
If
you're
just
new
and
want
to
learn
the
apis,
then
it's
mostly
about
the
apis.
A
Perfect,
so
I
think
that
that
is
it
for
questions
in
the
ask
a
question,
so
I
just
wanted
to
thank
you
for
the
excellent
presentation
today
and
just
a
reminder.
If
anyone
in
the
audience
has
any
final
questions,
please
feel
free
to
ask
them
in
the
chat
or
ask
a
questions.
Tab
I'll,
give
you
a
few
moments
to
do
that,
while
I
wrap
up
so
the
next
jakarta
talk
happens
on
april
12th,
implementing
servlet,
6.0
and
jetty,
so
you
can
register
for
that
session.
A
Using
the
link,
I
will
be
posting
in
the
chat
shortly.
We're
also
looking
to
book
more
jakarta
tech
talks
throughout
2022,
so
if
you're
interested
in
presenting
feel
free
to
fill
out
the
form
that
I'll
also
be
including
in
in
the
the
chat
as
well.
And
finally,
if
you
have
any
feedback
on
the
tech
talk
program,
we
would
love
to
hear
from
you
just
click
the
green
button
that
popped
up
and
let
us
know
how
you
enjoyed
the
talk.
So
thank
you
again,
ariana.
It
doesn't
look
like
there's
any
other.