Overriding Spring Configuration

Document created by resplin Employee on Jun 6, 2015
Version 1Show Document
  • View in full screen mode

Obsolete Pages{{Obsolete}}

The official documentation is at: http://docs.alfresco.com


As of Alfresco version 3.2, most basic configuration requirements can be met easily by editing the alfresco-global.properties file, which controls the environment-specific parameters read by Alfresco. See Developer Runtime Configuration for more details. However, for more advanced customization requirements such as plugging in custom code components, Alfresco provides a mechanism for supplementing and overriding the actual Spring bean definitions themselves.


Your custom spring bean definitions should live in a file alfresco/extension/dev-context.xml in the classpath of your application server. There are two main alternatives for ensuring this file shows up in the classpath.

Adding to the global classpath

On Tomcat installations, you can add your dev-context.xml to the global classpath by copying it to $TOMCAT_HOME/shared/classes/alfresco/extension/dev-context.xml. This means that your custom settings will be remembered between .war file deployments, or perhaps between context switches to different Alfresco versions. Other application servers provide mechanisms for controlling their global classpath. Consult your application server documentation, or refer to Alfresco's notes on your Application Server on this Wiki.

Embedding in your build

If instead, you'd like the dev-context.xml file to be incorporated directly into a .war file,
then copy it to the following location within the source code tree before building alfresco:


However, this requires that you do this for every source code branch you're working on;  this can be tedious & error-prone, depending on how often you create working copies of source code branches.

Example contents

Below is an example of a dev-context.xml file that defines a bean myExtraBean in the Spring container. If myExtraBean happened to be the ID of a preconfigured Alfresco bean, then this definition would override and replace the product default configuration of the bean. If (as is most likely the case here) myExtraBean is a new unique name, the bean will supplement the existing beans in the preconfigured product.


    <bean id='myExtraBean' class='com.company.MyExtraBeanClass'>
        <property name='someProperty'>


Customizing and Extending