-----Original Message----- From: Berin Loritsch [mailto:[EMAIL PROTECTED]
None of the Re* interfaces are properly supported in any of the containers. We have not had a use case for it so far to really drive the development of that process.
They are kept for legacy reasons, and its use is pretty much discouraged.
I've got a couple use cases:
In the JavaLobby Portal Framework we were looking at having web modules (essentially portlets) that could be dynamically added. We have a couple main services and one was going to be a DAO manager. When new modules are added we wanted to "reconfigure" the DAO Manager to include the DAO's specified by the module configuration. One way to accomplished that would be to have a listener for new modules and then call the DAOManager reconfigure method.
We have a swing application which uses Fortress and connects to a database backend. Thing is, we have three databases. It would be nice if when the user switches which database they want to look at, to have the various components (both swing and otherwise) reconfigure or reinitialize themselves for the new database connection.
Both of these things can be done without the re* methods, but I do think there are many legitimate use cases, particularly when we get into the area of dynamically adding services or services which can be suspended. The problem is how to inform the container what events should trigger a re* method for a particular service. Perhaps the ideas about container extensions could finally solve this problem and give us a way to properly use these lifecycle methods.
Truth is, these methods do not account for security concerns or other concerns that are equally important. The problem with the re* methods is the lack of a complete concept. Do they pass in a new object with the complete model (i.e. all Context entries, all ServiceManager entries, the complete Configuration tree), a difference (i.e. only the new entries or partial Configuration tree), or a set decision for the type of object.
Truth be told, there is no reason for the Reserviceable/Recomposable interfaces because the contianer can easily manage those changes. There is no reason for the Recontextualizable interface for the exact same reason. So the only Re* interface where it might be a nice solution is the Reconfigurable interface. My suggestion in the past was to create a persistence mechanism for configurations so that as a component's configuration changes it can save the changes as necessary. Others have suggested a sort of Configuration registry (much better than the Windows variation), and there are still other ideas that abound.
We want to do the right thing, but there are other pressing issues to work on as well. Perhaps this is the itch you want to scratch... In which case I say go for it!
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
