Это мой код. И может найти его на многих сетевых картах.
private string GetLocalIpAddress()
{
string localIpAddress = string.Empty;
NetworkInterface[] nics = NetworkInterface.GetAllNetworkInterfaces();
foreach (NetworkInterface nic in nics)
{
if (nic.OperationalStatus != OperationalStatus.Up)
{
continue;
}
IPv4InterfaceStatistics adapterStat = (nic).GetIPv4Statistics();
UnicastIPAddressInformationCollection uniCast = (nic).GetIPProperties().UnicastAddresses;
if (uniCast != null)
{
foreach (UnicastIPAddressInformation uni in uniCast)
{
if (adapterStat.UnicastPacketsReceived > 0
&& adapterStat.UnicastPacketsSent > 0
&& nic.NetworkInterfaceType != NetworkInterfaceType.Loopback)
{
if (uni.Address.AddressFamily == AddressFamily.InterNetwork)
{
localIpAddress = nic.GetIPProperties().UnicastAddresses[0].Address.ToString();
break;
}
}
}
}
}
return localIpAddress;
}
Если JSP являются частью WAR, который является частью EAR, развернутого как jar, то мне не ясно, почему ваши JSP не перекомпилируются. Разве JSP в файле war не имеют более новые метки времени, чем их файлы классов, скомпилированные JBoss из последнего развертывания? Если нет, не могли бы вы прикоснуться к JSP как части построения WAR / EAR перед развертыванием. [Я имею в виду использование команды Unix «touch», а не касание каждого файла JSP вручную.]
В качестве альтернативы, параметр DeleteWorkDirOnContextDestroy в $ JBOSS / server / default / deploy / jboss-web.deployer / META-INF / jboss-service.xml может быть тем, что вы ищете. По умолчанию это false, но вам может понадобиться установка значения true. Я думаю, это должно удалить файлы классов JSP при повторном развертывании, чтобы они воссоздались при первом доступе к каждому JSP.
Я не знаю настройки, но удаление сгенерированного файла класса Java в рабочем каталоге вашего экземпляра JBoss приведет к перекомпиляции JSP при следующем вызове.
Вы можете изменить сценарии запуска JBoss, чтобы явно удалить каталоги «tmp» и / или «рабочий», где хранятся скомпилированные JSP. Тогда JBoss не останется ничего, кроме как перекомпилировать их все.
Не тонко, но сработает.
Один из вариантов для вас - это предварительно скомпилировать все ваши jsp во время сборки. Это позволит быстро пометить любые ошибки компиляции.
Вы также можете сделать это в производственной среде - ускорение первого доступа, но я чувствую, что вы хотите этого больше для этапа контроля качества, чем для чего-либо еще. Если это так, вы можете добавить этап предварительной компиляции к этапу тестирования в выбранном вами инструменте сборки - и, таким образом, в среду CI. Это обеспечит уверенность в том, что jsp, которые не компилируются, не выйдут из тестирования.
Подробнее о выполнении задачи предварительной компиляции см. Здесь:
Надеюсь, это поможет.
Некоторые контейнеры JSP (согласно разделу 8.4.2 спецификации JSP 1.2) поддерживают возможность предварительной компиляции страницы JSP.
Чтобы предварительно скомпилировать страницу JSP, откройте страницу со строкой запроса? jsp_precompile
http://hostname.com/mywebapp/mypage.jsp?jsp_precompile
Страница JSP не будет выполнена. Если контейнер поддерживает предварительную компиляцию, при необходимости JSP-страница будет скомпилирована.
Паблоджим находится на правильном пути. Вам просто нужна дополнительная информация, чтобы получить полное представление о том, что происходит. Вот как я это понимаю.
В prod вы изменили jsp, который требует перекомпиляции других jsps. Для их перекомпиляции должно произойти одно из двух.
Если вам все еще нужно убедиться, что все ваши jsps работают, все они должны быть предварительно скомпилированы с помощью задачи ant . это также позволяет вам развернуть военный файл с предварительно скомпилированным jsps в военном файле. Это должно решить вашу проблему.
Если ваши файлы не развернуты в военном файле, но в развернутом формате вам следует серьезно подумать о том, чтобы упаковать свое веб-приложение в файл war для развертывания. Это делает его удобным для развертывания между средами.