Le 06/01/16 16:05, Shawn McKinney a écrit : >> On Jan 6, 2016, at 8:52 AM, Emmanuel Lécharny <[email protected]> wrote: >> >> Le 06/01/16 15:00, Jan Sindberg a écrit : >>> If there is no connection to the LDAP, then it is no longer possible to >>> create an AccessMgrFactory. >>> >>> First we get: >>> org.apache.directory.fortress.core.CfgRuntimeException: static init: Error >>> loading from cfg file: [fortress.properties] >>> SecurityException=org.apache.directory.fortress.core.FinderException: >>> getConfig dn [cn=DEFAULT,ou=Config,dc=example,dc=com] caught >>> LdapException=INVALID_CREDENTIALS: Bind failed: ERR_316 Directory service >>> is not started., errCode=127 >>> >>> On subsequent calls we get: >>> java.lang.NoClassDefFoundError: Could not initialize class >>> org.apache.directory.fortress.core.AccessMgrFactory >>> >>> Is there a way to handle this and make the Fortress core api reconnect >>> later? >> Complicated... >> >> Fortress is storing all the Authz information in a remote server, and if >> it's not reachable, then you won't be able to make any decision. >> >> AFAIR, we had internal discussion about setting up a local cache within >> the API to allow Fortress to keep going even if the remote LDAP server >> is down. I'm not sure it's in Fortress atm, and I'm not sure we decided >> anything about such an addition... >> >> Shawn ? > I think it would be a lot of work to satisfy a corner case. But you might > wonder why instantiating a manager component is hitting the remote server in > the first place. The reason is fortress stores much of its parameters on the > remote server itself in a configuration node. > > For explanation check out this writeup: > https://github.com/apache/directory-fortress-core/blob/master/README-CONFIG.md > > The runtime is in the process of pulling back that config info when it gets > the connection error and gives up. > > There might be a case where we want to delay hitting that server, or maybe > allow it to retry later, i.e. at regular intervals. Not as complicated as > caching the information, but tricky. It would require rewiring how the > configuration subsystem and ldap pooling mechanisms work. Worth considering, > but we need to be careful here, no guarantees against overcomplicating or > creating new problems. > > Shawn AFAIR, when we had this conversation (probably 2 years ago), we talked about using an embedded ApacheDS server in the Fortress API, server that would be synced with the remote LDAP server.
This is far from being a simple architecture...
