org.forgerock / org.forgerock.opendj

10 Nov, 2009

1 commit

02 Feb, 2009

1 commit

31 Jan, 2009

1 commit

06 Jan, 2009

1 commit

18 Dec, 2008

1 commit

26 May, 2008

1 commit

  • bf8d765c   Fix for 3259: No messages support in example plugin ... Browse Dir » 
    Changes by file:

. resource/admin/example-plugin/ExamplePlugin.java
  - support for messages
  - fix for PluginResult.Startup refactoring

. resource/admin/example-plugin/example_plugin.properties
  - 3 messages used in the example plugin (english/default)

. resource/admin/example-plugin/example_plugin_fr.properties
  - 3 messages used in the example plugin (french)

. resource/admin/example-plugin/build.xml
  - automatic generation of messages from properties files located in
    resource/messages while keeping package name.
    (eg. resource/messages/my/example/example_plugin.properties will
    generate a message class with package name "my.example")

. resource/Messages.java.stub
  - forced underlying properties files to be located in /messages within
    jars file (eg MY_JAR_FILE:/messages/example_plugin.properties)
  - support for messages available from extensions' classloaders

. src/messages/src/org/opends/messages/Message.java
  - typo in javadoc

. build.xml
  - added message template used by generator in the build-tools.jar
  - added the "resource/messages" directory at the root of the example
    plugin
  - added example properties files in the example plugin zipfile

. src/build-tools/org/opends/build/tools/GenerateMessageFile.java
  - stopped assuming messages are targeted in package name
    org.opends.messages
  - template for message class generation now retrieved from the
    build-tools.jar when generating messages for extensions
  - for user messages, set destination files automatically based on the
    source full filename and apply basic pattern
    (eg. source=resource/messages/my/example/example_plugin.properties
    sets destination to
    src-generated/my/example/ExamplePluginMessage.java)


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

18 Mar, 2008

1 commit

06 Mar, 2008

1 commit

27 Feb, 2008

1 commit

  • 069eb677   For Configuration Reference generated doc: ... Browse Dir » 
    Added 2 new parameters (java properties) for M1 needs (1st one only):

OpendsWiki - The URL of the OpenDS Wiki
             (default is "https://www.opends.org/wiki")
OpendsHome - The URL of the OpenDS project Home page
             (default is "http://www.opends.org")

Usage:
In the M1 build target, add :
      <jvmarg value="-DOpendsWiki=https://www.opends.org/<M1 Wiki>"/>
 
Note that as a side effect, now all the html files are generated (index.html and maintop.html were not generated until now)





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

12 Feb, 2008

2 commits

08 Feb, 2008

2 commits

17 Jan, 2008

1 commit

14 Jan, 2008

2 commits

  • dd793810   Add support to admin framework for retrieving an i18n description of the constra… ... Browse Dir » 
    …ints 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.

git-svn-id: https://svn.forgerock.org/opendj/trunk@3669 41b1ffd8-f28e-4786-ab96-9950f0a78031
    matthew_swift
     
  • 5bd2e865   Partial fix for issue 2661 - public APIs must not reference private classes. ... Browse Dir » 
    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.


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

19 Dec, 2007

2 commits

  • 20353bca   Fix issue 2451 part #1: https://opends.dev.java.net/issues/show_bug.cgi?id=2451 ... Browse Dir » 
    It is now possible to override the default naming argument for dsconfig sub-commands using the CLI profile in the XML definitions. To do this add the "naming-argument-override" attribute to a relation's CLI profile relation element. For example:

 <adm:relation name="virtual-attribute">
   <adm:one-to-many />
   <adm:profile name="ldap">
     <ldap:rdn-sequence>
       cn=Virtual Attributes,cn=config
     </ldap:rdn-sequence>
   </adm:profile>
   <adm:profile name="cli">
     <cli:relation naming-argument-override="name">
       <cli:default-property name="enabled" />
       <cli:default-property name="attribute-type" />
     </cli:relation>
   </adm:profile>
 </adm:relation>


git-svn-id: https://svn.forgerock.org/opendj/trunk@3591 41b1ffd8-f28e-4786-ab96-9950f0a78031
    matthew_swift
     
  • 8559dade   Fix for issue 2446 part #1. ... Browse Dir » 
    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).



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

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