Post on 27-May-2015
description
Bert ErtmanFellow at Luminis in the NetherlandsJUG Leader for NLJUG and a Java Champion
Paul BakkerSenior developer at Luminis Technologies
@bertertman
@pbakker
Who is this talk for?
You are using old school Spring and wonder how to move forwardJava EE seems to be hot again, should you jump on this train?You love the J2EE Design and Development book; but is it still actual?
Why listen to us?
..not employed by an application server vendor
..and we’re no Rod Johnson
groupies either
..worked extensively with
J2EE, Spring and modern Java EE
We’ve had endless
Java EE vs.
Spring
discussions...
some disclaimers:
Not looking for another holy warNo shootoutNo silver bullets
Why migrate?
Upgrading from old school Spring requires a lot of work anyway Why not take it to
the standard?
Spring is proprietary technology
This might have been competitive in the past...
But now we want THIS!
Let’s get
a couple of misunderstandings
out of the way
first...
Isn’t Java EE too fat?
Startup times with application deployedJBoss AS 7 ~2 secondsGlassfish V3 ~4 secondsTomcat 6 + Spring ~4 seconds
Java EE 6 WAR file < 100kb
Isn’t Java EE too fat?
Startup times with application deployedJBoss AS 7 ~2 secondsGlassfish V3 ~4 secondsTomcat 6 + Spring ~4 seconds
Java EE 6 WAR file < 100kb
Our favorite quote:
“Nowhere in the Java EE spec does it say that Java EE servers should be heavy
weight and slow...”
Isn’t Java EE supposed to be evil?
Based on 2004 rhetorics
Ever heard of the fable of the tortoise and
the hare?
But I need dependency injection?
Java EE 6 introduced CDI More powerful,
contextual DI modelMakes the platform
extensible in a standard way
But I must have AOP!
Really?
You love getting your code all
asymmetric and unreadable?
Or are you just using AOP light
a.k.a. Spring AOP a.k.a. (Java EE)
Interceptors?
Can I still do unit testing?
It took a while to get
there, but yes Java EE
supports testing as well
do I need heavy tooling?
do I need heavy tooling?
NO!
Capabilities comparison
Capability Spring JavaEE
Dependency
InjectionSpring Container CDI
Transactions AOP / annotations EJB
Web framework Spring Web MVC JSF
AOP AspectJ (limited to Spring beans) Interceptors
Messaging JMS JMS / CDI
Data Access JDBC templates / other ORM / JPA JPA
RESTful Web
ServicesSpring Web MVC (3.0) JAX-RS
Integration testing Spring Test framework Arquillian *
* Not part of the Java EE specification
Apparently,
it can all be done using
plain vanilla light weight
Java EE
rm -Rf spring*
Sure it would be fun, but not very
realistic
We need a recipe that moves us forward
step by step
Old school Spring app
lots of complex XML, no annotations
old / outdated ORM solution
JDBC Templates, Kodo, Toplink, etc.
deprecated extension based Web MVC
(SimpleFormController, etc.)
Migration path
1.Upgrade Spring version
2.Replace old frameworks
(ORM, web framework)
within Spring 3.Run Spring and Java EE
container side by side
4.Replace Spring entirely
5.Remove Spring container
Migration path
1.Upgrade Spring version
2.Replace old frameworks
(ORM, web framework)
within Spring 3.Run Spring and Java EE
container side by side
4.Replace Spring entirely
5.Remove Spring container
Upgrade Spring version
Upgrade Spring runtime (replace JAR files)
No code / configuration changes
Migration path
1.Upgrade Spring version
2.Replace old frameworks
(ORM, web framework)
within Spring 3.Run Spring and Java EE
container side by side
4.Replace Spring entirely
5.Remove Spring container
pres
enta
ton
lay
erD
ata
/ In
teg
rati
onla
yer
Web MVC
Tasks
Spring JDBC TemplatesKodo
@AutoWired
busi
nes
sla
yer
JMS beans
@AutoWired
@AutoWired
Spring beans
replace old frameworkswithin Spring
pres
enta
ton
lay
erD
ata
/ In
teg
rati
onla
yer
Web MVC
Tasks
Spring JDBC Templates
@AutoWired
busi
nes
sla
yer
JMS beans
@AutoWired
@AutoWired
JPA
Spring beans
replace old frameworkswithin Spring
pres
enta
ton
lay
erD
ata
/ In
teg
rati
onla
yer
Tasks
Spring JDBC Templates
@AutoWired
busi
nes
sla
yer
JMS beans
@AutoWired
@AutoWired
JPA
JSF
Spring beans
replace old frameworkswithin Spring
pres
enta
ton
lay
erD
ata
/ In
teg
rati
onla
yer
Tasks
Spring JDBC Templates
@AutoWired
busi
nes
sla
yer
JMS beans
@AutoWired
@AutoWired
JPA
JSFDon’t touch Spring
specific APIs yet
Spring beans
replace old frameworkswithin Spring
What about Spring APIs we
don’t want to change yet?
Jdbc TemplatesREST TemplatesTask Schedulingetc.
Migration path
1.Upgrade Spring version
2.Replace old frameworks
(ORM, web framework)
within Spring 3.Run Spring and Java EE
container side by side
4.Replace Spring entirely
5.Remove Spring container
Using Spring and Java EE
side-by-side
Disclaimer 1: this is just to give an idea, this is not a production ready framework!
Disclaimer 2: this is a migration path. Not
the way you should build your next application...
Spring application
myapp.warSpring container
Servlet Container
Spring beans
Spring beansT
X m
anag
er
AO
P
OR
M
Java EE applicationJava EE 6 application server
CDI / EJB container
myapp.war
CDI beans
Session beansTX
man
ager
Secu
rity
Inte
rcep
tors
JPA
MixedJava EE 6 application server
CDI / EJB container
myapp.warCDI beansSession beans
TX
man
ager
Secu
rity
Inte
rcep
tors
JPA Spring
Spring beans
Spring beansT
X m
anag
er
AO
P
OR
M
pres
enta
ton
lay
erD
ata
/ In
teg
rati
onla
yer
busi
nes
sla
yer
run Spring withinJava EE container
Spring beans Tasks
Spring JDBC Templates JMS beans
@AutoWired
@AutoWired
JPA
JSF
Add stuff
here...
pres
enta
ton
lay
erD
ata
/ In
teg
rati
onla
yer
busi
nes
sla
yer
add Java EE codekeep old Spring code
Spring beans Tasks
Spring JDBC Templates JMS beans
@AutoWired
@AutoWired
JPA
JSF
EJB CDI
@Inject
@Inject
Dependency Injection
Spring already supports
JSR-330 Use @Inject anywhere you use
@AutoWiredCDI could be almost a drop-in
replacement for Spring DI
but opens up much more
powerful options
Encapsulate Spring with CDI
Write a CDI extension that
bootstraps the Spring
containerlooks up Spring Beans in the
Spring container and
publish in CDI context
The Spring DAO
JSF / CDI bean
Here we don’t
want to know
about Spring
CDI extension example
https://github.com/paulbakker/migrating-spring-to-javaee
Migration path
1.Upgrade Spring version
2.Replace old frameworks
(ORM, web framework)
within Spring 3.Run Spring and Java EE
container side by side
4.Replace Spring entirely
5.Remove Spring container
pres
enta
ton
lay
erD
ata
/ In
teg
rati
onla
yer
busi
nes
sla
yer
entirely replace Spring
Spring beans Tasks
Spring JDBC Templates JMS beans
@AutoWired
@AutoWired
JPA
JSF
EJB CDI
@Inject
@Inject
pres
enta
ton
lay
erD
ata
/ In
teg
rati
onla
yer
busi
nes
sla
yer
entirely replace Spring
EJB Timers
MDB
@Inject
@Inject
JPA
JSF
EJB CDI
@Inject
@Inject
Spring JDBC Templates
The TX layer
Migrate Spring TX and DAOs to EJB
The TX manager is in the app server
An EJB is transactional by default
EJB has JPA integration
You bet!
EJBs are just container managed
POJOs
Come on, are you telling me EJBs are cool now?
Just like Spring beans,
but without the container
configuration
The Spring DAO
The Java EE alternative
btw - this is an
EJB! :)
Dealing with lazy loading
Many Spring apps use the Open-
EntityManager-In-View pattern
EJB has the Extended Persistence
Context
LazyInitializationException
Fixing lazy loading
Detached entities
Spring DAOs are stateless (all singletons)
Load > edit > save needs a merge
With an Extended PU we don’t
Migration path
Hooked to JDBC Templates!?
Phase 1: denial
Phase 2: migrate ;-)
Template addict?
Hmm, let’s start
the old discussion
whether or not to
use ORM...
Using JDBC Templates
1.Can be injected with simple
Producer method
2.It is not relying on Spring
container
3.some extra dependencies though
Template producer example
Migration path
1.Upgrade Spring version
2.Replace old frameworks
(ORM, web framework)
within Spring 3.Run Spring and Java EE
container side by side
4.Replace Spring entirely
5.Remove Spring container
Removing Dependencies
Our classpath just has to
contain APIs, no framework
classesFrom ~40 dependencies to just:
What about testing?
Spring is pretty good at this
Java EE was not
How to test this?
CDI alternatives
What about JPA code?
Arquillian
Create micro deployments using an API
Run tests in real containers
Arquillian example
Wrap up
Is it all worth it?
blissful ignorance or painful reality ?!
Is there life after Spring?
We believe that there is always
room for innovationIdeally through Open Source
When it flies, bring it back to
the spec!
Other sessions of interestArquillian: The Extendable Enterprise Test
Platform (24121)
Beginning Java EE 6
(23421)
CDI Today and Tomorrow
(19941)
Enterprise JavaBeans
Technology 3.2 (23180)
Hacking Java EE: CDI
Extension Writing n00b to
l33t (23805)
Introducing Contexts and
Dependency Injection 1.1
(22480)
Java EE 6: The Cool Parts
(21641)
Java EE and Spring/MVC
Shoot-out (24161)
Rethinking Best Practices
with Java EE 6 (21622)
contact us:
Bert Ertmanbert.ertman@luminis.eu
Paul Bakkerpaul.bakker@luminis.eu