►
Description
In the span of several weeks, we took a legacy app that had been running in production for 12 years, moved it to git, mavenized it, upgraded from Java 6 to Java 8, and upgraded from Java EE 5 to Java EE 7. Oh, and did I mention that it uses SOAP, JSP, and JSF 1.2? We did all this with a relatively minor amount of code changes, thanks to the backward compatibility of Java 8 and Java EE. Come to this session to learn how we did it, what issues we ran into, which app server we were using, and why we didn't move to a newer JDK, Java EE 8, or Jakarta EE.
A
Hello,
everyone
and
welcome
to
another
jakarta
tech
talk.
My
name
is
serena
and
joining
us
today
is
keto
man
who
will
be
presenting
on
the
topic
of
upgrading
a
legacy
java
ee
app
with
style.
If
you
have
any
questions
for
keto
as
we
move
through,
today's
presentation
feel
free
to
ask
it
in
the
chat
or
use
the
ask
a
questions
tab
so
without
further
delay.
Keto
over
to
you.
B
All
right,
thank
you
very
much,
serena
hello,
hi.
My
name
is
keto.
Welcome
to
this
jakarta
ee
talk
this
session,
as
she
said,
is
about
upgrading
a
legacy
java,
ee
app
with
style.
So
basically,
I'm
going
to
be
walking
through
the
a
real
live
project,
not
not
in
a
lot
of
detail,
but
at
a
high
level
where
we
upgraded
in
a
legacy
job
yeah,
but
we'll
go
through
sort
of
the
challenges
we
ran
into
and
sort
of
how
we
went
about
that
whole
process.
B
B
We
do
consulting
training,
mentoring
on
front
end
development
and
back
in
java,
and
you
know
the
whole
gamut,
whether
it's
cloud,
whether
it's
mobile,
whether
it's
you
know,
legacy
applications
whatever.
But
basically
you
know
along
the
the
well
the
realm
world
of
enterprise
web
application
development.
B
I
participated
in
several
java
community
process
expert
groups
over
the
years
and
I'm
also
a
jakarta
ee
ambassador,
which
means
I'm
I'm
very
interested
in
sort
of
ensuring
that
jakarta
ee
lives
and
grows
as
a
technology
all
right.
So
that's
it.
That's
me
I'd
like
to
hear
a
little
bit
about
the
people
in
the
webinar.
B
A
B
Thank
you
thad
all
right.
Well,
I'm
sure,
I'm
sure
you
guys
have
lots
of
interesting
stories
to
say
one
day.
So
if
you
have
anything
to
say
along
the
way,
just
go
ahead
and
type
in
the
chat
and
I'll
try
to
address
it
as
possible
or
when
I
can
so
you
know
at
least
one
of
you
has
worked
with
tomcat
and
jakarta
e
or
java
e
before,
which
is
cool
all
right.
B
B
Although
it
is
possible
to
get
a
docker
image,
you
can
still
deploy
in
a
cluster
with
kubernetes
all
that
kind
of
fun
stuff,
but
they
were
using
an
old
version
websphere
and
like
most
larger
organizations,
they
like
to
have
support,
and
this
version
of
websphere
didn't
have
support
anymore.
So
they're
like
hey,
can
you
help
us
upgrade
this
old
application?
B
So
I
had
the
pleasure
of
working
on
this
project
with
walker
schultz,
who
is
well
known
in
sort
of
the
the
java
server
faces.
Job
e
communities
he's
a
lead
committer
for
omni
faces,
which
is
a
library
for
jsf
and
also
wrote
the
definitive
guide
to
jsf
a
much
newer
book
than
mine,
and
if
you
ever
have
any
question
about
java
server
faces
or
anything
like
that
on
stack
overflow
you'll
find
he
has
an
answer
there.
A
really
good
answer.
So
it's
great
to
have
him
on
the
project.
B
So
it
turns
out
what
we
needed
to
do
was
in
the
more
detail
was
move
this
application
to
a
supported
java
or
jakarta
e
application
server
integrate
with
a
new
cloud-based
version
of
the
app.
So
essentially,
this
application
has
been
around
for
a
long
time
and
what
they
had
done
was
they
built
the
entire
application
from
scratch
for
an
insurance
company
for
managing
insurance
claims,
and
things
like
that,
so
they
had
migrated
a
large
portion
of
their
application
and
lots
of
lines
of
business
to
a
new
sort
of
insurance
platform.
B
So
that
was
that
was
the
deal
now
once
we
got
into
it.
We
realized
there
was
one
other
thing
that
wasn't
initially
clear
to
us,
which
is
that
they
needed
to
replace
the
existing
security
with
octa
and,
if
you've
heard
of
octa,
if
you
haven't
heard
of
octa
octa,
is
a
identity
management
platform,
so
basically
handles
single
sign-on
for
multiple
applications
within
the
organization,
and
you
can
also
use
it
just
for
managing
logins.
B
You
know
for
all
of
your
users,
so
I've
seen
it
used
for
external
use
cases
and
also
internal,
and
this
client
was
using
it
for
both
using
it
for
all
of
their
users,
internally
single
sign-on
into
their
their
their
vpn
and
all
that
kind
of
stuff,
and
also
for
single
sign-on
for
all
of
the
external
users
using
their
applications.
So
so
we're
like
okay.
B
So
we
need
to
integrate
with
octa
and
I've
worked
with
doctor
before,
but
but
it
turns
out
that
the
security
that
they
were
using
for
all
of
their
users
was
actually
in
the
legacy
application.
So
we
needed
to
replace
that
with
octa
integration
that
ended
up
being
a
large
portion
of
the
project
as
well.
B
So
it
turns
out
this
application
was
first
released
over
12
years
ago
and
was
kind
of
cool
is
I
was
involved
in
the
initial
version
of
it.
I
helped
kick
start
the
project
12
years
ago
and
it
was
kind
of
neat
to
go
back
to
the
source
code
and
see
my
comments
in
there
and
things
like
that.
So
that
was
kind
of
cool.
B
It
was
over
550
000
lines
of
java
code
and
over
550
web
pages
and
includes,
and
only
about
half
or
less
were
in
use.
So,
like
a
lot
of
legacy
code
bases,
you
know
there's
a
lot
of
code
there,
but
not
all
of
it
is
in
use,
but
no
one's
gone
and
pruned
out
the
dead
code.
Really,
so
you
kind
of
have
to
deal
with
the
whole
thing.
B
So
how
many
people
remember
soap,
anybody
just
just
say
plus
one
if
you,
if
you
remember
soap
or
you've,
worked
with
it
up,
there's
a
plus,
okay,
anyone
else
all
right
couple
people,
so
most
people
think
of
web
services.
Now,
I
think
of
rest
rest
apis,
so
predated
it
and
it
was.
It
was
heavier
all
xml
based
and
because
it
was
sort
of
heavier
and
more
complicated.
I
think
it
kind
of
died
once
once
rest
took
off,
but
I've
still,
you
know
this
is
not
the
first
project.
B
I've
seen
recently
with
soap.
It's
still
around
and
you
know
it.
It
follows
the
sort
of
general
rule
of
software
development
right
in
most
businesses,
if
it,
if
it
isn't
broke
and
it's
running
in
production
chances,
are
it's
going
to
run
in
production
until
it
has
to
be
removed
or
changed
so
you'll
still
run
into
soap
apis.
If
you
work
in
large
organizations,
so
we
didn't
have
a
budget
to
rewrite
any
of
the
sub
web
services,
which
meant
it's
questionable,
whether
or
not
that
would
have
been
worth
the
effort.
B
So
so
those
were
sort
of
our
constraints,
that's
sort
of
the
story
and
of
course
we
had
to
look
at
the
java
e
app
server
right.
So
that
was
the
first
thing:
it's
like
okay!
Well,
they
want
to
upgrade
this
to
something
new
or
something
supported
at
least
what
would
that
be?
What
does
that
look
like
so
whoops
so
before
we
had
the
wipes
for
application
server,
7,
that's
what
everything
was
running
on
and
it
was
interesting
they're
actually
using
enterprise
application,
archives,
ears.
B
So
that's
what
we
have
before
and
what
we
ended
up
with
was
webs
for
application,
server,
nine
full
profile.
We
really
really
wanted
to
move
to
webster
liberty
and
take
advantage
of
all
the
all
the
goodness
in
the
renewable
versions
of
jakarta
ee
and,
if
you're
not
familiar
jakarta.
Ee
is
the
successor
to
java
ee.
That's
fully
open
source
and
managed
by
the
eclipse
foundation.
So
all
the
vendors
like
red
hat,
ibm,
oracle,
tommy,
tribe
and
some
others.
B
They
have
a
jakarta
ee
application
servers
and
those
are
currently
the
new
versions
and
lots
of
great
features.
They're
easy
to
deploy
in
the
cloud.
All
that
kind
of
stuff,
webs49
full
profile
is,
is
a
little
older.
It
supports
java
ee-8,
so
it
was
like
the
last
major
version
of
java
ee
before
it
turned
into
jakarta
ee
and
because
the
main
reason
that
we
couldn't
use
liberty
was
that
we
needed
jack's
rpc
support.
B
Jack's
rpc
is
what
was
underpinning
all
of
the
web
services
in
the
application,
and
the
web
service
stuff
was
fairly
complicated.
So
it
wasn't.
It
wasn't
really
something
that
we
felt
like.
We
could
replace
that
I
mentioned
earlier,
so
we
kind
of
needed
something
that
could
support
all
that
out
of
the
box
and
really
nothing
supported
jax
our
pc,
except
for
you,
know,
websphere
liberty,
full
profile.
B
We
could
have
looked
at
non-ibm
products,
but
considering
the
fact
that
the
client
was
already
had
a
relationship
with
ibm
for
support
and
everything
we
would
have
had
to
have
a
really
really
strong
use
case
for
switching.
So
in
the
end,
we
ended
up
with
webs
replication
server
server
full
profile.
The
other
main
reason
for
sticking
with
it
was
that
this
application
was
still
going
to
be
running
on
prem
and
and
it's
good
for
the
team,
the
infrastructure
team
to
know
how
to
manage
it.
B
B
All
right,
so
that's
the
story
with
the
app
server.
Let's
also
talk
a
little
bit
about
some
of
the
other
areas,
so
they
were
using
ibm,
jdk6,
websphere,
typically,
ships
with
the
ibm
jdk
and
generally
only
runs
on
the
ibm
jdk.
I
don't
think
you
can
very
easily
switch,
they
were
using
java
ee5
and
this
means
servlet
2.5
jsp
2.1.
B
So
that's
what
we're
stuck
with
something
a
pretty
old
application,
jdk
6
and
what
we're
beyond
19
just
came
out.
If
I
remember
correctly
so
a
pretty
old
tech
stack.
So
what
we
were
able
to
do.
I
should
actually
just
take
a
step
back.
So
one
of
the
things
we
were
very
concerned
about
was
the
front
end
code
right
and
that's
been
the
majority
of
what
the
application
was
anyways
other
than
the
web
services.
B
So
you
know
apache
my
faces
are
still
around.
We
could
still
use
that
we
thought
about
maybe
switching
to
a
non-jsf
framework
if
we
found
that
the
overhead
was
so
much
work
that
we
might
as
well
just
rewrite
the
front
end
that
wasn't
really
the
case,
and
since
this
application
was
only
going
to
be
around
for
a
couple
more
years,
you
know
there's
really
no
logical
reason
to
rewrite
the
front
end
if
we
didn't
have
to
so
from
a
jsf
front-end
perspective.
B
The
question
was
well
what
component
libraries
are
available?
Jsf
is
a
component-based
java
web
framework
and
it
has
different
component
libraries
and
the
one
that
we
used
back
then
in
several
years
ago,
over
12
years
ago,
was
infogestic's
net
advantage.
Infogistics
is
a
component,
a
ui
component
developer.
B
However,
they
had
they
discontinued
this
version
of
components
back
in
2009,
and
currently
they
have
several
other
component
libraries
but
they're,
not
really
other
than
android
they're,
not
really
in
the
java
space
anymore,
fun
fact.
I
actually
helped
them
kickstart
that
infrastructure
that
advantage
a
long
long
time
ago,
I
met
there
with
their
co
and
their
cto
and
everything
at
the
time.
B
B
So
this
was
a
library
that
used
to
ship
with
rational
application,
developer
and
ibm
web
ibm
websphere,
and
they
also
use
apache
my
faces
tomahawks.
This
was
another
component
library
which
used
to
be
around
it.
It's
not
really
active
anymore,
so
they
have
three
different
component
libraries
mixed
in
there,
so
this
was
really
where
we
were
concerned
about
because
we're
like
okay,
if
we
upgrade
this
to
a
newer
version
of
jsf,
which
we
kind
of
need
to
do
is,
are
all
the
components
going
to
break.
B
B
B
Actually,
I
think
at
the
time
17
was,
I
don't
think
it
even
come
out
yet
so
really
the
question
at
that
point
was
to
which
lts
version
and
we
wanted
to
do
11,
but
we
couldn't
so
jdk8
was
the
latest
version
supporters,
so
we
kind
of
had
to
use
that
and
it
turns
out
upgrading
the
java
side.
The
pure
java
side
was
really
not
a
big
deal
at
all.
B
In
terms
of
the
component
library,
we
were
able
to
basically
keep
all
of
the
components
that
we
needed.
We
didn't
have
to
basically
get
rid,
get
rid
of
anything.
We
did
it.
We
did
sort
of
remove
some
library
that
we
didn't
use
or
some
components
that
were
weren't
very
useful
anymore
or
that
there
was
an
obvious
equivalent
in
jsf
2.2
2.24,
but
we
didn't
have
to
remove.
Remove.
We
didn't
have
to
like
remove
an
entire
component
library,
which
was
pretty
cool.
B
So-
and
I
will
say
just
the
fact
that
we
were
able
to
do
this
without,
like
rewriting
lots
of
stuff,
really
does
emphasize
the
ability
for
java
to
evolve
over
time
and
to
be
upgraded
fairly
easily,
and
I
think
that's
one
of
the
the
biggest
benefits
you
know
we
talk
about.
We
complain
about
the
backwards
compatibility
problem
right
that
you
know,
java
doesn't
move
very
quickly
if
you
all
these
things
and
support
backwards
compatibility,
but
that
means
is
that
in
a
lot
of
cases,
upgrading
is,
is
not
that
difficult.
B
So
so
we're
very
pleased
to
see
that
that's
true
also
for
jakarta
and
java
ee.
So
the
fact
that
we
were
able
to
upgrade
to
you
know
a
newer
version
of
jsf,
a
newer
version
of
jdk
and
everything
and
still
use
ancient
components
that
were
that
were
discontinued
in
2009
is
very,
very
cool.
So
we're
very
pleased
to
see
that
that
being
said,
everything
wasn't
perfect
right.
B
So,
on
the
jsf
side,
the
infogestus
component,
which
we
were
surprised
to
see,
worked
with
minimal
changes
with
jsf2
and
everything
the
ibm
java
web
components.
Most
of
them
were
removed
because
there
were,
there
were
better
alternatives
that
were
just
simple
and
didn't
affect
the
functionality,
so
that
was
really
the
deal.
It
was
really
just
going
through
all
the
pages
making
sure
that
all
the
components
worked
and
everything
so
so
that
worked
out
very
well.
B
The
web
services
side
was
more
of
a
pain,
actually
turns
out.
So
so
a
lot
of
the
problems
we
had
were
a
lot
of
obfuscated
errors.
Where,
like
we
get
some,
you
know
generic
soap
error,
but
there
was
really
bug
inside
of
all
the
ibm
code
before
it
got
to
the
error
message,
so
the
initial
exception
was
completely
obfuscated,
so
that
was
very
difficult
and
also
on
top
of
that,
their
handling
inside
the
application
was
very
poor.
So
we
had
a
lot
of
trouble
tracking
down
errors.
B
B
But
then
there
was
a
lot
of
generated
code
which
wasn't
checked
in
and
we
had
to
like
track
down
where
it
was
generated,
how
it
was
built
and
it
turned
out.
The
story
was
that
the
developers
themselves
were
using
rational
application
developer
and
it
would
generate
always
code
for
them,
and
then
they
had
some
build
scripts
that
were
generating
all
that
same
code
and
deploying
it,
but
to
people
who
are
just
given
all
the
code
to
look
at.
B
We
need
to
sort
of
figure
all
that
out,
you're,
just
like
okay,
where
the
first
generation
code
coming
from.
How
did
the
developers
even
work
with
this?
To
begin
with,
so
we
we
sort
of
made
it
fairly
straightforward
for
new
developers
to
work
with
all
the
code
generation
is
handled
in
the
build
now,
and
we
actually
standardized
on
using
eclipse
for
this
project.
B
Also,
we
thought
at
the
time
the
developers
are
more
familiar
with
the
clips,
although
we
learned
that's
not
really
the
case,
but
we
basically
just
set
everything
up.
So
it's
easy
to
use
in
eclipse.
So
and
that's
a
big
deal
for
me
because
I
haven't
really
used
eclipse
for
years,
so
I
had
to
kind
of
like
remember
how
it
worked,
I'm
more
of
an
intellij
guy,
but
but
bokeh
is
an
eclipse
guy,
so
that
worked
out
well
for
him.
B
So
that's
that's
sort
of
the
story
with
just
the
code
itself,
but
like
any
project,
there's
more
to
it
than
just
code
right.
So,
in
addition
to
the
code,
there's
also
the
security
aspect
right.
So
I
said
initially
that
you
know
we
thought
we
were
just
migrating
this
list.
One
app
turned
out
to
be
four
apps
also
turned
out
to
have
security
component,
which
we
didn't
really
initially
factor
in.
B
B
There
was
no
security,
which
was
fine
right,
because
in
that
scenario
everything
was
running
on-prem
right.
The
apps
that
you
needed
to
call
the
web
services
were
just
on
the
same
network
and
any
other
security
for
external
parties
entering
in
was
handled
externally
before
it
even
got
to
the
web
services.
So
the
web
services
themselves
had
no
security,
so
what
we
had
to
do
was
was
basically
ensure
that
the
web
services
could
be
accessed
by
new
applications.
B
So
one
of
the
things
I
haven't
really
mentioned
is
that
it
turns
out
once
we
started
this
project.
We
realized
that
it
was
really
part
of
a
much
larger
project
which
was
to
migrate
the
newer
application,
which
was
on
this,
this
insurance
framework
to
the
cloud.
So
that
was
all
on
prem,
but
we
were
moving
that
whole
application
to
the
cloud.
B
So
that
was
the
story
so
because
of
that,
we
had
to
have
a
machine
machine
to
machine
oauth
and
we
use
ought
to
client
credentials
grant
type
in
order
to
do
that,
we
had
to
run
a
servlet
filter
and
we
we
decided
not
to
use
any
of
the
fancy
subsecurity
stuff.
We
just
said:
okay,
we'll
just
use
normal
oauth
2
and
we'll
write
a
survey
filter
and
we'll
just
return
a
server,
a
soap
response
if
there
are
any
errors.
B
B
So
for
the
public
jsf
apps,
it
was
a
little
more
complicated
right
because
now
we're
in
a
situation
where
initially
well.
Let
me
take
a
step
back
so
before
security
was
managed
via
the
ibm,
webseal
and
ibm
security
access
manager.
So
that's
basically
how
all
of
these
sort
of
internal
users
were
being
managed,
and
then,
on
top
of
that
you
know
normal
users
from
the
public
users.
They
were
accessing
basically
using
custom
database.
Optimization
using
jdbc
and
db2
db2
is
an
older,
ibm
database
and
it
turns
out
this.
B
The
strategy
was
being
used
for
the
new
application
as
well
before
it
moved
to
the
cloud.
So,
basically,
whenever
you
go
into
the
application,
you
would
log
in
through
the
old
java
ee
app,
it
would
do
the
optimization
and
then
it
would
redirect
you
to
this
new
front
end
in
this
new
application.
So
so,
basically
we
had
to
replace
the
entire
authentication
mechanism
for
the
old
application
with
octa
and
then
ensure
that
we
could
integrate
with
the
new
application.
B
And
yes
that
was
the
story.
So
it
took
a
little
bit
of
work,
but
we
were
able
to
get
it
done,
I'm
using
normal
servlet
filters
and
everything,
and
that
was
the
story
there
turns
out
with
the
internal
jsf
app.
We
didn't
have
to
do
anything
because
it's
all
internal-
and
you
know
if
you're
in
if
you're
in
the
vpn
they
didn't
really
care.
As
long
as
you
could
access
it
so
very
good.
So
that
was
the
story
there.
B
B
So
a
few
pain
points.
The
octadocks
are
not
so
hot,
so
they
look
like
they're
great,
they
seem
great,
but
then
you
realize
they're
missing
details
that
are
important.
So
there
are
a
lot
of
questions.
You
have
it's
kind
of
a
pain.
The
primary
examples
for
java
are
in
spring
boot,
which
is
great
if
you're
using
spring
boot,
but
not
if
you're,
not
so
so
it
it
takes
a
little
bit
more
work.
B
B
He
wrote
some
of
the
spring
boot
stuff
articles
and
everything
and
he's
like
you
know
the
docs
aren't
that
great.
But
that's
why
we
write
lots
of
blog
posts,
so
he's
he's
an
evangelist
there
or
a
developer
advocate.
I
should
say
so
so
if
you
do
end
up
working
with
octa
just
you
know,
fyi
keep
this
in
mind
and
then
read
the
blog
post
from
the
developer
advocates.
So
it's
a
story
there.
A
B
All
right,
okay,
so
so
we
talked
about
the
code.
We
talked
about
the
java
e
app
server
but
of
course,
and
security
right,
but
then,
of
course,
there's
testing
right.
So
testing
is
a
very
key
part,
I'm
very
into
unit
testing
and
integration
tests
automated
tests
in
general,
I'm
not
really
a
tdd
person.
I
wish
I
was
I've
tried
it
before,
but
but
at
the
very
least
I
like
to
write
tests
and
make
sure
that
there
are
automated
tests
running
on
my
projects.
B
So
when
you're
working
with
legacy
code
base,
you
don't
always
have
that
luxury
though
so
so
what
we
were
able
to
do,
though,
is
ensure
that
all
the
existing
unit
tests
work.
So
that
would
give
us
some
coverage.
They
weren't
really
the
best
tests,
though,
and
they
also
relied
on
an
existing
database,
which
makes
them
sort
of
flaky,
but
we
did
actually
just
try
and
make
sure
everything
we
had
there
worked.
B
Their
test
coverage
was
not
very
good.
So
so,
instead
of
you
know
going
back-
and
you
know
writing
test
cases
for
all
of
their
code,
knowing
that
the
application
is
only
going
to
be
around
for
two
or
three
years,
we
said
well,
let's
just
make
sure
that
for
all
of
our
new
code
or
any
code
that
we
touch
or
refactor,
let's
try
to
write
test
for
that.
B
We,
we
didn't
use
anything
fancy
like
our
killian,
which
is
great
for
testing
java
ee
apps,
mainly
because
it
would
have
been
very
time
consuming
and
difficult
to
set
up
for
this
particular
environment,
and
we
didn't
use
any
sort
of
front-end
testing
tools
because
they
didn't
have
those
in
place
and
there's,
of
course,
no
budget
for
that,
because
the
integrating
ui
in
in
writing
ui
integration
tests,
which
I've
done
a
lot
of,
is
a
pretty
time
consuming
test.
So
we
really
would
have
had
to
have
a
separate
budget
for
that.
B
So
initially,
there's
scattered
outdated
documentation,
some
in
sharepoint,
they
don't
didn't,
have
a
wiki
themselves
and
a
lot
of
times.
You'd
ask
a
question
and
then
someone
would
send
you
a
document
and
even
though
we
had
access
to
their
sharepoint,
I
don't
remember
seeing
much
on
there.
That
was
terribly
helpful.
B
So
so
that's
the
way
it
was
initially
so
we
said
we
said
sort
of
from
day
one.
What
we
want
to
do
is
actually
you
know,
maintain
a
wiki
and
also
ensure
that
all
the
documentation
for
the
project
was
written.
You
know
in
the
project
itself,
so
you
know
this
is
one
of
the
issues
that,
or
things
to
think
about
in
general,
is
that
documentation
for
code
should
be
closest
to
code
that
you
can
make
it.
B
So,
although
maybe
some
architecture,
documents
and
a
lot
of
things
like
you
know,
different
host
names
and
environments
and
stuff,
all
that
was
on
the
wiki
on
maybe
how
to
do
something
with
octa.
That
was
on
the
wiki.
But
when
it
came
down
to
you
know
the
structure
of
the
project,
how
to
do
a
build?
How
to
do
all
that
kind
of
stuff.
B
B
Okay,
sorry
about
that
eric.
Why
don't
we
once
we
get
towards
the
end?
If
you
have
any
questions,
I
can
maybe
fill
it
in.
That
might
be
helpful.
So
sorry,
you
had
trouble
getting
into
the
session
there,
so
we
made
sure
we
had
a
lot
of
documentation
along
the
way-
and
I
think
this
has
been
very
handy
and
hopefully,
when
we
leave
anyone
has
to
come
back
to
work
on
this
project.
They
will.
They
will
have
some
idea
what's
going
on.
B
Okay,
so
let
me
see
make
sure
I
didn't
miss
anything
here.
Okay,
all
right,
so
another
key
thing
is
version
control.
So
you
know
in
a
perfect
world
everybody
uses
git,
hopefully-
and
in
your
you
know,
you're
good
to
go.
You
have
they
give
you
access
to
your
get
rid
to
the
git
repo.
You
create
a
branch
or
you
have
to
fork
it
or
whatever,
but
you're
good
to
go.
However,
that
wasn't
really
the
case
for
us.
B
B
So
the
problem,
though
you
know,
is
that
we
we
did
a
clean
break.
We
lost
all
the
history.
Unfortunately,
they
didn't
really
care,
so
that
was
good.
Had
they
really
wanted
the
history
that
would
have
been
certainly
an
issue
we
would
have
had
to
figure
out
how
to
migrate
that
from
from
mks.
So
so
we
basically
just
took
the
code
and
put
all
of
it
in
git
and
just
started
from
there.
B
Now,
of
course,
we
ran
into
a
couple
issues
right.
One
is
that
the
code
we
received
wasn't
the
latest,
and
we
didn't
realize
this
to
later
on
in
the
project
when,
like
you
know,
there
was
some
feature
they
thought
which
should
be
there
and
it
wasn't
there
and
we're
like.
Why
isn't
this
feature
there?
We
didn't
do
anything
to
that
part
of
the
code,
and
then
we
found
out.
You
know
that
there's
some
other
class
that
have
been
changed
since
the
version
we
got
which
so
that
caused
some
issues
down
the
road.
B
So
something
to
keep
in
mind
if
this
ever
happens,
that
you
need
to
need
to
somehow
ask
them
to
double
check
a
few
times
to
make
sure
I
showed
the
latest
code
and
we
also
ran
into
an
issue
where
some
team
members
were
not
familiar
with
git,
which
that's
always
a
scenario.
If
you
work,
if
you're
working
with
a
team,
that's
more
fully
you're
more
familiar
with
subversion
or
another
version
control
system
get.
B
B
B
B
B
B
A
few
different
things
here,
let
me
okay,
so
we
we
basically
ended
up,
doing,
builds
and
deployments
using
jenkins,
and
I
like
jenkins
a
lot.
I
know
some
know
jenkins
has
some
haters,
but
I
like
it
a
lot
and
I
was
very
happy
to
use
the
jenkins
pipelines.
Pipelines
has
been
in
jenkins
for
a
while
and
it's
a
really
great
feature
for
automating
the
build
and
and
also
deployment
via
code.
B
B
There
is
a
multi-pipeline
bitbucket
plugin
that
we
use
because
we're
using
bitbucket,
so
that
allowed
us
to
automatically
handle
building,
pull
requests
and
different
branches,
and
things
like
that
and
we
had
a
lot
of
issues
getting
the
build
to
run.
So
we
we'll
talk
about
this
in
a
second,
but
we
ended
up
with
a
maven
project
right
and
for
whatever
reason,
we
have
trouble
getting
any
bills
to
run
on
their
current
maven
on
their
current
jenkins
agents.
B
So
we
basically
created
a
new
one
using
docker
and
running
red
hat
enterprise
linux.
So
that
was
nice
because
it
allowed
us
to
have
a
dedicated
build
container
for
our
builds.
So
that
worked
out
well,
I
ended
up
with
a
multi-module
maven
project
and
four
wires,
and
we
said
we
took
out
all
the
ear
stuff
just
made
four
water
files
and
it
turned
out.
B
We
couldn't
get
rid
of
all
the
ant
stuff
because
some
of
the
deployment
stuff
that
was
specific
to
a
websphere
uses
ant
tests
and
there's
no
maven
equivalent.
Unfortunately,
maven
makes
it
really
easy
to
delegate
to
ant
so
so
we
still
had
maven
for
using
the
build,
and
then
we
delegated
some
ant
tasks
when
necessary
and
those
ant
tasks
were
primarily
for
the
jax
rpc
code
generation
and
remember.
Jax
rpc's
is
is
for
soap
and
it's
deprecated.
B
So
that's
why
the
ant
tasks
haven't
been
upgraded
because
it's
not
a
whole
lot
of
demand
for
newer
versions
of
this
code.
But
this
is
another
thing.
That's
great
about
the
job
ecosystem
is
that
you
know
these
are
ancient
ant
tasks
for
some
deprecated
technology.
We're
able
to
just
use
it
inside
of
a
new,
entirely
new,
build
and
for
say
whatever
you
will
about
maven,
but
it
works
great
and
it's
extremely
flexible
and
powerful.
B
So
we're
able
to
do
that.
We
also
found
a
webster
plug-in
for
maven
that
allowed
us
to
do
deployment
from
the
maven
build,
so
so
that
was
kind
of
cool,
so
we
were
able
to
handle
deployment
to
websphere
using
that
and
what's
interesting
about
websphere
and
I'll.
Take
it
I'll
take
a
step
back
here.
So
you
know
we're
all
in
this
whole
container
world
right
where
we've
got
docker
containers
and
you
know
running
on
kubernetes
or
some
variation
thereof
right
and
what's
interesting.
B
If
you
go
back
and
look
at
something
like
websphere
and
it's
console,
it
has
all
these
abilities
to
start
and
stop
to
manage
clusters
start
and
stop
clusters.
You
know
add
servers
to
clusters
all
that
kind
of
stuff,
and
it's
sort
of
reminds
me:
it's
basically
like
all
of
the
network,
orchestration
that
you
have
with
something
like
kubernetes,
but
it's
all
at
the
websphere
level,
and
everything
is
a
websphere
instance.
B
So
so,
basically,
what
our
plugin
did
was
deploy
our
application
to
different
environments
which
are
running
on
different
different
app
servers
in
different
clusters.
So
it
was
kind
of
an
interesting
way
to
look
at
things
and
kind
of
kind
of
remind
you
that
every
time
we
move
forward
as
an
industry
we're
basically
just
taking
parts
of
things
we've
already
done
before
and
providing
a
new
take
on
it.
B
So
anyways,
that's
my
soapbox,
but
I
will
say
we
got
all
it
working
pretty!
Well,
it's
very
smooth.
Now
we
can
deploy
to
any
environment
all
through
jenkins
and
you
know,
run
the
pipeline
deploy
via
maven,
and
you
know
maybe
even
connects
to
the
external
servers
from
the
docker
container
and
there's
all
this
fun
stuff.
So
it
works
out
really
well.
What
we
found,
though,
is
that
this
is
kind
of
a
funny
funny
quirk.
So
back
in
the
day.
B
Websphere,
an
eclipse
well
back
in
the
day
for
java
ee
development
ears
were
really
the
thing
the
way
to
go,
so
it
turns
out
that
the
eclipse,
websphere
tooling,
doesn't
really
even
recognize
war
file.
So
we
had
to
do
this
weird
hack,
to
get
it
to
recognize
war
files,
so
just
a
funny
funny
little
side
effect
of
everything.
So,
but
eventually
we
got
everything
working
and-
and
now
it's
really
nice
we
can
just
deploy
any
of
the
four
web
apps
to
any
environment.
We
want
via
jenkins.
B
There
we
go
so
so
this
was
one
of
the
one
of
the
very
interesting
pain
points,
so
they
didn't
have
their
internal
artifact
repository.
So
there's
no
internal
maven
repository
right.
So
we
realized
that
several
of
the
jars
they
were
using
weren't
in
maven,
central
and
essentially
they're.
All
all
the
jars
were
copied
into
source
control.
I'm
I'm
sure
many
of
you
remember
those
days
and
and
also
they
were
they
were
physically
on
the
websphere
deployment
servers.
So
basically
we
had.
We
had
to
essentially
figure
out
how
to
handle
this.
B
There
was
not
an
appetite
for
installing
a
a
artifact
repository.
We
did
discuss
it,
but
there
was
no
no,
no
uptake
in
that.
So
we
ended
up
finding
all
the
jars
that
we
needed,
which
took
a
little
bit
of
work
and
because,
in
some
cases
we
had
to
upgrade
so
it
wasn't
like
we
could
just
always
copy
the
version
that
they
had
and
we
ended
up
creating
a
local
repo
stored
in
get,
and
essentially
it's
it's
a
local
maven
repo.
B
B
B
We
of
course
also
ran
into
character,
encoding
issues
and
source
code,
because
because
windows
and
and
also
we
learned
pretty
quickly,
that
some
of
these
libraries
require
the
ibm
jdk.
So
so
any
attempts
that
we
made
to
get
things
working
with
with
a
non-ibm
jdk
did
not
work
and
again
that's
specific
to
that's,
specifically
a
websphere
issue,
not
really
something
to
run
into
with
a
non-web
sphere.
Server.
B
B
B
And
that
was
the
build
okay,
so
I
think
before
we
go
to
the
takeaways,
does
anyone
have
any
questions
or
any
about
what
I've
covered
so
far,
any
questions
or
things
that
I've
missed
or
that
you
missed?
I
should
say
that
you
want
me
to
mention
real
briefly
and
then
I'll
just
go
over
sort
of
the
key
takeaways.
B
B
And
I
I
think
that's
really
the
number
one
thing
I
mean:
we've
got
all
this
stuff
working,
it's
working
quite
well
and
I
think
it'll
serve
them
well
until
they
have
migrated
their
lines
of
business
to
the
newer
platform,
which
is
also
java
and
jvm-based,
but
it's
different
jvm
language
and
everything
so,
but
I
think
this
has
been
kind
of
a
nice
process
to
kind
of
go
through
and
also
is
interesting,
just
to
see
how
we
were
able
to
take
it.
And
just
you
know,
we
modernized
the
parts
we
could
right.
B
The
build
is
modern.
You
know
it's
got.
It's
got
unit
test
on
your
code.
It
integrates
with
octa
all
that
kind
of
stuff,
but
you
know
it's
still
using
a
lot
of
really
old
code
in
there
right
all
the
business
logic
is
old.
We
do
not
change
business
logic,
all
of
those
ancient
jsf
components,
even
though
it's
a
much
more
much
newer
version
of
jsf,
but
it
all
works
quite
well.
So
I
think
that's
one
of
the
key
things
to
point
out
here.
B
Another
thing
is
that,
when
you're
upgrading
legacy
project,
the
code
itself
may
not
be
the
most
complex
or
time-consuming
task,
and
it
wasn't
for
us,
I
mean
just
the
java
code.
Wasn't
a
big
deal.
The
jsf
migration
was,
you
know,
took
a
little
bit
of
work.
You
know
a
few
weeks,
but
not
that
big
of
a
deal,
but
what
took
the
most
time
honestly
was
the
builds,
the
ci
cd
and
the
octa
integration.
B
Those
were
the
things
that
took
most
of
the
time
because
not
for
the
build
we
had
to
basically
redo
the
build,
because
sticking
with
the
old
ant
structure
just
was
not
a
good
idea,
especially
since
we
had
already
mavenized
the
entire
project.
We
would
have
had
to
change
the
build
anyways,
so
that
was
a
big
part
of
it
and,
of
course,
integration
was
the
major
piece
of
work.
So
just
just
keep
in
mind
that
the
what
seems
like
it's
the
easiest
may
not
be
the
well.
B
B
Another
key
thing
is
that
you
want
to
change
as
little
as
possible.
You
know
going
into
a
code
base,
that's
over
12
years
old,
you
kind
of
want
to
rewrite
things.
You
you
look
at
it
and
think,
okay.
Why
did
they
do
it?
That
way,
you
know
any
any
code
base
that
old
is
gonna
have
a
lot
of
craft
because
different
people
have
worked
on
it
over
the
years,
but
you
know
unless
your
job
is
to
rewrite
it
and
refactor
the
code.
B
B
Another
thing
is
that
having
the
qa
resources
is,
of
course,
very,
very
important,
and
you
kind
of
are
going
to
have
to
have
that
if
you
want
to
succeed,
unless
you
have
qa
capacity
yourself,
another
thing
that
we
try
to
do
is
make
sure
that
things
are
easier
for
those
who
come
after
us,
because
you
kind
of
look
at
it
and
think.
Okay,
this
is
an
ancient
project.
There's
no
documentation,
everything's
all
scattered.
No
one
really
knows
all
the
answers.
B
So
since
it's
your
job
to
gather
all
the
answers
you
might
as
well
just
write
them
down,
even
if
it's
not
perfect
at
least
someone
who
comes
along
after
you
has
some
idea,
you
know
sort
of
where
to
go,
so
we
try
to
provide
instructions
for
people
like
you
know,
if
you're
setting
up
a
new
project,
this
is
how
you
do
it.
This
is
how
the
build
works.
B
A
A
No,
I
think
we
are
good.
So
I
wanted
to
thank
you
for
have
the
excellent
presentation
today.
Keto
and
just
a
reminder
again,
if
you
guys
have
any
questions,
while
I'm
wrapping
things
up
here,
feel
free
to
go
ahead
and
put
them
in
the
ask
a
questions,
tab
or
directly
in
the
chat.
Whatever
is
most
convenient
for
you,
so
the
new
and
then
the
next
jakarta
tech
talk
happens
on
may
17th.
A
It's
jakarta
meal,
2.1
angus
mail
1.0.
So
you
can
register
for
that
session.
Using
the
link,
I
will
be
posting
in
the
chat
and
also,
if
you
have
any
feedback
on
the
tech
talk
programs,
we
would
love
to
hear
from
you.
So
just
click
on
the
green
button
that
will
pop
up
once
we
end
this
webinar
and
let
us
know
if
you've
enjoyed
the
talk,
so
I'm
just
going
to
go
quickly
again.
Make
sure
that
there's
nothing
in
the
ask
of
questions.