P_Alexander

Здравствуйте!
Почему бы вам не восопльзоваться возможностями шаблонизатора?
Вот, несколько вариантов решения вопроса:

1) Использование тернарного оператора

<span th:text="${address.city != null} ? ${address.city} : 'No data!'">City</span>

2) Использование: if unless (аналог if else на java). Обратите внимание, что если city это строка, то можно использовать ==, а если объект, то нужно использовать eq

<span th:if="${address.city} == null">Non data</span>
<span th:unless="${address.city} != null" th:text="'Your city : ' + ${address.city}">Non data</span>

Также обратите внимание, что вы можете "обеспечить защиту" приложение, если значение null используя оператор безопасной навигации ?. между address & city

<span th:text="'Your city : ' + ${address?.city}">Non data</span>

Терминал открыть можете? Если да, попробуйте сначала lsblk, он покажет все блочные устройства, разделы на них и точки монтирования, если есть. Ну и если, вдруг, /dev/sda5 кудато смонтирован, то umount /dev/sda5.

git reset --hard HEAD

git reset --hard
https://git-scm.com/docs/git-reset

У меня маленький опыт общения с SSD, но вероятно будет интересно. Примерно год назад провёл опыт: купил дешевый SSD (PLEXTOR LiteOn MU 3 PH6-CE120-M06 120Гб), зарядил на него все временные файлы, кэши системы и программ. Работаю дизайнером, так что довольно быстро на диске было занято 70 Гб. Жил девайс около 2 месяцев, потом мне вернули деньги, а я получил хлопоты с переназначением путей в системе и программах.
Потом нашёл вот этот материал (обновляется!) https://3dnews.ru/938764 и по их наводке купил снятый с производства Кингстон на MLC (KINGSTON SUV300S37A120G). Пашет он примерно пол-года в том же режиме (все системные темпы, кэши + все графические кэши). SMART 96%. Если просматривать в Бридже по несколько тысяч картинок и крутить в Фотошопе пару Гб, то вполне. Для себя сделал вывод, что SSD для работы требует денег. Мой копеечный Кингстон - редкий случай. Если буду собирать следующий рабочий комп, то буду ориентироваться на SSD с большим ресурсом и свой кошель.

Базы не стоит хранить на SSD.
Их стоит держать на SSD - для скорости работы - и почаще бэкапить хотя бы на HDD, если вам дороги данные и рассудок.

- возьмите минимум x SSD-диска и сделайте из них RAID1.
- возьмите минимум x*2 SSD-диска и сделайте из них RAID10.
в каждом случае x>2

SSD - это расходник. Давно уже нужно понимать, что в 99% случаев, жизнь SSD более чем достаточна, особенно для "базы для личной разработки". Возьмите нормальный SSD на терабайт, и он переживет HDD

Стоит ли хранить базы данных на SSD?

Да, если требуется высокая скорость работы с БД.

перенести на HDD для продления жизни SDD?

Бред.

В зависимости от "энтерпрайзности" вашего SSD и частоты обращения к нему, все индивидуально
ЗЫ. качаю торренты на SSD и не парюсь

сервер базы стоит на SSD

Я думаю, где стоит сам сервер - особой разницы нет.

Меня интересует стоит ли хранить сами базы на SDD или лучше их перенести на HDD для продления жизни SDD?

Для ответа на этот вопрос, нужно оценить следующие факторы:
1. Оно Вам действительно нужно, что бы базы работали на SSD, скорости HDD не хватает?
2. Резервирование диска? Т.е. если диск "крякнется" - есть дублирующий носитель, RAID или что-то ещё подобное? Если у одного из дисков он есть - лучше хранить на том диске, у которого оно есть.

3.

Стоит отметить что базу используя для личной разработки.

