Если вы заглянете внутрь флага jersey-media-json-jackson
, вы увидите файл
META-INF/services/org.glassfish.jersey.internal.spi.AutoDiscoverable
. Содержимое этого файла должно быть единственным полным именем класса, который реализует имя файла, а именно
org.glassfish.jersey.jackson.internal.JacksonAutoDiscoverable
Этот файл используется механизмом автообнаружения для Джерси для автоматической регистрации функций без необходимости их явного их регистрации. Вкратце, как это работает, все модули / банки Джерси, у которых есть компоненты, которые должны быть автоматически зарегистрированы, должны иметь вышеупомянутый файл, расположенный в банке, причем содержимое является именем (именами) компонента с возможностью автоматического обнаружения. Затем Джерси будет использовать шаблон загрузчика Service Loader , чтобы загрузить классы, указанные в файле, и зарегистрировать их.
Проблема, которая возникает при создании uber-банок, заключается в том, что вы можете иметь только один копия файла, у вас не может быть дубликатов. Итак, что, если у нас есть несколько банок с вышеупомянутым файлом? Ну, только один из этих файлов будет включен в банку uber. Который из? Кто знает, но есть только один счастливый победитель. Таким образом, для остальных банок их механизм автоматического обнаружения никогда не срабатывает. Это относится к вашей функции Джексона, где автообнаружение регистрирует JacksonFeature
. Вы можете попытаться явно зарегистрировать свое приложение, и вы увидите, что он теперь работает.
Но как насчет других банок / модулей, которые могут иметь этот файл? Именно по этой причине при создании uber jars вы должны использовать maven-shade-plugin . Что этот плагин позволяет вам сделать, объединить содержимое файлов, чтобы все обнаруживаемые объекты включались в этот один файл. Ниже приведен пример использования
org.apache.maven.plugins
maven-shade-plugin
2.3
true
*:*
META-INF/*.SF
META-INF/*.DSA
META-INF/*.RSA
package
shade
com.example.YourApp
. Этот пример был фактически взят из Начало работы Dropwizard . Вы можете проверить это для дальнейшего объяснения. Основная часть проблемы - ServicesResorceTransformer
, которая объединяет файлы служб.
Некоторый профилировщик как profiler4j может показать управляемое и неуправляемую память (живая кривая). Затем Вы видите, есть ли у Вас утечка и когда утечка происходит. Но Вы не находит больше информации.
После этого существует 2 возможных решения:
Я люблю valgrind (http://valgrind.org/), если Вы выполняете его в системе, он поддерживает. Это действительно качается!