сервлеты и путь к классам

Question

Я прошу прощения за враждебную тему.

Я начал работать в новой компании на прошлой неделе, и меня сразу же бросили в логово льва. У нас было приложение на грани запуска в производство ... Один из моих парней запустил приложение и проверил его, поэтому я не стал слишком углубляться в детали того, что он делал.

У нас было это:

../legacy/ROOT/
..............index.jsp
..............WEB-INF/
.....................lib/
.........................(libs)
.....................classes/
............................x.class

В conf / server.xml есть виртуальный хост, который определил корень как ROOT.

Новое приложение, похоже, запустилось как копирование / вставка устаревшего приложения. У него нет записи в server.xml. Так сказать, в старых приложениях, даже если оно полностью разделено. Новое приложение укоренено в legacy / ROOT / NewApp:

../legacy/ROOT/
..............index.jsp
..............WEB-INF/
.....................lib/
........................(libs)
.....................classes/
............................x.class
..............NewApp/
....................index.jsp
....................WEB-INF/
...........................lib/
..............................(libs)
...........................classes/
..................................x.class

Чтобы перейти к устаревшему приложению, перейдите к http://theUrl. Чтобы перейти к NewApp, перейдите к http://theUrl/NewApp. Все это прекрасно работает. Может быть.

Мы установили новое приложение в субботу вечером. Утром в понедельник мы обнаруживаем, что хотя NewApp отлично работает, наши пользователи не могут войти на устаревший сайт. Они получают сгенерированную приложением ошибку «неверное имя пользователя».

Мне приходит в голову, я не знаю, почему NewApp работает вообще. Я не менял web.xml. Итак, я предполагаю, что Tomcat находит URL-адрес, который ему нравится, просматривая определения HOST, затем видит / NewApp в URL-адресе и с радостью переходит в старый подкаталог / ROOT / NewApp, где находит index.jsp, и мы к гонкам.

Теперь я очень запутался. Унаследованный код имеет папку WEB-INF, и также существует NewApp / WEB-INF. Я не знаю, почему Tomcat что-то делает с NewApp / WEB-INF. Тем не менее, это потому, что NewApp прекрасно работает. Что еще хуже, файлы libs и и class в обоих приложениях практически идентичны по имени и содержанию. Файл x.class в NewApp немного отличается от старого: в NewApp появился новый метод входа в систему. Однако в xAclass в NewApp все еще используется старый метод входа, хотя в NewApp его никто не использует.

Я пытаюсь определить, как сбой наследства связан с нашим развертыванием. Должно быть - но трудно понять как. Мы проверили даты файла. Ничто в наследство не изменилось. Я думаю, это как-то связано с классовой дорожкой.

Итак, у меня есть одно приложение или два? Я думал, что это последнее. Но я не так уверен. Я так растерялся, что даже не могу задать хороший вопрос: - /

Единственная другая странность заключалась в том, что Tomcat не взорвал файл WAR, хотя конфигурация выглядела так, как должна. Мы должны были сделать это вручную - и это сработало.

---

Вот что происходит, когда ваш ведущий разработчик говорит «3 месяца», а руководство говорит: «Нет, 1 месяц». Это кредит, он работает вообще.

Answer 1

Я повторяю то, что сказал Родни. Tomcat ищет файлы WAR и рассматривает их как отдельное веб-приложение (я думаю ...). В вашем случае, как говорит Родни, с точки зрения Tomcat все, что у вас есть, - это веб-приложение, в котором есть папка с некоторыми файлами классов.

То, что я подозреваю, происходит , это то, что NewApp имеет те же имена пакетов / классов, что и устаревшие, и поэтому один перезаписывает другой (поскольку Tomcat, вероятно, выбирает папку NewApp WEB-INF - я не понимаю Я не совсем понимаю, как, но вот и ты).

Это не то, что вы или ваша компания хотите услышать, но их никогда не следовало объединять в два отдельных приложения. Если NewApp зависит от Legacy, то вы можете получить JAR-файл требуемого кода от Legacy и включить его в качестве зависимости для NewApp. Но, как вы понимаете, они должны быть отдельными, и я бы сказал, что Tomcat сильно запутался.

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

Answer 2

Вау! Определенно момент для вас. : - (

Вот мой уловок в понимании этого, и, конечно, я могу ошибаться: во время выполнения Tomcat не заботится о том, что находится на том же уровне в файловой системе, что и корень приложения, если он находит то, что считает действительная война в корне. И было бы разумно, чтобы Tomcat проверил, соответствует ли данная структура папок в URL веб-приложению, прежде чем проверять, является ли это папка В веб-приложении. Так что это объяснило бы «новое» приложение.

Что касается оригинального приложения, если оно вообще не ссылается на папку «NewApp», то у Tomcat не было бы никакой причины даже заглядывать туда, и если бы оно это делало, оно проигнорировало бы тот факт, что оно выглядит как веб-приложение. Это просто еще одна папка с файлами. Я подозреваю, что вы можете получить доступ к любому файлу, непосредственно создавая URL-адрес. Handy. : -p (Правка: вероятно, нет, если подумать об этом, Tomcat, скорее всего, просто воспользуется ссылкой «NewApp» для обозначения нового приложения, а не файла в старом приложении.)

Итак ... у вас есть два веб-приложения. Я думаю Tomcat будет держать их отдельно. Но ... мне бы показалось, что у меня есть что-то подобное в производстве ...