The Alfresco spring context file load order for services etc is controlled by application-context.xml. The last bean defined with a given name wins, so if Alfresco ships with a bean definition for
fooServiceand you define your own one later with the same name, yours will be used. Handily, as shown in that context file, spring context files in /extensions/ and /modules/ are loaded late, so your modules can include override services.
The picture is not quite so rosy for overriding the built-in webscripts. Here, the key context file is web-application-context.xml. This loads application-context.xml which we saw above, and then it loads the web scripts. This means that the built-in webscritps are always loaded after modules, so your module can never override a built in webscript.
However, at the bottom of that file we see the answer - we need to provide a single alfresco/extension/custom-web-context.xm
For my current project, we have added the following file as alfresco/extension/custom-web-context.xm
<?xml version='1.0' encoding='UTF-8'?> <!DOCTYPE beans PUBLIC '-//SPRING//DTD BEAN//EN' 'http://www.springframework.org/dtd/spring-beans.dtd'> <beans> <import resource="classpath*:alfresco/module/*/module-webscripts-context.xml" /> </beans>All of our Repository modules already had a module-context.xml file in alfresco/module/<name>/. Those that need to override webscripts can now also provide a second file in that directory, module-webscripts-context.xml, and any webscripts defined in there can be guaranteed to win and be used.
(The new custom-web-context.xml file can be bundled in a jar, shipped in an existing AMP, packaged as a brand new AMP, or dropped in your classes override directory similar to your repository properties file - it all depends what'll be cleaner for your setup)