Статьи

Отслеживание исключений — часть 6 — создание исполняемого фляги

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

Написав код и тесты, и будучи достаточно уверенным, он сработает следующим и последним шагом — упаковать все это и развернуть на производственном компьютере. Фактические методы развертывания и упаковки будут зависеть от процессов и процедур вашей организации. Однако в этом примере я собираюсь выбрать самый простой способ создания и развертывания исполняемого файла JAR. Первый шаг был выполнен несколько недель назад, и это определяет наш вывод как файл JAR в файле Maven POM, который, как вы, вероятно, уже знаете, выполняется с использованием элемента упаковки:

     <packaging>jar</packaging>

Это нормально, если у вас есть JAR-файл, но в этом случае есть еще один шаг: сделать его исполняемым. Чтобы сделать исполняемый файл JAR, вам нужно добавить файл MANIFEST.MF и поместить его в каталог с именем META-INF. Файл манифеста  файл , который описывает файл JAR как для виртуальной машины Java и человека читателей.

Как обычно, есть несколько способов сделать это, например, если вы хотите усложнить себе жизнь, вы можете вручную создать свой собственный файл и поместить его в каталог META-INF внутри src / main / resources проекта. каталог. С другой стороны, вы можете использовать плагин maven-jar  и делать это автоматически. Для этого вам нужно добавить следующее в ваш файл POM.

       <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-jar-plugin</artifactId>
            <version>2.4</version>
            <configuration>
                 <archive>
                     <manifest>
                           <addClasspath>true</addClasspath>
                           <mainClass>com.captaindebug.errortrack.Main</mainClass>
                           <classpathPrefix>lib/</classpathPrefix>
                      </manifest>
                 </archive>
            </configuration>
       </plugin>

Интересным моментом здесь является элемент конфигурации <archive> <manifest>. Он содержит три подэлемента: 

  1. addClasspath: это означает, что плагин добавит classpath в файл MANIFEST.MF, чтобы JVM могла найти все файлы поддержки при запуске приложения.
  2. mainClass: сообщает плагину добавить атрибут Main-Class в файл MANIFEST.MF, чтобы JVM знала, где найти точку входа в приложение. В этом случае это com.captaindebug.errortrack.Main
  3. classpathPrefix: это действительно полезно. Это позволяет вам находить все jar поддержки в другом каталоге основной части приложения. В этом случае я выбрал очень простое и короткое имя lib.

Если вы запустите сборку, а затем откроете получившийся файл JAR, извлечете и изучите файл /META-INF/MANIFEST.MFfile, вы найдете что-то вроде этого:

Manifest-Version: 1.0

Built-By: Roger
Build-Jdk: 1.7.0_09
Class-Path: lib/spring-context-3.2.7.RELEASE.jar lib/spring-aop-3.2.7.RELEASE.jar lib/aopalliance-1.0.jar lib/spring-beans-3.2.7.RELEASE.jar lib/spring-core-3.2.7.RELEASE.jar lib/spring-expression-3.2.7.RELEASE.jar lib/slf4j-api-1.6.6.jar lib/slf4j-log4j12-1.6.6.jar lib/log4j-1.2.16.jar lib/guava-13.0.1.jar lib/commons-lang3-3.1.jar lib/commons-logging-1.1.3.jar lib/spring-context-support-3.2.7.RELEASE.jar lib/spring-tx-3.2.7.RELEASE.jar lib/quartz-1.8.6.jar lib/mail-1.4.jar lib/activation-1.1.jar
Created-By: Apache Maven 3.0.4
Main-Class: com.captaindebug.errortrack.Main
Archiver-Version: Plexus Archiver

Последний шаг — собрать все файлы поддержки в один каталог, в данном случае — каталог lib, чтобы JVM могла найти их при запуске приложения. Опять же, есть два способа приблизиться к этому: легкий путь и трудный путь. Сложный путь состоит в том, чтобы вручную собрать все файлы JAR, как определено POM (как прямые, так и временные зависимости), и скопировать их в выходной каталог. Самый простой способ — заставить  подключаемый модуль maven-dependency-plugin  сделать это за вас. Это включает добавление следующего к вашему файлу POM:

       <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-dependency-plugin</artifactId>
            <version>2.5.1</version>
            <executions>
                 <execution>
                      <id>copy-dependencies</id>
                      <phase>package</phase>
                      <goals>
                          <goal>copy-dependencies</goal>
                      </goals>
                      <configuration>
                           <outputDirectory>
                                ${project.build.directory}/lib/
                           </outputDirectory>
                      </configuration>
                 </execution>
            </executions>
       </plugin>

В этом случае вы используете цель копирования-зависимостей, выполненную на этапе пакета, чтобы скопировать все зависимости проекта в каталог $ {project.build.directory} / lib / — обратите внимание, что последняя часть пути к каталогу,  lib , соответствует настройке classpathPrefix из предыдущего шага.

Чтобы упростить жизнь, я также создал небольшой скрипт run: runme.sh:

#!/bin/bash         

echo Running Error Tracking...
java -jar error-track-1.0-SNAPSHOT.jar com.captaindebug.errortrack.Main

И это все. Приложение почти готово. Я скопировал его на свою сборочную машину, где он теперь отслеживает примеры приложений и сборки Captain Debug Github. 

Я мог бы и даже могу добавить еще несколько функций в приложение. Есть несколько грубых краев, которые нужно выбить из кода: например, лучше ли запускать его как отдельное приложение, или лучше было бы превратить его в веб-приложение? Кроме того, не будет ли хорошей идеей обеспечить, чтобы одни и те же ошибки не сообщались дважды?

Возможно, я скоро найду что-нибудь, или я поговорю о чем-то другом; так много о блоге так мало времени …


Код для этого блога доступен на Github по адресу:  https://github.com/roghughe/captaindebug/tree/master/error-track . Если вы хотите посмотреть другие блоги этой серии, загляните сюда … 

  1. Отслеживание исключений приложений с помощью Spring
  2. Отслеживание исключений в Spring — часть 2 — шаблон делегата
  3. Отчеты об отслеживании ошибок — часть 3 — стратегия и пакет
  4. Отслеживание исключений — часть 4 — отправитель почты Spring
  5. Отслеживание исключений — часть 5 — планирование с помощью Spring