On Mar 20, 2007, at 4:09 PM, Raymond Feng wrote:
Hi,
Interestingly I just hit the same issue independent of your work. I
got two instances of the ComponentManager and the one contributed
from the system.scdl shadows the primordial one.
Which actually the correct behaviour, just not the desired one here :-)
Does it mean the primordial components are not replaceable?
Depends on what you mean by replaceable.
The way AbstractRuntime boots it:
* creates a primordial fabric (ComponentManager, Connector, about 4
other components)
* creates a primordial deployer runtime
* uses the deployer runtime to deploy the system scdl into the
primordial fabric creating the local runtime
(the remaining 100 or so components)
* uses the freshly booted system to load applications
The primordial components are those needed to wire the composite in
the system scdl. For example, the components it contains need to be
registered with a ComponentManager as they are deployed, so the
ComponentManager can't be in the system scdl.
Instead, they are created by the createBootstrapper() call and
registered in registerBaselineSystemComponents(), both of which are
overridable allowing the implementations to be replaced. If that
doesn't go far enough, the entire AbstractRuntime class can be
replaced with something that boots the local runtime in a completely
different way. For someone considering swapping out the fabric,
that's a trivial change.
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
