26 Oct, 2009

5 commits


23 Oct, 2009

2 commits


22 Oct, 2009

4 commits

  • git-svn-id: https://svn.forgerock.org/opendj/trunk@6027 41b1ffd8-f28e-4786-ab96-9950f0a78031
    dugan
     
  • git-svn-id: https://svn.forgerock.org/opendj/trunk@6025 41b1ffd8-f28e-4786-ab96-9950f0a78031
    pgamba
     
  • … with SSL and multiple threads.)
    
    This fix has two parts:
    
    1. Modify the threading mechanism used to search the contents of an entry.  From now only one thread is created to do this task.  The result is that there is no need of interrupting threads and that the number of threads that are generated is limited.
    
    2. When the server contents are read, check also if the user connection (the one used by the LDAP browser to read user data) works.  If it is not the case, a message informing the user to provide authentication is displayed.  This modification helps in the case we encounter other issues and does not force the user to reopen the control panel dialog (or to figure out that the workaround is to go to 'File->Server to Administer'.
    
    This check is already done for the admin connection, so this is just a completion of that check.
    
    
    git-svn-id: https://svn.forgerock.org/opendj/trunk@6023 41b1ffd8-f28e-4786-ab96-9950f0a78031
    jvergara
     
  • When the rawEntryDN of a CompareOperationBasis is modified, the field entryDN is
    reset and not initialized. If the getEntryDN() routine is called and entryDN is
    null, it should try to decode the rawEntryDN.
    
    
    git-svn-id: https://svn.forgerock.org/opendj/trunk@6022 41b1ffd8-f28e-4786-ab96-9950f0a78031
    floblanc
     

21 Oct, 2009

2 commits


20 Oct, 2009

4 commits


19 Oct, 2009

6 commits


17 Oct, 2009

1 commit

  • The biggest issue was that the trust manager was reset when connecting to the second server, this caused the establishing of the connections to fail.
    
    There was also a problem with the way the code found out whether a NamingException was caused by a certificate problem or not.
    
    Finally the code handles the particular case where the user provides global administrator credentials but this is not defined on the second server.  If this is the case, the code now prompts only for the credentials (and not for the whole second server connection parameters).
    
    
    git-svn-id: https://svn.forgerock.org/opendj/trunk@5998 41b1ffd8-f28e-4786-ab96-9950f0a78031
    jvergara
     

16 Oct, 2009

4 commits

  • git-svn-id: https://svn.forgerock.org/opendj/trunk@5996 41b1ffd8-f28e-4786-ab96-9950f0a78031
    dugan
     
  • …control systematically)
    
    Add two menu items in the 'View' menu of the browse entries panel where the user can specify to sort the user data and to follow referrals automatically.  The request control are updated depending on what the user chooses and these request controls that are used are not critical.
    
    
    git-svn-id: https://svn.forgerock.org/opendj/trunk@5995 41b1ffd8-f28e-4786-ab96-9950f0a78031
    jvergara
     
  • This issue happens when a new OpenDS server is added to a topology which has been up and
    running for some time and the new server is both a Replication Server and a Directory Server.
    
    In such cases the Replication Server starts empty and is therefore very late with regards to
    the other servers.
    The Directory Server is initialized from an up to date DS already in the topology and is therefore
    not late.
    
    The problem is that the new DS incorrectly choose the RS that was just installed to be provided
    with all the new changes in the topology.
    
    The DS therefore as to wait for the RS to grab all the old changes before being provided with the
    new change.
    
    The fix is to change the algorithm that is used by the DS to select the RS and to give priority
    to the RS that are more up to date.
    
    Gary would like to see this in the 2.2 branch and would therefore have to be back-ported there.
    
    I have also added unit tests for this case and other similar ones.
    replica DS after init
    
    git-svn-id: https://svn.forgerock.org/opendj/trunk@5993 41b1ffd8-f28e-4786-ab96-9950f0a78031
    gbellato
     
  • …e of the dialog and the component that must be used as a reference to display the dialog.
    
    In some cases the frame that is going to display the progress dialog is hidden just after the progress dialog is displayed (this is the case for most of the cases in the control panel).  Depending on the OS, hiding the parent frame implies to hide the progress dialog.  The result is that the progress dialog is also hidden with the parent frame.  However in other cases it is interesting to pass the frame that displays the progress dialog (for instance when we want to have a modal progress dialog this is required).
    
    
    git-svn-id: https://svn.forgerock.org/opendj/trunk@5992 41b1ffd8-f28e-4786-ab96-9950f0a78031
    jvergara
     

15 Oct, 2009

3 commits


14 Oct, 2009

2 commits

  • git-svn-id: https://svn.forgerock.org/opendj/trunk@5984 41b1ffd8-f28e-4786-ab96-9950f0a78031
    dugan
     
  • The problem was that the code had a hardcoded list of editable operational attributes.  The code has been modified to calculate this list from the schema contents.
    
    The code has also been updated to use some special Strings ("1.1" and "+") to request no attributes and operational attributes.
    
    Some generics have been used to avoid some warnings reported by my IDE.
    
    
    git-svn-id: https://svn.forgerock.org/opendj/trunk@5980 41b1ffd8-f28e-4786-ab96-9950f0a78031
    jvergara
     

13 Oct, 2009

7 commits