User object in Application vs in Application Context

General
1

I think the user object
(made manifest by the methods setUser() and getUser() and the listener UserChangeListener)
should have been placed in the ApplicationContext rather than in the Application class.

When I have a web session, a user change affects the whole session - as this is what the javadoc for ApplicationContext interface says:


ApplicationContext provides information about the running context of the application. Each context is shared by all applications
that are open for one user
.

Placing the user object in the Application class is akin to disastrous normalisation of relational data in a failed effort to prevent update anomaly, so that when user change is detected at one Application instance, I have to search all other Application instances running under that user-based context to update the user object.

Otherwise, I have to assign one of the Application instances as the “main Application” instance (akin to an Application having a main Window instance) so that any changes in user object is take place only on that main Application instance. Then, all other Application instances would have to descend into the context to look for the main Application instance whenever they need to find out the current user. Then, also, whenever user change event happens, the main Application has to descend into the context to list all active Application instances and tell them about the user-changed event.

What’s your opinion?

2

While many applications may share user login information among each other, there are also cases where such sharing might be undesirable. Also, many applications simply do not use the get/setUser() mechanism in Application but instead define their own, more complete user management.

If you want to associate your user management with the whole session (application context), it should be easy to create your own subclass of Application that accesses the (HTTP or portlet) session in setUser() and getUser(). Getting user change events to work does require iterating over the applications of the session in setUser(), though. You could then use this Application class as the base class of all your related applications, so there is no need for a separate “master” application.

If the applications should be runnable either as servlets or as (JSR-286) portlets, your methods to access the session need to be able to handle both cases, which does require an instanceof test or two.