> On Mar 11, 2016, at 7:01 PM, Chris Pike <[email protected]> wrote: > > We need to handle the config initialization differently. See the static init > block in this class... > > https://github.com/apache/directory-fortress-core/blob/master/src/main/java/org/apache/directory/fortress/core/util/Config.java > > If this fails when the application starts, it throws an exception and is > never reinitialized. This results in all further requests throwing > NoClassDefFoundError > (http://stackoverflow.com/questions/6352215/java-why-java-lang-noclassdeffounderror-caused-by-static-field-initializ-failur)
Chris, It’s good that your eyeballs are here. Using a singleton to store config data is a caveat of this system. As such there’s been an open ticket wrt fortress config using a singleton for some time. The thing is the core depends on that class being properly instantiated, and config data loaded - early. Any changes here will reverberate across the system as a whole. Having said that I don’t disagree that it needs changing, but also want to be careful. In your comments above you point out the symptom of the problem, which is a misleading exception that occurs when something goes wrong during bootstrap which complicates problem resolution - if you’ve never seen it before. The actual problem is that fortress can’t recover once something goes wrong during config initialization - right? So with that problem description, and my concerns being duly noted, what are your recommendations, i.e. how would you load the config data, and when? Here’s some background on how the config system works. We’ll need to preserve this capability, i.e. loading data from multiple sources: https://github.com/apache/directory-fortress-core/blob/master/README-CONFIG.md Thanks, Shawn
