The Spring Framework has no-doubt played a major role in evolving the way we write enterprise applications on the Java platform today. However, it is still a proprietary framework owned by a single company. The age of having to rely on such proprietary frameworks in order to develop decent enterprise applications is now over and Java EE 6 has become an even easier way to develop enterprise applications based on standards which makes it the best choice for any enterprise application. In this session you will experience how to migrate a typical full stack Spring application to a standards based, completely portable, Java EE 6 application including integration tests.

2. Bert Ertman
Fellow at Luminis in the Netherla
nds
JUG Leader for NLJUG and a Java
Champion
@bertertman
Paul Bakker
Senior developer at Luminis Tech
nologies
@pbakker

3. Who is this talk
for?
You are using old school
Spring and wonder how to
move forward
Java 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?

4. Why listen to us?
d endless ..worked
We’ve ha
extensively with
Ja va EE vs.
J2EE, Spring and
Spring
modern Java EE
dis cussions...
..not employed by ..and we’re no
an application Rod Johnson
server vendor groupies either

5. some disclaimers:
Not looking for another holy war
No shootout
No silver bullets

6. Why migrate?
Spring is
proprietary
technology
Upgrading from
old school Spring
requires a lot of
work anyway
Why not take it to
the standard?

7. This m ight have been competitive in the past...

8. But now we want THIS!

9. Let’s get
a couple of misunderstandings
out of the way
first...

10. Isn’t Java EE too fat?
Startup times with application deployed
JBoss AS 7 ~2 seconds
Glassfish V3 ~4 seconds
Tomcat 6 + Spring ~4 seconds
Java EE 6 WAR file < 100kb

11. Isn’t Java EE too fat?
Startup times with application deployed
JBoss AS 7 ~2 seconds
Glassfish V3 ~4 seconds
Our favorite quote:
Tomcat 6 + Spring ~4 seconds
Java EE 6 WAR file < 100kb in the Java EE spec
“Nowhere
does it say that Java EE
servers should be heavy
weight and slow...”

12. Isn’t Java EE
supposed to be evil?
Based on 2004 rhetorics
Ever heard of the fable of the tortoise and
the hare?

13. But I need dependency
injection?
Java EE 6 introduced CDI
More powerful,
contextual DI model
Makes the platform
extensible in a
standard way

14. But I must have AOP!
Really?
You love getting
your code all
Or are you just
asymmetric and
using AOP light
unreadable?
a.k.a. Spring AOP
a.k.a. (Java EE)
Interceptors?

15. Can I still do unit
testing?
It took a while to get
there, but yes Java EE
supports testing as well

16. do I need heavy tooling?

17. NO!
do I need heavy tooling?

18. Ca pabilities comparison
Spring JavaEE
Capability
Dependency CDI
Spring Container
Injection
EJB
Transactions AOP / annotations
JSF
Web framework Spring Web MVC
Interceptors
AOP AspectJ (limited to Spring beans)
JMS JMS / CDI
Messaging
JPA
Data Access JDBC templates / other ORM / JPA
RESTful Web JAX-RS
Spring Web MVC (3.0)
Services
Arquillian *
Integration testing Spring Test framework
tion
* Not part of the Java EE specifica

19. Apparently,
it can all be done using
plain vanilla light weight
Java EE

20. rm -Rf spring*

21. Sure it would be
fun, but not very
realistic

22. We need a recipe that
moves us forward
step by step

23. 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.)

24. 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

25. 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

26. Upgrade Spring version
Upgrade Spring runtime (replace JAR files)
No code / configuration changes

27. 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

28. replace old frameworks
within Spring
presentaton
layer
Web MVC
@AutoWired
business
Spring beans
layer
Tasks
@AutoWired @AutoWired
Data / Integration
Spring JDBC
layer
Kodo JMS beans
Templates

29. replace old frameworks
within Spring
presentaton
layer
Web MVC
@AutoWired
business
Spring beans
layer
Tasks
@AutoWired @AutoWired
Data / Integration
Spring JDBC
layer
JPA JMS beans
Templates

30. replace old frameworks
within Spring
presentaton
layer
JSF
@AutoWired
business
Spring beans
layer
Tasks
@AutoWired @AutoWired
Data / Integration
Spring JDBC
layer
JPA JMS beans
Templates

31. replace old frameworks
within Spring
presentaton
layer
JSF
Don’t touch Spring
@AutoWired specific APIs yet
business
Spring beans
layer
Tasks
@AutoWired @AutoWired
Data / Integration
Spring JDBC
layer
JPA JMS beans
Templates

