Tuesday, March 12, 2013

JBoss startup time with Spring and Struts

After migrating to JBoss 6.1.0, Spring 3.0.6 (were are using Struts 2) our application server started slowing down on strut-up. Before the migration if I am correct it used to take about around less then a minute and after migration it was taking around 3 mins.
 Recently I got new lappy at work, with new configuration the boot up was good but not so good, now it took me around 1min 30secs to boot.
 To know the startup issue, I profile the jvm with jvisualvm and profile data showed that time was taken by spring to initialize itself. Then to make things to initialize lazily, changed the xml configuration of spring and set default-lazy-init to true for every "beans" tag.
 Now I started JBOSS expecting it to start in secs, but then it again had the same story, it took same amount of time. Then again I profiled the jvm and saw there was no difference, then to trace down I noticed that even if beans were marked as lazy there were being initialized by struts by method
 com.opensymphony.xwork2.spring.SpringObjectFactory.getClassInstance(String) [This is found in xwork jar we have 2.0.4 version]

By looking at the method it suppose to get the class instance only and not create bean, but the code does have a call like below

clazz = appContext.getBean(className).getClass();

The above code is actual culprit, to get class instance the call is creating bean and then getting the class, the code should have been as

clazz = appContext.getType(className);

As our is web application I create a copy of this class with same package name and placed it in our WEB-INF\Classes dir (as this would be first to get loaded and then *.jar) this made sure that our customized class (SpringObjectFactory) would be loaded first by jboss server and not SpringObjectFactory from xwork.jar (other way's we can do is add agents to manipulate the class method using BCEL or Javassist)

After this changes, I started JBOSS, now it takes me about 37 to 39 secs too boot (still slow but its ok for now).
Wanted to give a patch for above fix in SpringObjectFactory, but found that xwork site is in RIP state, and I could not find any other version system to give above fix.