Развлекаюсь с сервлетами, делаю ритуальное:
и понимаю, что получается портянка с большим количеством похожих кусков.
Начинаю разносить похожие куски по отдельным методам и получается, что каждому надо передавать более-менее значительное число параметров, чтобы учесть различия похожих кусков.
Задумываюсь и понимаю, что должен помочь класс-обёртка, который назовём "капсулой".
Экземпляр капсулы будет создаваться внутри service(), хранить состояние всего, что мне нужно, а методы капсулы будут напрямую работать с переменными экземпляра.

Как пример - протоколирование.
Я должен или собирать строку каждый раз, когда требуется log.debug(сообщение), что громоздко или передавать адрес клиента, текстовую строку, идентифицирующую стадию обработки, размер прочитанных/записанных данных, время, потраченное на обработку и т.п. в отдельный метод, что чуть компактнее, но всё равно коряво.
С классом-обёрткой будет что-то вроде logPhase1() и т.п.
Разумеется, класс-обёртка всё равно получится достаточно большим - портянка есть портянка и весь вопрос: "куда её прятать?".

"Внимание, вопрос!".
С учётом того, что ява хорошо справляется с большим количеством короткоживущих объектов, выглядит неплохо, но может быть я изобретаю велосипед и "есть способ лучше"?

P.S. Про ThreadLocal - в курсе, но это (всего лишь) способ хранения капсулы со своими плюсами и минусами.
То, что такой способ может привести к утечке ресурсов - тоже понимаю.

вадяSingleton не рассматривал?
в нем сохранять все параметры, а каждый метод будет извлекать только нужные ему параметры?Singleton не годится в принципе - у каждого запроса своё состояние и одновременно может (и будет) обрабатываться несколько запросов.

scfЕсть - IoC контейнеры
Guice или даже Spring Framework.Подключение Spring-a, чтобы (несколько) упростить пятикилобайтный класс - некий оверкил, но, может быть, я чего-то не понимаю?
Можно более расширительно?

Petro123если нужно состояние, то его выдялют в некий объект ВНЕ сервлета и БЛ-сервисов и хранять в сессииИменно так оно и есть - отдельный объект, экземпляр которого создаётся внутри service().
В данном конкретном случае всё полностью sessionless, хотя (недавно) клиент и научился работать с сессиями.А сам сервлет - процедурное программирование.Вот поэтому и хочется состояния.

Petro123из треда не видно, что ты делаешь "стандартную корзину покупателей"Боже упаси. Ничего близкого к интернет-магазину, витрине, каталогу, e.t.c.....и в чём вопрос?Вопрос в корректности подхода к хранению состояния http-запроса.состояние делается инжекцией объекта Корзина из сессии.Нет сессий, нет. И бизнес-логики нет.
Голый транспорт, который надо обработать и запротоколировать эту обработку.

Petro123подробнее.
Время там есть, имя класса есть, уровни есть....
Вроде тривиально, но добавляем логирование:
Если копипастить такой код в разные места, то это не только коряво и увеличивает размер класса на ровном месте, но и "разбавляет" основную логику, затрудняя чтение и понимание.
И это ещё не рассматривается отслеживание времени обработки и увеличение детализации обработки - отслеживание числа фактически прочитанных байт или/и ведение трассировки.
Если вынести в отдельные методы внутри сервлета, то им придётся передать кучу параметров.

вадяа более подробно о проекте?
возможно и другое решение..Из http-запроса достаётся (возможно упакованный) массив байтов, отправляется на сервер приложений и ответный массив байтов возвращается http-клиенту.
Входящий запрос контролируется на минимальный и максимальный размер, распакованное задание контролируется на максимальный размер.
Если ответ сервера приложений не упакован - упаковываем перед отправкой клиенту, если размер ответа превышает два килобайта.
Чтение запроса, отправка задания серверу приложений и запись ответа протоколируются в отладочном режиме.
Обрабатываются ситуации:
1. Контейнер сворачивает (undeploy) контекст - по возможности возвращаем ошибку клиенту, протоколируем информационное сообщение в методе destroy и отладочное сообщения в методе service;
2. Запрос не прошёл контроль - по возможности возвращаем ошибку клиенту и протоколируем отладочное сообщение;
3. Ошибка чтения запроса - прерываем обработку и протоколируем предупреждение;
4. Ошибка обмена с сервером приложений - возвращаем ошибку клиенту и протоколируем предупреждение;
5. Ошибка записи ответа - протоколируем предупреждение.
За обмен с сервером приложений отвечает отдельный (готовый) класс, потроха которого нас не интересуют.

Petro123я делаю так:
...
в самом начале сервлетаЭто годится только для самого примитивного случая - проинформировать, что "шитхэппенед".
При разборе проблем извлечь из такого сообщения полезную информацию невозможно.

P.S. А количество "строк на событие" определяется исключительно желаемой или требуемой детальность: трассировка с лёгкость может создать десятки и даже сотни строк на каждое событие.

Petro123ты не понял. Там внутри логировщик тоже.
ООП же, хоть и в процедурном программировании без состояния.Я понял, но в лог-файле нет ни логгеров ни ООП - только текстовые строки.
А мне хочется сделать протоколирование на качественном уровне. Тем более, что и пример есть - DrWeb Enterprise Suite

Petro123т.е. если тебя DOC'ят, то входные неверные - нужно выходить из обработки как можно быстрееИ это понятно. Просто в моём случае нет никаких особых признаков атаки, поэтому используется простейший контроль по априорным параметрам.

Petro123по задаче.
Т.к. у тебя нет сессий, т.е. нет и состояния. Весь поток ты принимаешь за раз. И обрабатываешь за один реквест.
Тебе хранить между реквестами нечего.Мне и не нужно хранить между запросами. Нужно хранить внутри запроса, т.к. он разбивается на логические фазы. Причём эти фазы мельче "технически необходимых".

P.S. В принципе, можно закругляться: принципиальных возражений я не вижу, остальное - детали реализации, которые виднее именно мне