The Alfresco repository comes with a wcm_deployment_receiversubsystem. The default 'type' is configured to use Java RMI as a transport mechanism. This page outlines the process of creating an 'http' deployment receiver type using the extension classpath mechanism.
The default id of the http deployment receiver will:
Add a /deployment servlet to alfresco's main 'web.xml' file.
Import the configured deploymentReceiverEngine bean from the wcm_deployment_receiver subsystem to a new, top-level deployment servlet file, and configure.
Edit the configuration to add the 'http-only' target locations.
Create the directory structure
There is a difference between 'what should work' according to the documentation, and 'what does work'. The desired condition is to create a specialized 'type' of WCM deployment receiver which contains all the configuration necessary for HTTP transport. This is unattainable for a couple of reasons:
The main web.xml file must be edited to add a new servlet.
Merely creating the correct directory structure, as described in the documentation, does not appear to create a new type of subsystem.
As a workaround the configuration here overrides the 'default' instance. Consider this an opportunity to contribute your knowledge to the wiki. If you know how to make subsystems work the way I wanted them to, edit this page.
What should work
NOTE: This doesn't in fact work, so don't do it. Do this instead. I leave this in so that a subsystem guru can fix it.
To create a new type of an existing subsystem, the appropriate directory needs to be created in the tomcat/shared/classes directory. The directory structure takes the following form:
Copy deployment-engine-context.xml from the configuration page to alfresco/extension/subsystems/wcm_deployment_receiver/http/default. You will need to copy the text from the wiki and paste it into a blank file.
Copy deployment-engine.properties from the configuration page to alfresco/extension/subsystems/wcm_deployment_receiver/http/default. Edit the usernames and passwords to your liking.
Edit your copy of deployment-engine-context.xml to use Alfresco authentication. (Comment out the simple authenticator and uncomment the Alfresco authenticator.)
Import the deployment targets
Append the following as the last children of the <beans> element in your modified copy of the deployment-engine-context.xml.
The desired condition is that we are essentially 'extending' the Alfresco web app with this configuration. The deployment receiver will be running on the same http server as Alfresco, which means it uses the same host and port as Alfresco. The deployment receiver is accessed by adding /deployment to Alfresco's root URL. The deployment server should be located at:
At this point, Alfresco should be configured to publish the deployment receiver on http://.../alfresco/deployment. Community users will need to restart and enterprise users can use the JMX panel to start this subsystem. All targets which are in the 'common' directory, as well as those which are in the 'http-only' directories will be accessible via http.
A caveat: by overriding the deploymentReceiverEngine and by not overriding the deploymentReceiverTransportRMI (which merely exports deploymentReceiverEngine), we have created the situation where everything which is accessible via HTTP is also accessible via RMI. It is not possible to turn the RMI interface off except by overriding the deploymentReceiverTransportRMI bean which is declared in deployment-receiver-context.xml. You may expose different targets via different interfaces by using a different name for the deploymentReceiverEngine bean everywhere in this config. Community Edition 3.2 3.2r2 AVM