cleanup version parsing

[openldap] / servers / slapd / back-ldap / chain.c

diff --git a/servers/slapd/back-ldap/chain.c b/servers/slapd/back-ldap/chain.c
index 64f5bb5fc38adfb3423bfab39b0eb6a180a87f78..6c041620757a5bd803cda79a3ee8377fff2ef9a6 100644 (file)
--- a/servers/slapd/back-ldap/chain.c
+++ b/servers/slapd/back-ldap/chain.c
@@ -219,25 +219,6 @@ ldap_chain_uri_dup( void *c1, void *c2 )
        return 0;
 }
 
-static int
-ldap_chain_operational( Operation *op, SlapReply *rs )
-{
-       /* Trap entries generated by back-ldap.
-        * 
-        * FIXME: we need a better way to recognize them; a cleaner
-        * solution would be to be able to intercept the response
-        * of be_operational(), so that we can divert only those
-        * calls that fail because operational attributes were
-        * requested for entries that do not belong to the underlying
-        * database.  This fix is likely to intercept also entries
-        * generated by back-perl and so. */
-       if ( rs->sr_entry->e_private == NULL ) {
-               return 0;
-       }
-
-       return SLAP_CB_CONTINUE;
-}
-
 /*
  * Search specific response that strips entryDN from entries
  */
@@ -269,6 +250,10 @@ ldap_chain_cb_search_response( Operation *op, SlapReply *rs )
                                break;
                        }
                }
+
+               /* tell the frontend not to add generated
+                * operational attributes */
+               rs->sr_flags |= REP_NO_OPERATIONALS;
                
                return SLAP_CB_CONTINUE;
 
@@ -355,7 +340,7 @@ static int
 ldap_chain_op(
        Operation       *op,
        SlapReply       *rs,
-       int             ( *op_f )( Operation *op, SlapReply *rs ), 
+       BI_op_func      *op_f,
        BerVarray       ref )
 {
        slap_overinst   *on = (slap_overinst *) op->o_bd->bd_info;
@@ -461,7 +446,7 @@ Document: draft-ietf-ldapbis-protocol-27.txt
                        }
                }
 
-               rc = ( *op_f )( op, rs );
+               rc = op_f( op, rs );
 
 cleanup:;
                ldap_memfree( li.li_uri );
@@ -766,7 +751,7 @@ cleanup:;
                /* FIXME: ldap_back_extended() by design 
                 * doesn't send result; frontend is expected
                 * to send it... */
-               /* FIXME: what aboit chaining? */
+               /* FIXME: what about chaining? */
                if ( rc != SLAPD_ABANDON ) {
                        send_ldap_extended( op, rs );
                        rc = LDAP_SUCCESS;
@@ -786,7 +771,13 @@ cleanup:;
        case LDAP_SUCCESS:
        case LDAP_REFERRAL:
                /* slapd-ldap sent response */
-               assert( sc2.sc_private == LDAP_CH_RES );
+               if ( !op->o_abandon && sc2.sc_private != LDAP_CH_RES ) {
+                       /* FIXME: should we send response? */
+                       Debug( LDAP_DEBUG_ANY,
+                               "%s: ldap_chain_response: "
+                               "overlay should have sent result.\n",
+                               op->o_log_prefix, 0, 0 );
+               }
                break;
 
        default:
@@ -1293,6 +1284,7 @@ ldap_chain_db_init(
                return 1;
        }
        memset( lc, 0, sizeof( ldap_chain_t ) );
+       ldap_pvt_thread_mutex_init( &lc->lc_lai.lai_mutex );
 
        on->on_bi.bi_private = (void *)lc;
 
@@ -1500,6 +1492,9 @@ static int
 ldap_chain_db_open(
        BackendDB       *be )
 {
+       slap_overinst   *on = (slap_overinst *) be->bd_info;
+       ldap_chain_t    *lc = (ldap_chain_t *)on->on_bi.bi_private;
+
 #ifdef LDAP_CONTROL_X_CHAINING_BEHAVIOR
        int     rc = 0;
 
@@ -1509,6 +1504,13 @@ ldap_chain_db_open(
        }
 #endif /* LDAP_CONTROL_X_CHAINING_BEHAVIOR */
 
+       if ( lc->lc_common_li == NULL ) {
+               void    *be_private = be->be_private;
+               ldap_chain_db_init_common( be );
+               lc->lc_common_li = lc->lc_cfg_li = (ldapinfo_t *)be->be_private;
+               be->be_private = be_private;
+       }
+
        return ldap_chain_db_func( be, db_open );
 }
 
@@ -1532,6 +1534,7 @@ ldap_chain_db_destroy(
 
        if ( lc ) {
                avl_free( lc->lc_lai.lai_tree, NULL );
+               ldap_pvt_thread_mutex_destroy( &lc->lc_lai.lai_mutex );
                ch_free( lc );
        }
 
@@ -1797,17 +1800,6 @@ chain_initialize( void )
        ldapchain.on_bi.bi_db_close = ldap_chain_db_close;
        ldapchain.on_bi.bi_db_destroy = ldap_chain_db_destroy;
 
-       /* ... otherwise the underlying backend's function would be called,
-        * likely passing an invalid entry; on the contrary, the requested
-        * operational attributes should have been returned while chasing
-        * the referrals.  This all in all is a bit messy, because part
-        * of the operational attributes are generated by the backend;
-        * part by the frontend; back-ldap should receive all the available
-        * ones from the remote server, but then, on its own, it strips those
-        * it assumes will be (re)generated by the frontend (e.g.
-        * subschemaSubentry.) */
-       ldapchain.on_bi.bi_operational = ldap_chain_operational;
-       
        ldapchain.on_bi.bi_connection_destroy = ldap_chain_connection_destroy;
 
        ldapchain.on_response = ldap_chain_response;