32. W hat about Spring APIs we
don’t want to change yet?
Jdbc Templates
REST Templates
Task Scheduling
etc.

33. 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

34. 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...

35. Spring application
Servlet Container
myapp.war
Spring container
TX manager
ORM Spring
beans
AOP
Spring
beans

36. Java EE application
Java EE 6 application server
CDI / EJB container
myapp.war
TX manager
Interceptors
Security
JPA
CDI
beans
Session
beans

37. Mixed
Java EE 6 application server
CDI / EJB container
myapp.war
CDI
beans
Session
beans
TX manager
Interceptors
Security
JPA Spring
TX manager
Spring
ORM
AOP
beans
Spring
beans

38. run Spring within
Java EE container
presentaton
layer
JSF
@AutoWired
business
f
Spring beans d stuf
layer
Ad
here...
Tasks
@AutoWired
Data / Integration
Spring JDBC
layer
JPA JMS beans
Templates

39. add Java EE code
keep old Spring code
presentaton
layer
JSF
@AutoWired
@Inject
business
layer
Spring beans EJB CDI Tasks
@AutoWired @Inject
Data / Integration
Spring JDBC
layer
JPA JMS beans
Templates

40. Dependency Injection
Spring already supports
JSR-330
Use @Inject anywhere you use
@AutoWired
CDI could be almost a drop-in
replacement for Spring DI
but opens up much more
powerful options

41. Encapsulate Spring with
CDI
Write a CDI extension that
bootstraps the Spring
container
looks up Spring Beans in the
Spring container and
publish in CDI context

42. The Spring DAO

43. JSF / CDI bean
Here we don’t
want to know
about Spring

44. CDI extension example
https://github.com/paulbakker/migrating-spring-to-javaee

45. 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

46. presentaton
layer
entirely replace Spring
JSF
@AutoWired
@Inject
business
Spring beans EJB CDI
layer
Tasks
@AutoWired @Inject
Data / Integration
Spring JDBC
layer
JPA JMS beans
Templates

47. presentaton
layer
entirely replace Spring
JSF
@Inject
@Inject
business
EJB CDI EJB Timers
layer
@Inject @Inject
Data / Integration
Spring JDBC
layer
JPA MDB
Templates

48. 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

49. Come on, are you telling me EJBs are cool now?
You bet!
Just like
EJBs are just Spring beans,
container but without
managed the container
POJOs configuration

50. The Spring DAO

51. The Java EE alternative
btw -
this is an
EJB! :)

52. Dealing with lazy loading
Many Spring apps use the Open-
EntityManager-In-View pattern
EJB has the Extended Persistence
Context

53. LazyInitializationException

54. Fixing lazy loading

55. Detached entities
Spring DAOs are stateless (all singletons)
Load > edit > save needs a merge
With an Extended PU we don’t

56. Migration path

57. Template addict?
Hooked to JDBC Templates!?
Hmm, let’s start
the old discussion
whether or not to
use ORM...
Phase 1: denial
Phase 2: migrate ;-)

58. Using JD BC Templates
1. Can b e injected with simple
Producer method
2.It is n ot relying on Spring
container
3.some extra dependencies though

59. Template producer example

60. 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

61. Removing Dependencies
Our classpath just has to
contain APIs, no framework
classes
From ~40 dependencies to just:

62. What about testing?
Spring is pretty good at this
Java EE was not

63. How to test this?

64. CDI alternatives

65. What about
JPA code?

66. Ar quillian
Create micro deployments
using an API
Run tests in real containers

67. Arquillian example

68. Wrap up

69. Is it all worth it?
blissful ignorance or painful reality ?!

70. Is there life after Spring?
We believe that there is always
room for innovation
Ideally through Open Source
When it flies, bring it back to
the spec!

71. Other sessions of interest
Arquillian: The
Extendable Enterprise Test
Introducing Contexts and
Platform (24121)
Dependency Injection 1.1
Beginning Java EE 6 (22480)
(23421)
Java EE 6: The Cool Parts
CDI Today and Tomorrow (21641)
(19941)
Java EE and Spring/MVC
Enterprise JavaBeans Shoot-out (24161)
Technology 3.2 (23180)
Rethinking Best Practices
Hacking Java EE: CDI with Java EE 6 (21622)
Extension Writing n00b to
l33t (23805)

72. contact us:
Bert Ertman
bert.ertman@lum
inis.eu
Paul Bakker
paul.bakker@lum
inis.eu