ApacheDS db corrupt
Hi Emmanuel, Our problem is that the database became corrupt and we don't know how to repair it. We have tried to use apacheds.sh default repair and the utility says that repair went successfully but it didn't help with our problem. Our ApacheDS version is 2.0.0.AM24 There are a few bugs reported with a similar problem. Could you please advice on how to fix out problem During last week we have experienced a following problem: 1. When searching for uid we get an answer that uid doesn't exist, but when we try to create a uid with the same number the answer is the uid already exists. 2. We have an alarming error message in log WARN [pool-5-thread-4] org.apache.directory.server.ldap.LdapProtocolHandler.exceptionCaught():236 - Unexpected exception forcing session to close: sending disconnect notice to client. java.lang.Error: ERR_554 double get for block 134,207 at jdbm.recman.RecordFile.get(RecordFile.java:185) at jdbm.recman.PhysicalRowIdManager.allocNew(PhysicalRowIdManager.java:202) at jdbm.recman.PhysicalRowIdManager.alloc(PhysicalRowIdManager.java:177) at jdbm.recman.PhysicalRowIdManager.update(PhysicalRowIdManager.java:101) at jdbm.recman.BaseRecordManager.update(BaseRecordManager.java:281) at jdbm.recman.CacheRecordManager.updateCacheEntries(CacheRecordManager.java:417) at jdbm.recman.CacheRecordManager.commit(CacheRecordManager.java:349) at org.apache.directory.server.core.partition.impl.btree.jdbm.JdbmIndex.sync(JdbmIndex.java:590) at org.apache.directory.server.core.partition.impl.btree.jdbm.JdbmPartition.sync(JdbmPartition.java:567) at org.apache.directory.server.core.partition.impl.btree.AbstractBTreePartition.modify(AbstractBTreePartition.java:1580) at org.apache.directory.server.core.partition.impl.btree.AbstractBTreePartition.modify(AbstractBTreePartition.java:1523) at org.apache.directory.server.core.shared.partition.DefaultPartitionNexus.modify(DefaultPartitionNexus.java:491) at org.apache.directory.server.core.api.interceptor.BaseInterceptor$1.modify(BaseInterceptor.java:170) at org.apache.directory.server.core.api.interceptor.BaseInterceptor.next(BaseInterceptor.java:506) at org.apache.directory.server.core.journal.JournalInterceptor.modify(JournalInterceptor.java:229) at org.apache.directory.server.core.api.interceptor.BaseInterceptor.next(BaseInterceptor.java:506) at org.apache.directory.server.core.trigger.TriggerInterceptor.modify(TriggerInterceptor.java:370) at org.apache.directory.server.core.api.interceptor.BaseInterceptor.next(BaseInterceptor.java:506) at org.apache.directory.server.core.event.EventInterceptor.modify(EventInterceptor.java:298) at org.apache.directory.server.core.api.interceptor.BaseInterceptor.next(BaseInterceptor.java:506) at org.apache.directory.server.core.subtree.SubentryInterceptor.modify(SubentryInterceptor.java:1220) at org.apache.directory.server.core.api.interceptor.BaseInterceptor.next(BaseInterceptor.java:506) at org.apache.directory.server.core.collective.CollectiveAttributeInterceptor.modify(CollectiveAttributeInterceptor.java:165) at org.apache.directory.server.core.api.interceptor.BaseInterceptor.next(BaseInterceptor.java:506) at org.apache.directory.server.core.operational.OperationalAttributeInterceptor.modify(OperationalAttributeInterceptor.java:449) at org.apache.directory.server.core.api.interceptor.BaseInterceptor.next(BaseInterceptor.java:506) at org.apache.directory.server.core.schema.SchemaInterceptor.modify(SchemaInterceptor.java:1206) at org.apache.directory.server.core.api.interceptor.BaseInterceptor.next(BaseInterceptor.java:506) at org.apache.directory.server.core.hash.ConfigurableHashingInterceptor.modify(ConfigurableHashingInterceptor.java:185) at org.apache.directory.server.core.api.interceptor.BaseInterceptor.next(BaseInterceptor.java:506) at org.apache.directory.server.core.exception.ExceptionInterceptor.modify(ExceptionInterceptor.java:252) at org.apache.directory.server.core.api.interceptor.BaseInterceptor.next(BaseInterceptor.java:506) at org.apache.directory.server.core.admin.AdministrativePointInterceptor.modify(AdministrativePointInterceptor.java:1453) at org.apache.directory.server.core.api.interceptor.BaseInterceptor.next(BaseInterceptor.java:506) at org.apache.directory.server.core.authz.DefaultAuthorizationInterceptor.modify(DefaultAuthorizationInterceptor.java:273) at org.apache.directory.server.core.api.interceptor.BaseInterceptor.next(BaseInterceptor.java:506) at org.apache.directory.server.core.authz.AciAuthorizationInterceptor.modify(AciAuthorizationInterceptor.java:947) at org.apache.directory.server.core.api.interceptor.BaseInterceptor.next(BaseInterceptor.java:506) at org.apache.directory.server.core.referral.ReferralInterceptor.modify(ReferralInterceptor.java:317) at org.apache.directory.server.core.api.interceptor.BaseInterceptor.next(BaseInterceptor.java:506) at org.apache.directory.server.core.authn.AuthenticationInterceptor.processPasswordPolicydModify(AuthenticationInterceptor.java:931) at org.apache.d
Re: ApacheDS db corrupt
Hi Sergey, On 23/07/2019 09:25, Sergey Mikhno wrote: Hi Emmanuel, Our problem is that the database became corrupt and we don't know how to repair it. We have tried to use apacheds.sh default repair and the utility says that repair went successfully but it didn't help with our problem. Our ApacheDS version is 2.0.0.AM24 There are a few bugs reported with a similar problem. Could you please advice on how to fix out problem Sadly, there is no way to fix the problem with the released version. The 'repair' option will fix it most of the time, but it may happen that the database get corrupted beyond repair. The coming release is suppose to fix this problem. Basically, in all the released versions we weren't guaranteeing operations atomicity: when you do a add/delete/modify, many BTree get updated. In some cases, we may end in a situation where some of those BTrees get updated, but other not, leaving the database in a bad state. We have added a transaction support around operations that is expecting to either commit the whole modifications in one shot, or rollback it. I do expect to have it released in the coming weeks. In the mean time, the only solution is to export the data and reimport them. I'm sorry for that. During last week we have experienced a following problem: 1. When searching for uid we get an answer that uid doesn't exist, but when we try to create a uid with the same number the answer is the uid already exists. 2. We have an alarming error message in log WARN [pool-5-thread-4] org.apache.directory.server.ldap.LdapProtocolHandler.exceptionCaught():236 - Unexpected exception forcing session to close: sending disconnect notice to client. java.lang.Error: ERR_554 double get for block 134,207 at jdbm.recman.RecordFile.get(RecordFile.java:185) at jdbm.recman.PhysicalRowIdManager.allocNew(PhysicalRowIdManager.java:202) at jdbm.recman.PhysicalRowIdManager.alloc(PhysicalRowIdManager.java:177) at jdbm.recman.PhysicalRowIdManager.update(PhysicalRowIdManager.java:101) at jdbm.recman.BaseRecordManager.update(BaseRecordManager.java:281) at jdbm.recman.CacheRecordManager.updateCacheEntries(CacheRecordManager.java:417) at jdbm.recman.CacheRecordManager.commit(CacheRecordManager.java:349) at org.apache.directory.server.core.partition.impl.btree.jdbm.JdbmIndex.sync(JdbmIndex.java:590) at org.apache.directory.server.core.partition.impl.btree.jdbm.JdbmPartition.sync(JdbmPartition.java:567) at org.apache.directory.server.core.partition.impl.btree.AbstractBTreePartition.modify(AbstractBTreePartition.java:1580) at org.apache.directory.server.core.partition.impl.btree.AbstractBTreePartition.modify(AbstractBTreePartition.java:1523) at org.apache.directory.server.core.shared.partition.DefaultPartitionNexus.modify(DefaultPartitionNexus.java:491) at org.apache.directory.server.core.api.interceptor.BaseInterceptor$1.modify(BaseInterceptor.java:170) at org.apache.directory.server.core.api.interceptor.BaseInterceptor.next(BaseInterceptor.java:506) at org.apache.directory.server.core.journal.JournalInterceptor.modify(JournalInterceptor.java:229) at org.apache.directory.server.core.api.interceptor.BaseInterceptor.next(BaseInterceptor.java:506) at org.apache.directory.server.core.trigger.TriggerInterceptor.modify(TriggerInterceptor.java:370) at org.apache.directory.server.core.api.interceptor.BaseInterceptor.next(BaseInterceptor.java:506) at org.apache.directory.server.core.event.EventInterceptor.modify(EventInterceptor.java:298) at org.apache.directory.server.core.api.interceptor.BaseInterceptor.next(BaseInterceptor.java:506) at org.apache.directory.server.core.subtree.SubentryInterceptor.modify(SubentryInterceptor.java:1220) at org.apache.directory.server.core.api.interceptor.BaseInterceptor.next(BaseInterceptor.java:506) at org.apache.directory.server.core.collective.CollectiveAttributeInterceptor.modify(CollectiveAttributeInterceptor.java:165) at org.apache.directory.server.core.api.interceptor.BaseInterceptor.next(BaseInterceptor.java:506) at org.apache.directory.server.core.operational.OperationalAttributeInterceptor.modify(OperationalAttributeInterceptor.java:449) at org.apache.directory.server.core.api.interceptor.BaseInterceptor.next(BaseInterceptor.java:506) at org.apache.directory.server.core.schema.SchemaInterceptor.modify(SchemaInterceptor.java:1206) at org.apache.directory.server.core.api.interceptor.BaseInterceptor.next(BaseInterceptor.java:506) at org.apache.directory.server.core.hash.ConfigurableHashingInterceptor.modify(ConfigurableHashingInterceptor.java:185) at org.apache.directory.server.core.api.interceptor.BaseInterceptor.next(BaseInterceptor.java:506) at org.apache.directory.server.core.exception.ExceptionInterceptor.modify(ExceptionInterceptor.java:252) at org.apache.directory.server.core.api.interceptor.BaseInterceptor.next(BaseInterceptor.java:506) at org.apache.directory.server.core.admin.AdministrativePointInterceptor.modify(Admi
Re: Custom interceptor throws NPE while calling next(opContext)
Hi Emmanuel,
Thank you for replying to my question and providing a thorough explanation. I
tried some recipes based on your response (with partial success) and that’s my
observations.
1) I have to deal with some legacy code developed by a guy who left our
company, so I’m trying not to break things and introduce very granular changes
for the same purpose
2) Directory Server created explicitly with the following code as an example:
DefaultDirectoryServiceFactory factory = new DefaultDirectoryServiceFactory()
factory.init(“xxx.ldapgw")
cs = new CacheService()
cs.initialize( null)
directoryService = factory.getDirectoryService()
directoryService.setShutdownHookEnabled(true)
directoryService.setAllowAnonymousAccess(ldapSettings.allowAnonymousAccess)
if ( ldapSettings.schemaLdif.length() > 0 ) {
def fSchema = new File(ldapSettings.schemaLdif)
if ( !fSchema.exists()) {
throw new Exception("LDIF file does not exist:" +
ldapSettings.schemaLdif)
}
auditLog.info "Loading Schemas${new
LdifFileLoader(directoryService.getAdminSession(), fSchema, null).execute()}"
}
directoryService.dnFactory = new DefaultDnFactory(
directoryService.schemaManager, cs.getCache("dnCache"))
// add our bind interceptor to the front of the list
def interceptors = directoryService.getInterceptors()
interceptors.add(0, bindInterceptor)
//
interceptors.add(findNormalizationInterceptorPosition(interceptors) + 1,
crudInterceptor)
bindInterceptor.init(directoryService)
directoryService.setInterceptors(interceptors)
directoryService.addFirst(crudInterceptor)
def adminSession = directoryService.getAdminSession()
ldapServer = new LdapServer()
ldapServer.directoryService = directoryService
...
So it’s not declarative like it’s shown in the online documentation, which I
have to admit is quite outdated. Maybe there is a place where it’s in the most
recent state?
As you can see from the file, there is a section related to interceptors, and
while setting server up, I see that my interceptors is in the middle of the
pack. I can also see that while doing “modify(opContext)” in my custom
interceptor, where opContext would reflect total number of interceptors and
current number (though still throwing NPE at next(opContext)). Nevertheless, I
tried to grab the default config.ldif from downloaded DS archive and inserted a
section related to interceptors into schemaLdif file. That didn’t really change
anything for me. I think it might be related to the fact that I can’t see
anything with Directory Browser under ou=config, after server is up. So would
be really nice if you can direct me to how I can use config.ldif while setting
the server up programmatically.
2) As you can see from the snippet, I tried to do .addFirst(crudInterceptor)
and from a first glance it worked for me, no more NPE, my custom code works
fine, but as you said, I’m not sure if that’s a right way or any complications
can be right around the corner.
Please let me know your thoughts on those two topics.
Thank you,
Philipp
===
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
Re: Custom interceptor throws NPE while calling next(opContext)
Just for the record, which ApacheDS version is this based on ?
On 23/07/2019 18:00, Philipp Grigoryev wrote:
Hi Emmanuel,
Thank you for replying to my question and providing a thorough explanation. I
tried some recipes based on your response (with partial success) and that’s my
observations.
1) I have to deal with some legacy code developed by a guy who left our
company, so I’m trying not to break things and introduce very granular changes
for the same purpose
2) Directory Server created explicitly with the following code as an example:
DefaultDirectoryServiceFactory factory = new DefaultDirectoryServiceFactory()
factory.init(“xxx.ldapgw")
cs = new CacheService()
cs.initialize( null)
directoryService = factory.getDirectoryService()
directoryService.setShutdownHookEnabled(true)
directoryService.setAllowAnonymousAccess(ldapSettings.allowAnonymousAccess)
if ( ldapSettings.schemaLdif.length() > 0 ) {
def fSchema = new File(ldapSettings.schemaLdif)
if ( !fSchema.exists()) {
throw new Exception("LDIF file does not exist:" +
ldapSettings.schemaLdif)
}
auditLog.info "Loading Schemas${new
LdifFileLoader(directoryService.getAdminSession(), fSchema, null).execute()}"
}
directoryService.dnFactory = new DefaultDnFactory(
directoryService.schemaManager, cs.getCache("dnCache"))
// add our bind interceptor to the front of the list
def interceptors = directoryService.getInterceptors()
interceptors.add(0, bindInterceptor)
//
interceptors.add(findNormalizationInterceptorPosition(interceptors) + 1,
crudInterceptor)
bindInterceptor.init(directoryService)
directoryService.setInterceptors(interceptors)
directoryService.addFirst(crudInterceptor)
def adminSession = directoryService.getAdminSession()
ldapServer = new LdapServer()
ldapServer.directoryService = directoryService
...
So it’s not declarative like it’s shown in the online documentation, which I
have to admit is quite outdated. Maybe there is a place where it’s in the most
recent state?
As you can see from the file, there is a section related to interceptors, and
while setting server up, I see that my interceptors is in the middle of the
pack. I can also see that while doing “modify(opContext)” in my custom
interceptor, where opContext would reflect total number of interceptors and
current number (though still throwing NPE at next(opContext)). Nevertheless, I
tried to grab the default config.ldif from downloaded DS archive and inserted a
section related to interceptors into schemaLdif file. That didn’t really change
anything for me. I think it might be related to the fact that I can’t see
anything with Directory Browser under ou=config, after server is up. So would
be really nice if you can direct me to how I can use config.ldif while setting
the server up programmatically.
2) As you can see from the snippet, I tried to do .addFirst(crudInterceptor)
and from a first glance it worked for me, no more NPE, my custom code works
fine, but as you said, I’m not sure if that’s a right way or any complications
can be right around the corner.
Please let me know your thoughts on those two topics.
Thank you,
Philipp
===
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
Re: Custom interceptor throws NPE while calling next(opContext)
So this is M23. 3 years old. Hmmm. We should have released more often,
considering it's currently M25.
Regardless, answering to your questions now...
On 23/07/2019 18:00, Philipp Grigoryev wrote:
Hi Emmanuel,
Thank you for replying to my question and providing a thorough explanation. I
tried some recipes based on your response (with partial success) and that’s my
observations.
1) I have to deal with some legacy code developed by a guy who left our
company, so I’m trying not to break things and introduce very granular changes
for the same purpose
I understand...
2) Directory Server created explicitly with the following code as an example:
DefaultDirectoryServiceFactory factory = new DefaultDirectoryServiceFactory()
factory.init(“xxx.ldapgw")
cs = new CacheService()
cs.initialize( null)
directoryService = factory.getDirectoryService()
directoryService.setShutdownHookEnabled(true)
directoryService.setAllowAnonymousAccess(ldapSettings.allowAnonymousAccess)
if ( ldapSettings.schemaLdif.length() > 0 ) {
def fSchema = new File(ldapSettings.schemaLdif)
if ( !fSchema.exists()) {
throw new Exception("LDIF file does not exist:" +
ldapSettings.schemaLdif)
}
auditLog.info "Loading Schemas${new
LdifFileLoader(directoryService.getAdminSession(), fSchema, null).execute()}"
}
directoryService.dnFactory = new DefaultDnFactory(
directoryService.schemaManager, cs.getCache("dnCache"))
// add our bind interceptor to the front of the list
def interceptors = directoryService.getInterceptors()
interceptors.add(0, bindInterceptor)
//
interceptors.add(findNormalizationInterceptorPosition(interceptors) + 1,
crudInterceptor)
bindInterceptor.init(directoryService)
It's not necessary. init() will be called when the addFirst() method
will be called.
directoryService.setInterceptors(interceptors)
directoryService.addFirst(crudInterceptor)
def adminSession = directoryService.getAdminSession()
ldapServer = new LdapServer()
ldapServer.directoryService = directoryService
...
So it’s not declarative like it’s shown in the online documentation, which I
have to admit is quite outdated. Maybe there is a place where it’s in the most
recent state?
No. This is still a work in progress...
As you can see from the file, there is a section related to interceptors, and
while setting server up, I see that my interceptors is in the middle of the
pack. I can also see that while doing “modify(opContext)” in my custom
interceptor, where opContext would reflect total number of interceptors and
current number (though still throwing NPE at next(opContext)). Nevertheless, I
tried to grab the default config.ldif from downloaded DS archive and inserted a
section related to interceptors into schemaLdif file. That didn’t really change
anything for me. I think it might be related to the fact that I can’t see
anything with Directory Browser under ou=config, after server is up. So would
be really nice if you can direct me to how I can use config.ldif while setting
the server up programmatically.
Th ecurrent version, as M23, is now starting the server and configure it
using the LDIF file that is stored on disk. If you look at the
UberJarMain file, which is the starting point of the whole system, it
takes an argument which is the layout (ie, the place where all your
server config/data etc are stored), then call start(), then
ApacheDsService.start(), which load the schema, initialize the config
partition, read it, and create instance of XXXBean:
initSchemaManager( instanceLayout );
DnFactory bootstrapDnFactory = new DefaultDnFactory(
schemaManager, 100 );
initSchemaLdifPartition( instanceLayout, bootstrapDnFactory );
initConfigPartition( instanceLayout, bootstrapDnFactory );
// Read the configuration
ConfigPartitionReader cpReader = new ConfigPartitionReader(
configPartition );
ConfigBean configBean = cpReader.readConfig();
ConfigBean contains the whole config for your server. Then the
initDirectoryService() method is called, which create the DirectoryService:
DirectoryService directoryService =
ServiceBuilder.createDirectoryService( directoryServiceBean,
instanceLayout, schemaManager );
This is where the interceptors get loaded, the Map computed.
If you follow the same steps, you should be good to go. At the end, it's
really all about defining the proper config file.
2) As you can see from the snippet, I tried to do .addFirst(crudInterceptor)
and from a first glance it worked for me, no more NPE, my custom code works
fine, but as you said, I’m not sure if that’s a right way or any complications
can be right around the corner.
It depends :-)
The interceptors order is critical for the server to work well. It would
make no sense for inst
Re: Custom interceptor throws NPE while calling next(opContext)
> On Jul 23, 2019, at 5:24 PM, Emmanuel Lécharny wrote: > > So this is M23. 3 years old. Hmmm. We should have released more often, > considering it's currently M25. Nothing actually stops me from trying to update to the latest. I think I even tried to do that, but then ran into some minor things, so decided not to bring more changes into the equation, until I have a working solution. > > > Regardless, answering to your questions now... > > >> >> 2) Directory Server created explicitly with the following code as an example: >> >> >> // add our bind interceptor to the front of the list >> def interceptors = directoryService.getInterceptors() >> interceptors.add(0, bindInterceptor) >> >> // >> interceptors.add(findNormalizationInterceptorPosition(interceptors) + 1, >> crudInterceptor) >> >> bindInterceptor.init(directoryService) > > It's not necessary. init() will be called when the addFirst() method will be > called. Here is the first thing where I confused you. There are 2 interceptors: bind one is the legacy one, and crudInterceptor is the one I’m working on currently > > >> >> directoryService.setInterceptors(interceptors) >> directoryService.addFirst(crudInterceptor) This is the guy! >> >> As you can see from the file, there is a section related to interceptors, >> and while setting server up, I see that my interceptors is in the middle of >> the pack. I can also see that while doing “modify(opContext)” in my custom >> interceptor, where opContext would reflect total number of interceptors and >> current number (though still throwing NPE at next(opContext)). Nevertheless, >> I tried to grab the default config.ldif from downloaded DS archive and >> inserted a section related to interceptors into schemaLdif file. That didn’t >> really change anything for me. I think it might be related to the fact that >> I can’t see anything with Directory Browser under ou=config, after server is >> up. So would be really nice if you can direct me to how I can use >> config.ldif while setting the server up programmatically. > > > Th ecurrent version, as M23, is now starting the server and configure it > using the LDIF file that is stored on disk. If you look at the UberJarMain > file, which is the starting point of the whole system, it takes an argument > which is the layout (ie, the place where all your server config/data etc are > stored), then call start(), then ApacheDsService.start(), which load the > schema, initialize the config partition, read it, and create instance of > XXXBean: > > > initSchemaManager( instanceLayout ); > DnFactory bootstrapDnFactory = new DefaultDnFactory( schemaManager, > 100 ); > initSchemaLdifPartition( instanceLayout, bootstrapDnFactory ); > initConfigPartition( instanceLayout, bootstrapDnFactory ); > > // Read the configuration > ConfigPartitionReader cpReader = new ConfigPartitionReader( > configPartition ); > > ConfigBean configBean = cpReader.readConfig(); > > ConfigBean contains the whole config for your server. Then the > initDirectoryService() method is called, which create the DirectoryService: > > DirectoryService directoryService = > ServiceBuilder.createDirectoryService( directoryServiceBean, > instanceLayout, schemaManager ); > > This is where the interceptors get loaded, the Map computed. > > > If you follow the same steps, you should be good to go. At the end, it's > really all about defining the proper config file. Ok, thank you for some insights. I’ll try to follow your recipe. > >> 2) As you can see from the snippet, I tried to do .addFirst(crudInterceptor) >> and from a first glance it worked for me, no more NPE, my custom code works >> fine, but as you said, I’m not sure if that’s a right way or any >> complications can be right around the corner. > > > It depends :-) > > The interceptors order is critical for the server to work well. It would make > no sense for instance to have the SchemaInterceptor be the first one in the > chain, before authent or authz... > > As your interceptor deal with Bind, it's probably correct to have it at first > position. That’s actually a confusion I brought by mentioning a legacy one, as I said above. > > Now, I will ask you what is this interceptor doing ? There are other means to > implement a mechanism that manage authentication, through Authenticators. But > that is another discussion… The interceptor I’m implementing is actually capturing LDAP add/modify/delete commands and calls REST api to reflect the changes in a different system which is kinda synced with LDAP. I looked at AvlPartition.add/modify method as a possible candidate, but don’t feel like it’s the right place, or is it? Regards, Philipp -- CONFIDENTIALITY NOTICE: This message (including any attachments) contains confidential informa
Re: Custom interceptor throws NPE while calling next(opContext)
Now, I will ask you what is this interceptor doing ? There are other means to implement a mechanism that manage authentication, through Authenticators. But that is another discussion… The interceptor I’m implementing is actually capturing LDAP add/modify/delete commands and calls REST api to reflect the changes in a different system which is kinda synced with LDAP. I looked at AvlPartition.add/modify method as a possible candidate, but don’t feel like it’s the right place, or is it? If you are to call a REST api when a modification is made on the LDAP serve,r I would suggest your interceptor to be the last one in the interceptor chain: just before the modification hits the backend. Doing so would eliminate any potential operation rejection by one of the previous interceptors. Typically, if the authz interceptor reject the modification, what's the point of calling the REST api ? Unless you want to have a track of every request the server receives, and then having your interceptor in first position would make sense... - To unsubscribe, e-mail: users-unsubscr...@directory.apache.org For additional commands, e-mail: users-h...@directory.apache.org
