Yes, the actual problem is that fortress can't recover.
There are probably a number of ways to approach this... One simple way I was
able to get working was to change singleton pattern in Config.java to
private static Config INSTANCE = null;
public static Config getInstance() {
if(INSTANCE == null) {
LOG.info("Creating new instance");
INSTANCE = new Config();
}
return INSTANCE;
}
then in one of the factories, not loading the class name statically
public static AdminMgr createInstance(String contextId)
throws SecurityException
{
String adminClassName =
Config.getInstance().getProperty(GlobalIds.ADMIN_IMPLEMENTATION);
----- Original Message -----
From: "Shawn McKinney" <[email protected]>
To: [email protected]
Sent: Saturday, March 12, 2016 5:24:32 AM
Subject: Re: Static Config Initialization Problems
> 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
