Где разместить файлы DTD и схемы - PullRequest
4 голосов
/ 20 апреля 2009

У меня довольно типичное приложение JavaEE, составленное с использованием EJB3, компонентов шва, пружинных компонентов и 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/components-2.0.dtd). Поскольку сервер JBoss проверяет XML при загрузке с использованием этого местоположения, сбой развертывания приложения.

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

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

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

Ответы [ 2 ]

0 голосов
/ 22 апреля 2009

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

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

0 голосов
/ 21 апреля 2009

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

...