2010-11-12 2 views
0

Я был добавлен в проект с использованием древней версии мула 1.3. Они используют разделенную конфигурацию, как предложено, например, here.Конфигурационные файлы Mule 1.3, имеющие «mule-descriptor» непосредственно под «mule-configuration», не подтверждают валидацию

Все эти файлы имели http://www.symphonysoft.com/dtds/mule/mule-configuration.dtd в качестве определения DTD. Это оказалось проблемой для просто-старой Mule IDE, поскольку она, по-видимому, пытается загрузить этот URL-адрес, домен которого ушел.

Я нашел файл на http://www.mulesoft.org/dtds/mule-configuration.dtd, который, казалось бы, был бы тем же DTD. Тем не менее, теперь я получил ошибки проверки во всех файлах конфигурации, но в главном файле mule-config.xml, так как они следуют предложению в первой ссылке: Имейте элементы mule-descriptor непосредственно под элементом конфигурации mule. Однако DTD, кажется, не позволяют это (элемент мул-дескриптор ниже элемента модели):

<!ELEMENT mule-configuration (description?, environment-properties?, 
    mule-environment-properties?, container-context*, security-manager?, 
    transaction-manager?, agents?, connector*, endpoint-identifiers?, 
    transformers?, global-endpoints?, interceptor-stack*, model*)> 

Любые идеи, кроме хостинга модифицированную DTD сами? Есть ли еще DTD?

ответ

0

Хорошо, только если кто-то эту проблему: The «S» в «ОТД» из URL должен был быть в поддавки: http://www.mulesoft.org/dtds/

1.3.3 DTD имел ожидаемый «мул-дескриптор» непосредственно под 'mule-configuration', и как Mule IDE, так и проверка Eclipse теперь счастливы.

(Причина ошибок проверки заключалась в том, Eclipse, в котором говорится, что «если вы найдете этот PUBLIC-идентификатор, используйте этот локальный файл», в разделе «Настройки -> XML -> Каталог XML».)

Смежные вопросы