> -----Original Message----- > From: Berin Loritsch [mailto:[EMAIL PROTECTED] > > 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.
My thoughts is that there would be a handler (similar to ComponentHandlers) for the re* lifecycle (suspend, re*, resume). The idea of container extensions is still fuzzy right now, but I think that if the security concerns around container extensions can be resolved, then you would at the same time resolve any security concerns with these lifecycle methods. Additionally the specific behavior (complete, difference, set decision) of re* methods could be determined by the particular handler. > 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. I agree about reserviceable. Recontextualizable might also have a use case similar to that of reconfigurable. The first question is whether or not context values should ever change (I think they probably could). If so a service may very well want to know that. An alternative to recontextualize() is something like the servlet spec's ServletContextAttributeLister so that a service can be notified when a particular context value is changed. > 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! The place to start right now would be to add some lifecycle or stage extensions for re* methods and get a better feel for how it should be done. In the end I think is belongs as a sort of kernel/container extension. I have so many "itches" right now the hard thing to determine is which to scratch first. :) jaaron --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
