Le 07/01/16 12:36, Jan Sindberg a écrit : >> Fra: Shawn McKinney [mailto:[email protected]] >> Sendt: 6. januar 2016 16:44 >> Til: [email protected] >> Emne: Re: Handling missing connection to LDAP >> >> >>> On Jan 6, 2016, at 9:23 AM, Emmanuel Lécharny <[email protected]> >> wrote: >>> 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... >> Ah yes I remember now. In that scenario the runtime would always use the >> cache, in this case embedded ldap server. Worth considering down the >> road… >> >> Shawn > I like the idea of an in-memory ApacheDS in slave mode. They are still > reachable by apache directory studio and most likely also from a Fortress > Commander - could be used to emergency changes in case of network failures. > It doesn't sound too difficult (if jar-hell can be handled ... ;-). - This > is however more about network related performance and resilience - It does > not change the current situation that the LDAP must be running and fully > synchronized before anyone tries to use fortress core.
Which is a non issue, if you don't have millions of entries. If you assume that when you initialized Fortress for the very first time, it was able to access data from the remote server, then every update made on the main LDAP server will be propagated to the client in a matter of ms. > > A quick search found 18 static initializer blocks in fortress core. And then > there is stuff like this: > private static final String SAFE_TEXT_PATTERN_STRING = Config.getProperty( > GlobalIds.REG_EX_SAFE_TEXT ); We can also change that. One idea, *if* we use an embedded ApacheDS, would be to store the config in LDAP too. No more statc initializers...
