org.forgerock / org.forgerock.opendj

05 Feb, 2008

1 commit

  • 18a5f38d   Fix for issue 2902 (stop-ds -R restarts the server with client tool JVM) ... Browse Dir » 
    When the java properties are set to not overwrite the environment variables (which is the default behavior) when we call start-ds from the stop-ds scripts, OPENDS_JAVA_ARGS is already set with the arguments for the stop (client arguments).  The fix consists basically on resetting the environment variables to those we had before calling stop-ds before calling start-ds.


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

22 Jan, 2008

1 commit

21 Jan, 2008

1 commit

  • 5c98ae82   Fix issues 2831 and 1948. ... Browse Dir » 
    Change local DB backend configuration so that db-directory and import-temp-directory properties now name a parent directory within which a sub-directory is created having the same name as the backend-id. This simplifies configuration and reduces the risk of name collisions.

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

18 Jan, 2008

2 commits

17 Jan, 2008

2 commits

16 Jan, 2008

1 commit

  • 19ee981f   This fix removes the option to use nanosecond etime resolution as a JVM property… ... Browse Dir » 
    …. It is now a global configuration attribute. Due to the 10% throughput decrease I saw when using System.nanoTime, the default still uses System.currentTimeMillis to timestamp operations. System.nanoTime will only be used when the ds-cfg-etime-resolution attribute is set to nano-seconds.

Fix for issue 2499


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

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
     

10 Jan, 2008

1 commit

  • b559735f   Fixes for : ... Browse Dir » 
    2786 : DSML Gateway misses saaj jars
2774 : DSML gateway war file contains many unnecessary files



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

08 Jan, 2008

1 commit

04 Jan, 2008

1 commit

03 Jan, 2008

3 commits

21 Dec, 2007

2 commits

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
     

17 Dec, 2007

3 commits

  • 35263763   Fix global ACI mistakenly removed. ... Browse Dir » 
    git-svn-id: https://svn.forgerock.org/opendj/trunk@3578 41b1ffd8-f28e-4786-ab96-9950f0a78031
    dugan
     
  • 21b1a3fb   Add objectclass attribute to schema attributes. Issue 2759. ... Browse Dir » 
    git-svn-id: https://svn.forgerock.org/opendj/trunk@3576 41b1ffd8-f28e-4786-ab96-9950f0a78031
    dugan
     
  • b5ad1173   2730: New - The setup command should perform some basic memory tuning ... Browse Dir » 
    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. 


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

14 Dec, 2007

1 commit

08 Dec, 2007

1 commit

07 Dec, 2007

