[
https://issues.apache.org/jira/browse/FC-26?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14189959#comment-14189959
]
Emmanuel Lecharny commented on FC-26:
-------------------------------------
There are many aspects to cover here.
First, the Config class is statically initialized, as it's statically used in
the other classes :
{code}
private static String accelClassName =
Config.getProperty(GlobalIds.ACCEL_IMPLEMENTATION);
{code}
Which means we will have to change the way the constants are loaded in many
classes, as the configuration will not anymore be loaded while the Config class
will be loaded.
OTOH, calls like the one above can probably be removed, because the value will
be initialized during the class instance creation :
{code}
public static AccelMgr createInstance(String contextId)
throws SecurityException
{
VUtil.assertNotNull(contextId, GlobalErrIds.CONTEXT_NULL, CLS_NM +
".createInstance");
if (!VUtil.isNotNullOrEmpty(accelClassName))
{
accelClassName = AccelMgrImpl.class.getName();
}
{code}
(note that raises another concern : what is the cost of creating the binding
everytime we create an instance of a manager ? Wouldn't it be a better idea to
cache the bound method, and reuse it ? Typically, we are talking about 2
different ways to get connected to the API, either using Java or using Rest...)
The second usage of the Config class is in the GlobalIds class, with all the
fields being static too 7 fields are initialized from the config file there).
It's probably an option to use the config instance directly, instead of using
those fields.
Otherwise, there are many parameters that are requested on the fly, like in
this method :
{code}
protected String getRootDn( String contextId )
{
StringBuilder dn = new StringBuilder();
...
else
{
dn.append( Config.getProperty( GlobalIds.SUFFIX ) );
}
{code}
Here, we typically have a dynamic configuration, that might evolve after the
API startup. For those calls, a instance of the config clss could be used :
{code}
dn.append( configInstance.getProperty( GlobalIds.SUFFIX ) );
{code}
So the biggest issue is how to define a dynamic system, that will require a
init phase when starting the API, without having to read the configuration.
It's likely that every class will have to be initialized explicitly instead of
statically.
One solution would be to separate the instance creation from the init phase.
Even if it's convenient to have an API which is auto-configured, it's not too
demanding to require our users to explicitely initialize the API before using
it. W ecan even have both world, if we have a mechanism that detects the
presence of a config file on disk, and if so, read it, and initialize
everything, otherwise expect the user to call an apiInit( config ) method that
does the job. Of course if none of those two things is done, we will end in
error.
thoughts ?
> Make it possible to programatically configure Fortress
> ------------------------------------------------------
>
> Key: FC-26
> URL: https://issues.apache.org/jira/browse/FC-26
> Project: FORTRESS-CORE
> Issue Type: New Feature
> Affects Versions: 1.0-RC27
> Reporter: Emmanuel Lecharny
> Fix For: 1.0.0
>
>
> Currently, all the fortress configuration is done though a configuration file.
> It would be very convenient to be able to configure Fortress without
> depending on a configuration file.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
