org.forgerock / org.forgerock.opendj

16 Nov, 2007

2 commits

  • 5fa5763c   Update admin framework and dsconfig to support tagging ... Browse Dir » 
    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.


git-svn-id: https://svn.forgerock.org/opendj/trunk@3460 41b1ffd8-f28e-4786-ab96-9950f0a78031
    matthew_swift
     
  • b3106d3b   Advanced properties phase 1: tag advanced properties and perform ... Browse Dir » 
    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.


git-svn-id: https://svn.forgerock.org/opendj/trunk@3456 41b1ffd8-f28e-4786-ab96-9950f0a78031
    matthew_swift
     

28 Sep, 2007

1 commit

27 Sep, 2007

1 commit

  • c40a66ed   Improvements to aggregation support and foundation work for expressing arbitrary… ... Browse Dir » 
    … 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.


git-svn-id: https://svn.forgerock.org/opendj/trunk@3229 41b1ffd8-f28e-4786-ab96-9950f0a78031
    matthew_swift
     

26 Sep, 2007

2 commits

25 Sep, 2007

1 commit

20 Sep, 2007

1 commit

18 Sep, 2007

1 commit

17 Sep, 2007

1 commit

  • 539109e2   Implement a new configuration definition called "TopCfgDefn" which acts as the p… ... Browse Dir » 
    …arent 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).

git-svn-id: https://svn.forgerock.org/opendj/trunk@3082 41b1ffd8-f28e-4786-ab96-9950f0a78031
    matthew_swift
     

15 Sep, 2007

1 commit

  • 1a7e885e   Performance improvements to server-side admin framework. ... Browse Dir » 
    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.


git-svn-id: https://svn.forgerock.org/opendj/trunk@3078 41b1ffd8-f28e-4786-ab96-9950f0a78031
    matthew_swift
     

14 Sep, 2007

3 commits

  • be7ddd41   Avoid managed object definition initialization dependency problems. Using featur… ... Browse Dir » 
    …es 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.


git-svn-id: https://svn.forgerock.org/opendj/trunk@3061 41b1ffd8-f28e-4786-ab96-9950f0a78031
    matthew_swift
     
  • da262bed   Modify the aggregation definition property stylesheet to generate two server-sid… ... Browse Dir » 
    …e getter methods for each aggregation property. The first is a "default" getter of the form:

    String getXXX()
    SortedSet<String> getXXX()

Where XXX is the name of the property. This getter follows the same pattern as all other property getters. In this case it returns a String (or set of Strings) containing the common name(s) of the referenced component(s).

The second server-side getter is of the form:

    DN getXXXDN()
    SortedSet<DN> getXXXDNs()

Where again XXX is the name of the property. This getter returns the distinguished name(s) associated with the referenced component(s). It is useful on the server-side where component implementations need to retrieve referenced implementations from a DirectoryServer table based on their DN.


git-svn-id: https://svn.forgerock.org/opendj/trunk@3060 41b1ffd8-f28e-4786-ab96-9950f0a78031
    matthew_swift
     
  • 65ff445e   Add support to the admin framework code generation scripts so that properties ca… ... Browse Dir » 
    …n define their own syntax specific getters and setters.

git-svn-id: https://svn.forgerock.org/opendj/trunk@3059 41b1ffd8-f28e-4786-ab96-9950f0a78031
    matthew_swift
     

13 Sep, 2007

1 commit

12 Sep, 2007

1 commit

10 Sep, 2007

1 commit

  • c6ff7b0f   Add support for password storage schemes using AES, 3DES, RC4, and Blowfish. ... Browse Dir » 
    The AES, RC4, and Blowfish implementations all use 128-bit ciphers, and the
3DES implementation uses a 168-bit cipher.

Note that while these password storage schemes are functional, they rely on the
crypto manager, which is not fully implemented.  The storage schemes are not
exposed in the server configuration because the crypto manager does not have
any mechanism to persist secret keys for symmetric encryption.  Until the
crypto manager provides persistence for these keys, passwords encoded using
these schemes will not be usable after the server is restarted.  Once the
crypto manager implementation is complete, these schemes should be exposed in
the server configuration.

OpenDS Issue Numbers:  315, 316, 317, 318


