jRebel without a pause – avoiding PermGen roulette in WebCenter Sites deployment

Bad habits can creep in to the WebCenter Sites development cycle. In this post I’ll look at how we can work to alleviate the worst of them by creating more testable code that focusses directly on the task in hand. We’ll also see how we can crush the number one problem that we face as WCS developers; the problem of deployment.     

Let’s talk about your guilty secret

You know, the one where you end up putting business logic in Templates and CSElements. You do it because adding code to a JAR file and redeploying it every time that code changes is painful. Very painful. You even thought about using Groovy at one point, but that just wasn’t your style. You have deadlines to meet and waiting for that application server to restart for each re-deploy just wastes valuable minutes of your day. Of course, you can re-deploy to some app servers, and hope you get away with it, but that’s a gamble …

And that’s how it begins: the PermGen Roulette WCS anti-pattern

You’re constantly trying to avoid deploying JARs and classes to WCS, in fear of the overhead that incurs and so you tell yourself that you’ll re-factor the code eventually. After all, they must have created those tag libraries for a reason. And, do you know what, why can’t you iterate that list, or look for all the assets in an association, or even just set a counter variable for use later in the template. To make it safe, it’s definitely a good idea to mark it with a TODO: just so that everyone knows the code was delivered with the best intentions and in the smallest amount of time.

What’s a developer to do?

A roulette-free approach

I’m no doctor, but let me prescribe the following approach

• Firstly, you need to re-asses the way you work with Templates. Start thinking MVC and look at those Templates as Views. To that end, download and install the GSF foundation classes for your WCS release (11g or 12c). The GSF is Open Source, but written by folks with years of experience of poking round the WCS innards.
• Then, start to re-factor the whole delivery experience by taking the first step and examining that logic in the Template and then removing as many of the WCS tags as you can.
• Now, continue with your re-factoring and consider using JSTL in those Templates. JSTL is so much better than the WCS tags and removes a lot of the clutter in a Template.
• Next, rip out the business logic from your Templates and add this code to proper Java classes. Make these classes functional but not too heavy. Create POJOs and use them in conjunction with your business logic to enable a well-testable codebase. Rip out the dependency on the ICS and use Mockito where you must.
• Finally, put the last element of this re-factoring in place by starting to use Action classes to load your asset data for a Template, and making use of those Java classes and POJOs you’ve just written. Derive and matriculate in the Actions and use the Templates to surface that information.
• Use the secret sauce to deploy your code changes as you make them.
• No chance to pause – your code is redeployed and available for use immediately you save it.

New confidence in your code base

In fact, those initial steps describing re-factoring and testing give you a whole new level of confidence in your code base. This neat way of testing code in a standalone fashion is one of the basic tenets we apply to development at Manifesto. You can have no confidence in changing code if you have no way to prove that the change is not breaking the functionality. Introducing a best practice approach to development is hugely important for the longevity and maintainability of your application. Doing this lets you lay the foundation to work in an Agile and lean way.

The secret sauce: jRebel

Now, I imagine you were quite happily following along in that list of steps above, probably all the way up to the last two. So, what on earth is “the secret sauce” and how can you possibly not pause after deployments?

It is possible, friends, and let me tell you how …

Remember PermGen Roulette ? The gamble you take every time you drop code into our App Server? If you’re lucky, you’ll get a shot at running the new code, as the App Server forgot its old allegiances and loaded those new classes, but if you’re unlucky, it’s restart time.  🙁

So, let me tell you about the secret sauce: its name is jRebel, from ZeroTurnaround. We all know that that Hot Code Replace has been around for a while in the JVM and there are numerous tools, either coming with the JVM or as OSS projects, that allow you to do some of this work, but not all.

What jRebel allows, over and above what those tools offer, is the ability to edit and redeploy classes to the application server, making them immediately available. It also lets me change method signatures and add constants, change base classes, and a whole lot more. And then I deploy without waiting!

Have cake and eat it No free lunch

All this wonder and amazement does of course come with a cost, but you need to weigh up the cost of a licence versus the amount of time you waste waiting for that app server to restart.

In fairness, there are and always will be ways to reduce these steps and the costs. Some may argue that you do not need to pay for additional tools to manage a development process that is well defined. You might have a process where you already create Java to deal with your business logic and you always re-deploy and it always turns round quite quickly (probably because you’re using Tomcat and WCS 11g and you love dicing with PermGen Roulette).

So, finally, a few questions about your dev. environment and your attitude to development in general.

• Is your WCS 11g site running on Tomcat in production, or does it target an alternate application server?
• Are you targeting more heavyweight servers like Oracle Weblogic or IBM WebSphere, and have you got all the features and functions of that App Server factored in to the development routine?
• How near is the development set-up to the real environment that your code will be running in?
• What will you do when you switch to WCS 12c where Tomcat support is looking, frankly, very unlikely at the time of writing? All of a sudden, you’re back to that dreadful cycle of changing, redeploying and waiting. The PermGen Roulette.

Nip those bad WCS development habits in the bud

With jRebel, you need not fear this PermGen Roulette; you can redeploy time after time after time. On App Servers like WebLogic and WebSphere, that is an absolute must. Time wasted is time badly spent. It’s also time where folks can sit around and think about avoiding redeploying and ‘just’ adding a bit of code into the Templates and that’s where the anti-patterns creep in. Don’t let those bad habits develop!

Here at Manifesto Towers, we’ve successfully applied the rapid deployment approach to WCS development and deployment, and you can too. If you would like to talk to us about this, or any other work we do with WCS then please do contact us.

So, let me urge you to make your WCS development life a whole lot easier. Be a Rebel. A jRebel without a pause.