Веб-приложение GWT против системного пути к классам для динамически загружаемых классов

Question

В моем веб-приложении GWT я храню все свои файлы JAR вне моего проекта и ссылаюсь на них с помощью переменных classpath. Это позволяет мне ссылаться на jar-файлы из других проектов / команд без необходимости помещать копию jar-файла в каталог lib моего веб-приложения. Хостинг-режим любезно просматривает классы в этом системном classpath, а затем добавляет их в classpath веб-приложения, предупреждая меня, что это происходит. При развертывании моей системы сборки загружаются только банки, которые мне нужно отправить в моем веб-приложении, и это не проблема.

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

Конкретная проблема, с которой я сталкиваюсь, связана с персистентностью - она ​​ищет реализации EntityManagerFactory путем поиска файлов META-INF / services. У меня также была похожая проблема с Римом и его расширениями модуля.

У меня есть обходной путь, в режиме dev / hosted я просто ссылаюсь на класс, который, как я знаю, находится в банке, которую я хочу, и это вызывает его добавление в мой путь к классу веб-приложения. Я делаю это по телефону

private void devModeClassPathHack() {
    Class<?> gwtDevModeHack1 = EntityManagerImpl.class;
}

из моего режима разработки Модуль Guice.

Мой вопрос прост - есть ли "более приятный" способ сделать это?

Answer 1

Я не думаю, что есть более хороший способ - использование этого временного механизма "самовосстановления" в режиме GWT Jetty / dev уже является хаком :) Если у вас когда-нибудь возникнет необходимость запустить серверную часть Код, например, на JBoss во время разработки (вместе с режимом разработки GWT для клиентской стороны), это перестанет работать.

(В качестве дополнительной проблемы, порядок загрузки классов - и, следовательно, приоритет в случаях, когдаЕсть несколько версий класса в разных банках - это будет зависеть от выполнения программы. Это может быть очень неприятно для отладки.)

Вы упоминаете, что вы извлекаете все банки извне.В этом случае я бы установил .svnignore (или .gitignore / ...) в "* .jar" в директории WEB-INF / lib.Затем я выполнил бы тот же шаг сборки, который используется для создания производственной сборки, чтобы скопировать файлы jar в каталог lib перед запуском сервера.