Mailing-List: contact users-help@directory.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@directory.apache.org
Received-SPF: pass (nike.apache.org: domain of imavroukakis@gameaccount.com
 designates 83.244.222.83 as permitted sender)
Message-ID: <49A2B6F7.1080707@gameaccount.com>
Date: Mon, 23 Feb 2009 14:47:19 +0000
From: Yiannis Mavroukakis <imavroukakis@gameaccount.com>
Organization: GameAccount
User-Agent: Thunderbird 2.0.0.19 (Windows/20081209)
MIME-Version: 1.0
To: users@directory.apache.org
Subject: Re: [ApacheDS] Poor man's cluster interceptor
References: <498AFE3A.7050406@vogon.net>
	 <d45b08f00902191112t20bb4fc4nd91e6f1c3851ee94@mail.gmail.com>
	 <499DD922.90702@gameaccount.com>
 <499DDC29.9080107@nextury.com>	 <499ED47B.3030005@gameaccount.com>
	 <d45b08f00902200810p57d7dd58x498bf56d49e39e2d@mail.gmail.com>
	 <49A27601.40707@gameaccount.com>
	 <d45b08f00902230216w6ee41b1h61e7affcc645827c@mail.gmail.com>
	 <d45b08f00902230217v7b4e2430h111a686f7a3cb4b1@mail.gmail.com>
	 <49A286AB.1000809@gameaccount.com>
 <d45b08f00902230347t26d1b226l8221ea0905f7f08@mail.gmail.com>
 <49A29519.3030202@gameaccount.com>
In-Reply-To: <49A29519.3030202@gameaccount.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit


Hello again,

Little bit of background info before my question

2009-02-23 14:34:51,407 DEBUG 
[org.apache.directory.server.schema.registries.DefaultOidRegistry] 
looked up OID '1.3.6.1.4.1.1466.115.121.1.12' with id 'dn'
2009-02-23 14:34:51,407 DEBUG 
[org.apache.directory.server.schema.registries.DefaultOidRegistry] 
looked up OID '2.5.18.12' with id 'collectiveAttributeSubentries'
2009-02-23 14:34:51,407 DEBUG 
[org.apache.directory.server.schema.registries.DefaultAttributeTypeRegistry] 
lookup with id2.5.18.12' of attributeType: <2.5.18.12, 
collectiveAttributeSubentries>
2009-02-23 14:34:51,407 DEBUG 
[org.apache.directory.server.schema.registries.DefaultOidRegistry] 
looked up OID '2.5.4.0' with id 'objectClass'
2009-02-23 14:34:51,407 DEBUG 
[org.apache.directory.server.schema.registries.DefaultAttributeTypeRegistry] 
lookup with id2.5.4.0' of attributeType: <2.5.4.0, objectClass>

As i've mentioned in my previous posts, Jabber XCP seems to stick dn as 
an attribute in its search request. Now the question is, is it correct 
to implement

search( NextInterceptor next , SearchOperationContext opContext )

in order to remove DN?  I've tried to do something very very basic like

   public EntryFilteringCursor search( NextInterceptor next ,
            SearchOperationContext opContext ) throws Exception
    {
       EntryFilteringCursor cursor = next.search( opContext );

        Set<AttributeTypeOptions> returnAttributes = opContext
                .getReturningAttributes( );

        if( returnAttributes != null )
        {
            Set<AttributeTypeOptions> modifiedAttributes = new 
HashSet<AttributeTypeOptions>( );

            for( AttributeTypeOptions attributeTypeOptions : 
returnAttributes )
            {
                if( !attributeTypeOptions.hasOption( "1.1" ) )
                {
                    modifiedAttributes.add( attributeTypeOptions );
                }
            }
            opContext.setReturningAttributes( modifiedAttributes );
        }
        return cursor;
   }

But that doesn't seem to do the trick, as DS is still complaining about 
the existence of dn as an attribute in the search. Am I going along the 
right
path or is this all very very wrong ? :-)

Thank you!

Yiannis

Yiannis Mavroukakis wrote:
> I'll try it, although my understanding of how to do either one is poor 
> :-)
>
> Y.
>
> Emmanuel Lecharny wrote:
>> You can even write an interceptor which will remove the DN from the
>> returned attributes, and add it when the search is successfull (you
>> will have to add a Filter)
>>
>> I think it can be done in half an hour.
>>
>> Otherwise, I would rather implement RFC 5020, transform the DN to
>> entryDN in an interceptor, and back. That would be way better, but a
>> bit longer :)
>>
>> On Mon, Feb 23, 2009 at 12:21 PM, Yiannis Mavroukakis
>> <imavroukakis@gameaccount.com> wrote:
>>  
>>> I've looked around the config for Jabber XCP and it doesn't seem to 
>>> be a
>>> configurable attribute. Is it possible to use
>>> an interceptor, implement search( NextInterceptor next
>>> ,SearchOperationContext opContext ), and rewrite the attribute to be 
>>> 1.1
>>> instead of dn ?
>>>
>>> Thanks,
>>>
>>> Yiannis
>>>
>>> Emmanuel Lecharny wrote:
>>>    
>>>> More specifically, if you just want to get the DN of each entry
>>>> without any other attribute, just specify "1.1 " as requested
>>>> attributes.
>>>>
>>>> On Mon, Feb 23, 2009 at 11:16 AM, Emmanuel Lecharny
>>>> <elecharny@apache.org> wrote:
>>>>
>>>>      
>>>>> Hi,
>>>>>
>>>>> DN is not an attribute. You should not send a search request with it
>>>>> as a requested attribute. That's why you get this warning.
>>>>>
>>>>>
>>>>> -- 
>>>>> Regards,
>>>>> Cordialement,
>>>>> Emmanuel L�charny
>>>>> www.iktek.com
>>>>>
>>>>>
>>>>>         
>>>>
>>>>
>>>>       
>>
>>
>>
>>