I asked Vita this:
(1) When some module (e.g. the JavaModule) looks
up a setting,
>     I've modified TreeNodeContext to look in
>     
/Settings/Configurations/....../Settings/Contexts
instead
>     of /Settings/Contexts as it used to.
>
>     Now lets say the user goes and selects a new
configuration
>     as the active configuration.
>
>     How do I "Refresh" the system such that for
example the
>     property sheet which may have a different
setting for the
>     compiler flags is shown ?
>
and his reply was:

Ach, you touched the hardest part. My plan is to
have the
TreeNodeContext implementing the
javax.naming.EventContext,
which is capable to fire changes in bindings
stored within it.
When user changes active configuration,
TreeNodeContext
should fire events for all bindings stored within
that context.
Then beans like ContextSettings would be able to
listen on
underlying EventContext and fire propertyChange events
according to EventContext's notifications.

If you would try to implement this, don't forget that:
- TNC for PO1 is using the TNCs from
ProjectObjects which PO1
depends on, that means that bringing PO1 in
up-to-date state means
to have all its dependencies up-to-date

- IMO firing events could be delayed, but calls to
lookup/bind should
by synchronous (or should wait on update task), at
least I expect
it would be useful to have some background task
which will update
whole hierarchy

- clients will very likely access settings values
from the notification,
the TNC should be up-to-date before any
notification is fired,
also it may cause some threading problems.