Re: Queston on Interceptor
Le 22/09/16 à 21:52, Sathyanarayan, Harish a écrit :
> Thanks, will look at it and get back to you what I find. Meanwhile, wanted
> to check how the EntryFilteringCursor for search works?.
This interface is used to add a Filter on Entries being processed by a
Cursor. The Cursor is used to navigate backward and forward (if te
implementation allows it), and teh EntryCursor navigates across a set of
Entries. The EntryFilter is used to filter an entry : make it a valid
candidate or not. It can also be used to apply some modifications on the
entry.
Basically, an EntryFilter contains an accept() methods that retursn true
or false if the entry should be accpetd or discarded. Here is an example :
/**
* the search result filter to use for the addition of mandatory
operational attributes
*/
private class OperationalAttributeSearchFilter implements EntryFilter
{
/**
* {@inheritDoc}
*/
@Override
public boolean accept( SearchOperationContext operation, Entry
entry ) throws LdapException
{
if ( operation.getReturningAttributesString() == null )
{
return true;
}
// Add the SubschemaSubentry AttributeType if it's requested
SchemaManager schemaManager =
operation.getSession().getDirectoryService().getSchemaManager();
if ( operation.isAllOperationalAttributes()
|| operation.getReturningAttributes().contains(
new AttributeTypeOptions(
schemaManager.getAttributeType( SchemaConstants.SUBSCHEMA_SUBENTRY_AT )
) ) )
{
AttributeType subschemaSubentryAt =
schemaManager.getAttributeType( SchemaConstants.SUBSCHEMA_SUBENTRY_AT );
entry.add( new DefaultAttribute( subschemaSubentryAt,
directoryService.getPartitionNexus().getRootDseValue(
subschemaSubentryAt ) ) );
}
return true;
}
Don't be scared by this piece of code, the meat is just doing some
controls on the content of the entry, and depending on teh result, make
it acceptable or not.
It is used this way :
/** The filter that add the mandatory operational attributes */
private final EntryFilter operationalAttributeSearchFilter = new
OperationalAttributeSearchFilter();
/** The filter that add the subordinates operational attributes */
private final EntryFilter subordinatesSearchFilter = new
SubordinatesSearchFilter();
...
public EntryFilteringCursor search( SearchOperationContext
searchContext ) throws LdapException
{
EntryFilteringCursor cursor = next( searchContext );
if ( searchContext.isAllOperationalAttributes()
|| ( ( searchContext.getReturningAttributes() != null ) &&
!searchContext.getReturningAttributes().isEmpty() ) )
{
if ( directoryService.isDenormalizeOpAttrsEnabled() )
{
cursor.addEntryFilter( denormalizingSearchFilter );
}
cursor.addEntryFilter( operationalAttributeSearchFilter );
cursor.addEntryFilter( subordinatesSearchFilter );
return cursor;
}
return cursor;
}
As you can see, we update the cursor we got back from thebackend search
by adding some new filters, that will get executed when the cursor will
be navigated later on. This is automatic.
> I cannot return it back(Entry result from search operation) from the
> interceptor to the client.
The interceptor wil always return a cursor for the search operation,
your client will be able to use it.
RE: Queston on Interceptor
Hi Emmanuel,
I just checked. Yes Search, Add and Modify show up my Interceptor. I have
method signatures for all these three in my Custom Interceptor. I tried
delete(no signature), it did not show my interceptor. So I guess the behavior
seems consistent. So what could be the problem then...
Thanks!
-Original Message-
From: Emmanuel Lécharny [mailto:elecha...@gmail.com]
Sent: Thursday, September 22, 2016 3:32 PM
To: Apache Directory Developers List
Subject: Re: Queston on Interceptor
Le 22/09/16 à 20:55, Sathyanarayan, Harish a écrit :
> Hi Emmanuel,
>
> The custom interceptor I wrote looks like:
>
> public class ProxyInterceptor extends BaseInterceptor {
>
> @Override
> public EntryFilteringCursor search(final SearchOperationContext
> searchContext) throws LdapException {
>
> // call connector
> }
>
> @Override
> public void add(final AddOperationContext addContext) throws
> LdapException {
> try { logger.info("addContext.getEntry() ");
> proxyConnector.add(addContext.getEntry());
> } catch (CursorException e) {
> logger.info(e.getMessage());
> }
> next(addContext);
> }
>
> @Override
> public void modify(final ModifyOperationContext modifyContext) throws
> LdapException {
>
> }
>
> }
>
>
> I am calling this interceptor from my resource class. For example the rest
> call for modify does not work:
>
> Modification mod = new DefaultModification(
> ModificationOperation.REPLACE_ATTRIBUTE, "o",
> "test123456" );
> ModifyRequest modifyRequest = new ModifyRequestImpl();
> modifyRequest.setName(new Dn("dc=example,dc=com"));
> modifyRequest.addModification(mod);
>
> getConnection().modify(modifyRequest);
> // connection.modify("test", );
> logger.info("after modify");
> releaseConnection(connection);
>
>
> Hope this helps, let me know if anything else...thanks!
Ok, makes sense.
The interceptors are weird little beasts... The way they are called is a bit
complex.
Basically, each interceptor can implement as many method as needed, from the
interface they implement. Each of those method is going to be called by the
previous interceptor. Up to this point, you get it right.
Now, the tricky part is how the interceptors get called, and how ne interceptor
know which is the next one.
Each operation is associated with an ordered list of interceptor As you may not
want to implement some operation, these lists may be longer or shorter. For
instance, the search operation is handled by pretty much all the interceptor,
but ChangeLogInterceptor or JournalInterceptor (because we don't log searches,
and a search is not an change). This is true for every interceptor.
This list may change, depending on which interceptor is loaded and enabled. If
you add your own interceptor, then the lists are going to be longer.
All in all we use a map> to store this
information. the tricky part is to have this map created. Actually, you need to
modify the server's configuration, insterting your intercerceptor are the place
you want, and this is the moment the map is fed.
Let's do that : can you check the content of this map? You can get each
operation list by calling DirectoryService.getInterceptors( OperationEnum )
where OperationEnum is one of :
ADD
BIND
COMPARE
DELETE
GET_ROOT_DSE
HAS_ENTRY
LIST
LOOKUP
MODIFY
MOVE
MOVE_AND_RENAME
RENAME
SEARCH
UNBIND
Typically, try with SEARH, and see what list you have, and try with ADD to see
what you have. Your interceptor must be listed in both case.
>
>
> -Original Message-
> From: Emmanuel Lécharny [mailto:elecha...@gmail.com]
> Sent: Thursday, September 22, 2016 2:48 PM
> To: Apache Directory Developers List
> Subject: Re: Queston on Interceptor
>
> Le 22/09/16 à 20:32, Sathyanarayan, Harish a écrit :
>> Hi:
>>
>> I have written a proxy interceptor that implements BaseInterceptor
>> operations like Search, add, modify etc. I have tried inserting both next to
>> the normalizationinterceptor and at the very end of the chain. I run the
>> ApacheDS as embedded service under dropwizard.
> You probably want to insert your interceptor after the
> normalizerInterceptor : That wuld be the natural position
>> I have a REST API performi
RE: Queston on Interceptor
Thanks, will look at it and get back to you what I find. Meanwhile, wanted to
check how the EntryFilteringCursor for search works?. I cannot return it
back(Entry result from search operation) from the interceptor to the client.
What would be the best way to handle that? Please advice
-Original Message-
From: Emmanuel Lécharny [mailto:elecha...@gmail.com]
Sent: Thursday, September 22, 2016 3:32 PM
To: Apache Directory Developers List
Subject: Re: Queston on Interceptor
Le 22/09/16 à 20:55, Sathyanarayan, Harish a écrit :
> Hi Emmanuel,
>
> The custom interceptor I wrote looks like:
>
> public class ProxyInterceptor extends BaseInterceptor {
>
> @Override
> public EntryFilteringCursor search(final SearchOperationContext
> searchContext) throws LdapException {
>
> // call connector
> }
>
> @Override
> public void add(final AddOperationContext addContext) throws
> LdapException {
> try { logger.info("addContext.getEntry() ");
> proxyConnector.add(addContext.getEntry());
> } catch (CursorException e) {
> logger.info(e.getMessage());
> }
> next(addContext);
> }
>
> @Override
> public void modify(final ModifyOperationContext modifyContext) throws
> LdapException {
>
> }
>
> }
>
>
> I am calling this interceptor from my resource class. For example the rest
> call for modify does not work:
>
> Modification mod = new DefaultModification(
> ModificationOperation.REPLACE_ATTRIBUTE, "o",
> "test123456" );
> ModifyRequest modifyRequest = new ModifyRequestImpl();
> modifyRequest.setName(new Dn("dc=example,dc=com"));
> modifyRequest.addModification(mod);
>
> getConnection().modify(modifyRequest);
> // connection.modify("test", );
> logger.info("after modify");
> releaseConnection(connection);
>
>
> Hope this helps, let me know if anything else...thanks!
Ok, makes sense.
The interceptors are weird little beasts... The way they are called is a bit
complex.
Basically, each interceptor can implement as many method as needed, from the
interface they implement. Each of those method is going to be called by the
previous interceptor. Up to this point, you get it right.
Now, the tricky part is how the interceptors get called, and how ne interceptor
know which is the next one.
Each operation is associated with an ordered list of interceptor As you may not
want to implement some operation, these lists may be longer or shorter. For
instance, the search operation is handled by pretty much all the interceptor,
but ChangeLogInterceptor or JournalInterceptor (because we don't log searches,
and a search is not an change). This is true for every interceptor.
This list may change, depending on which interceptor is loaded and enabled. If
you add your own interceptor, then the lists are going to be longer.
All in all we use a map> to store this
information. the tricky part is to have this map created. Actually, you need to
modify the server's configuration, insterting your intercerceptor are the place
you want, and this is the moment the map is fed.
Let's do that : can you check the content of this map? You can get each
operation list by calling DirectoryService.getInterceptors( OperationEnum )
where OperationEnum is one of :
ADD
BIND
COMPARE
DELETE
GET_ROOT_DSE
HAS_ENTRY
LIST
LOOKUP
MODIFY
MOVE
MOVE_AND_RENAME
RENAME
SEARCH
UNBIND
Typically, try with SEARH, and see what list you have, and try with ADD to see
what you have. Your interceptor must be listed in both case.
>
>
> -Original Message-
> From: Emmanuel Lécharny [mailto:elecha...@gmail.com]
> Sent: Thursday, September 22, 2016 2:48 PM
> To: Apache Directory Developers List
> Subject: Re: Queston on Interceptor
>
> Le 22/09/16 à 20:32, Sathyanarayan, Harish a écrit :
>> Hi:
>>
>> I have written a proxy interceptor that implements BaseInterceptor
>> operations like Search, add, modify etc. I have tried inserting both next to
>> the normalizationinterceptor and at the very end of the chain. I run the
>> ApacheDS as embedded service under dropwizard.
> You probably want to insert your interceptor after the
> normalizerInterceptor : That wuld be the natural position
>> I have a REST API performing CRUD op
Re: Queston on Interceptor
Le 22/09/16 à 20:55, Sathyanarayan, Harish a écrit :
> Hi Emmanuel,
>
> The custom interceptor I wrote looks like:
>
> public class ProxyInterceptor extends BaseInterceptor {
>
> @Override
> public EntryFilteringCursor search(final SearchOperationContext
> searchContext) throws LdapException {
>
> // call connector
> }
>
> @Override
> public void add(final AddOperationContext addContext) throws
> LdapException {
> try { logger.info("addContext.getEntry() ");
> proxyConnector.add(addContext.getEntry());
> } catch (CursorException e) {
> logger.info(e.getMessage());
> }
> next(addContext);
> }
>
> @Override
> public void modify(final ModifyOperationContext modifyContext) throws
> LdapException {
>
> }
>
> }
>
>
> I am calling this interceptor from my resource class. For example the rest
> call for modify does not work:
>
> Modification mod = new DefaultModification(
> ModificationOperation.REPLACE_ATTRIBUTE, "o",
> "test123456" );
> ModifyRequest modifyRequest = new ModifyRequestImpl();
> modifyRequest.setName(new Dn("dc=example,dc=com"));
> modifyRequest.addModification(mod);
>
> getConnection().modify(modifyRequest);
> // connection.modify("test", );
> logger.info("after modify");
> releaseConnection(connection);
>
>
> Hope this helps, let me know if anything else...thanks!
Ok, makes sense.
The interceptors are weird little beasts... The way they are called is a
bit complex.
Basically, each interceptor can implement as many method as needed, from
the interface they implement. Each of those method is going to be called
by the previous interceptor. Up to this point, you get it right.
Now, the tricky part is how the interceptors get called, and how ne
interceptor know which is the next one.
Each operation is associated with an ordered list of interceptor As you
may not want to implement some operation, these lists may be longer or
shorter. For instance, the search operation is handled by pretty much
all the interceptor, but ChangeLogInterceptor or JournalInterceptor
(because we don't log searches, and a search is not an change). This is
true for every interceptor.
This list may change, depending on which interceptor is loaded and
enabled. If you add your own interceptor, then the lists are going to be
longer.
All in all we use a map> to store this
information. the tricky part is to have this map created. Actually, you
need to modify the server's configuration, insterting your
intercerceptor are the place you want, and this is the moment the map is
fed.
Let's do that : can you check the content of this map? You can get each
operation list by calling DirectoryService.getInterceptors(
OperationEnum ) where OperationEnum is one of :
ADD
BIND
COMPARE
DELETE
GET_ROOT_DSE
HAS_ENTRY
LIST
LOOKUP
MODIFY
MOVE
MOVE_AND_RENAME
RENAME
SEARCH
UNBIND
Typically, try with SEARH, and see what list you have, and try with ADD
to see what you have. Your interceptor must be listed in both case.
>
>
> -Original Message-
> From: Emmanuel Lécharny [mailto:elecha...@gmail.com]
> Sent: Thursday, September 22, 2016 2:48 PM
> To: Apache Directory Developers List
> Subject: Re: Queston on Interceptor
>
> Le 22/09/16 à 20:32, Sathyanarayan, Harish a écrit :
>> Hi:
>>
>> I have written a proxy interceptor that implements BaseInterceptor
>> operations like Search, add, modify etc. I have tried inserting both next to
>> the normalizationinterceptor and at the very end of the chain. I run the
>> ApacheDS as embedded service under dropwizard.
> You probably want to insert your interceptor after the normalizerInterceptor
> : That wuld be the natural position
>> I have a REST API performing CRUD operations. My question is: when I
>> call the Resource to perform add and search it calls the interceptor
> Hmm. Not sure I understand this sentence : do you call the interceptor
> directly, or is the interceptor called by the uer layer ?
>
>> that talks to the connector to perform the proxy operation. This works as
>> intended. But if I try modify and delete, it does not even hit the
>> interceptor and there is no response. Wondering what could be the root cause
RE: Queston on Interceptor
Hi Emmanuel,
The custom interceptor I wrote looks like:
public class ProxyInterceptor extends BaseInterceptor {
@Override
public EntryFilteringCursor search(final SearchOperationContext
searchContext) throws LdapException {
// call connector
}
@Override
public void add(final AddOperationContext addContext) throws
LdapException {
try { logger.info("addContext.getEntry() ");
proxyConnector.add(addContext.getEntry());
} catch (CursorException e) {
logger.info(e.getMessage());
}
next(addContext);
}
@Override
public void modify(final ModifyOperationContext modifyContext) throws
LdapException {
}
}
I am calling this interceptor from my resource class. For example the rest call
for modify does not work:
Modification mod = new DefaultModification(
ModificationOperation.REPLACE_ATTRIBUTE, "o",
"test123456" );
ModifyRequest modifyRequest = new ModifyRequestImpl();
modifyRequest.setName(new Dn("dc=example,dc=com"));
modifyRequest.addModification(mod);
getConnection().modify(modifyRequest);
// connection.modify("test", );
logger.info("after modify");
releaseConnection(connection);
Hope this helps, let me know if anything else...thanks!
-Original Message-
From: Emmanuel Lécharny [mailto:elecha...@gmail.com]
Sent: Thursday, September 22, 2016 2:48 PM
To: Apache Directory Developers List
Subject: Re: Queston on Interceptor
Le 22/09/16 à 20:32, Sathyanarayan, Harish a écrit :
> Hi:
>
> I have written a proxy interceptor that implements BaseInterceptor operations
> like Search, add, modify etc. I have tried inserting both next to the
> normalizationinterceptor and at the very end of the chain. I run the ApacheDS
> as embedded service under dropwizard.
You probably want to insert your interceptor after the normalizerInterceptor :
That wuld be the natural position
>
> I have a REST API performing CRUD operations. My question is: when I
> call the Resource to perform add and search it calls the interceptor
Hmm. Not sure I understand this sentence : do you call the interceptor
directly, or is the interceptor called by the uer layer ?
> that talks to the connector to perform the proxy operation. This works as
> intended. But if I try modify and delete, it does not even hit the
> interceptor and there is no response. Wondering what could be the root cause
> of this issue?
Can you show the signature for these operations ?
The information contained in this electronic mail transmission may be
privileged and confidential, and therefore, protected from disclosure. If you
have received this communication in error, please notify us immediately by
replying to this message and deleting the email and its attachments from all
computers without copying or disclosing it.
Re: Queston on Interceptor
Le 22/09/16 à 20:32, Sathyanarayan, Harish a écrit : > Hi: > > I have written a proxy interceptor that implements BaseInterceptor operations > like Search, add, modify etc. I have tried inserting both next to the > normalizationinterceptor and at the very end of the chain. I run the ApacheDS > as embedded service under dropwizard. You probably want to insert your interceptor after the normalizerInterceptor : That wuld be the natural position > > I have a REST API performing CRUD operations. My question is: when I call the > Resource to perform add and search it calls the interceptor Hmm. Not sure I understand this sentence : do you call the interceptor directly, or is the interceptor called by the uer layer ? > that talks to the connector to perform the proxy operation. This works as > intended. But if I try modify and delete, it does not even hit the > interceptor and there is no response. Wondering what could be the root cause > of this issue? Can you show the signature for these operations ?
