Hi Jerome, At first I though that the first requirement would already have met because of a common container context... Here are the use cases..
1) Sharing resources: Suppose I have a very expensive resource that is not only accessed (multiple times) but also managed within the same physical container then I might have an application that initializes and manages that resource and then publishes it for other applications to use. Makes sense? 2) Hierarchical Applications: Let's say i deploy an application X that is an open source application and then i want to extend it without necessarily tweaking X. So I develop an application Y that is "based" on X. Being based on X I inherit the classloader and hence all the resources of X and also its configuration .. Y then overrides parts of X and also perhaps adds more behavior. Does that make sense? Now if we have implemented 2) I think 1) will follow as we could create an application A that manages the resource and child applications have access to application A. And singeltons aren't a solution. As for "security" an application can be final i.e. it can't be extended. Cheers Piyush