1 commit

  • 8cfaab0f   This relates to issue 2661 "public APIs must not reference private classes". ... Browse Dir » 
    The classes in org.opends.messages need to be made public so that they can be referenced from other public APIs. This change adds the PublicAPI annotation to the classes defined in this package as follows:

   * the org.opends.messages package is VOLATILE

   * the org.opends.messages core classes (Message, MessageDescriptor,
     MessageBuilder, Category, and Severity) are all UNCOMMITTED

   * the class org.opends.messages.MessageDescriptorRegistry is PRIVATE
     (it's only used in unit tests)

   * generated message classes are PRIVATE

In addition minor cleanup was made to the classes where appropriate to make them suitable for public APIs:

   * used "final" where possible

   * reduced visibility of classes, methods, and members where appropriate

   * fixed some potential bugs spotted during this clean-up: class
     members not being initialized (the "final" keyword is useful for
     spotting this!)

   * added missing javadoc
   
   * I've removed the third-party and user-defined message generation
     since we could see know way in which they could be easily used
     without impacting core OpenDS source


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

05 Dec, 2007

1 commit

02 Dec, 2007

1 commit

30 Nov, 2007

1 commit

  • 4f1e54bd   Fix 2319 - protect acces to dc=replicationChanges by default ... Browse Dir » 
    Description
dc=replicationChanges is enabled by default on all the replication servers
and show all the modifications done on all replicated suffixes.
It may therefore contain sensitive information and should be available only
administrators.

Fix
This is fixed by a global ACI on the "dc=replicationChanges" suffix denying all ops for all users. Only "directory manager" can access to the changes by default or change the ACI.
Unit test written and passed successfully individually but set disabled because it fails when ran as part of the whole suite (issue 1569 to be addressed asap).



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

29 Nov, 2007

2 commits

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
     

14 Nov, 2007

1 commit

06 Nov, 2007

1 commit

02 Nov, 2007

2 commits

30 Oct, 2007

1 commit

  • ee0ceaa1   s set of files provides the workflow configuration manual mode. ... Browse Dir » 
    Until now, the workflows were automatically configured-a wokflow
was created for each base DN in the backends. When new suffixes
were added or when a backend was added, the associated workflows
were also created (and simillarly workflows were deleted as suffixes
or backends were removed).

With the manual mode, each and every workflow in the server must
be defined explicitely in the configuration. By default, the server is
running in automatic configuration mode. To have a server running
with manual configuration mode one must set the attribute in
cn=config:

    dn: cn=config
    ...
    ds-cfg-workflow-configuration-mode: auto|manual


No attribute means "auto" mode.

The workflow configuration consist of 3 parts:
- the configuration of workfow elements
- the configuration of workfows
- the configuration of network groups


The Workflow Elements - A workflow element is a basic task in a
workflow. The workflow elements are organized in trees and the
simplest tree is made of one element. For example, the workflow
element that wraps a local backend is configured as follow:

    dn: ds-cfg-workflow-element-id=userRoot,cn=workflow elements,cn=config
    objectClass: top
    objectClass: ds-cfg-workflow-element
    objectClass: ds-cfg-local-backend-workflow-element
    ds-cfg-workflow-element-id: userRoot
    ds-cfg-enabled: true
    ds-cfg-java-class: org.opends.server.workflowelement.localbackend.LocalBackendWorkflowElement
    ds-cfg-backend: ds-cfg-backend-id=userRoot,cn=Backends,cn=config

From an admin standpoint, the local backend workflow element
is an aggregation of a single backend (attribute ds-cfg-backend).
So we cannot disable/delete a backend as long as it is used by a
local backend workflow element.


The Workflows - A workflow is a chain of processing and it's
targeting all the entries under a given baseDN. The processing
is actually identified by the root node of the task tree described
above. The configuration of a workflow looks like:

    dn: ds-cfg-workflow-id=userRoot,cn=workflows,cn=config
    objectClass: top
    objectClass: ds-cfg-workflow
    ds-cfg-workflow-id: userRoot
    ds-cfg-enabled: true
    ds-cfg-workflow-element: ds-cfg-workflow-element-id=userRoot,cn=workflow elements,cn=config
    ds-cfg-base-dn:  dc=example,dc=com

From an admin standpoint, the local workflow is an aggregation
of a single elements (attribute ds-cfg-workflow-element).
So we cannot disable/delete a workflow element as long as it is used
by a local workflow.


The Network Groups - A network group defines categories for
client connection. The network group contains a set of workflows
and each client operation is routed to one (or more) workflow(s).
By default, the server create a default network group which contains
all the workflows defined in the server. The default network group
looks like:

    dn: ds-cfg-id=defaultNetworkGroup2,cn=network groups,cn=config
    objectClass: top
    objectClass: ds-cfg-network-group
    ds-cfg-id: defaultNetworkGroup2
    ds-cfg-enabled: true
    ds-cfg-workflow: ds-cfg-workflow-id=adminRoot,cn=Workflows,cn=config
    ds-cfg-workflow: ds-cfg-workflow-id=ads-truststore,cn=Workflows,cn=config
    ds-cfg-workflow: ds-cfg-workflow-id=backup,cn=Workflows,cn=config
    ds-cfg-workflow: ds-cfg-workflow-id=config,cn=Workflows,cn=config
    ds-cfg-workflow: ds-cfg-workflow-id=monitor,cn=Workflows,cn=config
    ds-cfg-workflow: ds-cfg-workflow-id=schema,cn=Workflows,cn=config
    ds-cfg-workflow: ds-cfg-workflow-id=tasks,cn=Workflows,cn=config
    ds-cfg-workflow: ds-cfg-workflow-id=userRoot,cn=Workflows,cn=config

From an admin standpoint, the network group is an aggregation
of several workflows (attribute ds-cfg-workflow). So we cannot
disable/delete a workflow as long as it is used by a network group.


A unit test named WorkflowConfigurationTest tests the configuration
of network groups, workflows and workflow elements.



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

23 Oct, 2007

1 commit

  • 338c53a5   Fix for issue 2505 (Provide monitoring information about the number of entries on a given base DN) ... Browse Dir » 
    The following changes are aimed to include a new attribute in the backend monitor entry to provide the number or entries per base DN. This information is used by the status, status-panel, dsreplication and graphical setup to be able to display the number of entries under a given base DN even when there are several base DNs defined in the same database.

The way the new attribute appears in the monitoring entry is:

ldapsearch -w s -p 1389 -b cn=monitor ds-backend-id=userRoot ds-base-dn-entry-countdn: cn=userRoot Backend,cn=monitor
ds-base-dn-entry-count: 0 dc=ta
ds-base-dn-entry-count: 1 dc=ti
ds-base-dn-entry-count: 1 dc=to

I prefer this approach because in my opinion having the number of entries is more important that the suffix.  Anyway I think the discussion around the structure of the value is not crucial as long as the value is easy to parse (which is the case).

The new attribute is defined in the schema and the new OID assigned to it is 1.3.6.1.4.1.26027.1.1.434.

In order to have a minimum impact on performances, the method backend.numSubordinates is only called when there are several base DNs defined in the database.





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

13 Oct, 2007

1 commit

  • 4d0792f3   No issue. ... Browse Dir » 
    CryptoManager
Step 1 to factor a CryptoManager interface from the implementation.


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