WSO2: настройка узлов кластера интеграционных шин на использование единого LDAP хранилища пользователей

Для того, чтобы не заниматься управлением пользователями на всех экземплярах WSO2ESB в кластере (впрочем, это относится не обязательно к кластеру, и вообще даже не только к ESB, а и к другим продуктам WSO2), удобно использовать единое хранилище пользователей. Вариантов здесь несколько: можно использовать JDBC-коннектор к единой БД, а можно - встроенный в Carbon LDAP-сервер.
Пусть всеми узлами будет использоваться LDAP-сервер узла-менеджера кластер-группы, слушающий порт 10386 (напомню, порт этот можно настроить в repository/conf/carbon.xml  в теге <LDAPServerPort>).
Тогда на всех остальных экземплярах шины необходимо зайти в  repository/conf/embedded-ldap.xml и установить:

<EmbeddedLDAP>
     <Property name="enable">false</Property>
     ....
</EmbeddedLDAP>

, чтобы они не стартовали свой LDAP, т.к. он больше нужен не будет. Затем идем в  repository/conf/user-mgt.xml и устанавливаем URL LDAP-сервера (в моем случае узел ESB, играющий роль менеджера кластер-группы, а теперь и менеджера пользователей, расположен на том же хосте, что и остальные узлы, т.е. на localhost) :

<UserStoreManager class="org.wso2.carbon.user.core.ldap.ApacheDSUserStoreManager">
     <Property name="ReadOnly">false</Property>
     <Property name="ConnectionURL">ldap://localhost:10386</Property>
</UserStoreManager>

Впрочем, <Property name="ReadOnly"> будет логичнее установить в true, чтобы вносить изменения мог только центральный узел, однако при попытке это сделать WSO2 вылетает с исключением, что, дескать, этот UserStoreManager должен быть Read/Write (возникает правда вопрос, зачем тогда в его настройках есть свойство ReadOnly?). Поэтому, если нужно, чтобы хранилище пользователей было только для чтения, меняем атрибут "class" тега UserStoreManager с org.wso2.carbon.user.core.ldap.ApacheDSUserStoreManager на org.wso2.carbon.user.core.ldap.LDAPUserStoreManager.

Очевидный минус подхода с использованием в качестве хранилища пользователей встроенного LDAP одного из экземпляров шины - необходимость запускать экземпляры в строго определенном порядке, и, более того, к моменту запуска slave-экземпляров LDAP-сервер на master-экземпляре должен успеть запуститься. Это условие затрудняет написание скриптов автоматизации запуска шин.