Configuration file vs multi XML configuration

In 1.2 you have been using a single synapse.xml file which resides on the repository/conf directory of the distribution, where as on 2.0.0 we have structured this into a configuration repository with multiple directories to have different artifact types and each and every artifact configuration to reside on a different files inside the desired repository directory. This repository directory on the 2.0.0 release resides in the repository/conf directory too, and named as synapse-config. The repository directory structure inside the synapse-config directory looks like follows;

synapse-config
    /endpoints
    /event-sources
    /local-entries
    /priority-executors
    /proxy-services
    /sequences
        main.xml
        fault.xml
    /tasks
    registry.xml
    synapse.xml

As you can see in the above sketch of the repository though it is a repository based configuration, it also supports the old style single flat synapse.xml file in which case it has to reside inside the root of the repository.

So the easiest way to migrate the configuration is to move your already existing synapse.xml file in repository/conf directory in 1.2 version into the repository/conf/synapse-config directory of the 2.0.0 version. Note: When doing this migration you should also delete the main.xml and fault.xml files which are there on the sequences directory of the repository, otherwise there will be 2 main and fault sequences one coming from the sequences directory and the other coming from your just copied synapse.xml file

Endpoint URLs for proxy services

In release 2.0.0 the endpoint URLs for proxy services have changed from /soap to /services . E.g. http://localhost:8280/services/StockQuote should be used instead of http://localhost:8280/soap/StockQuote .

MediatorDeployer

Release 1.3 has enhanced capabilities for extension deployment. While in 1.2 extension deployment was limited to mediators bundled as simple JAR files, 1.3 extended this support to startups and defined a new archive format (XAR) that allows to bundle these extensions together with their dependency JARs (see SYNAPSE-377 for more details). Enabling these features requires changes to the axis2.xml configuration file. In 1.2 the deployer was configured as follows:

<deployer extension="jar" directory="mediators" class="org.apache.synapse.core.axis2.MediatorDeployer"/>

In 2.0.0 the suggested configuration is:

<deployer extension="xar" directory="extensions" class="org.apache.synapse.deployers.ExtensionDeployer"/>

It is possible to have multiple configuration entries for the extension deployer with different settings. For example, if you used the deployer in 1.2 you might want to have the following configuration:

<deployer extension="jar" directory="mediators" class="org.apache.synapse.deployers.ExtensionDeployer"/>
<deployer extension="xar" directory="extensions" class="org.apache.synapse.deployers.ExtensionDeployer"/>

JMS transport

The way the JMS transport determines the content type of incoming messages has slightly changed between Synapse 1.2 and 2.0.0. The mechanism is also more flexible. See SYNAPSE-304 and SYNAPSE-424 for the reasons of this change and refer to the WS-Commons Transport project for documentation.

Main Sequence

On Synapse 1.2 you could have mediator configuration on the top level definitions tag and they were treated as the main sequence if there is no main sequence defined in the configuration. How ever removing the conflict of having top level mediators and a main sequence leading the synapse to fail to start on 2.0.0 Synapse configuration builder simply ignores the top level mediators. So you need to wrap the top level mediators, if there are any, with the sequence named main on the new 2.0.0 version.

To further explain this lets have a look at the following valid configuration bit (this is the sample 0 configuration) on the 1.2;

<definitions xmlns="http://ws.apache.org/ns/synapse">
    <!-- log all attributes of messages passing through -->
    <log level="full"/>

    <!-- Send the message to implicit destination -->
    <send/>
</definitions>

which needs to be changed to the following configuration on 2.0.0

<definitions xmlns="http://ws.apache.org/ns/synapse">

    <sequence name="main">
        <!-- log all attributes of messages passing through -->
        <log level="full"/>

        <!-- Send the message to implicit destination -->
        <send/>
    <sequence/>

</definitions>

Filter Mediator

From 2.0.0 onwards Synapse filter mediator supports the else close as well, and hence the filter matching set of mediators has to be enclosed within a <then> element.

If we consider the following sample from the 1.2 version of synapse;

<filter source="get-property('To')" regex=".*/StockQuote.*">
    <send>
        <endpoint>
            <address uri="http://localhost:9000/soap/SimpleStockQuoteService"/>
        </endpoint>
    </send>
    <drop/>
</filter>

the equivalent configuration for the 2.0.0 release is going to be;

<filter source="get-property('To')" regex=".*/StockQuote.*">
    <then>
        <send>
            <endpoint>
                <address uri="http://localhost:9000/soap/SimpleStockQuoteService"/>
            </endpoint>
        </send>
        <drop/>
    <then/>
</filter>

You could also add an else close to this conditional statement as follows on 2.0.0 which is not possible on 1.2

<filter source="get-property('To')" regex=".*/StockQuote.*">
    <then>
        <send>
            <endpoint>
                <address uri="http://localhost:9000/soap/SimpleStockQuoteService"/>
            </endpoint>
        </send>
        <drop/>
    <then/>
    <else/>
        <log/>
    <else/>
</filter>

Migration Tool

In general it is recommended to run the configuration through the migration tool provided with the Synapse 2.0.0 release, on your synapse 1.2 configuration before using it with the 2.0.0.

To run the migration tool execute the synapse-config-migrator.sh by passing the synapse.xml file location of the 1.2 configuration. Which will create the 2.0.0 compatible configuration with the .new suffix. For example;

sh bin/synapse-config-migrator.sh synapse-1.2/repository/conf/synapse.xml

Custom Extensions and API changes

Even though there is a migration tool it just takes care of your configuration and not custom extensions that you have done for example like CustomMediators or Tasks and so forth. There are some API changes that affect your custom extensions unfortunately. This section tries to list all the public API changes which affects the backward compatibility of the custom extensions that you have been running with the 1.2 version of Synapse

Class	Method	Change Description
AbstractMediatorFactory	createMediator(OMElement)	This was the method that you have been overwriting on the 1.2 version to implement a new custom mediator factory to build the mediator by looking at the XML configuration. On the 2.0.0 version you should be extending the createSpecificMediator(OMElement, Properties) . Note that in the process of changing the method to be extended, the method createMediator method has been changed to be final. From a users point of view of this interface he/she should be using the createMediator method which is what Synapse does
AbstractMediatorSerializer	serializeMediator(Mediator)	This was the method that you have been overwriting on the 1.2 version to implement a new custom mediator serializer to serialize to the XML Configuration by walking through the mediator properties. On the 2.0.0 version you should be extending the serializeSpecificMediator(Mediator) . Note that in the process of changing the method to be extended, the method serializeMediator method has been changed to be final. From a users point of view of this interface he/she should be using the serializeMediator method which is what Synapse does

Further to that if you have been using ServerManager class you may have noticed that the class is no more a singleton and doesn't have the static getInstance method. Also note that the common utilities like data sources JMX and RMI registration stuff have been moved to a new module with org.apache.synapse.commons package name.

On the configuration building front all entities are given a properties map to construct its instance and that has been used to pass in any additional information required like RESOLVE_ROOT, or SYNAPSE_HOME startup parameters. For example if you look at the MediatorFactoryFinder class the getMediator method is expecting a properties map apart from the OMElement argument. It is safe to pass in a empty properties map if you are using these methods for any testing purposes or even in cases where you do not resolve dependencies