[jira] [Commented] (FC-26) Make it possible to programatically configure Fortress

["Emmanuel Lecharny (JIRA)" <ji...@apache.org>]

    [ 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)