Alfresco provides a powerful way of customizing content via user-defined behaviors. These behaviors allow you to create reusable pieces of code which gets executed each type a custom "actions" happens on your content. These custom actions include: creation of content, updating of content, adding aspects and so onmore.

If you're familiar with Aspect-Oriented Programming (AOP)AOP, you can think of these behaviors as cross-cutting concerns.

Policies

The technical means by which you bind a behavior to an action in Alfresco is called a policy. These policies define the pointcuts at which the behaviors are applied. Alfresco 3.3 comes, out of the box, with the following policies:

• AsynchronousActionExecutionQueuePolicies
• CheckOutCheckInServicePolicies
• ContentServicePolicies
• CopyServicePolicies
• NodeServicePolicies
• VersionServicePolicieVersionServicePolicy

Each of those is basically a top-level interface, with a lot of inner interfaces that should be implemented depending on your requirements. For example, if you want to execute a certain piece of code each time the properties of a content are changed, you would implement:

NodeServicePolicies.OnUpdatePropertiesPolicy in your own custom class and then map it in your custom Spring context.

Alfresco triggers these policies from its core services. In the above example, NodeService's default implementation would be the one responsible for calling the OnUpdatePropertiesPolicy.

AVM

All is fine and dandy if you're working with Alfresco ADM, but when it comes to working with AVM content, you may notice these behaviors don't work anymore, because Alfresco doesn't trigger the policies.

As it turns out, even though the AVM is built on top of the ADM, there are special service implementations for working with AVM content. For example, the NodeService implementation used in AVM is called AVMNodeService.

The reason, why in Alfresco 3.3.x or 3.4 the custom policies aren't triggered in Alfresco 3.3.x or 3.4, is because of the wayhow these services are configured in Spring. You can, hHowever, you can overcome this limitation by overwriting the AVM service beans in your own custom Spring context, like this:

<bean id="avmNodeService" class="org.alfresco.repo.avm.AVMNodeService" init-method="init">
    <property name="dictionaryService">
        <ref bean="dictionaryService"/>
    </property>
    <property name="avmService">
        <ref bean="avmService"/>
    </property>
    <property name="policyComponent">
        <ref bean="policyComponent"/>
    </property>
    <property name="tenantService">
        <ref bean="tenantService"/>
    </property>
    <property name="invokePolicies" value="true"/>
</bean>

Good thing you can overwrite beans in Spring.