Obsolete Pages{{Obsolete}}
The official documentation is at: http://docs.alfresco.com
{{AVMWarning}}
This is an example of how to configure more than one File System Deployment Target in the same Deployment Receiver Engine, regardless of whether that deployment receiver is running in stand alone mode or within Alfresco. This example also omits any mention of the transport protocol (Java RMI or HTTP), as this is configured externally. Please note that this is not a complete, end-to-end example of how to configure the stand-alone deployment receiver. This example also completely ignores any configuration which takes place on the authoring server. We consider only the common configuration required of any deployment receiver.
This example focuses on configuration which achieves the following objectives:
The resultant directory structure, assuming deployment targets named web1, web2 ... webN, is:
This configuration example requires that the following properties be set correctly:
Property | Sets Property | On Component | Description |
---|---|---|---|
deployment.filesystem.errorOnOverwrite | errorOnOverwrite | File System Receiver Service | Flag indicating whether overwriting files unrelated to the deployment is an error condition. |
deployment.filesystem.baseDir | base of all paths | File System Receiver Service, File System Deployment Target | Path to base of the directory structure |
deployment.filesystem.autofix | autoFix | File System Deployment Target | Flag to control the automatic repair of metadata. |
A rough outline of the approach is as follows:
Two beans are common to all targets: the File System Receiver Service and its housekeeper. In deployment-receiver-context.xml, which I am using as a starting point for this example, the housekeeper does not appear to be used. Therefore it will also appear to not be used in the following configuration file.
Conceptual details of the configuration follow:
Property | Value |
---|---|
errorOnOverwrite | ${deployment.filesystem.errorOnOverwrite} |
dataDirectory | ${deployment.filesystem.baseDir}/temp |
logDirectory | ${deployment.filesystem.baseDir}/logs |
commandQueue | bean ref: deploymentReceiverCommandQueue |
Property | Value |
---|---|
fileSystemReceiverService | bean ref: fileSystemReceiverService |
<beans>
<bean id='fileSystemReceiverService' class='org.alfresco.deployment.impl.fsr.FileSystemReceiverServiceImpl'
init-method='init'>
<property name='errorOnOverwrite'><value>${deployment.filesystem.errorOnOverwrite}</value></property>
<property name='dataDirectory'>
<value>${deployment.filesystem.baseDir}/temp</value>
</property>
<property name='logDirectory'>
<value>${deployment.filesystem.baseDir}/logs</value>
</property>
<property name='commandQueue'><ref bean='deploymentReceiverCommandQueue' /></property>
</bean>
<bean id='fileSystemReceiverHousekeeper' class='org.alfresco.deployment.impl.fsr.FileSystemReceiverHousekeeper'
init-method='init'>
<property name='fileSystemReceiverService'><ref bean='fileSystemReceiverService'/></property>
</bean>
<import resource='classpath*:alfresco/deployment/*-fsr.xml' />
<import resource='classpath*:alfresco/extension/deployment/*-fsr.xml' />
</beans>
The objective of making a template is so that targets can be quickly declared with minimal editing. In this case, the only parameter required to fill in the template is the target name. Any text editor (or sed for that matter) should be capable of instantiating this template quickly.
The template creates only two beans, and one is a utility which is used to register the target with the deployment engine. Both beans are anonymous (i.e., they have no id property.) Conceptual details follow:
Property | Value |
---|---|
name | TARGET |
registry | bean ref: deploymentReceiverEngine |
target | bean definition (see below) |
Property | Value |
---|---|
name | TARGET |
rootDirectory | ${deployment.filesystem.baseDir}/TARGET/data |
metaDataDirectory | ${deployment.filesystem.baseDir}/TARGET/metadata |
autoFix | ${deployment.filesystem.autofix} |
authenticator | bean ref: targetAuthenticator |
fileSystemReceiverService | bean ref: fileSystemReceiverService |
<beans>
<bean class='org.alfresco.deployment.impl.server.DeploymentTargetRegistrationBean'
init-method='register'>
<property name='name'>
<value>TARGET</value>
</property>
<property name='registry'>
<ref bean='deploymentReceiverEngine'/>
</property>
<property name='target'>
<bean class='org.alfresco.deployment.impl.fsr.FileSystemDeploymentTarget'
init-method='init'>
<property name='rootDirectory'>
<value>${deployment.filesystem.baseDir}/TARGET/data</value>
</property>
<property name='metaDataDirectory'>
<value>${deployment.filesystem.baseDir}/TARGET/metadata</value>
</property>
<property name='autoFix'>
<value>${deployment.filesystem.autofix}</value>
</property>
<property name='fileSystemReceiverService'>
<ref bean='fileSystemReceiverService'/>
</property>
<property name='name'>
<value>TARGET</value>
</property>
<property name='authenticator'>
<ref bean='targetAuthenticator'/>
</property>
</bean>
</property>
</bean>
</beans>
To customize the above template, simply do a case-sensitive global search and replace. Replace the string TARGET with the name you have chosen for your target. Because this name will appear in the path, it should be a legal directory name on whatever system you plan on running your filesystem deployment receiver. Wise users will avoid spaces and special characters.
After the substitution is done, save the file as {your directory name here}-fsr.xml.
The proper location to install the files depends on whether you are running the stand alone deployment receiver or your receiver is running within Alfresco itself.
The pattern in this file may be used to support more than one 'series' of deployment targets. Take, for instance, the situation where one base directory contains all web projects to be served by Apache httpd, and another base directory contains all web projects to be served by Apache Tomcat. Instead of performing the configuration on this page once, resulting in a single deployment-fsr-target.xml and the associated directory files {directory}-fsr.xml, it would be necessary to perform the configuration once for each collection of directories. If the two series were 'httpd' and 'tomcat':
Any target configured as a 'Test' server will likely fail. Before trying to debug your target configuration too much, just configure it as a 'Live' server and see if the error persists. See ALF-1527. It looks like this is fixed on head right now and will be fixed in the Community 3.3 release.