| a2d7d59a2ab8c9c17d054297982a055c1b3bb176 3061 |
|
14-Sep-2007 |
matthew_swift |
Avoid managed object definition initialization dependency problems. Using features like inherited default values and aggregation properties it is quite straightforward to encounter initialization dependency problems. For example: the global configuration will contain an aggregation property which references the default password policy. This aggregation definition is defined using a managed object path which, when decoded, contains a reference to the root configuration and its "password-policy" relation. This is what happens during initialization of the root configuration:
1) load the root configuration definition class and start constructing and registering its relation definitions
2) initialize the global configuration relation definition. This forces the JVM to load the global configuration definition
3) the global configuration contains an aggregation property definition which references a default password policy. Password policies are contained in the "password-policy" relation of the root configuration. Since the aggregation property definition references the password policy via a managed object path, decoding the path forces the root configuration definition to be loaded and its "password-policy" relation definition to be retrieved
4) the lookup of the "password-policy" relation definition fails because the root configuration has not finished initializing and the relation has not been constructed yet.
The fix is to "delay" decoding of inter-component references such as these until all the associated classes are loaded and initialized. To that end, property definitions and their default behaviors now have a new method called "initialize()". In addition, each property definition and default behavior has been modified so that any managed object paths and property definitions that they depend upon are not decoded during construction. This is now performed by the initialize() method.
The admin framework class loader provider has been modified so that it now performs this two-phase initialization:
1) load and instantiate each managed object definition class, forcing all property definitions and relation definitions to be constructed and registered
2) initialize each managed object definition instance: the instance invokes initialize() on each of its property definitions and default behaviors. This will force all inter-component references to be decoded and validated.
A positive side-effect of this change is that any inter-component references which have not been specified properly in their XML definition will be flagged during server start-up, rather than on-demand. |
| 1b8133cb3dcf0764d020b0aae8b90b16befcd989 3023 |
|
12-Sep-2007 |
matthew_swift |
Partial fix for issue 1449: improve server-side referential integrity support.
Previous to this change referential integrity was only enforced when a referencing (aggregating) component was added or modified. The support did not prevent a referenced component from being disabled or deleted. This change adds this remaining support:
* a component cannot be deleted if it is referenced by one or more components
* a component cannot be disabled if it is referenced by one or more components (it is possible to restrict this constraint so that it only applies when the referencing component(s) are enabled)
This implementation only enforces referential integrity for referencing components which have listeners associated with them. For example, if component A references component B, then referential integrity will only be enforced automatically if component A has a change listener registered against it, or if it is "added" using an add listener that was registered against its parent. In effect, referential integrity is only enforced for components which are in use or are about to be used. |