1

All rights reserved. 2013 ZeroTurnaround O

MS LEARNING & CONSULTING
CASE STUDY
2
All rights reserved. 2013 ZeroTurnaround O
COMPANY
SCORE CARD
.
Technologies in use: Tomcat 7.x, Ant, Liferay, JSPs, WebServices
.
Types of apps being built: Portal application for a production website
.
Build time before JRebel: 20 seconds
.
App redeploy time before JRebel: 2 minutes
.
Amount of turnaround time spent per hour, per developer: 30-35 minutes
Size of development team: 1
3
All rights reserved. 2013 ZeroTurnaround O
MS Learning & Consulting is a 17 year old company which focuses on consulting and training. Around 8-10 days of the
month is typically training which includes areas such as Java Concurrency, Java Performance, and Liferay.
The consulting work is based around development and architecture best practices including areas like code reviews
& architecture POCs
Company Profle
Muhammed Shakir is the CEO/Founder of MS Learning & Consulting
and with over 17 years in the industry is very experienced in the feld.
Muhammed is also an application developer and has designed and
developed the portal which the www.mslearningandconsulting.com site
uses today. The site provides loads of course content and learning materials
which can be read online, which is used by Muhammed and his clients. The
education platform uses Liferay which Muhammed has been using for many
years, which gives him the upper hand in the Liferay customisation and
confg changes required to tune the platform.

Muhammed hosts the education portal on Tomcat 7.x, a lightweight server,
but still has to endure redeploys and the delay is typically down to the
application as well as the platform. Muhammed says:
"Redeployment is a big problem for my
application, it's painful even on Tomcat.
Changes to JSPs are no bother, but Java
Classes are a pain."
4
All rights reserved. 2013 ZeroTurnaround O
The application has two layers; a presentation layer and a web service layer. The presentation layer is JQuery based
and takes input from a bunch of Java components that ultimately make a web service call into the web service layer.
The WebService layer runs in a separate module and war file.
The Application
Liferay generates, via the service generator, a raft of Java fles, which can
range from DAOs to web services. This is the boilerplate code which
a developer codes their own logic around Muhammed codes both layers
in an eclipse IDE and tests locally against his Tomcat runtime. He currently
uses JRebel in the presentation layer only, not the web services layer.
But is keen to implement the pattern matched includes/excludes so he
can use it in the web services layer without the runtime reloading code
generated by Liferay every time.
In a smaller team/company,
the backing infrastructure and
integration is rarely there, so
it's not possible to just drop
your code into a prebuilt
test environment with CI and
jenkins etc. JRebel Remoting
is a more lightweight way
of putting code into a test
environment easily with no
fuss.This is a really helpful
function and I'm really excited
to try this out.
5
All rights reserved. 2013 ZeroTurnaround O
Each and every coder has a different style of developing and Unit Testing. Some people like to write loads of code and
then go through a test/bug fix cycle. Others, including Muhammed prefer to do things in a step by step fashion, by
writing smaller pieces of code and testing while you code. This exacerbates the redeploy and overhead problem as
you find yourself building and redeploying much more often.
How do you code?
Muhammeds ant script (which perform
compilation, assembly and kicks of
deployment) took approx 20 seconds to
run, with the deployment taking another
90-120 seconds. He ran it on an average
15 times an hour. Muhammed says
"It was a massive pain just to run the
ant script which did the deployment and
testing".




Note that redeploying a portlet plugin
project does include redeploying of all
the portlets. Each portlet in turn uses
Spring and the Spring Context also needs
to be initialized. I am using tiles as well
and the tiles defnitions are supposed
to be reloaded. Worst case scenario
the PortletSesison is destroyed and all
the test data entered is lost as well. So
approximately 2 to 3 mins of efort in
redeploying.
6
All rights reserved. 2013 ZeroTurnaround O
There's another problem in doing this of course. Each time you make a chage to a .java in eclipse, the context is
reloaded and a new instance of WebAppClassLoader is created. As this is new instance, it does not contain the objects
of class Class that contains the bytecode of the classes that are used by the application.
Classloader hell
The new instance reloads all the classes (note the point all the classes)
that application actively uses; this is how your application sees the changed
class when you immediately test it in the browser. However, the earlier
instance of WebAppClassLoader leaks because of a java.util.logging.Level
which is used by Tomcat. If this intance of classloader leaks, all the objects
of class Class are also not collected.

So efectively, each time you change
the .java fle the new intance of
WebAppCloassLoader is created and an
earlier instance leaks. This results in OOME
Perm Gen Space. Then you have no choice
but to restart the tomcat server. Well.. if it
was plain tomcat then it is not a big pain
but then I have Liferay Portal Container
starting up on top of Tomcat which is a
heavy thing and restart is not that fast.
7
All rights reserved. 2013 ZeroTurnaround O
There's another problem in doing this of course. Each time you make a change to a .java in eclipse, the context is
reloaded and a new instance of WebAppClassLoader is created. As this is new instance, it does not contain the objects
of class Class that contains the bytecode of the classes that are used by the application.
The Solution
JRebel saves me from all this
- On changing the class, JRebel
does not reload the context i.e. it
does not recreate a new instance of
WebAppClassLaoder; instead it redefnes
the class directly.
The entire day of work without
redeploying and without restart. thanks
to JRebel! This saves me more than 50%
of my development time
Implementing JRebel takes just minutes,
as a one of job. It then saves you time
straight away. In Muhammeds case, lets
look at the numbers:
Firstly it takes 20 seconds to run the ant script (build)
Followed by another 90 to 120 seconds for the redeploy.
Doing this 15 times an hour takes up 30-35 mins every hour.
Thats over 50% of Muhammeds development time!

With JRebel all this wasted time is given
back to the developer.
8
All rights reserved. 2013 ZeroTurnaround O
C
o
n
t
a
c
t

U
s
Estonia
likooli 2, 5th foor
Tartu, Estonia, 51003
Phone: +372 740 4533
Twitter: @JRebel
Web: http://zeroturnaround.com
Email: info@zeroturnaround.com
USA
399 Boylston St., 3rd fr.
Boston, MA, USA, 02116
Phone: 1(857)277-1199
Czech Republic
Osadn 35 - Building B
Prague, Czech Republic 170 00
Phone: +372 740 4533