Programování

First post of this series ended with code snippet, which invokates importAction itself. It’s not still the importing itself, but we are almost there. This post will be about what happenes, what hapened before and what is going to happen . But first things first, let’s have a look on Factory and Proxy pattern, which are used while calling imports.

Factory pattern is based on idea instead of creating a new object with new operator, factory is asked, which returns a new instance. This is way standard Spring’s bean factory works. It may looks like following diagram (image is from oodesign.com):

Factory Pattern (click for source - oodesign.com)

To hide newly created instance behind an interface facade Proxy pattern is used. This functionality is imho basic of AOP programming, because instead of calling original object, something else may be called. Have a look on following diagram (again from oodesign.com):

Proxy Pattern (click for source - oodesign.com)

Now it’s possible to put those patterns together and get real importAction functionality: importAction is just an interface, which hides importActionImpl newly created for every request. This can be seen on following snippet of application context configuration.

<bean id="ImportAction" class="org.springframework.aop.framework.ProxyFactoryBean">
    <property name="targetName" value="importAction"/>
    <property name="singleton" value="false"/>
    <property name="proxyInterfaces">
        <list>
            <value>cz.shmoula.imports.ImportAction</value>
        </list>
    </property>
</bean>

<bean id="importAction" class="cz.shmoula.imports.ImportActionImpl" scope="prototype" />

As I wrote a while before – all of this is done due to posibility of calling something else. But back to implementation, for details refer to some AOP documentation. Method importAction.invocateImportScript() is a pointcut, on which two advisors are bound. Have a look at following diagram.

ImportActionAdvice

This configuration can be achieved by NameMatchMethodPointcutAdvisor, see following snippet for ImportContentAdvisor bean definition and updated ImportAction itself:

<bean id="importContentAdvice" class="cz.shmoula.imports.ImportContentAdvice" />

<bean id="ImportContentAdvisor" class="org.springframework.aop.support.NameMatchMethodPointcutAdvisor">
    <property name="advice" ref="importContentAdvice"/>
    <property name="mappedNames">
        <list>
            <value>invocateImportScript</value>
        </list>
    </property>
</bean>

<bean id="ImportAction" class="org.springframework.aop.framework.ProxyFactoryBean">
    <property name="targetName" value="importAction"/>
    <property name="singleton" value="false"/>
    <property name="proxyInterfaces">
        <list>
            <value>cz.shmoula.imports.ImportAction</value>
        </list>
    </property>
    <property name="interceptorNames">
        <list>
            <value>ImportContentAdvisor</value>
            <value>DeployContentAdvisor</value>
        </list>
    </property>
</bean>

<bean id="importActionTask" class="cz.shmoula.imports.ImportActionTask" scope="prototype">
    <property name="importAction" ref="ImportAction"/>
</bean>

Last few lines is definition of importActionTask I wrote in previous post. In this class importAction.invocateImportScript() method is called. This method has one parameter – map of properties of config file (in format <QName, Serializable>) to read them once and have them all the time and not need to call nodeService.getProperties() again and again – in advisors or importAction class. When this method is called, proxy of importAction catches this calling and calls invoke() method on ImportContentAdvice and DeployContentAdvice. Let’s have a look on invoke() method in ImportContentAdvice:

public Object invoke(MethodInvocation invocation) throws Throwable {
    Object[] objects = invocation.getArguments();
    Object result = null;
    Map<QName, Serializable> propertiesMap = __resolve_arguments_to_map_(objects);

    String lockToken = (String) propertiesMap.get(ContentModel.PROP_NODE_UUID);
    setTokenOnTarget(invocation, lockToken);

    try {
        AuthenticationUtil.setRunAsUser(AuthenticationUtil.getSystemUserName());
        misLockingService.createLock(lockToken);

        object = invocation.proceed();

        misLockingService.releaseLock(lockToken);
    } finally {
        AuthenticationUtil.clearCurrentSecurityContext();
    }

    return result;
}