Дочитал до этого пункта и... Из личного опыта могу рассказать Вам одну историю... Есть у нас сервер 1U, купленный изначально "для работы", потом мы его отдали под проект. В сервере среди прочего стоит SSD, самый обыкновенный, на 120Гб, из числа тех что стоят сейчас в районе 1500руб., стоит он там уже более 2-х лет (с того момента как мы его отдали проекту), ежедневно и беспрерывно, 24х7 диск "молотит" база достаточно крупного проекта (и сам проект стоит там же), изначально было много опасений на тему того, что диск не проживёт там и месяц... но, любопытство всё же пересилило и мы решили попробовать. Результат - по прошествии 2+ лет "здоровье" диска в районе 74%, думаю ещё года 3 он там проживёт за милую душу. Единственное отличие нашего диска от тех, что продаются сейчас - у него MLC-память, но что-то мне подсказывает, что этот факт никак не даёт диску сколь-нибудь фантастическую живучесть по сравнению со всеми остальными.

P.S. С учётом цен на SSD на сегодняшний день, и того, что Вы собираетесь его использовать даже не в боевых условиях - я бы не стал забивать себе голову такими мелочами. Храните базу там, где Вам удобнее. Скорее всего, диск будет выброшен и заменён на другой раньше по техническим причинам, чем успеет "сдохнуть".

Вам нужен алиас (alias), а не ссылка, если я правильно понял замысел.

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

Скидывайте выводы
blkid
fdisk -l

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

static variable

Thymeleaf

imho, никакой. Вполне достаточно отдавать данные (например в виде json), а весь фронт - в виде какого-нибудь js или мобильного приложения.

Выбирайте сами spring-template-engines
Если MVC то я взял бы Thymeleaf, если репортинг то всё ещё Velocity

jwt в первую очередь используется в микросервисных архитектурах, когда конечный клиентский запрос будет обрабатываться одним из нескольких серверов.

Классически в такой архитектуре использовали механизмы OAuth. которые при обслуживании каждого запроса клиента осуществляли запрос на сервер OAuth - "клиент с токеном ААА запрашивает выполнение действия БББ"

Понятно что узким местом становится сервер OAuth - который должен выдержать "шторм" запросов при нагрузке. Вторым узким местом такой архитектуры становится увеличение времени ожидания ответа на запрос - внутри запроса как минимум будет выполнен 1 запрос авторизации.

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

JWT решает эти проблемы следующим путем: access токен сразу же содержит необходимую информацию: на пример о Ролях текущего пользователя, или о доступных ему действиях, кроме того предоставляет информацию о времени жизни этого токена. Обязательно в конце токена цифровая подпись. По ней собственно и проверяется "действительность" токена.

Алгоритм прост:
1. осуществить авторизацию - получить ответ 2 токена access, refresh.
2. обращаемся к микросервисам с использованием access токена.
3. если необходимо с помощью refresh токена обновляем access токен.
4. когда и refresh токен истек - осуществляем повторную авторизацию.

Где хранить JWT токен - где угодно. все зависит от инструментов и реализации. На пример можно реализовать хранение токена в LocalStorage, и пробрасывание его во время каждого запроса в виде header'а. Если один и тот же домен - то токен можно хранить в cookie и т.д.

Что хранить в виде полезной нагрузки? Сам разработчик должен для себя решить какой объем информации публиковать в таком токене, кроме того стоит учитывать что информацию из токена можно прочитать - это просто base64 кодированная JSON строка...

ну, кроч, там же, в помнике, есть секция properties, где можно задать значения и таскать их по всему пому

вот, например

<properties>
        <java.version>1.8</java.version>
        <hibernate.version>4.3.5.Final</hibernate.version>
        <log4j.version>2.6</log4j.version>
</properties>

а если, при запуске, я захочу переопределить значение, скажем для log4j.version, то я просто могу

mvn clean install -Dlog4j.version=тут новое значение

В статьях такое пишут
${versions.wildfly}
просто потому, что версия не важна и предполагается, что вы используете самую актуальную (ну или самую стабильную версию)

Зачем такое вообще делать?
Предположим, у вас в проекте много зависимостей от одного поставщика
Spring, например. У него там тьма пакетов. При этом, рекомендуется использовать эту тьму всегда одной версии для всех (они их так и релизят)
Если версия задается только в одном месте - легко будет ее переопределить для всего проекта