git-svn-id: https://svn.forgerock.org/opendj/trunk@3000 41b1ffd8-f28e-4786-ab96-9950f0a78031
    neil_a_wilson
     

06 Sep, 2007

2 commits

05 Sep, 2007

1 commit

  • 4d7b96b5   Partial fix for issue 1449: administration framework aggregation support ... Browse Dir » 
    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).



git-svn-id: https://svn.forgerock.org/opendj/trunk@2967 41b1ffd8-f28e-4786-ab96-9950f0a78031
    matthew_swift
     

02 Sep, 2007

1 commit

31 Aug, 2007

1 commit

  • 27113fd3   Create configuration definitions for "generic" objects in the server ... Browse Dir » 
    configuration.  This also includes allocating object classes for each of these
types.  This will help make it easier for users to create new instances of
these kinds of configuration objects because they will not need to know the
fully-qualified name of the Java class that implements the associated logic.


git-svn-id: https://svn.forgerock.org/opendj/trunk@2894 41b1ffd8-f28e-4786-ab96-9950f0a78031
    neil_a_wilson
     

30 Aug, 2007

1 commit

23 Aug, 2007

1 commit

  • 908a08a7   Add support for overriding the user friendly singlular and plural names of components. ... Browse Dir » 
    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".


git-svn-id: https://svn.forgerock.org/opendj/trunk@2751 41b1ffd8-f28e-4786-ab96-9950f0a78031
    matthew_swift
     

15 Aug, 2007

1 commit

  • 7b183900   This commit is a step toward getting OpenDS internationalized. There are still i… ... Browse Dir » 
    …ssues to be resolved before we can declare that we are internationalized but this commit covers the bulk of changes needed at this time.

In general this commit converts any string values that might potentially be shown to an end user (client or administrator) to a new class called Message.  This includes exception messages, error log messages, alert and email text, labels, and CLI output.  Message's main interface includes methods for rendering itself as a string in the default locale using toString() or a specified locale toString(Locale).  In addition to addressing localization, this would allow us to potentially support controls allowing clients to set a preferred locale for server communication or output log messages in different languages.  Message extends CharSequence so it can be used in some places where strings are currently used with not code change (e.g. writing to a buffer) as well as allowing messages to be composed of one another.

In order to create localized messages, instead of adding them to the *Messages.java class, you define them in the corresponding properties files.  In general the property file keys are used to derive the new messages severity, category, and ordinal.  There are directives that can be used in the properties file in order to avoid doing this however.  For instance all the properties files used internally include the 'global.category' directive at the top of the file that instructs the generator to make all the following message belong to a single category.  So for internal messages the property value key will be as follows:

   [SEVERITY]_[DESCRIPTION]_[ORDINAL]

See the properties files themselves for more information.

Once your messages are in the properties file you can use the ant target 'generatemessages' to create create MessageDescriptor objects that are referred to in the Java code.  In the code you might think of these objects as replacing the int-valued message IDs.  To create messages you call MessageDescriptor.get() which replaces MessageHandler.getMessage().  It might be helpful then to try to define your messages before referring to them in your code since until you run 'generatemessages' you won't have any Java-code with with to create your message objects.

