On Mon, 2002-07-22 at 18:13, Marcus Crafter wrote:
> Hi All,
heya!
> Berin mentioned a few posts ago something which sparked my mind about
> the implementation of the Re* interfaces in Fortress.
>
> I thought about taking a look at implementing it, but I think I'm
> missing some of the concepts here.
>
> When are the following Re* methods actually intended to be invoked
> on implementing Components:
>
> o Recontextualizable
> o Recomposable
> o Reconfigure/Reparameterizable
we've not defined this clearly enough atm for these interfaces to be
used unambigously.
The way I see it, a component should be configured with some state
*once* and only *once* during its lifetime. Its ComponentManager should
not change; that could lead to unexpected behaviour.
if an app does:
class MyComp
{
OtherComp otherComp;
compose( ComponentManager cm )
{
otherComp = (OtherComp)cm.lookup(OtherComp.ROLE);
}
bla()
{
otherComp.doStuff();
}
bla2()
{
otherComp.doStuff();
}
}
everything should be exactly the same (probably equals() should be true
if that were not a messy issue) as when it does:
class MyComp
{
ComponentManager cm;
compose( ComponentManager cm )
{
this.cm = cm;
}
bla()
{
((OtherComp)cm.lookup(OtherComp.ROLE)).doStuff();
}
bla2()
{
((OtherComp)cm.lookup(OtherComp.ROLE)).doStuff();
}
}
In order to make it possible to have lookup() return other stuff (where
FA instanceof will yield different results on Othercomp) on the same
lookup, or provide a different implementation of CM, or do
less-expensive 'restarts' using remote management, there is
Recomposable.
When component creation/initialization is not immensely expensive it is
okay not to use Re* but just dump the component and create a new one.
This may not be desireable in some cases.
> I can imagine a change in the .roles/.xconf files causing
> components to be reconfigured and given a new component manager
> reference, but perhaps that's wrong (?).
.xconf is the way we currently do component resolution. If one imagines
a massively complex, long-running, distributed setup (I've been looking
at the way renderfarms work), Recomposable makes sense.
The other Re* seem a lot less complex to me. For example, if you
configure a component with a JDBC database URL using Configurable, then
copy the database to a new location (maybe the hard drive is full), and
want to change the URL to it with minimal loss of service,
Reconfigurable is a natural choice.
summary: Re* is thus mostly interesting for expensive components or for
components where destruction and recreation is not a neat option.
Re* is not neccessary very often as many systems would use them so
sparingly on their expensive components that destruction/recreation is
acceptable overhead, or in case of vital components that always need to
be available there is some kind of pool anyway.
just my take on it.
BTW, we should either specify Re* are optional for 'full compliance'
from containers, or we should make all our containers work with them.
cheers,
- LSD
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
