Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.


  1. Create a new database for AS 5.3.0 and restore the backup of the old database in this new database.
  2. To connect AS 5.3.0 to the upgraded database, configure the following files:
    1. Configure the <AS_HOME_5.3.0>/repository/conf/datasources/master­datasources.xml file as shown in the following example:

      Code Block
      user manager</description>
      <description>The datasource used for registry and
      <definition type="RDBMS">
    2. Go to the <AS _HOME_5.3.0>/repository/conf/ directory and update the datasource references in the user-­mgt.xml and registry.xml files to match the updated configurations in the master­datasources.xml file. The following are sample configurations if the datasource is “jdbc/WSO2CarbonDB”:


      Code Block
      <dbConfig name="wso2registry">


      Code Block
  3. The configurations for SaaS web applications has changed in AS 5.3.0. In previous releases, SaaS configurations were enabled in the web.xml file of web application by adding a context-param called carbon.enable.saasIn AS 5.3.0, SaaS is configured via the context.xml file that needs to be placed under the META-INF/ folder of the web application. See the more details about configuring SaaS applications in AS 5.3.0.
  4. KeyStore configuration in

    Prior to AS 5.

    2.1 has been converged into

    3.0, the primary keystore configured in the carbon.xml

    . But users wanted to configure different keystore for SSL communication, and so on. Hence, in

    file was used for securing transports. In AS 5.3.0,


    the keystore used for transports should be separately


    configured in the

    transport keystores through

    catalina-server.xml file.


    The “RegistryKeyStore” configuration


    in carbon.xml

    has been

     is removed.

    This is not really there in the AS 5.2.1, but was added later in a patch. This has been reverted in AS 5.3.0.

     See the section on configuring keystores for more information.

  5. Check for any other configurations that were done for AS 5.2.1 .0 (based on your solutions), and update the configuration files in AS 5.23.1 0 accordingly. For example, external user stores, caching, mounting, etc.

Migrating third party libraries

If there are any third party libraries used with AS 5.2.1 that you want to migrate, copy them to the  following following directories as applicable to in AS 5.3.0 as applicable.

  1.  If you have used JDBC drivers etc, copy them into to the <AS_HOME>/repository/components/lib directory.
  2. If you have used OSGi bundles such as SVNKit etc, copy them into to the <AS_HOME>/repository/components/dropins directory.   

Migrating the services and artifacts

You can migrate all artifacts relevant to the super - tenant and as well as the ordinary tenants by copying the following directories from the old server to the new server.

  1. To migrate the super - tenant’s artifacts, copy the <AS_HOME>/repository/deployment/server/ directory from AS 5.2.1 to AS 5.3.0.

  2. If you are using multi­-tenancymulti­tenancy, copy the <AS_HOME>/repository/tenants/ directory  directory from AS 5.2.1 to AS 5.3.0.

  3. Since the Axis2 Quality of Services UI to apply policies such security has been removed from the management console, users need to use alternative mechanisms and apply the policies for their services. For Axis2 AAR services, the policies can be applied through the services.xml. Refer <link to page on how to apply QoS configuration if any> for more details. 

  4. To  In AS 5.3.0, it is not possible to globally engage modules , users using the management console. Therefore, you need to use update the axis2.xml that can be found at AS_HOME file in the <AS_HOME>/repository/conf/axis2 directory . Refer the following sample:as shown below. You can find more information on engaging modules for axis2 services from here.

    Code Block
    <axisconfig name="AxisJava2.0">
        <module ref=”addressing”/>
    The UI to globally engage a module is no longer available.

Testing the upgrade

  1. When the database upgrade scripts are executed, the following are some of the new tables that will be created in the database:
  2. Verify that all the required scenarios are working as expected. This confirms that the upgrade is successful.