In order to support non-localizable text in messages (host names, DN's, etc.) Message's can be created from String values by calling Message.raw(String).  In this way it is also possible to circumvent the intention of changing the APIs to use Message objects instead of Strings which is to support writing of localizable messages.  This method is currently used in the code as a crutch for areas of the code that need internationalization (tagged with a 'TODO: i18n' comment).  It might also be used by 3rd party developers that don't intend to localize their products.  However for internal use we should not be using this method to create Messages for text that is locale sensitive.

Additionally this code includes a MessageBuilder that can be used in much the same way that a StringBuilder can be used.  It has a method toMessage() that can be used to generate a message object when needed.  At this time this method just converts the buffer contents to a raw, unlocalizable message so this will need to addressed in the future.

Some other issues:

- While all of the unit tests pass after this commit, there may be issues in the code where we have no or minimal test coverage.  This includes much of the setup and GUI tools packages for which I have not done any testing but will begin after this commit.

- The new message related Java sources are contained in package org.opends.messages and organized in a new module src/module modeled somewhat after the admin module:

    src/messages/src (non-generated Java source files)
    src/messages/generated (generated source files)
    src/messages/messages (properties files for messages)

If you run the code from within your IDE you will have to mark all messages/src, messages/generated and messages as source directories.

- To generated the MessageDescriptor files you invoke the 'generatemessages' target.

- If you run the code from within your IDE you will probably ne

- This commit would change the plugin API.  Here are the changes caught by DirectoryServerPluginTestCase:

    doShutdown(String)->doShutdown(Message)

    doPostDisconnect(PostDisconnectPluginResult,ClientConnection,DisconnectReason,int,String) ->         doPostDisconnect(PostDisconnectPluginResult,ClientConnection,DisconnectReason,Message);

- This commit aligns the entire code-base behind the new Formatter class (printf style formattings like %s) as opposed to the older MessageFormat style (using curly braces for message arguments).  This allows us to provide more type safety for message arguments.  So for instance you can include a %c argument specifier in your format string and the MessageDescriptor will enforce specification of a Character as message creation time.

- Not all of the config framework has not been converted to use Messages.  Perhaps as some point we might have a 'message' syntax for locale-sensitive textural data.  I'm sure Matt will have ideas about this.

- In addition to Message, MessageDescriptor and MessageBuilder, the org.opends.server.message package includes enums for Category and Severity that replace the definitions formerly found in MessageHandler.

- The interface for the ErrorLogger has been simplified to allow logging of messages using a single Message parameter.  The severity and category of the message will be derived from the Message itself instead of specified as arguments when a message is logged.

- I will provide more documentation about this plumbing on the Wiki shortly.

- I will expand on the included tests soon.


git-svn-id: https://svn.forgerock.org/opendj/trunk@2641 41b1ffd8-f28e-4786-ab96-9950f0a78031
    kenneth_suter
     

27 Jul, 2007

1 commit

  • 7439e734   These set of changes implement VLV and filter capability to OpenDS: ... Browse Dir » 
    - A VLV index is defined by a name, base DN, search filter, search scope, sort order. A search request must match these parameters exactly to 
use the VLV index.
- A VLV index made up of the entry IDs matching the definition criteria (above) and the corresponding attribute values that are part of the sort 
order in the sort order. This information is broken up into blocks of sorted sets. The block size can be configured through admin framework. 
Default block size is 4000. In the database, the sorted set is stored with the following format:

      4 byte set size | entry IDs of 8 bytes each ... | attribute values of 16 bytes each ...

- Each sorted set is keyed by the entry ID and attribute values of the largest entry in the sorted set. A special comparator (VLVKeyComparator) 
is used to sort the keys in the database in the order of the specified sort order.
- When entries are added to the VLV index, its sort values are extracted and inserted into the sorted set whose key (also the largest entry in 
the set) is the smallest key that represents a entry that is greater or equal to the entry being inserted. If the sorted set exceeds the block 
size, it is divided in two and stored back into the database with the new key. In this implementation, a sorted set's key is never changed after 
it is created.
- On importing from LDIF, each entry's sort values and ID is written out to a intermediate file in order. These files are later merged and 
inserted into the database.
- Index rebuild and verify also works with VLV indexes. The verify job ensures that all the entries stored in the VLV index is in the correct 
order.
- With this implementation, once a VLV index is created, it can not be changed without a rebuild. The server will NOT warn the user if 
the index 
has changed offline. Until a rebuild is done, it can return incorrect results. This should be fixed later.
- Performance wise, modify, add, and delete performance will be degraded if the entry matches the indexing criteria. Searches not using the VLV 
index should not see any notable performance degradation. If the block size is set too big, there is a potential that a large number of updates 
will result in some JE lock timeouts since the few sorted sets are hotly contested. However, if the block size is too small, searches using the 
VLV control with offsets could be slow since there are more records to look through. This area need further investigation to determine the 
optimal default value.

Fix for issue 38


git-svn-id: https://svn.forgerock.org/opendj/trunk@2499 41b1ffd8-f28e-4786-ab96-9950f0a78031
    boli
     

26 Jul, 2007

1 commit

  • 88d86daf   Partial fix for issue 1831 - dsconfig interactive mode. ... Browse Dir » 
    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).


git-svn-id: https://svn.forgerock.org/opendj/trunk@2480 41b1ffd8-f28e-4786-ab96-9950f0a78031
    matthew_swift
     

23 Jul, 2007

