This is how I see the implementation.
User can be in any part of the application. So any time user request comes to server, it goes through the controllers. I can write a method (and call from each controller) that checks if message needs to be displayed. Put that into application context and display it. Along with that I will also have a flag that keeps track that if the message has already been displayed or not (to the user). If message has been displayed, no need to call that method again.
Saurabh Pillai wrote:and call from each controller
It is completely unnecessary to infect each and every controller with this undesirable extra code. Look up how to use servlet filters.
PS:- I have not implemented cookies before.
Is there a better way?
I'd store the info in a properties file for quick and easy access without the need to involve the database.
Bear Bibeault wrote:Cookies aren't useful because those are stored on each user's browser and you need to know when to set them, so that's no good.
I don't have any experience with cookies. But this is how I see it working. You look for cookie in request, if found, pass it as an attribute. If it is not found, set it and also pass it as attribute.
Bear Bibeault wrote:I'd store the info in a properties file for quick and easy access without the need to involve the database.
How do you make it dynamic then?
If the time needs to be variable, the filter can read the properties file on each invocation, which will still avoid hitting the database.
Depends upon your requirements.
If your webapp is not actually going to be brought down but rather you just want to temporarily disable it, you can set up a "maintenance window check" filter in front of other filters that does something like what Bear described. We have this in our apps and it's useful when we just want to do maintenance work on the database and not bring down the app itself. In our case we have the filter look in the application context for an object that has maintenance window information. If that object is there, the filter can decide to block further processing and generate a 503 error (see a list of error codes: http://www.informit.com/articles/article.aspx?p=29817&seqNum=7)
Your web.xml can be configured to show a certain resource when you get a 503 error. See http://www.onehippo.org/library/concepts/error-pages-and-error-handling/1.-handling-error-codes-and-exceptions-by-the-web.xml.html
You can have an "admin" route/URL/service that's only known to admin folks and they can submit a request to that URL to setup a maintenance window. The request is first authenticated and authorized and if successful, it processes the request and puts a "maintenance window" object that the filter I mentioned before is checking for. You can either have the maintenance window object contain expiration date/time or you can have the maintenance window filter check for other parameters that indicate that the current maintenance window is to be terminated. There are a number of variations you can introduce to this design but that's the general idea.