Re: [Phoenix] Reconfigurable

[Berin Loritsch <bl...@apache.org>]

Farr, Aaron wrote:

> 
>>-----Original Message-----
>>From: Berin Loritsch [mailto:bloritsch@apache.org]
>>
>>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: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org