2 commits

  • ce90ebb6   Fix issue 1819: add support for tagging properties as advanced. ... Browse Dir » 
    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.


git-svn-id: https://svn.forgerock.org/opendj/trunk@2457 41b1ffd8-f28e-4786-ab96-9950f0a78031
    matthew_swift
     
  • c6cba704   Improve documentation for property definition element "mandatory" attribute. ... Browse Dir » 
    git-svn-id: https://svn.forgerock.org/opendj/trunk@2453 41b1ffd8-f28e-4786-ab96-9950f0a78031
    matthew_swift
     

20 Jul, 2007

1 commit

  • 676e88e1   Fix issues 1966 and 1792. ... Browse Dir » 
    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.

git-svn-id: https://svn.forgerock.org/opendj/trunk@2444 41b1ffd8-f28e-4786-ab96-9950f0a78031
    matthew_swift
     

19 Jul, 2007

1 commit

  • d4c60353   Fix issues 1943 (unable to create je-index), 1996 (exception when creating compo… ... Browse Dir » 
    …nents 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.


git-svn-id: https://svn.forgerock.org/opendj/trunk@2434 41b1ffd8-f28e-4786-ab96-9950f0a78031
    matthew_swift
     

06 Jul, 2007

1 commit

15 Jun, 2007

1 commit

  • 8c91e0f4   Partial fix for issue 1426: improve support for required admin actions. ... Browse Dir » 
    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.


git-svn-id: https://svn.forgerock.org/opendj/trunk@2110 41b1ffd8-f28e-4786-ab96-9950f0a78031
    matthew_swift
     

13 Jun, 2007

1 commit

  • a9fc769d   Add support for tagging managed object definitions so that similar types of mana… ... Browse Dir » 
    …ged 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)


git-svn-id: https://svn.forgerock.org/opendj/trunk@2093 41b1ffd8-f28e-4786-ab96-9950f0a78031
    matthew_swift
     

11 Jun, 2007

2 commits

  • 3b0ebacb   Add a CLI profile for defining CLI related annotations to managed object and pro… ... Browse Dir » 
    …perty definitions. The CLI profile defines two annotations at the moment:

* the operand name which should be used in sub-command usage help to identify the names of managed objects being added, removed, modified, etc
* the list of properties which should be displayed by default in list-xxx sub-commands. For example, when listing connection handlers we can display a summary table that lists the "enabled", "listen-port", and "use-ssl" properties by default

Both of these annotations apply only to relation definitions. Existing relations have been updated to include these CLI annotations, although their content is subject to change if we decide that better operand names/default properties exist.

These annotations will be used in the forthcoming dsconfig CLI.

git-svn-id: https://svn.forgerock.org/opendj/trunk@2075 41b1ffd8-f28e-4786-ab96-9950f0a78031
    matthew_swift
     
  • ec4635e7   Add support for specifying a "usage" string for string based property definition… ... Browse Dir » 
    …s 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.


git-svn-id: https://svn.forgerock.org/opendj/trunk@2073 41b1ffd8-f28e-4786-ab96-9950f0a78031
    matthew_swift
     

30 May, 2007

2 commits

  • e2107b9b   Add default plugin-class to example-plugin. ... Browse Dir » 
    git-svn-id: https://svn.forgerock.org/opendj/trunk@1977 41b1ffd8-f28e-4786-ab96-9950f0a78031
    matthew_swift
     
  • a49181bf   Fix issue 1736: add default values for java-implementation-class properties ... Browse Dir » 
    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).

git-svn-id: https://svn.forgerock.org/opendj/trunk@1976 41b1ffd8-f28e-4786-ab96-9950f0a78031
    matthew_swift
     

29 May, 2007

1 commit

  • 4cb23fdd   Fix issue 1580: support overriding of property default values. ... Browse Dir » 
    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.


git-svn-id: https://svn.forgerock.org/opendj/trunk@1969 41b1ffd8-f28e-4786-ab96-9950f0a78031
    matthew_swift
     

28 May, 2007

1 commit

  • 7b92b893   Fix the following issues: ... Browse Dir » 
    * 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]


git-svn-id: https://svn.forgerock.org/opendj/trunk@1960 41b1ffd8-f28e-4786-ab96-9950f0a78031
    matthew_swift