org.forgerock / org.forgerock.opendj

01 Feb, 2008

1 commit

30 Jan, 2008

1 commit

29 Jan, 2008

5 commits

24 Jan, 2008

1 commit

22 Jan, 2008

1 commit

21 Jan, 2008

2 commits

  • 69285b46   Doc review on identity mapper config doc ... Browse Dir » 
    git-svn-id: https://svn.forgerock.org/opendj/trunk@3711 41b1ffd8-f28e-4786-ab96-9950f0a78031
    lfrost
     
  • 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

4 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

08 Jan, 2008

1 commit

19 Dec, 2007

2 commits

17 Dec, 2007

1 commit

13 Dec, 2007

1 commit

08 Dec, 2007

1 commit

04 Dec, 2007

1 commit

02 Dec, 2007

1 commit

16 Nov, 2007

2 commits

  • edb0c4c5   Tag components as advanced or intended for customization. ... Browse Dir » 
    This relates to issue 1829.


git-svn-id: https://svn.forgerock.org/opendj/trunk@3462 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
     

13 Nov, 2007

1 commit

06 Nov, 2007

1 commit

  • 6eee8e2f   Fix for 2423 : remove some replication configuration parameters ... Browse Dir » 
    The attributes :
 ds-cfg-max-receive-queue,
 ds-cfg-max-receive-delay,
 ds-cfg-max-send-queue,
 ds-cfg-max-send-delay
 
were left from some prototyping I did a while ago and not usefull
for now.

I've therefore removed them from the configuration of the
Replication Domain.

  

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

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
     

19 Oct, 2007

1 commit

18 Oct, 2007

1 commit

  • cca8fa34   no issue ... Browse Dir » 
    CryptoManager
1. remove shared secret key wrapping transformation (ds-cfg-key-wrapping-transformation) from configuration
2. other miscellaneous cleanup, including adding TODOs with issue numbers for some recently opened issues.


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

17 Oct, 2007

1 commit

  • 845f11b5   no issue ... Browse Dir » 
    CryptoManager
RC4 -> RC4/NONE/NoPadding


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

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
     

10 Oct, 2007

1 commit

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