HTTP Instance of WCM deployment receiver

Document created by resplin Employee on Jun 6, 2015
Version 1Show Document
  • View in full screen mode

Obsolete Pages{{Obsolete}}

The official documentation is at: http://docs.alfresco.com



{{AVMWarning}}


Objectives


The Alfresco repository comes with a wcm_deployment_receiver subsystem. 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:


  • Incorporate the Deployment Receiver Engine Configuration (which was developed separately).
  • Provide a baseline which can be used to create other types of this subsystem, representing other transports.
  • Provide a separate directory for deployment targets which will only be available via http.
  • Make available via http all of the 'common' targets which are defined in the places that the default deployment receiver type currently looks.

Prerequisites


The Alfresco server must be configured to start the wcm_deployment_receiver subsystem. Add the wcm-bootstrap-context.xml from the WCM download to your shared/classes/extension/alfresco directory.


Approach


  1. Create the appropriate directory structure in the extension directory.
  2. Copy deployment-engine-context.xml from the configuration page to the appropriate directory.
  3. Add a /deployment servlet to alfresco's main 'web.xml' file.
  4. Import the configured deploymentReceiverEngine bean from the wcm_deployment_receiver subsystem to a new, top-level deployment servlet file, and configure.
  5. 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:


  1. The main web.xml file must be edited to add a new servlet.
  2. 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:



alfresco/extension/subsystems/<category>/<type>/<id>

In the above, 'category' is wcm_deployment_receiver, 'type' is 'http', and 'id' is 'default'.  Create directories such that the following path exists:



alfresco/extension/subsystems/wcm_deployment_receiver/http/default

What does work


Note: This is the workaround described above. Do this.

To override the default instance of a subsystem, the appropriate directory needs to be created in the tomcat/shared/classes directory. The directory structure takes the following form:



alfresco/extension/subsystems/<category>/default/default

In the above, 'category' is wcm_deployment_receiver. Create directories such that the following path exists:



alfresco/extension/subsystems/wcm_deployment_receiver/default/default

Copy the deployment receiver config


  1. 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.
  2. 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.
  3. 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.



    <import resource='classpath*:alfresco/deployment/*-target.xml' />
    <import resource='classpath*:alfresco/extension/deployment/*-target.xml' />
    <import resource='classpath*:alfresco/deployment/http/*-target.xml' />
    <import resource='classpath*:alfresco/extension/deployment/http/*-target.xml' />

Publish the service


Edit Alfresco's web.xml


To share URL space with the main Alfresco application, it is necessary to declare a new servlet and url mapping in the web.xml file. Add the following text near the other servlet declarations.



   <servlet>
      <servlet-name>deployment</servlet-name>
      <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
      <load-on-startup>10</load-on-startup>
   </servlet>
  
   <servlet-mapping>
      <servlet-name>deployment</servlet-name>
      <url-pattern>/deployment</url-pattern>
   </servlet-mapping>

deployment-servlet.xml


Create a new deployment-servlet.xml file in tomcat's webapps/alfresco/WEB-INF directory, which does the following:


  1. Imports the deploymentReceiverEngine from the wcm_deployment_receiver subsystem.
  2. Creates a HttpInvokerServiceExporter bean to expose the deploymentReceiverEngine
  3. Maps the /deployment URL path to the http invoker.

The file should contain the following:



<beans>
    <bean id='deploymentReceiverEngine' class='org.alfresco.repo.management.subsystems.SubsystemProxyFactory'>
        <property name='sourceApplicationContextFactory'>
            <ref bean='wcm_deployment_receiver' />
        </property>
        <property name='sourceBeanName'>
            <value>deploymentReceiverEngine</value>
        </property>
        <property name='interfaces'>
            <list>
                <value>org.alfresco.deployment.DeploymentReceiverTransport</value>
            </list>
        </property>
    </bean>
   
    <bean id='deploymentReceiverTransportHTTP'
        class='org.springframework.remoting.httpinvoker.HttpInvokerServiceExporter'>
        <property name='service'>
            <ref bean='deploymentReceiverEngine'/>
        </property>
        <property name='serviceInterface'>
            <value>org.alfresco.deployment.DeploymentReceiverTransport</value>
        </property>
    </bean>
    <bean id='urlMapping' class='org.springframework.web.servlet.handler.SimpleUrlHandlerMapping'>
        <property name='mappings'>
            <props>
                <prop key='/deployment'>deploymentReceiverTransportHTTP</prop>
            </props>
        </property>
    </bean>
</beans>

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:



http://my.alfresco.server:port/alfresco/deployment




Result


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

Attachments

    Outcomes