Куда поместить файлы DTD и схемы

У меня есть довольно типичное приложение JavaEE, составленное с использованием EJB3, компонентов шва, бинов Spring и JSF, упакованных в несколько файлов jar и war внутри файла ear. Естественно, для JavaEE у нас есть много файлов XML как часть приложения. Некоторые из этих XML-файлов проверяются с использованием DTD (seam), а некоторые — с использованием схемы.

Поскольку большинство файлов были взяты из примеров и других проектов, все DTD и схемы ссылаются на сайт проекта, где находится DTD или схема по умолчанию. А вот и проблема: по какой-то причине сайт JBoss сегодня пропускает шовные DTD (проверьте http://www.jboss.com/products/seam/components-1.1.dtd, http://www.jboss.com/products/seam/components-1.2.dtd, http://www.jboss.com/products/seam/компоненты-2.0.dtd). Поскольку сервер JBoss проверяет XML при начальной загрузке, используя это расположение, развертывание приложения завершилось неудачно.

У меня такой вопрос: в данном случае куда мне поместить файлы DTD и определения? Я вижу три варианта:

  1. Используйте расположение по умолчанию, как я делал раньше. Поскольку это означает, что теперь я добавляю стабильность JBoss, Sun, Spring и любого другого поставщика в свою систему на случай, если мне понадобится повторно развернуть приложение, я предпочитаю этого не делать.
  2. Скопируйте все файлы DTD и схемы на мой сервер, чтобы URL-адреса указывали на сервер, находящийся под моим контролем.
  3. Скопируйте все файлы DTD и схемы в мое приложение или сервер приложений и используйте их локально.

Я предпочитаю вариант №3, так как он обеспечивает полный контроль над файлами без сетевых зависимостей. В проведенном нами тесте это даже значительно сократило время начальной загрузки сервера — по-видимому, синтаксический анализатор XML не кэширует определения. Есть ли что-то, что я упускаю, выбирая этот путь?


person David Rabinowitz    schedule 20.04.2009    source источник


Ответы (2)


Нет, это правильный поступок. Первый нужно использовать только для возни или игры с кодом, но не для чего-то серьезного, а второй не имеет преимуществ перед третьим и в то же время сложнее.

person MahdeTo    schedule 20.04.2009

Реальный вопрос: вам действительно нужно проверять XML-файлы? В большинстве случаев проверка не выполняется в производственном коде — в большинстве случаев она слишком медленная.

Если вы действительно хотите проверить, выберите вариант № 3.

person J-16 SDiZ    schedule 22.04.2009
comment
Как отключить проверку в JBoss? Я не тот, кто вызывает парсер XML. - person David Rabinowitz; 22.04.2009