Затмение на острове Java или внимательней читайте стэктрейсы

[Vayun]

Есть же tcpdump

[c0ba]

Сама разработка ведется не из под linux, к сожалению (я уже начинаю всерьез об этом задумываться). На винде я так понимаю это тот еще квест.

[Antti]

Есть замечательный wireshark.

[qwazer]

Есть же дебаггер.
Есть же логирование нужных классов с уровнем TRACE.

[c0ba]

Честно говоря не так часто приходится пользоваться дебаггером и поэтому не очень люблю это дело. Особенно когда начинаешь "плясать" по кругу (если дебажить по "шагам"). Но в описанной ситуации собирался уже воспользоваться дебаггером, если бы ничто другое не помогло. А вот про логирование нужных классов с уровнем TRACE не понял, проясните, пожалуйста, о чем речь.

[qwazer]

Я имел ввиду, что большинство библиотек в экосистеме Java используют логирование с помощью какого-нибудь логирующего фреймворка типа log4j. Если задать уровень логирование в максимально подробный, то в логах можно увидеть причину того или иного поведения программы.
Правда, в Вашем случае, похоже, этот прием не помог бы.

[elw00d]

Загрузку внешних схем из XML можно отключить. Тут есть варианты: https://www.owasp.org/index.php/XML_External_Entity_(XXE)_Processing (см параграф с Java).

А диагностировать неудачный коннект можно было ещё попробовать с помощью dtrace.

[chabapok]

Как-то это вообще неправильно, что критичные для старта компоненты подгружаются из интернета.
В том же спринге, например, xml-конфиг ссылается на какие-то внешние ресурсы, но эти xml так же есть внутри jar, и он их берет из jar, а не подтягивает из интернета. Как это сделано, я не разбирался.

[grossws]

В специальных properties файлах прописан маппинг url -> путь в classpath, вот и всё. Примерно так же, как описано в http://docs.spring.io/spring/docs/current/spring-framework-reference/htmlsingle/#extensible-xml-registration

[c0ba]

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

[Throwable]

Обычно сервера держат необходимые схемы в локальных ресурсах, и подгружаться ничего не должно. Просто Вы зачем-то взяли уж очень экзотическую и старую схему для web.xml. Обычно используют что-то вроде этого:

<web-app version=«2.4» xmlns=«http://java.sun.com/xml/ns/j2ee» xmlns:xsi=«http://www.w3.org/2001/XMLSchema-instance» xsi:schemaLocation=«http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd»>

А с недавнего времени (servlet 3.0, лет 5 как уже) используют это:

<web-app xmlns=«http://java.sun.com/xml/ns/javaee»
xmlns:xsi=«http://www.w3.org/2001/XMLSchema-instance»
xsi:schemaLocation=«http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd»
version=«3.0»
metadata-complete=«false»>

В этих случаях ничего нигде ниоткуда не подгружается, сервер знает все схемы.

[c0ba]

Взял не я, похоже разработчики лифта не особо спешат схему обновлять. А чем чреват способ, который применил я — удаления объявления схемы из XML? После этого нигде ничто не сломалось и даже не ругнулось. Но должны же быть какие-то подводные камни!

[Throwable]

Теоретически ничем. Схема — это фишка исключительно парсера, который в случае ее указания, пытается сначала проверить XML на соответствие оной. Если схема не указана, XML парсится без нее как есть. А затем уже сервер готовит контекст, зная заранее структуру.

[c0ba]

Чтож, посмотрим как оно будет дальше себя вести. Похоже в моем случае шаг с валидацией пропускается молча, если не указана схема.