Announcement Announcement Module
Collapse
No announcement yet.
Problem with unbind Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Problem with unbind

    Hi!

    I am trying to delete an entry in my LDAP Directory using ldaptemplate.unbind (name dn) method, the DN value of the entry contains the character "@" and I got the error "LDAP: error code 65 - Object Class Violation"

    I deleted the same entry from command line with the command:
    idsldapdelete -D xxxx -w xxxx "tc=abc@4444444444, o=sg, c=MX"
    and it was successful.

    I tested the same with JNDI and it was successful too.

    Too I tested with an entry without "@" and it was successful so I think the problem is the character "@".

    I will glade if somebody help me.

  • #2
    We'll need some more information, i.e. actual code snippet and full stack trace in order to analyze this problem.

    Comment


    • #3
      Hi!

      This is the actual code snippet:
      Code:
      public void delete(TProfileDto tProfileDto) {
         ldapTemplate.unbind(buildDn(tProfileDto.getTC()));
       }
      
      private Name buildDn(String tAccount) {
         DistinguishedName dn = null;
         dn = new DistinguishedName();
         dn.add("tc", tAccount);
         return dn;
      }
      and the stack trace is:

      [LDAP: error code 65 - Object Class Violation]; nested exception is javax.naming.directory.SchemaViolationException: [LDAP: error code 65 - Object Class Violation]; remaining name 'tc=s@4422385758'

      I tested other operations like: add, update and search with the same DN value ant they were successful only delete was wrong.

      Thanks

      Comment


      • #4
        I'm sorry, this is the full stack trace
        Code:
        Exception: [LDAP: error code 65 - Object Class Violation]; nested exception is javax.naming.directory.SchemaViolationException: [LDAP: error code 65 - Object Class Violation]; remaining name 'tc=s@4422385759'
        
        org.springframework.ldap.SchemaViolationException: [LDAP: error code 65 - Object Class Violation]; nested exception is javax.naming.directory.SchemaViolationException: [LDAP: error code 65 - Object Class Violation]; remaining name 'tc=s@4422385759'
        
        Caused by: javax.naming.directory.SchemaViolationException: [LDAP: error code 65 - Object Class Violation]; remaining name 'tc=s@4422385759'
        
              at com.sun.jndi.ldap.LdapCtx.mapErrorCode(LdapCtx.java:3016)
        
              at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2931)
        
              at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2737)
        
              at com.sun.jndi.ldap.LdapCtx.c_rename(LdapCtx.java:685)
        
              at com.sun.jndi.toolkit.ctx.ComponentContext.p_rename(ComponentContext.java:693)
        
              at com.sun.jndi.toolkit.ctx.PartialCompositeContext.rename(PartialCompositeContext.java:251)
        
              at javax.naming.InitialContext.rename(InitialContext.java:389)
        
              at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        
              at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        
              at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        
              at java.lang.reflect.Method.invoke(Method.java:585)
        
              at org.springframework.ldap.transaction.compensating.LdapCompensatingTransactionOperationFactory$NonClosingDirContextInvocationHandler.invoke(LdapCompensatingTransactionOperationFactory.java:196)
        
              at $Proxy0.rename(Unknown Source)
        
              at org.springframework.ldap.core.LdapTemplate$29.executeWithContext(LdapTemplate.java:1153)
        
              at org.springframework.ldap.core.LdapTemplate.executeWithContext(LdapTemplate.java:775)
        
              at org.springframework.ldap.core.LdapTemplate.executeReadWrite(LdapTemplate.java:770)
        
              at org.springframework.ldap.core.LdapTemplate.rename(LdapTemplate.java:1150)
        
              at org.springframework.ldap.transaction.compensating.UnbindOperationExecutor.performOperation(UnbindOperationExecutor.java:103)
        
              at org.springframework.transaction.compensating.support.DefaultCompensatingTransactionOperationManager.performOperation(DefaultCompensatingTransactionOperationManager.java:71)
        
              at org.springframework.transaction.compensating.support.CompensatingTransactionUtils.performOperation(CompensatingTransactionUtils.java:47)
        
              at org.springframework.ldap.transaction.compensating.manager.TransactionAwareDirContextInvocationHandler.invoke(TransactionAwareDirContextInvocationHandler.java:88)
        
              at $Proxy0.unbind(Unknown Source)
        
              at org.springframework.ldap.core.LdapTemplate$23.executeWithContext(LdapTemplate.java:1040)
        
              at org.springframework.ldap.core.LdapTemplate.executeWithContext(LdapTemplate.java:775)
        
              at org.springframework.ldap.core.LdapTemplate.executeReadWrite(LdapTemplate.java:770)
        
              at org.springframework.ldap.core.LdapTemplate.doUnbind(LdapTemplate.java:1037)
        
              at org.springframework.ldap.core.LdapTemplate.unbind(LdapTemplate.java:1002)
        
              at com.telmex.dp.dao.TelmexProfileDao.delete(TelmexProfileDao.java:227)
        
              at com.telmex.dp.control.Executer.borrarPerfilTelmex(Executer.java:215)
        
              at com.telmex.dp.OperationHandler.handleRequest(OperationHandler.java:166)
        
              at com.telmex.www.dataplatform.DataPlatformServiceSkeleton.execute(DataPlatformServiceSkeleton.java:44)
        
              at Client.borrarPerfilTelmex(Client.java:372)
        
              at Client.test(Client.java:58)
        
              at Client.main(Client.java:33)
        Thanks!

        Comment


        • #5
          The stack trace indicates that you are using compensating transactions. This means that an unbind will in effect be a rename and then an unbind, if the transaction is committed. In your case, it's the rename that fails. Could you disable transactions and see if a plain unbind works?

          The object class violation error indicates that either an attribute is not allowed or that a required attribute is omitted. Which objectclass are you using for your entries? Which LDAP server?

          Comment


          • #6
            Hi!

            In fact I'm using transaction and it's necessary because if the other operation fails the rollback must apply so I must use transaction.

            It's important to point out that in the same transaction context I deleted an entry wtihout "@" and it was successful.

            My own object class is:
            Code:
            dn: cn=Schema
            changetype: modify
            add: objectClasses
            objectclasses:( tprofile-oid NAME 'TProfile' 
            		DESC 'Perfil' 
            		SUP 'top'
            		STRUCTURAL
            		MUST (tc $ sc $ pn $ ipbr $ so $ stbp )
            		MAY (guid $  nsrg $ iprg $ macAddress $ model $
            		     rack $ shelf $ slot $ portd $ ipd $
            		     id7450 $ ip7450 $ ids7450 $ iom $ mda $ port7450 $
            		     outer $ inner))
            The LDAP server is Tivoli Directory Server.

            Thanks!

            Comment


            • #7
              Originally posted by sacara View Post
              Hi!
              In fact I'm using transaction and it's necessary because if the other operation fails the rollback must apply so I must use transaction.
              Of course, but what I meant was to disable it temporarily just to test if an unbind works. What fails for you now is a rename, because transactions intercept the unbind.

              Comment


              • #8
                Hi!

                Ok, I disabled the transaction context and I deleted the same entry (with "@") and exactly it was successful.

                Comment


                • #9
                  OK, so it seems it's only the rename that fails then. Could you try performing a rename manually, as opposed to the one that the transaction performs? I mean doing a rename as you did the add, update and search operations. What I'm looking for here is this: is it the transaction rename that for some reason does something bad, or will a rename simply not work.

                  Comment


                  • #10
                    I actually have an idea what might be the problem - it might have to do with the default TempEntryRenamingStrategy; possibly you'll have to use the DifferentSubtreeRenamingStrategy in stead of the default TempEntryRenamingStrategy.

                    Comment

                    Working...
                    X