directory-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Yiannis Mavroukakis <imavrouka...@gameaccount.com>
Subject Re: [ApacheDS] Poor man's cluster interceptor
Date Mon, 23 Feb 2009 14:47:19 GMT

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
>>>>>
>>>>>
>>>>>         
>>>>
>>>>
>>>>       
>>
>>
>>
>>   

Mime
View raw message