|Overriding built-in Java backed WebScripts in Alfresco
||[Jan. 30th, 2013|03:27 pm]
Generally, Alfresco makes it fairly easy for you to override the built-in core repository Services. There's this wiki page and this one to get you started, then once you know about Spring you can largely make it happen.
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
fooService and 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.xml which pulls in our module webscripts. That gets loaded last, so will win!
For my current project, we have added the following file as alfresco/extension/custom-web-context.xml
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE beans PUBLIC '-//SPRING//DTD BEAN//EN' 'http://www.springframework.org/dtd/spring-beans.dtd'>
<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)