Fix issue 3734 - Make network group policies extensible. See issue tracker for more details.

Integrating the changes related to Collation indexing support

Add support to admin framework for retrieving an i18n description of the constraints applicable to an aggregation property. This is required for issue 2004 (HTML configuration guide generation). Two new methods are added to the AggregationPropertyDefinition: getSourceConstraintSynopsis() and getSourceConstraintSynopsis(Locale). All aggregation definitions which had constraints have been updated to included the description. In addition, dsconfig is modified to output the constraint description when displaying verbose help on aggregation properties.

Fix for issue 2446 part #1. Add support to the admin framework for specifying one or more "default" managed objects which should be created automatically when a parent managed object is created. The XML mark-up is provided as part of the parent managed object's relation definition as follows (the sample is taken from the LocalDBBackend XML definition): <adm:relation name="local-db-index"> <adm:one-to-many naming-property="attribute"> <adm:default-managed-object name="aci"> <adm:property name="index-type"> <adm:value>presence</adm:value> </adm:property> <adm:property name="attribute"> <adm:value>aci</adm:value> </adm:property> </adm:default-managed-object> <adm:default-managed-object name="entryUUID"> <adm:property name="index-type"> <adm:value>equality</adm:value> </adm:property> <adm:property name="attribute"> <adm:value>entryUUID</adm:value> </adm:property> </adm:default-managed-object> <adm:default-managed-object name="objectClass"> <adm:property name="index-type"> <adm:value>equality</adm:value> </adm:property> <adm:property name="attribute"> <adm:value>objectClass</adm:value> </adm:property> </adm:default-managed-object> </adm:one-to-many> The functionality is implemented on the client-side API in a generic manner so that it is independent of the underlying driver implementation (so the default indexes would be created if we had an offline direct to file driver as well).

Update admin framework and dsconfig to support tagging of component definitions as advanced and customizable: * advanced components: these will not be displayed by default in dsconfig. Examples include the various system backends * customizable components: these components are tagged as intended for customization using the CLI XML profile. Customizable components are usually the top level components previously referred to as "generic" by dsconfig. This term confused users who would, for example, mistake a "generic" backend for a JE backend. This change is part of issue 1829.

Advanced properties phase 1: tag advanced properties and perform various clean-up to the XML definitions: * clean up typos and any bad grammar in the synopsis/description elements * fixed common errors. For example, there were many places where the synopsis was repeated in the description (the description is only ever used in conjunction with the synopsis). There were also many places where the <adm:user-friendly-name> was being used in property definition description elements to refer to the property name, when it actually refers to the managed object name * split big synopsis (not sure of the plural form - synopsi?) where possible - there were lots of cases where we'd have a big synopsis but no description * overrode properties with sensible default values where appropriate (for example, I provided sensible default values for some of the attribute-type properties in the virtual attribute definitions) * generally made documentation more consistent across the definitions * removed unneeded XML attributes of the form 'mandatory="false"'. Attributes only need to be specified if their value is true as they default to false. Adding redundant attributes just makes the XML harder to read * removed any documentation that referred to the configuration in LDAP related terms (with one exception in the Schema backend). All documentation now refers to other properties using the property names, not their associated LDAP attribute.

Add support for specifying arbitrary constraints in managed object definitions and use it within the LDAP and JMX connection handlers to enforce their SSL/StartTLS settings. This feature will be re-used for other managed object definitions as the need arises.

Improvements to aggregation support and foundation work for expressing arbitrary constraints within components. This change adds support for defining arbitrary conditions which can be used to test properties and their values. Conditions can be used within aggregations to define 1) when a referenced managed object needs enabling and 2) when it is enabled. For example, the LDAP connection handler requires that its key manager provider and trust manager provider are enabled when it is enable and when either SSL or StartTLS are enabled. Conditions are also intended for use within the existing constraint/dependency support. For example, it should be possible to indicate that a property "min" is always less than or equal to a property "max", or that when "use-ssl" is set to true, any required SSL configuration related properties are also defined. This will be implemented in a subsequent change (this change just focuses on the work required to resolve issue 1449). This change adds support for the following conditions: * logical "not" * logical "and" * logical "or" * logical "implies" * contains - determines if a property contains a particular value * is-present - determines if a property has any values (incl. defaults) More will be added as required.

Merge branches/temp-admin@3208 onto trunk@3208.

Modify the aggregation definition support to permit multiple source "enabled" boolean properties. This is useful in components such as the LDAP connection handler where the referenced key/trust manager must be enabled only if the connection handler is enabled and if it is using SSL.

These changes allow dsconfig to decode the ACI string similar to what is done for the DN syntax attributes. A new <adm: aci /> syntax has been created that DSEE compat configuration handler is now using.

Partial fix for issue 1449: administration framework aggregation support This change adds support for "aggregation" properties, which are properties which reference other managed objects (see issue 1449 for more details). Subsequent changes will add server-side and client-side referential integrity support, as well as migrating components over to using them (this will be post MS1.0).

Add support for overriding the user friendly singlular and plural names of components. The user friendly names (UFN) are usually derived automatically from the component's "name" and "plural-name" attribute. However, sometimes these names are not that user friendly. For example, the names may be abbreviated forms (e.g. replication -> repl or password policy -> pwp). In these cases it would be nice to be abled to display the full human friendly name in help and documentation. This change includes an overridden UFN for the global configuration. So we should stop seeing messages in applications like "The Global was updated successfully".

