<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="/source/rss.xsl.xml"?>
<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/">
<channel>
    <title>Changes in ldapmodify</title>
    <link>http://src.iws.cs.ovgu.de/source/rss/forgerock/opendj2/resource/bin/ldapmodify</link>
    <description></description>
    <language>en</language>
    <copyright>Copyright 2005</copyright>
    <generator>Java</generator>
    <item>
        <title>Fix for OPENDJ-222 : Renamed environment variables to OPENDJ_...
    Updated scripts so that if OPENDJ_JAVA_HOME and OPENDJ_JAVA_ARGS are not defined, we look at the legacy OPENDS_... ones.</title>
        <description>/forgerock/opendj2/resource/bin/ldapmodify - 0f8553e2af5fc49a510ecfcfc93e66d06713f631</description>
        <pubDate></pubDate>
        <dc:creator>ludo</dc:creator>
    </item>

    <item>
        <title>Updated the copyright statement to reflect that Sun owns the full copyright on the project files.</title>
        <description>/forgerock/opendj2/resource/bin/ldapmodify - a3d3ab94806056d2355afea6fe8daac41059b9fb</description>
        <pubDate></pubDate>
        <dc:creator>ludovicp</dc:creator>
    </item>

    <item>
        <title>2730: New - The setup command should perform some basic memory tuning
    Note: this issue is not fully covered by the proposed modifications but
    all that is missing in order to fix it is to figure out which are the
    default memory values that we want to propose in the setup.
    
    2620: Server should be started as server JRE and clients should be
    started as client JREs
    
    The proposed solution goes beyond fixing the two issues and proposes a
    manner for the user to set specific java arguments (and use a specific
    JVM) for every command-line.
    
    Today the user can specify the JVM to be used using the OPENDS_JAVA_HOME
    environment variable and the java arguments by using the
    OPENDS_JAVA_ARGS environment variable.  In the case of the JVM this
    covers most of the use cases (in general we will use the same JVM for
    all the command-lines).  However this is quite limiting in the case of
    the java arguments we pass.  For instance in general we want to run the
    server (start-ds command-line) using the server mode of the JVM but
    other command-lines using the -client mode of the JVM.  In the same
    manner we might want to have a bigger heap when running the server than
    when we are running a "lightweight" utility as dsconfig.
    
    The proposed solution is to have a properties file called
    java.properties where the user specifies the different JVM and java
    arguments to be used for every command-line.  Once the user has edited
    this properties file, (s)he must run a command-line called
    dsjavaproperties that will update all the scripts to use the arguments
    specified in that properties file.
    
    NOTE: there are a number of command-lines (import-ldif, export-ldif,
    backup, restore) where the user will be able to specify different java
    arguments (and different JVM) to use depending on whether the
    command-line is run in online or offline modes.  You can see the
    comments on java.properties to get more information about this and in
    general about the different properties that can be set.
    
    The modification in the setup basically try to check if the JVM that is
    being used to run the setup (the one that will be used by default)
    supports the -client and -server options.  Depending on the results of
    these checks the setup will update the java.properties file and then run
    dsjavaproperties to update the scripts.</title>
        <description>/forgerock/opendj2/resource/bin/ldapmodify - 27f8adec83293fb8bd3bfa37175322b0ee3bb933</description>
        <pubDate></pubDate>
        <dc:creator>jvergara</dc:creator>
    </item>

    <item>
        <title>Complete fix for 1252 restrict installed bin files to relevant platform.
    
    The bat files are only under 'bat' directory and some function scripts that are not targetted to be used by the user (_server-script, _client-script, etc.) have been moved now to lib.</title>
        <description>/forgerock/opendj2/resource/bin/ldapmodify - 9da44d3de0a7180285a77b7e8d2426a72aca249e</description>
        <pubDate></pubDate>
        <dc:creator>jvergara</dc:creator>
    </item>

    <item>
        <title>Update all CDDL headers in source files to remove a typo.</title>
        <description>/forgerock/opendj2/resource/bin/ldapmodify - f71f7a61dec7c9089378d14493ad564a1dedf0b5</description>
        <pubDate></pubDate>
        <dc:creator>neil_a_wilson</dc:creator>
    </item>

    <item>
        <title>Make a number of changes to administrative tools provided with OpenDS.  These
    are all made under the umbrella of issue #994, but there are individual issues
    for each change.
    
    - Issue #979 -- Re-order LDAP tool arguments
      When displaying usage information for many of the LDAP tools (e.g.,
      ldapsearch, ldapmodify, etc.), the arguments were not provided in any kind of
      logical grouping.  This has been corrected so that the arguments are listed
      in a more logical ordering.
    
    - Issue #983 -- Add tool description to argument parser
      When displaying usage information for administrative tools, it now includes a
      small summary of what the tool does at the top of the argument list.
    
    - Issue #984 -- Make tool usage more compact
      Previously, the tool usage included a blank line between each argument, which
      made the usage information seem too verbose, especially for tools like
      ldapsearch with a lot of arguments.  This extra space has been removed.
      Also, many of the argument descriptions have been rewritten in an attempt to
      avoid requiring multiple lines.
    
    - Issue #985 -- Wrap long output in administrative tools when appropriate
      Update most of the output for the administrative tools so that it is easier
      to read on 80-column displays.  This primarily impacts error message, and
      cases in which the format of the output is important (e.g., LDIF output from
      ldapsearch) no changes were made.
    
    - Issue #986 -- Eliminate hard-coded strings in tools
      Some of the tools had hard-coded strings used for error and warning messages.
      They have been replaced with localizeable output from the messages files.
    
    - Issue #990 -- LDAP tools don't use trust store password
      The LDAP tools didn't provide any mechanism for specifying the PIN needed to
      access the contents of an SSL trust store.  Some types of trust stores may
      require a PIN to access them, so it is now possible to either directly
      specify the PIN or to provide the path to a PIN file.
    
    - Issue #991 -- Disconnect when running stop-ds shouldn't be an error
      When using the stop-ds script, if the server began shutting down before it
      returned a response to the client, the client would provide an error message
      making it sound like something went wrong.  The output has now been updated
      to indicate that the server is likely in the course of shutting down.
    
    - Issue #992 -- Tool usage should include the tool name rather than the class
      When displaying usage information for the administrative tools, the
      fully-qualified class name for the Java class was displayed, where the name
      of the shell script or batch file would have been more useful.</title>
        <description>/forgerock/opendj2/resource/bin/ldapmodify - 266c5071a91fda6a5159b08ea8d45261228d03d5</description>
        <pubDate></pubDate>
        <dc:creator>neil_a_wilson</dc:creator>
    </item>

    <item>
        <title>added extensionless shell scripts</title>
        <description>/forgerock/opendj2/resource/bin/ldapmodify - 4edb61f8b0f8ce9f62d803c706612376498672b4</description>
        <pubDate></pubDate>
        <dc:creator>al_xipe</dc:creator>
    </item>

</channel>
</rss>

