Итак, как вы можете знать или не знать, BlazeDS (версия с открытым исходным кодом LiveCycle Data Services) - это хороший способ заставить ваше серверное приложение Java и Flex работать вместе. К сожалению, у него есть несколько подводных камней, которые необходимо исправить. Я постараюсь объяснить один из них здесь.
Вся конфигурация BlazeDS записывается с помощью файлов XML в папке flex/ вашего веб-приложения. Имена по умолчанию разделены для ясности, например services-config.xml, remoting-config.xml, messaging-config.xml и т. Д. В этих файлах конфигурации (в частности, services-config.xml) определены каналы; эти настройки URI и объекты, используемые для сбора и отправки информации между сервером и клиентом. В этих конфигурационных файлах довольно часто используется такой синтаксис:
<channel-definition id="my-secure-amf" class="mx.messaging.channels.SecureAMFChannel">
<endpoint url="https://{server.name}:{server.port}/{context.root}/messagebroker/amfsecure" class="flex.messaging.endpoints.SecureAMFEndpoint"/>
<properties>
<add-no-cache-headers>false</add-no-cache-headers>
</properties>
</channel-definition>
К сожалению, они не сообщают вам о том, что некоторые из этих замен (например: {context.root}) заменяются динамически при выполнении, но при компиляции файла WAR, который вы намереваетесь распространить. Очевидно, не очень хорошая идея при переключении доменов.
Итак, вместо этого я стремлюсь динамически определять эти каналы. Согласно документации, это все хорошо и отлично , но работает только в том случае, если канал уже существует при запуске веб-приложения . Я чувствую, что этот тип побеждает суть.
Итак, мой вопрос: как вы действительно создаете каналы динамически, чтобы и клиент, и сервер распознавали их существование?