> -----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. jaaron --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
