Q:

Hierarchical Configuration connected to Bean Configuration

I am currently designing an application configuration. 
The application will take advantage of Spring and it could use only its XML bean context configuration, yet the requirements are set so to have some hierarchical XML configuration next to it. This will make use of beans specified in the applicationContext. 
For example, given the following:
applicationContext.xml:
<bean id="A" class="" init-method="">
    <property name="namespace" value="${namespace}"/>
</bean>

<bean id="B" class="" init-method="">
    <property name="restTemplate" ref="restTemplate"/>
</bean>

config.xml:
<configuration>
   <consumers-config>
        <consumers>
            <!--A consumer should be first defined in another configuration file-->
            <consumer bean-name="A">
                <name>A-1</name>
                <namespace>...</namespace>
            </consumer>
            <consumer bean-name="B">
                <name>B-1</name>
            </consumer>
        </consumers>
    </consumers-config>
    <works>
       <work name="1">
          <consumers>
             <consumer>A-1</consumer>
             <consumer>B-1</consumer>
          </consumers>
       </work> 
    </works>
<configuration>

As you can see from the above, the config.xml refers a lot to applicationContext, effectively making the latter a dependency. 
The need for having a hierarchical configuration is to allow users to modify such configuration without them touching the applicationContext one.
Is this an ideal situation? Are there best practices that I should consider? In other words, what is the best way to approach such a problem? 

A:

Whether this is a usable solution heavily depends on your situation and your users. What would be wrong with the users editing the applicationContext.xml directly? If it is just for organization in files so that you know in which file which settings can be found and that your own special XML Syntax is more readable, then you can also simply use the <import> tag to include another spring xml configuration file that can be edited by the user. You can also create your own XML namespace so that you can use your own XML format in this file possibly making that file more readable.
However if your motivation to separate those file is that the files can be maintained independently and that users that don't understand the applicationContext.xml can edit that file or even that it is a security problem if users can edit that file, then this solution is a problem. You could of course solve this problems by specifying an explicit list of beans that are like an interface available to the editor of your config.xml file and run validations on the XML file to make sure that ONLY your namespace is used (which may not contain tags that maybe a security risk) and also validate that only bean names are references that are published in your API, but it will make maintenance harder and increases the risk for a security problem. To propose a better solution in this case will however require more indepth knowledge about what your requirements actually are and what you are trying to achieve.

