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
<[email protected]> 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
<[email protected]> 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
