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();
----- Original Message -----
From: "Shawn McKinney" <[email protected]>
To: [email protected]
Sent: Tuesday, March 15, 2016 12:24:51 PM
Subject: Re: Static Config Initialization Problems
Apologize for delay responding, am traveling atm….
> On Mar 12, 2016, at 7:41 AM, Chris Pike <[email protected]> wrote:
>
> 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);
With this approach we’re going to be adding weight to the instantiation of the
manger impl which up to now have been very light. My concern are usage patters
where these managers are created and discarded and don’t need to be held onto.
Shawn
