Custom interceptor throws NPE while calling next(opContext)

[Philipp Grigoryev <ph...@icsynergy.com>]

Hello All,

I’m building a service which has incoming LDAP interface and transforms LDAP requests into REST-calls to another service. I created a custom Interceptor for CRUD operations, but my problem is, when I try to pass control to the next interceptor in the chain I got NPE.

I posted a question on StackOverflow with details of my implementation and a stack trace. Not sure if I need to duplicate everything here, but will do if required. It’s my first time posting into this mail list.

Here is the URL for my question on SO -> https://stackoverflow.com/questions/57150901/calling-nextmodifycontext-from-a-custom-interceptor-leads-to-nullpointerexcept <https://stackoverflow.com/questions/57150901/calling-nextmodifycontext-from-a-custom-interceptor-leads-to-nullpointerexcept>

I’d appreciate any help or thoughts.

Regards,
Philipp
-- 

CONFIDENTIALITY NOTICE: This message (including any attachments) contains 
confidential information intended for a specific individual and purpose, 
and is protected by law. If you are not the intended recipient, you should 
delete this message. Any disclosure, copying, or distribution of this 
message, or the taking of any action based on it, is strictly prohibited. 
[v.E.1]

Re: Custom interceptor throws NPE while calling next(opContext)

[Emmanuel Lécharny <el...@gmail.com>]

Hi !

On 22/07/2019 23:44, Philipp Grigoryev wrote:
> Hello All,
>
> I’m building a service which has incoming LDAP interface and transforms LDAP requests into REST-calls to another service. I created a custom Interceptor for CRUD operations, but my problem is, when I try to pass control to the next interceptor in the chain I got NPE.

Accordingly to what you posted on stackoverflow, the NPE is due to the 
fact your interceptor does not know what is the next one to call:


     protected Interceptor getNextInterceptor( OperationContext 
operationContext )
     {
         String currentInterceptor = operationContext.getNextInterceptor();

         if ( currentInterceptor.equals( "FINAL" ) )

Here, currentInterceptor is most certainly null.


Why is that ?

The operationContext (here, it's an instance of ModifyOperationContext) 
contains a list of interceptors to call, and this list is computed when 
the server is started by the DefaultDirectoryServer.gatherInterceptors() 
private method. This method gets all the interceptors  that are 
configured, and for each operation context, search for the associated 
method using reflection (here, it willl search for the 'modify' method). 
At the end, each OperationContext instance is stored in a Map associated 
with the list of interceptors it may call ( this map is named 
operationInterceptors). When a new operation starts (ie when a user send 
a request to the server), it will get the list of interceptors to 
process from this map (which can be modified dynamically, but that's 
another story).

Anyway, the problem here is to be able to inject another interceptor and 
to have it properly 'linked' so that when the operation fetch the next 
interceptor, it finds it. This is all about registering the interceptor. 
Currently, this is done by this method:

     private void addInterceptor( Interceptor interceptor, int position )

It adds an interceptor at a given position. The thing is that this 
method is private, so it can't be called outside the 
DefaultDirectoryServer class.

It's called at two other places:

- addFirst

- addLast

which are public methods. That means the only way to inject an 
interceptor into the chain is to call one of those two methods (and as 
it only add an interceptor at the end or at the beginning of the list, 
it must be called  exactly at the right moment accordingly to the 
expected position of the new interceptor in the chain. It also means you 
don't really have a way to inject your interceptor in the middle of the 
chain, because you don't have a way to control how this chain is created 
(at least programatically).

The key here is to play with the server configuration. When the server 
starts, it reads the config from a set of LDIF files and extract the 
list of intercpeots - and the order in which they will be loaded - from 
this configuration. It then creates a list of those interceptors, pass 
it to the DefaultDirectoryServer instance using the setInterceptors() 
method, then the initOperationsList() method is called, which create the 
Map we mention before, with the proper intercaptor lists for each operation.

So you have to configure your system with a new LDIF like this one :


dn: 
ads-interceptorId=|MyCRUDInterceptor|,ou=interceptors,ads-directoryServiceId=default,ou=config
objectclass: top
objectclass: ads-base
objectclass: ads-interceptor
ads-interceptororder: <NNN>
ads-interceptorclassname: xxx.company.ldapbridge.impl.MyCRUDInterceptor
ads-interceptorid: |MyCRUDInterceptor|
ads-enabled: TRUE

Note that the ads-interceptororder value (here, <NNN>) must be 
consistent with the other interceptors' position, which means you will 
have to change all the other orders if you inject your interceptor in 
the middle.


Ok, this is how it works. It's not simple, and I hope I have been clear 
enough... Please ask if you have any issue with what I explained !


>
> I posted a question on StackOverflow with details of my implementation and a stack trace. Not sure if I need to duplicate everything here, but will do if required. It’s my first time posting into this mail list.
>
> Here is the URL for my question on SO -> https://stackoverflow.com/questions/57150901/calling-nextmodifycontext-from-a-custom-interceptor-leads-to-nullpointerexcept <https://stackoverflow.com/questions/57150901/calling-nextmodifycontext-from-a-custom-interceptor-leads-to-nullpointerexcept>
>
> I’d appreciate any help or thoughts.
>
> Regards,
> Philipp

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@directory.apache.org
For additional commands, e-mail: users-help@directory.apache.org