To clarify: creating a Distributed Session Manager is a good idea, and something that would be great for users.
My problem is with designing it at container-level, as an implementation of the servlet session API. Having all objects in a session distributed and no control or feedback is not good. You could have a DSMServlet that would have some init parameters in web.xml. There you can specify what classes/interfaces you want 'distributed', or even what attributes ( by name ). Then you can use the existing listeners and notifications to detect when those objects are saved in the session and do the distribution. You could also define a simple API allowing the user to control this - for example and update() method to be called after the user changes an object. What's different here is that the behavior of servlet sessions doesn't change - most objects can still be stored without an overhead. The user gets to choose what objects to persist/distribute and he has control over the process. And this will work in _any_ container, so the user can assume the objects he marks as persistent/distributable will be this way on any container ( you can't force people to switch to a different container to use your webapp ) You can also define specialized interfaces to be implemented by the objects that will be persisted/distributed. All of this can be done with only standard 2.3 support. A container may provide aditional hooks ( valves, interceptors, etc) of course. Costin -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
