Создание двойного клика по банке 'uber', которая вытягивает другие банки весеннего приложения

Question

У меня есть mavenized, многомодульное приложение на основе пружин (3.0.1), которое работает на tomcat. Я пытаюсь создать автономный инструмент, который я могу распространять среди пользователей через один jar (чтобы они могли просто дважды щелкнуть по нему), который входит в состав некоторых модулей приложения, упомянутых выше.

Я использовал maven-shade-plugin для сборки этой банки. Если я взорваю банку, создается впечатление, что все зависимости существуют, и два файла метаданных пружины были должным образом объединены из всех отдельных банок пружины. Приложение работает до момента, когда я пытаюсь создать экземпляр ClassPathXmlApplicationContext. Когда пользователь нажимает кнопку в приложении, выполняется следующий метод:

public void createAppContext() {
   ClassPathXmlApplicationContext context = 
       new ClassPathXmlApplicationContext(springFiles);
}

"SpringFiles" объявлен в классе следующим образом:

public final String[] springFiles = { "/applicationContext-beans.xml" };

При выполнении вышеуказанного метода появляется следующая ошибка:

Exception in thread "Thread-8" java.lang.ArrayIndexOutOfBoundsException: 3350
        at org.springframework.asm.ClassReader.(Unknown Source)
        at org.springframework.asm.ClassReader.(Unknown Source)
        at org.springframework.asm.ClassReader.(Unknown Source)
        at org.springframework.core.type.classreading.SimpleMetadataReader.(SimpleMetadataReader.java:48)
        at org.springframework.core.type.classreading.SimpleMetadataReaderFactory.getMetadataReader(SimpleMetadataReaderFactory.java:80)
        at org.springframework.core.type.classreading.CachingMetadataReaderFactory.getMetadataReader(CachingMetadataReaderFactory.java:82)
        at org.springframework.core.type.classreading.SimpleMetadataReaderFactory.getMetadataReader(SimpleMetadataReaderFactory.java:76)
        at org.springframework.context.annotation.ConfigurationClassBeanDefinitionReader.checkConfigurationClassCandidate(ConfigurationClassBeanDefinitionReader.java:302)
        at org.springframework.context.annotation.ConfigurationClassPostProcessor.processConfigBeanDefinitions(ConfigurationClassPostProcessor.java:157)
        at org.springframework.context.annotation.ConfigurationClassPostProcessor.postProcessBeanDefinitionRegistry(ConfigurationClassPostProcessor.java:132)
        at org.springframework.context.support.AbstractApplicationContext.invokeBeanFactoryPostProcessors(AbstractApplicationContext.java:584)
        at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:405)
        at org.springframework.context.support.ClassPathXmlApplicationContext.(ClassPathXmlApplicationContext.java:139)
        at org.springframework.context.support.ClassPathXmlApplicationContext.(ClassPathXmlApplicationContext.java:93)
        at com.mycompany.StandaloneTool$2.run(StandaloneTool.java:124)

Любая помощь будет принята с благодарностью!

Answer 1

Похоже, что файлы метаданных пружины скопированы правильно. Я начал использовать maven-shade-plugin по этой конкретной причине. :)

Я поднял регистрацию пружин в TRACE, что позволило получить дополнительную информацию (мне следовало сделать это, чтобы начать, к сожалению!). Я получаю кучу исключений, говорящих о том, что различные файлы .class имеют недопустимые магические числа Java.

Оказывается, проблема была в том, как я использовал плагин maven-dependency-plugin. Мое намерение состояло в том, чтобы вытащить артефакт .zip, распаковать его и скопировать его содержимое в определенный каталог сборки во время фазы генерируемых ресурсов. Одна потенциальная проблема заключается в том, что я по неосторожности использовал цель «распаковать-зависимости», которая потребляла больше зависимостей, чем я планировал (зависимости, которые в конечном итоге maven-shade-plugin будут объединять) Однако, что, казалось, наконец решило проблему, это удаление свойства элемента артефакта «output-directory», где я указал каталог под названием «generate-resources». Как только я удалил это свойство, все прошло гладко.

Мне не понятно, почему магические числа в файлах .class были изменены / повреждены, но, по крайней мере, проблема была решена. У кого-нибудь есть идеи относительно того, что на самом деле произошло?

Спасибо за все комментарии!

Answer 2

Просто догадка, но это может быть плагин затенения, перезаписывающий метаданные, которые Spring использует для своих пространств имен в файле конфигурации. Посмотрите на объединение содержимого определенных файлов в документации к плагину Shade, чтобы увидеть, решит ли он вашу проблему.