The real issue is that exceptions thrown in static initialization cause unrecoverable problems with the classloader. The static block in Config would be changed into an init() method that gets called by the constructor. So the getInstance() method would fail until a connection could be established. See the link below for an example of the modified Config class.
https://github.com/PennState/directory-fortress-core-1/blob/feature/modifyBootstrapSingleton/src/main/java/org/apache/directory/fortress/core/util/Config.java#L75 Any class using Config would need modified to call getInstance first and not call it in a static context. ----- Original Message ----- From: "Shawn McKinney" <[email protected]> To: [email protected] Sent: Tuesday, March 15, 2016 4:58:16 PM Subject: Re: Static Config Initialization Problems > On Mar 15, 2016, at 3:38 PM, Chris Pike <[email protected]> wrote: > > In this example, is your concern looking up the property? > PropertiesConfiguration in Config is loaded only once, so I can't imagine > that looking up a property is that inefficient. > > If it is we could create a variable and a getter in Config, something like... > > public String getAdminImplementation(){ > if(adminClassName == null){ > adminClassName = config.getProperty(GlobalIds.ADMIN_IMPLEMENTATION); > } > > return adminClassName; > } > > then in the factory > > String adminClassName = Config.getInstance().getAdminImplementation(); I misunderstood your approach. I thought you were saying each manager should gets its own instance of a Config object which would load all of the properties again and be heavy. Looking up a few properties is not a concern. I am wondering how this will help the system recover. If the objective is to (re)connect to an ldap server for example after bootstrap.
