Fix OPENDJ-265: Remove XSLT component naming constraint in admin framework

Partial fix for issue 2296: fix minor bugs in XSL scripts.

Java code generated from admin definitions using the RelativeInheritedDefaultBehaviorProvider won’t compile because of missing import for the DefaultBehaviorProvider class.

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

Updated the copyright statement to reflect that Sun owns the full copyright on the project files.

Partial fix for issue 2661 - public APIs must not reference private classes. In org.opends.server.admin.Configuration replace ManagedObjectDefinition<...,...> definition() With: Class<? extends Configuration> configurationClass() And remove method: ServerManagedObject<...> managedObject() This decouples generated server-side management APIs from the rest of the framework with the exception of configuration listeners.

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.

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.

Implement a new configuration definition called "TopCfgDefn" which acts as the parent of all other configuration definitions. This is analogous to the the "top" object class in LDAP. The principle use of the TopCfgDefn is to make it easier for applications to determine all the possible types of managed object the administration framework supports. The TopCfgDefn is not generated automatically from XML. Instead it is located in the org.opends.server.admin package together with the base client-side and server-side interfaces (ConfigurationClient and Configuration respectively).

Performance improvements to server-side admin framework. The strongly typed server-side APIs now retrieve and cache their property values during construction so that subsequent calls to property getters no longer have to repeatedly access the underlying ServerManagedObject. This avoids having to repeatedly perform hash-table look-ups in the ServerManagedObject and, in the case of single-valued properties, temporary construction of iterators. I have also modified the ServerManagedObject#getPropertyValues() method to return an UnmodifiableSortedSet rather than a defensive copy and updated the javadoc in the generated server-side getters to reflect that the returned set is unmodifiable.

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.

Add support to the admin framework code generation scripts so that properties can define their own syntax specific getters and setters.

Add support for generating property type specific code immediately after the property definition is constructed.

Fix bug in code generation which was preventing overriding the default behavior for enumerated properties.

Partial fix for issue 1831 - dsconfig interactive mode. With this change, dsconfig now prompts for component names if they are not specified on the command-line. Where more than one choice is available, dsconfig displays a list of choices. For create-xxx sub-commands dsconfig also prompts for the component type (-t flag) if it is not specified. Users can, at this point, request help which displays a detailed description of each type. A subsequent change will add support for interactively setting property values. A major part of this change includes improvements to the type-safety of the client admin APIs (e.g. use of raw types), which were being flagged in the latest version of Eclipse (apologies: I should have committed these separately, but they got too tangled up in this change).

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.

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)

Fix issue 1736: add default values for java-implementation-class properties This change adds default values for all java-implementation-class style properties where appropriate. These properties are usually defined in an abstract definition but have sensible default values in their sub-definitions. For example, the PasswordValidatorConfiguration definition defines a "validator-class" property which is mandatory but has no sensible default value. However, its derived definition DictionaryPasswordValidatorConfiguration does have a sensible default value for this property, DictionaryPasswordValidator, so this change adds a "property-override" to this sub-definition which defining this default value. Having default values defined for java-class type properties will make it much easier for administrators to create new configurations as they will no longer need to figure out which class is appropriate (they are still free to override the default with their own implementation if they wish).

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]

Various improvements and refactorings of the admin framework client API, including: * client API methods are much more specific about what sort of exceptions they can throw * new exceptions for wrapping underlying transport related error conditions (e.g. IO problems, authorization problems) * improved Javadoc generation for client APIs * pull-up AbstractPropertyDefinitionVisitor into PropertyDefinitionVisitor and improve type-safety of EnumPropertyDefinition visitor method * refactor the LDAP client implementation (remove LDAPChangeBuilder, introduce JNDI DirContext wrapper interface called LDAPConnection to make the client APIs more testable) * move various unit test classes out of the admin server-side unit tests so that they can be re-used by client unit tests * introduce "mock" client connections and property providers to facilitate testing of the admin client API * implement client API unit tests

Fix minor bug where required import statements were not being generated for relation definitions when defined in abstract managed object definitions.

Fix typo which prevented enumeration value Javadoc from being generated.

Fix for issue 1442. This change introduces a new style-sheet which generates en_US property files containing all the description elements from the XML configuration definitions. In order to expose these properties the admin framework APIs have been modified as follows: * managed object definitions o user friendly name o user friendly plural name o synopsis o description * property definitions o synopsis o description o unit description (for integer properties) o value descriptions (for enumeration properties) o pattern descriptions (for string properties). This is pretty much useless at the moment since the string property definition class does not support patterns (even though the XML schema does): issue 1523 o alias default behavior description * relation definitions o synopsis o description o user friendly name (usually the user friendly name of the referenced managed object) o user friendly plural name for one-to-many relations (usually the user friendly plural name of the referenced managed object) Since there is currently only weak API support for required admin actions (issue 1426), the admin action descriptions cannot be exposed through any API at this stage. For I18N, translators are expected to take the generated property files and translate them into localized versions.

Migrate the ExtendedOperationConfigManager to the new configuration framework.

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