This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
I have a webapp that I need to put in production, but I need to make changes on it rather constantly. Each time it takes the whole webapp down for a period of time, which I have to avoid-- it's in production.
I know that if I put all my code in jsps, then I can just change a jsp, and it will recompile without having to reload the entire webapp. But of course it is bad to put all the code in jsps.
Even if I take most of the business logic out, the webapp still needs to have logic to control the page flow, security, and other items.
So how can I ensure that I can change just about everything the way a webapp works without it reloading the entire webapp? Is there a framework or a pattern?
Has anybody else had this requirement? Or does everyone go for specific releases-- and require no changes between them?
I would be so incredibly grateful for all comments and ideas. I have been a loss on this for years, and it has become imminent.
You can't avoid it. When new classes are added to the web app, it has to reload. Some containers have options that allow them to check for such changes and automatically restart the app; though this is not recommended for production systems as the checking slows things down.
As you realized, putting code in JSPs to avoid this would be a horrible perversion.
What I'd do is to step back and figure out why you are needing to update the classes so often and see if there are better ways to do this. Can the changes be better handled by making the classes more configurable via data rather than code, for example.
Part of the problem is that we are constantly adding new logic and pages. The other part of the problem is that we are expected to have extremely quick turnaround from when the requests are made.
I was thinking that if I used some kind of front end framewok like Tapestry, and then used some kind of backend framework that could do lifecycle management of the java, that it would be possible.
But I haven't investigated, and I may be completely off-base to make those assumptions.
I am sure I could fix the problem by slowing down the release schedule, but then I am loosing the versatility and speed to production that my clients absolutely love.
It is interesting that this problem is such a hard one to tackle since others, such as ASP and PHP, avoid the problem inherently. I want to use Java, though, because of obvious other problems that ASP and PHP have.
I could be missing your point here, but if all your changes are fully tested on the development systems, and you have a build process in place to create a war file with all the new changes, the downtime should be very short. All you need to do is copy your war file to the right location, and ask the container to reload the web-app. It should only take a few minutes.
Could you possibly define your functionality in a more abstract way? How about defining program flow with an XML document and emphasizing interfaces in your class design so that a new class could fit right in because it implements a standard interface. If each user stays "attached" to the program flow document they start with, a new program flow document can be introduced for new users while existing ones continue. Eventually all references to the old will be lost and everybody will be working with the new. I have only done this with XML documents representing online exams but it does let me update without taking the app offline. Bill
Joined: Dec 03, 2004
Sonny, you are right that it is not a huge impact, but I was hoping to eliminate the impact. Here is an idea though-- Is it possible to pre-load a second instance of the webapp and then switch it?
William, There are parts of the site that I already do something like this. But for these "ad hoc" changes, they are often new functionality that can't be predicted.
Often, the biggest reason for making changes are because of new functionality "demos", and I am pretty certain that even if I split the "demos" off into it's own webapp, that I would still have to affect the larger "webapp".