Fix issue 1819: add support for tagging properties as advanced. It is now possible to tag a property as advanced. This is achieved by adding the "advanced" attribute to XML property definitions. For example: <adm:property name="java-implementation-class" mandatory="true" advanced="true"> ... </adm:property> Advanced properties must be either option or, if they are mandatory, have default values (defined or inherited). This constraint is enforced except for abstract property definitions where sub-definitions can override the property and give it a default (this is the case for java implementation class properties). Dsconfig has been modified so that get-xxx-prop and list-properties sub-commands only display advanced properties if the user provides the "--advanced" command line option. There will be similar support for set-xxx-prop and create-xxx sub-commands once they have a fully functional interactive mode (issue 1831). This change just adds support for advanced properties. A subsequent change (for issue 1829) will designate which properties are advanced.

Improve documentation for property definition element "mandatory" attribute.

Fix issues 1966 and 1792. Add support for hiding relations and, using this feature, prevent users from access root DN user configurations through the CLI. To make it easier to add new features to relation definitions in the future I have refactored the RelationDefinition classes so that they provide a Builder API for incrementally constructing new definitions.

Fix issues 1943 (unable to create je-index), 1996 (exception when creating components with empty names), and 1998 (exception when creating components with blank names). This change allows one-to-many relations to use a property of the referenced component for naming the component. For example, a je-index has an attribute called "index-attribute" which is the attribute type indexed by the index. There is no need for the je-indexes to have a naming attribute since the value of the "index-attribute" property is sufficient. With this change it is possible to specify a "naming property" for one-to-many relations. In the case of je-indexes, the je-backend je-index relation is now defined as follows: <adm:relation name="je-index"> <adm:one-to-many naming-property="index-attribute"/> <adm:profile name="ldap"> <ldap:rdn-sequence> cn=Index </ldap:rdn-sequence> </adm:profile> <adm:profile name="cli"> <cli:relation> <cli:default-property name="index-type" /> </cli:relation> </adm:profile> </adm:relation> Note that the one-to-many element now has a "naming-property" attribute which identifies the je-index property which should be used for naming. Also note that the LDAP profile no longer needs a naming-attribute element, since the naming attribute will be the one associated with the index-attribute property.

Partial fix for issue 1426: improve support for required admin actions. This change modifies the admin framework XML schema so that it is possible for all types of required admin action to have a description. For example, when there is no additional administrator action required when a property is modified, it is sometimes nice to indicate how the change will dynamically take effect. In addition, it is now possible to query the specific type of admin action associated with a property and its synopsis via the admin framework APIs.

Add support for tagging managed object definitions so that similar types of managed object can be grouped together. Tagging will enable us to automatically generate more user-friendly documentation and administration tools as a result of them being easier to navigate and search. For example, an administration CLI will be able to split the available set of sub-commands into categories, thus making it easier for administrators to find the sub-command that they need. This change is implemented as follows: * provide an extensible way in which tags can be defined: the XML root configuration definition element now supports an "adm:tag-definition" element, which can be used as follows: <adm:tag-definition name="logging"> <adm:synopsis>Logging</adm:synopsis> </adm:tag-definition> * provide a means for tagging managed object definitions with zero or more tags using an "adm:tag" element, which can be used as follows: <adm:tag name="logging"/> * add support to the admin framework APIs for querying a managed object definition's tags * define an initial set of tags and tag managed object definitions appropriately (this is just an initial guess and is likely to change): * logging * replication (incl. mmr) * database (incl. caching) * security (authn and authz) * identity (user account management, pwp, etc) * core (connection handlers, virtual attributes, etc)

Add support for specifying a "usage" string for string based property definitions which define a pattern constraint. The usage string is used when the syntax of a property needs to be displayed, for example in a CLI help screen or in server-side log messages when a bad property value is encountered. For example, a property whose values must be a valid UNIX mode could have the following string syntax definition: <adm:string> <adm:pattern> <adm:regex>^[0-7][0-7][0-7]$</adm:regex> <adm:usage>MODE</adm:usage> <adm:synopsis> An valid UNIX mode string. The mode string must contain three digits between zero and seven. </adm:synopsis> </adm:pattern> </adm:string> Existing string based properties have been updated with appropriate usage.

Fix issue 1580: support overriding of property default values. It is now possible to override the default behavior and required admin action of an inherited property definition using a "property-override" element. This makes it possible to specify default values for inherited properties like java-implementation-class and will, ultimately, make a client tools much more user-friendly. A subsequent change will add default values for java-implementation-class properties in all managed object definitions.

Fix the following issues: * 1444: implement inherited default values * 1445: prevent commit if mandatory properties are missing * 1446: refactor managed object factory method API in generated APIs * 1625: allow read-only properties to be defined during managed object construction and add support for "monitoring" properties (e.g. a property which is server generated and contains the list of support ciphers) These issues have been fixed in a single change as they depend upon each (issue 1446 being the main issue). [Reviewed by Josu]

Migrate the BackendConfigManager to the new configuration framework.

Update the admin framework to complete the partial support for the case-insensitive property of the string syntax.

Merge admin framework from config-prototype-branch onto trunk.