All what ImportActionAdvice does can be seen on previous snippet. It locks used config file to prevent access from another thread, using node uuid as a locking token. Then it authenticates a system user (mainImportThread runs outside any security context) and invocates next chain (DeployContentAdvisor and after then invocateImportScript(), if everything goes ok). After return from invocation lock is released and security context is cleared. If anything happens inside, lock release is skipped, so some rescue mechanisms are automaticaly initiated after some time. Simple, yet effective, i hope.

While creating import services I want some configuration mechanism for (not just) BatchProcessor. I like Alfresco’s *-config-custom.xml files (aka Spring framework XMLConfigService), so I did simple custom config service.

Anyone, who customized Alfresco, knows format of this file (web-client-config-custom.xml). I put that structure to new file – mis-config-custom.xml:

<alfresco-config>
    <config evaluator="string-compare" condition="imports">
        <processor>
            <worker-threads-num>3</worker-threads-num>
            <batch-size-num>6</batch-size-num>
            <split-transactions>false</split-transactions>
            <logging-interval>1000</logging-interval>
        </processor>
        <token>
            <time-refresh>1000</time-refresh>
            <time-expiration>20000</time-expiration>
        </token>
    </config>
</alfresco-config>

Please note those constants are just for ilustration purposes now, more on them in scripting series. My MisConfigService extends org.springframework.extensions.config.xml.XMLConfigService, but uses nothing from that class (except init method in bootstrap), I just added some statics inside to keep things together:

public class MisConfigService extends XMLConfigService {
    public MisConfigService(ConfigSource configSource) {
        super(configSource);
    }

    public static String getChildValue(Config config, String elementId, String childName, String defaultValue) {
        ConfigElement myConfig = config.getConfigElement(elementId);
        String result = myConfig.getChildValue(childName);

        return (result==null ? defaultValue : result);
    }

    public static Integer getChildValue(Config config, String elementId, String childName, Integer defaultValue) {
        Integer result = defaultValue;
        try {
            String number = getChildValue(config, elementId, childName, defaultValue.toString());
            result = Integer.parseInt(number);
        } finally { /* O:-) */ }
        return result;
    }

        . . .
}

To instantiate this service just add bean definition with UrlConfigSource(-s), which defines path to custom xml configuration:

<bean id="misConfigService" class="cz.mis.service.MisConfigService" init-method="init">
    <constructor-arg>
        <bean class="org.springframework.extensions.config.source.UrlConfigSource">
            <constructor-arg>
                <list>
                    <value>classpath:alfresco/extension/mis-config-custom.xml</value>
                </list>
            </constructor-arg>
        </bean>
    </constructor-arg>
</bean>

Now it’s possible to access those properties in code like this:

org.springframework.extensions.config.Config config = configService.getConfig(imports");
Boolean splitTransactions = MisConfigService.getChildValue(config, "processor", "split-transactions", false);

It’s also possible to access attributes of nodes in that config:

ConfigElement myConfig = config.getConfigElement("config-element");
for(ConfigElement child : myConfig.getChildren()) {
    // child.getAttributes()
    // child.getName()
    // child.getValue()
}

That’s all! And now for something completely different! I also spent some time trying to get properties files working and putting those properties into Spring configurations. There’s nice solved thread in Alfresco forums. Prefix helps:

<bean class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">
    <property name="locations">
        <list>
            <value>classpath*:alfresco/extension/mis-settings.properties</value>
        </list>
    </property>
    <property name="ignoreResourceNotFound" value="true" />
    <property name="placeholderPrefix" value="${mis:" />
    <property name="placeholderSuffix" value="}" />
</bean>

<!-- and I can use stuff from properties file with prefix -->
<bean class="foo.bar.Example">
    <property name="fooAttribute">
        <value>${mis:some.sample.property}</value>
    </property>
</bean>