Совет 💡

Если вы хотите получить сообщение о первопричине, вы можете легко и безопасно получить его с помощью Apache Commons ExceptionUtils. Методы getRootCauseMessage(Exception ex) выдают сообщение в виде {ClassNameWithoutPackage} {ThrowableMessage}

👉@BookJava

Опишите жизненный цикл сервлета

Поговорим об этапах работы центрального элемента JavaEE web-приложения – сервлета.

События жизненного цикла сервлета можно разделить на две группы. Первая группа – события, относящиеся непосредственно к самому сервлету. Все они объявляются методами из базового интерфейса Servlet. Примерно такие же фазы жизни и у фильтров.

1. Загрузка класса и создание экземпляра сервлета, конструктор. Может быть создано несколько экземпляров.

2. Инициализация – в общем случае метод init. Инициализация гарантированно происходит до первого запроса, один раз на один сервлет (даже если экземпляров несколько). По умолчанию она ленивая, то есть случается непосредственно перед обработкой этого первого запроса. Другой режим, пре-инициализация, включается свойством loadOnStartup.

Если в качестве инициализации нужно всего лишь параметризовать сервлет, вместо реализации метода достаточно передать параметры в свойстве initParams аннотации @WebServlet. Эти параметры, и другую информацию можно прочитать из объекта конфигурации типа ServletConfig. Дефолтная реализация init-метода принимает эту конфигурацию и сохраняется в поле.

3. Обработка запроса – service. В отличие от Spring Framework, в классической JavaEE все запросы вне зависимости от HTTP-метода, пути и набора параметров попадают в единый метод-обработчик. Вся информация о запросе приходит в параметре ServletRequest. У метода нет возвращаемого значения, вместо этого модифицируется второй параметр – ServletResponse. Для фильтров аналогичный метод doFilter, он кроме запроса и ответа принимает третий параметр, FilterChain.

4. Завершение работы – destroy. Здесь всё как обычно с финализациями: вызывается только однажды, только при корректном завершении, после ее вызова service/doFilter уже никогда не будет вызван.
Другая группа событий – то что происходит со связанными с сервлетом сущностями. Таких сущностей три: ServletContext, ServletRequest и HttpSession.

На каждую из этих сущностей есть два интерфейса-слушателя. Интерфейс XListener сообщает о создании и уничтожении сущности через два соответствующих метода. Так, чтобы совершить какое-то действие при открытии новой HTTP-сессии, действие нужно поместить в реализацию метода HttpSessionListener.sessionCreated().

Все три типа позволяют хранить пользовательские данные – атрибуты. Они хранятся по ключам-строкам, как в хэш-таблице. Методы второго интерфейса XAttributeListener дают возможность обработать добавление, изменение и удаление атрибутов. То есть, если где-то в программе в контекст сервлета добавляется значение (вызван ServletContext.setAttribute("myKey", someValue)), то сработает ServletContextAttributeListener.attributeAdded.

• ServletContext – прослойка между отдельными сервлетами и сервлет-контейнером. Есть только один контекст на всё web-приложение. Он в отличие от сервлетов не ленивый, и инициализируется на старте приложения, до инициализации отдельных сервлетов.

• ServletRequest – отдельный запрос. На каждый запрос создается новый такой объект, инициализируется перед основным обработчиком Servlet.service(), уничтожается после.

• HttpSession – HTTP-сессия, которая служит для поддержания состояния между запросами для одного пользователя. Обычно создается вручную внутри обработчика Servlet.service(). Уничтожаться может как тоже вручную в обработчике, так и по истечению срока жизни. Только для сессии есть третий интерфейс, который уведомляет об изменении идентификатора – HttpSessionIdListener.

Чтобы объект под этими интерфейсами начал получать уведомления, его нужно зарегистрировать в контексте. Это делается либо явным вызовом ServletContext.addListener, либо аннотацией @WebListener на класс.

👉@BookJava

Работаем с enum в kotlin/jvm правильно

А вы знали, что HashMap для enum уступает по эффективности EnumMap? Или что EnumSet под капотом это обычный long? Под катом несколько рецептов удобного применения этих структур.

https://habr.com/ru/articles/781730/

✍️ @kotlin_lib

Разбираемся с GraalVM, AOT и JIT

Если вы хотите разобраться, что такое GraalVM, как он работает, и в чем различия между Just-In-Time (JIT) компиляцией и Ahead-Of-Time (AOT) компиляцией, то это руководство — именно то, что вы искали.

https://www.marcobehler.com/guides/graalvm-aot-jit

👉@BookJava

Project Loom. Не только виртуальные потоки

Начиная с Java 19 нам доступны виртуальные потоки, которые отличаются от обычных, тем что умеют освобождать поток операционной системы во время блокирующих I/O операций. Для этого на уровне JVM был реализован механизм сохранения в хипе и восстановления из хипа стека вызова. Проще говоря, были реализованы полноценные корутины на уровне JVM.

И это небольшая революция, на которую мало кто обратил внимание. Само API для таких нативных корутин непубличное, доступно через класс jdk.internal.vm.Continuation, в котором есть методы yield() и run() для сохранения и восстановления стека вызова соответственно. Но получить доступ до него несложно, нужно лишь добавить пару аргументов в строку запуска JVM (либо воспользоваться инструментом, который позволяет обходить ограничения JPMS).

https://habr.com/ru/articles/785334/

👉@BookJava

Как сгенерировать фальшивые тестовые данные

Вы также часто не испытываете вдохновения, когда вам нужно придумать полезные тестовые данные для ваших модульных тестов? Является ли "неизвестный" вашим лучшим другом в тестировании? Не волнуйтесь, Java Faker приходит на помощь! В этом статье вы узнаете, как генерировать тестовые данные.

https://mydeveloperplanet.com/2022/04/19/how-to-generate-fake-test-data/

👉@BookJava

Как отслеживать приложение Spring Boot с помощью Ostara

Когда приложение в продакшене, разумно следить за его состоянием. Вы хотите быть уверены, что все работает без проблем, и единственный способ узнать это - определить состояние вашего приложения. Когда что-то пойдет не так, вы, надеюсь, получите уведомление до того, как ваш клиент заметит проблему, и, возможно, сможете решить ее до того, как клиент что-то заметит. В предыдущем посте было рассказано о том, как отслеживать состояние приложения с помощью Spring Actuator, Prometheus и Grafana. В этой заметке вы рассмотрите альтернативный подход с использованием Spring Actuator в сочетании с Ostara. Настройка Ostara немного проще, и поэтому она выглядит как подходящая альтернатива. Доказательство пудинга - в его поедании, так что давайте попробуем Ostara!

https://mydeveloperplanet.com/2023/11/29/how-to-monitor-a-spring-boot-app-with-ostara/

👉@BookJava