Как я дважды боролся с XML в Spring Boot
История одной зависимости Было у меня REST API приложение на Spring Boot 3. Всё работало идеально, все ответы от контроллеры отдавали в JSON. Но однажды понадобилось обработать пару XML-файлов. Я добавил зависимость: И тут начались страдания… Первый раз: Spring Boot 3 После добавления зависимости все мои контроллеры, которые раньше возвращали JSON, начали отдавать XML! Без всякой причины, без изменения кода. Спринг почему-то решил, что основной сериализатор отныне XmlMapper и везде использовал его, кроме тех случаев, когда при запросе на контроллер явно не указывался хэдер Accept: application/json. Много вариантов я перепробовал, перечитал кучу информации и изучил множество советов. Ничего не помогало. В итоге после дебага и поиска различных мест куда можно заинжектить корректирующий код, я наконец нашёл кажется идеальное решение в конфигурации WebMvcConfigurer: Работало! XML-конвертеры удалялись, JSON возвращался. А мой XmlMapper я использовал отдельно для редких XML-задач. Второй раз: Spring Boot 4 Прошёл год, я обновился до Spring Boot 4. И…
Как я дважды боролся с XML в Spring Boot
История одной зависимости Было у меня REST API приложение на Spring Boot 3. Всё работало идеально, все ответы приходили в JSON. Но однажды понадобилось обработать пару XML-файлов. Я добавил зависимость: И тут начался ад… Первый раз: Spring Boot 3 После добавления зависимости все мои контроллеры, которые раньше возвращали JSON, начали отдавать XML! Без всякой причины, без изменения кода. Я нашёл решение, которым даже гордился: Работало! XML-конвертеры удалялись, JSON возвращался. А мой XmlMapper я использовал отдельно для редких XML-задач. Второй раз: Spring Boot 4 Прошёл год, я обновился до Spring Boot 4. И всё сломалось снова! Мой код перестал работать. Метод configureMessageConverters стал устаревшим, вызов super больше ничего не делал. Spring полностью переписал механизм настройки конвертеров. Три дня я бился с новой архитектурой. Интернет предлагал кучу решений: Не работает. Тоже не работает. И это не работает. Я уже отчаялся. Перерыл весь код Spring, посмотрел, как устроен HttpMessageConverters.ServerBuilder, и наконец нашёл рабочий…
На кой фиг мне в 2026 ваши триггеры БД?
Когда я только начинал свой путь в программировании, у меня почему-то устоялось мнение, что хранимые процедуры и триггеры в базах данных — это нечто из разряда легаси, пережитки прошлого, и использовать их в современных системах, грубо говоря, моветон. Сегодня я поймал себя на мысли, что моё восприятие этих вещей кардинально изменилось, особенно в части триггеров. И поводом для этого стал очень интересный кейс. В моей базе данных хранится огромное количество элементов, и у каждого из них — бесчисленное множество свойств. Мне нужно при каждой выборке списка находить и группировать одинаковые сущности. Но чтобы понять, идентичны ли два элемента, необходимо сджойнить все связанные таблицы, проверить все атрибуты, теги, значения. В итоге получался монструозный запрос с кучей джойнов, который работал непозволительно долго и просто не отвечал требованиям системы по скорости. Решением казалось очевидное: вычислять специальный хэш на основе всех свойств и связанных данных и хранить его рядом. Но тут возникла новая проблема…
Claude слил недельный лимит на поиск опечатки в 1 символ
Сегодня я хочу поделиться поучительной историей о том, как современные ИИ-помощники могут быть одновременно невероятно умными и удивительно… скажем так, настойчивыми в своей неправоте. Проблема После допиливания новой фичи, столкнулся с массовым падением тестов при `mvn install`. LazyInitializationException, detached entities — знакомая боль всех, кто работал с Hibernate. ИИ во всей красе Из опыта знаю что скорее всего проблема в одном месте и эта проблема порчи контекста String где-то в процессе выполнения тестов. Решил поручить решение ИИ-ассистенту. С энтузиазмом новобранца он начинает сыпать решениями: — «Добавьте `@DirtiesContext`!» — предлагает он с важным видом. — «Разве не очевидно?» — продолжает ИИ, игнорируя моё возмущённое «плохое решение, нужно найти проблему, а не расставлять костыли!» ИИ, не теряя оптимизма, продолжает генерировать варианты конфигураций Hibernate, Spring контекста, транзакций… Ручное расследование Отчаявшись получить вразумительный ответ от ИИ, начиная собственное расследование. Один за другим откатываю коммиты, запускаю тесты, откатываю ещё, снова запускаю… Наконец-то! Вот он —…
💡 Момент озарения про JOIN’ы, декартовы произведения, проблему N+1 и трюк с ID
Несколько лет я развиваю свой сервис. За это время он оброс множеством интеграций с другими микросервисами. Для этих интеграций приходится делиться данными. 🔄 Проблема в том, что данные не собраны в одной таблице. Они разбросаны по разным, имеют связи: · «многие ко многим»· «один ко многим»· «один к одному» В разных кейсах их нужно комбинировать и фильтровать. И каждый раз — проблема с оптимизацией запросов. Одни работают быстро, другие — медленно. Где-то нужны дополнительные поля из смежных таблиц, где-то нет. 🐢⚡ В итоге у меня появилась куча контроллеров, которые достают одни и те же данные, но: · с разным списком полей· и по-разному обогащённые из смежных таблиц В какой-то момент я понял: этот зоопарк нужно приводить к одному эффективному виду. 🦁🐧🐪 Но возникла новая проблема: · одним запросам нужны обогащения из одних таблиц,· другим — из других,· третьим — минимальные обогащения (и они просто летают 🚀). Также нужно использовать разные…
Оптимизация SQL запросов — Entity для промежуточных таблиц в JPA
При работе со Spring Data JPA и @ManyToMany частой проблемой являются неоптимальные SQL-запросы из-за избыточных JOIN’ов. Создание отдельной Entity для промежуточной таблицы решает эту проблему, позволяя оптимизировать запросы и снизить нагрузку на базу данных. Такой подход также улучшает читаемость и поддержку кода.
Как я отказался от аренды VPS для своего проекта
Для моего сервиса я использую VPS-хостинг. Поскольку у меня в один момент времени запущено не менее 50 отдельных jar-микросервисов, серверу нужно достаточно много оперативной памяти. Я выкрутил настройки своего хостера на максимум довольствовался 32 ГБ оперативной памяти. Всё шло хорошо: клиенты оплачивали сервис, и с этих денег я оплачивал VPS. Так длилось около двух лет… пока 1 апреля 2026 года хостер не решил обновить тарифы. Да, он заранее присылал письмо, но конкретных цифр я не видел. Каково же было моё удивление, когда при очередном пополнении счёта я увидел, что мне предлагают оплатить в 3 (три!) раза больше, чем обычно! 🤯 Отрицание. Гнев. Торг… На стадии торга я написал в поддержку и попытался выпросить индивидуальные условия — ведь при такой стоимости услуг мой сервис переставал окупаться. К сожалению, техподдержка без капли сочувствия заявила, что цены на ОЗУ выросли, и теперь услуги будут стоить именно столько. Без вариантов. Последующих стадий (Депрессии, а…
Обособленная аутентификация через Вконтакте посредствам SSO на SpringSecurity
Я создал отдельный сервис SSO аутентификации 🔐чтобы собрать воедино всю аутентификацию и авторизацию многочисленных микросервисов проекта в одном месте. Однако, перенести всю локальную авторизацию в SSO не так-то просто и требует глубокого осмысления пути интеграции. Поэтому пока я морально к этому не готов и отложил это занятие на потом 😌 В то же время обнаружилось, что авторизация Вконтакте перестала работать ❌ оказалось, что тот способ с неограниченными access_token’ми вконтакт признал устаревшим и теперь он перестал работать. Возникла острая необходимость срочно переписывать подход на новые рельсы 🚨 Здесь как-раз очень удачно появился SSO, т.к. там аутентификация через ВК написана с новым подходом ✅ Однако, SSO позволяет авторизовываться не только через ВК, но и через Email, Яндекс, Google и Github. И теперь мне нужно как-то чтобы заставить пользователя авторизоваться именно через Вконтакте 🤯 Долго думал над вариантами, и каждый из них в рамках действующих потоков авторизации выглядел не очень удобно или даже…
JetGoods: Бесплатный конструктор Telegram-ботов с премиум-функциями без ограничений
JetGoods — это инновационный инструмент для создания Telegram-ботов. Он позволяет создавать и настраивать ботов без технических знаний. С помощью JetGoods вы можете улучшить взаимодействие с клиентами. Что такое JetGoods? JetGoods — это инновационная платформа, предназначенная для создания и управления Telegram-ботами без необходимости иметь глубокие технические знания. Она предлагает простой и интуитивно понятный интерфейс для создания сложных ботов. Простота использования: JetGoods предлагает интуитивно понятный интерфейс. Мощные функции: Широкий набор инструментов и функций. Гибкость и масштабируемость: Легкая адаптация к меняющимся потребностям. Используя JetGoods, пользователи могут создавать ботов, которые не только отвечают на базовые запросы, но и предоставляют персонализированный опыт. Преимущества JetGoods JetGoods предлагает ряд значительных преимуществ, которые делают его идеальным выбором для создания Telegram-ботов. Во-первых, JetGoods обеспечивает простоту и удобство в использовании, что позволяет пользователям сосредоточиться на разработке своего бота, не отвлекаясь на технические детали. Кроме того, JetGoods предоставляет широкий спектр функций и инструментов, которые позволяют создавать высокоэффективные и функциональные боты. Это…
JetGoods: Бесплатный конструктор Telegram-ботов с премиум-функциями без ограничений
Рынок конструкторов чат-ботов переполнен предложениями, но почти все они имеют существенный недостаток — жесткие лимиты и дорогие тарифы. Хотите больше 500 подписчиков? Платите. Нужна рассылка? Покупайте PRO-аккаунт. JetGoods.ru меняет правила игры. Создали платформу, которая предоставляет возможности дорогих корпоративных решений абсолютно бесплатно. Забудьте о ежемесячных платежах и скрытых комиссиях. Почему JetGoods — это революция в создании ботов? Наш сервис не просто «еще один конструктор». Это инструмент, который дает вам полную свободу действий без оглядки на бюджет. Честная бесплатность: Никаких ограничений В отличие от конкурентов, мы не ограничиваем вас в росте.Неограниченное количество ботов: Создавайте столько проектов, сколько нужно вашему бизнесу.Безлимитные подписчики: Неважно, 100 у вас клиентов или 100 000 — вы ничего не платите за объем аудитории. Премиум-функции, доступные каждому То, что другие продают в дорогих тарифах, у нас является базовым функционалом: Визуальный конструктор (Bot Builder) Вам не нужны программисты. Наш раздел Bot Builder позволяет собирать сложную логику из простых блоков. Перетаскивайте…