Timo Penndorf wrote:
> when writing our application we got some trouble
> at config element removals. As the dependencies
> are only resolved at config addition, it was
> possible to remove elements needed by other ones.
> So we changed the removing process to a similar
> functionality compared to the addition of elements.
> We introduced DepChecker::depNeeded and
> In ConfigElementHandler::configProcessPending we
> use the isNeeded method of dep_mgr to resolve
> the dependencies.
> Maybe you find this functionality useful. The given
> patch works with the 2.2 svn branch.
This is an interesting patch, but couldn't this lead to preventing run ti=
reconfiguration? When changing the properties of a config element, the
procedure is to remove the existing config element and replace it with a =
one that has the changed properties. In other words, if config element E1=
reconfigured, it is removed and replaced with E1' (which is still called =
as far as the Config Manager is concerned). An element E2 that refers to =
by name will continue to have its pointer resolved because E1 and E1' hav=
the same name. However, if a dependency checker for E1 indicated that it =
needed by another element, then reconfiguration of it would never happen
because the removal operation would be prevented.
Ultimately, I think this speaks to a larger issue with the way that
reconfiguration at run time works. The add/remove/re-add approach is a
little ham-fisted, but it might be quite hard to implement in-place
reconfiguration. It may not be as hard as I think, and Allen would probab=
have to speak to that detail.
Could you explain what you are trying to accomplish that caused the probl=
to arise? That would help provide some context for when this change is
Patrick L. Hartling
VP Engineering, Infiscape Corp.