Controller as a Singleton class in Front Controller Pattern

Trying to develop a prototype for Front Controller Pattern. I am considering implementing Controller as a singleton class. Now the Controller will be instantiated only once in the application lifecycle (client being servlets and getinstance of singleton controller being called in init method). In this situation all of the request will go through singleton controller (controller will just delegate requests and will not have any state, property or instance variables). Other components will remain the same as explained in j2ee patterns.
Is there possible architecture flaw /threading issue in this case. Any idea or suggestion
Thanks

My main issue with this is that I don't see the need for a Singleton. Given this, and the way that Singleton is so commonly misused or misunderstood, I'd avoid it.
Can you explain why you feel you need a Singleton here, rather than just a regular object?
The traditional way of doing this in a servlet/JSP context is to instantiate your Controller object once when the web-app starts, and place a reference to it in the "application" context. Then any servlets and JSPs which need it just fetch it from the application context and use it. No Singleton required.
This, incidentally, is a common way of dealing with any resource shared between servlets and JSPs, and can also be used for JNDI handles, JDBC connection pools and so on.

thanks it is a good idea to share application resources. i will not use the singleton approach . do you have any other idea or method for doing this .

OK, I'm glad you decided agains the Singleton, but I'm not entirely sure what you are asking now. Other idea or method for what, exactly ?

The reason for making controller singleton was to create it once in servlet life cycle (not to create a new controller object with every request). The idea you suggested is to instantiate Controller object once when the web-app starts, and place a reference to it in the "application" context.
What i meant was that is there any other way of doing this (persisting it through the web-app life cycle)?

Originally posted by Kripal Singh:
The reason for making controller singleton was to create it once in servlet life cycle (not to create a new controller object with every request). The idea you suggested is to instantiate Controller object once when the web-app starts, and place a reference to it in the "application" context.
What i meant was that is there any other way of doing this (persisting it through the web-app life cycle)?

Why do you need another way? Is putting it into the application context inappropriate for your problem? If so, why?

If you really want to, you can store it in a JNDI context, or make it available as a web service or whatever, but why bother. All modern servlet/JSP containers have an application context, and load-on-startup servlets in which you can create things like this. The web application lifecycle processing takes care of starting things once when the web-app starts, and shuts them down when it stops. It's what they are for, really.
Can you help me with some ideas of what might be an ideal solution for you, if this is not right, somehow?

Application context will work fine for me. But in multi tier architecture if there is need for controller object in a backend layer we will have to get hold of application context first. Which means we have to keep passing the context through all layers. Correct me if i am wrong.

It looks as though you are over-generalizing the pattern. The kind of controller you use in a servlet/JSP system is only responsible for controlling the interaction between HTTP requests, servlets and JSP.
I can't see any need to pass this controller around at all. If other layers use a similar pattern, they would need their own controllers for their own contexts.
Can you give us an example of another layer which might need access to a web-application controller?