Как отследить JAR с поврежденным индексом JAR, который вызывает InvalidJarIndexException в Tomcat в Eclipse

Я работаю над разработкой приложения, которое, помимо прочего, содержит ряд сервлетов. Средой разработки, которую я использую, является Eclipse (3.2.1, которая довольно старая), в которой я запускаю сервер Tomcat (5.5.23, также довольно старый), используя плагин Eclipse Tomcat Wrapper для этой задачи. Все это работает в системе RedHat 5.2 Linux.

Я использую среду выполнения Java - JDK 1.6.0(21), которую я обновил до (с предыдущей версии JDK 1.5) совсем недавно, и, насколько я помню, комбинация программного обеспечения выше (вместе с приложением, с которым я работаю)) действительно работал: я мог запустить сервер Tomcat, он встал без ошибок и жалоб, а сервлеты приложения были доступны через порт 8080.

Тем не менее, что-то где-то изменилось (может быть, в самих jarfiles приложений, я подозреваю, что по сути все на хосте является основной причиной этого). Теперь, когда я пытаюсь запустить сервер Tomcat, я получаю сообщение об ошибке sun.misc.InvalidJarIndexException в выводе консоли. Это происходит для следующих классов и методов:

  • org.apache.commons.modeler.Registry registerComponent (бывает 3 раза)
  • org.apache.catalina.core.StandardServer initialize (бывает один раз)
  • org.apache.catalina.connector.Connector start (бывает дважды)

Я нашел этот вопрос переполнения стека относительно того, как найти JAR Java-класса полезным, и я запустил find /usr -name \*name-of-suspected-jar\*.jar несколько раз, чтобы отследить ряд предлагаемых оскорбительных JARS. Я также попытался проверить конфигурацию среды выполнения сервера Tomcat в Eclipse, но на самом деле не смог сопоставить файлы JAR в системе с CLASSPATH ни установки времени выполнения Tomcat (или с CLASSPATH используется в среде при запуске Eclipse). Это усилие, вероятно, требует большей строгости с моей стороны, но прежде чем сделать это (и именно поэтому я сейчас не публикую все кровавые подробности, касающиеся CLASSPATH здесь), я прочитал о том, что именно InvalidJarIndexException действительно о.

Таким образом, JAR-файлы могут содержать необязательный файл INDEX.LIST, который содержит информацию о том, какие классы (и методы?) Найти в JAR-файле. Идея состоит в том, чтобы замкнуть поиск во всех JARS в CLASSPATH что полезно в ряде обстоятельств. Проблема в том, когда INDEX.LIST Файл оказывается поврежденным (или, как полагают, поврежденным), что приводит к тому, что загрузка класса полностью прекращается (загрузчик классов не отступает от поиска всех JAR-файлов в CLASSPATH) и ошибка InvalidJarIndexException быть брошенным. Чтобы сделать вещи более беспорядочными, порядок поиска JAR-файлов может повлиять на то, как загрузчик классов обрабатывает INDEX.LIST файл: INDEX.LIST файл одного JAR может ссылаться на другие JARS, и если те, которые относятся к JARS, не синхронизированы с первым JAR INDEX.LIST файл, загрузчик классов не с этим InvalidJarIndexException ошибка.

Таким образом (согласно этому вопросу Stackru) кажется, что эта ошибка может быть выдана не только потому, что файл JAR поврежден INDEX.LIST кажется, его даже можно бросить в JAR, даже если JAR имеет действительный INDEX.LIST или законно не хватает INDEX.LIST просто потому, что ранее найденный JAR перепутал загрузчик классов. (Другими словами, как это ни странно, это исключение может быть выдано даже для "невинных" не поврежденных файлов JAR из-за нарушителей в другом месте системы).

Итак, после написания простого романа, вот мой основной набор вопросов:

  • Каков наилучший способ отследить точный .jar файл, для которого каждый InvalidJarIndexException брошен?
  • Как лучше всего проверить, если случайно выбран .jar файл имеет INDEX.LIST файл, и если да, то если указанный файл действителен (то есть не поврежден)? Какие инструменты существуют для этой задачи?
  • Есть ли эффективный способ автоматически определить порядок поиска .jar файлы? Я могу попытаться следовать CLASSPATH вручную, но, честно говоря, это подвержено ошибкам и утомительно.
  • Есть ли эффективный способ выяснить, что .jar файл находится в порядке поиска, который может запутать загрузчик классов, чтобы обвинить невинных, не поврежденных .jar файлы позже в поиске, чтобы иметь неправильные INDEX.LIST файлы?

Отказ от ответственности: я знаю, что я запускаю старые версии программного обеспечения (даже если у меня установлены последние обновления моего Redhat 5.2, хотя), и я знаю, что реакция коленного рефлекса для многих людей состоит в том, чтобы предположить, что я не прикладываю никаких усилий для отладки этого но вместо этого обновите его до более поздней версии Tomcat, Eclipse и Linux (хотя Java появилась недавно). Причина, по которой я предпочел бы не делать этого, заключается в том, что после изучения вещей я обнаружил, что делать обновление или пытаться установить отдельный современный Tomcat или Eclipse рядом с RHEL5.2, предоставленным Tomcat/Eclipse, который я использую сегодня, довольно сложно. Кроме того, я считаю, что такого рода устранение неполадок дает возможность узнать некоторые полезные подробности о Java и связанных с ней инструментах и ​​функциях. Выяснить, как работает загрузка классов и что вызывает это InvalidJarIndexException в моей системе было бы очень поучительно!

(Но если это устранение неполадок не удастся, я серьезно подумаю об использовании современных Linux, Eclipse и Tomcat... Обещаю)

2 ответа

Решение

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

  1. Добавьте точку прерывания исключения в Eclipse (это J с иконкой восклицательного знака) и установите для нее остановку для обнаруженных и неперехваченных исключений типа InvalidJarIndexException.
  2. Начните отлаживать вашу программу.

Eclipse остановится на вашей точке останова исключения, когда выдается исключение InvalidJarIndexException. Даже без источника для URLClassPath вы все равно сможете проверять переменные в стеке, приводящие к исключению, включая имя класса, который URLClassPath пытается найти. Знание имени класса должно значительно сузить список JAR-файлов, которые вы должны изучить.

Возможно, вы локально добавили новый класс в пакет, и содержимое этого пакета описывается индексным файлом в устаревшем JAR-файле вашего classpath?

Попробуйте Tattletale, который является хорошим инструментом отчетности для банок. В этом случае я поочередно удалял INDEX.LIST из банок, пока я больше не получил InvalidJarIndexException

Другие вопросы по тегам