Установка пользовательских JAX-RS/JSON де- сериализацию в Wildfly

Question

Предположим, что мы имеем ситуацию с .ear приложения, содержащего несколько .war и .jar, где мы контролируем JSON де-/сериализации наших объектов в наших REST конечных точек с помощью пользовательских javax.ws.rs.ext.Provider упакованного внутри одного конкретного .jar, развернутого как lib с нашим .ear.

Теперь, когда мы собираемся расширить количество развертываний, используя вышеупомянутую пользовательскую де-/сериализацию, мы ищем способ уменьшить размер артефакта, и я придумал в основном три возможности, в которых работают только две работы и одна слишком многословный, чтобы быть реальным решением:

• Развертыванием javax.ws.rs.ext.Provider -artifact с каждым .ear отсылая к нему (Минус: множественный .ear -artifacts, содержащему же.jar библиотеки).

• Установите javax.ws.rs.ext.Provider -artifact как глобальный Wildfly модуль и добавить зависимость через jboss-deployment-structure.xml (недостаток: .ear -artifact могут быть развернуты, но де-/сериализации не работает, как ожидалось, как Wildfly модуль не является частью пути класса развернутого приложения .ear и javax.ws.rs.ext.Provider не регистрируются автоматически при развертывании).

• Установите javax.ws.rs.ext.Provider -artifact как «нормальный» Wildfly модуля и ссылки на пользовательские javax.ws.rs.ext.Provider в getClasses метод класса конфигурации REST, которая простирается javax.ws.rs.core.Application (Drawback: Мы бы перечислить все javax.ws.rs.ext.Provider и REST конечной точки явно вместо автоматическое обнаружение, используемое в данный момент).

Есть ли четвертая возможность достичь этой задачи или есть какие-либо улучшения в трех возможностях выше? Мне не удалось найти какое-либо решение этой (я думал) довольно простой задачи по установке «глобального» обычая javax.ws.rs.ext.Provider в Wildfly.

Answer 1

Решение было так же легко, как неуправляемым найти правильно:

Либо:

1. javax.ws.rs.ext.Provider -artifact расширяется с помощью файла с именем javax.ws.rs.ext.Providers помещен в /META-INF/services, где все классы аннотируемого с javax.ws.rs.ext.Provider являются перечисленные с их полностью квалифицированными именами классов.
2. .ear -artifact jboss-deployment-structure.xml распространяется двумя зависимостями:
   1. <module name="<module-name>" slot="main" /> для <deployment> -элемента.
   2. <module name="<module-name>" slot="main" services="import" /> для .war -artifacts <sub-deployment> -элемент, который (неявно) использует классы javax.ws.rs.ext.Provider -artifact.

Или:

1. Оставьте javax.ws.rs.ext.Provider -artifact, как это было раньше.
2. .ear -artifact jboss-deployment-structure.xml распространяется двумя зависимостями:
   1. <module name="<module-name>" slot="main" annotations="true" /> для <deployment> -элемента.
   2. <module name="<module-name>" slot="main" /> для .war -artifacts <sub-deployment> -элемент, который (неявно) использует классы javax.ws.rs.ext.Provider -artifact.