25 Apr, 2007

3 commits


24 Apr, 2007

3 commits

  • - Narrow down the set of packages that external developers will need to access
      in order to write a plugin or other type of extension.  Hopefully, for most
      things developers will only need to interact with the following packages (and
      their sub-packages):
      * org.opends.server.admin
      * org.opends.server.api
      * org.opends.server.config
      * org.opends.server.protocols.internal
      * org.opends.server.types
      * org.opends.server.util
    
    - As part of the attempted narrowing of packages that external developers need
      to access, I have moved the org.opends.server.core.Operation and
      org.opends.server.protocols.ldap.LDAPException classes to the
      org.opends.server.types package.  I have also created
      org.opends.server.types.RawAttribute to wrap the
      org.opends.server.protocols.ldap.LDAPAttribute class, and
      org.opends.server.types.RawModification to wrap the
      org.opends.server.protocols.ldap.LDAPModification class.
    
    - I have updated the internal operations API to add a few new convenience
      methods when performing internal operations.
    
    - I have updated all of our message strings so that none of them end in periods
      (except those that end with an ellipsis).  This will help us avoid the
      problem in which we see multiple periods due to embedding one message in
      another.
    
    - I have moved a message file from a synchronizaiton package to the messages
      package and resolved conflicts with existing message IDs.
    
    - I have updated a number of cases in which
      StaticUtils.stackTraceToSingleLineString() was used in client-facing code to
      replace those calls with StaticUtils.getExceptionMessage() instead.  This
      should provide a more user-friendly message that will hopefully not reduce
      our ability to debug problems that may arise.
    
    - I have cleaned up some of the code in the org.opends.server.api package so
      that all of the classes use consistent formatting, and to fix a couple of
      potential Javadoc problems.
    
    - I have moved the build-tools/src directory to src/build-tools to be more
      consistent with other components of the server.
    
    - I have updated the build script so that the xslt task will no longer dump
      lots of output to the terminal when generating code.  I have also gotten rid
      of warnings about run.classpath not being set properly.
    
    
    git-svn-id: https://svn.forgerock.org/opendj/trunk@1695 41b1ffd8-f28e-4786-ab96-9950f0a78031
    neil_a_wilson
     
  • git-svn-id: https://svn.forgerock.org/opendj/trunk@1690 41b1ffd8-f28e-4786-ab96-9950f0a78031
    lutoff
     
  • …discovered when specifying some duration based properties:
    
       * duration and size units had to be specified in default behaviors
    
       * upper/lower limit had to be specified without a unit and with
         values in the property's base unit (bytes for size properties)
    
    This change enables us to specify duration and size property constraints and defaults with or without units (when no unit is specified we default to the property's base unit).
    
    The Duration{Unit|PropertyDefinition} APIs have also been re-aligned with the Size{Unit|PropertyDefinition} APIs where possible and the unit tests updated (incl. replacing many bad uses of the assert keyword with the assertEquals TestNG method).
    
    git-svn-id: https://svn.forgerock.org/opendj/trunk@1689 41b1ffd8-f28e-4786-ab96-9950f0a78031
    matthew_swift
     

23 Apr, 2007

5 commits


20 Apr, 2007

3 commits


19 Apr, 2007

1 commit

  • 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.
    
    
    
    git-svn-id: https://svn.forgerock.org/opendj/trunk@1658 41b1ffd8-f28e-4786-ab96-9950f0a78031
    matthew_swift
     

18 Apr, 2007

4 commits


17 Apr, 2007

5 commits


16 Apr, 2007

2 commits


13 Apr, 2007

2 commits


12 Apr, 2007

2 commits


11 Apr, 2007

3 commits


10 Apr, 2007

4 commits

  • - Issue #338:  Prevent users from selecting a password that matches the value
      of any attribute (or a specified set of attributes) in that user's entry.
    
    - Issue #341:  Prevent users from selecting a password that matches a value
      contained in a dictionary.
    
    Both validators support both forward and reverse matching, and for the
    dictionary password validator I have compiled a dictionary from public domain
    word lists.
    
    
    git-svn-id: https://svn.forgerock.org/opendj/trunk@1611 41b1ffd8-f28e-4786-ab96-9950f0a78031
    neil_a_wilson
     
  • git-svn-id: https://svn.forgerock.org/opendj/trunk@1608 41b1ffd8-f28e-4786-ab96-9950f0a78031
    dugan
     
  • - Index rebuilding capabilities. All indexes including system and attribute indexes can 
    be rebuilt. Each index will be rebuilt by a seperate thread to increase performance. A 
    max number of rebuild threads could be set to limit the resources used by large rebuild 
    jobs. Partial rebuilds of attribute indexes could also be done by specifying the 
    attribute index type after the attribute type (ie. sn.approximate).
    - Index rebuilding standalone tool. Rebuilding of attribute indexes could be done with 
    the backend online. However, rebuilds including system indexes must be done with the 
    backend offline.
    - Index rebuilding task. Rebuilding of attribute indexes are done with the backend 
    online. Rebuilds that include system indexes will be performed after bring the backend 
    offline. The user must have index-rebuild privilages to rebuild indexes.
    - Approxitae indexing capability. The value of the attribute will be normalized using 
    the approximate maching rule of that attribute type. This is used as the key for the 
    index. Approximate indexes are fully supported by the index verify, rebuild, and import 
    jobs.
    - Fixed bug in build.xml where weave is enabled even if a test.* property is set.
    - Consolidated some common tool messages.
    - Consolidated some JE backend methods common to all tools.
    - Added unit tests for rebuild job and approximate indexes.
    
    Fix for issues 35, 39, 40, 41
    
    
    git-svn-id: https://svn.forgerock.org/opendj/trunk@1607 41b1ffd8-f28e-4786-ab96-9950f0a78031
    boli
     
  • they depended on attribute types being defined in the server schema.
    
    
    git-svn-id: https://svn.forgerock.org/opendj/trunk@1605 41b1ffd8-f28e-4786-ab96-9950f0a78031
    neil_a_wilson
     

09 Apr, 2007

3 commits