Если обновление JRE запускается без предварительной остановки службы Tomcat вручную, Tomcat больше не будет запускаться после следующей остановки. Чаще всего это происходит после перезагрузки по запросу установщика JRE.
Чтобы воспроизвести ошибку
Журналы после перезагрузки
Tomcat 7 стандартный вывод
2012-04-03 12:25:02 Commons Daemon procrun stdout initialized
2012-04-03 12:42:25 Commons Daemon procrun stdout initialized
Error occurred during initialization of VM java/lang/NoClassDefFoundError: java/lang/Object
Последняя часть Tomcat7 stderr (единственная строка после обновления и перезапуска Java)
2012-04-03 12:42:25 Commons Daemon procrun stderr initialized
Мы наблюдали это с давно работающим (но не Tomcat) Java-приложением, которое работает как служба Windows. Мы создаем его как службу Windows с механизмом «procrun» в Apache Commons Daemon, который аналогичен работе службы Tomcat Windows.
Судя по намекам в других отчетах об этом, похоже, что процесс обновления Java перемещает / переименовывает файлы как часть обновления до новой версии. По завершении установки может остаться одно или два переименования, и эти переименования должны произойти после перезагрузки. Но если одновременно с обновлением запущено долгосрочное приложение Java, в этом приложении будут заблокированы различные библиотеки Java и exe (например, основной jre.exe), и обновление Java завершится ошибкой.
Один из симптомов этого - открыть командное окно и ввести «java -version». Если вы получаете ошибку noclassdeffound для java / lang / Object, вполне вероятно, что комбинация обновления JDK с долго работающим приложением Java оставила вам поврежденный JDK / JRE.
Мы нашли два обходных пути: (1) переустановите приложение; (2) переустановите Java. (1) обычно работает для нас, потому что у нас есть установщик для приложения, который при необходимости также установит чистую версию Java. Однако иногда даже это не удается, и появляется сообщение «Не удалось запустить jar-файл 'достижим-поток-установщик-izpack.jar'». (IzPack - это инструмент автоматической установки, который мы используем). В этом случае мы возвращаемся к (2).
Ни один из способов обхода не очень хорош. Жаль, что автоматическое обновление JDK, предоставляемое Java, ломает наше приложение.
Добились ли вы каких-либо успехов в этом вопросе с момента публикации вашего исходного сообщения?