Мы внедрили фильтр или плагин в брокере ActiveMq, который перехватывает входящие сообщения и проверяет их с точки зрения безопасности.
Нам нужен удобный для программиста способ получения этих исключений на стороне производителя (в идеале нена уровне соединения, но на уровне сеанса или производителя, так как они могут нуждаться в специфической реакции сеанса).
Мы выполняем авторизацию на уровне сообщений на стороне посредника следующим образом: в поставщике ActiveMq (сервере) мы реализуемBrokerFilter (плагин) для перехвата входящего сообщения JMS и проверки маркера доступа JWT, прикрепленного к сообщению, как свойства.Если токен JWT действителен, то сообщение пропускается по нисходящей цепочке, если оно недопустимо, генерируется исключение SecurityException.
Мы замечаем, что сообщение действительно возвращается отправляющей JVM, которая сообщает, что ExceptionListener отсутствуетэкземпляры, зарегистрированные для конкретного исключения.
Наш вопрос: где мы можем лучше всего зарегистрировать ExceptionListener в Spring JMS для этого сценария?У нас есть прямой доступ к производителю и сеансу JMS, но не к соединению JMS.
Это правда, что регистрация ExceptionListener для соединения была бы полезна для событий уровня соединения, но для событий уровня сеанса это может сделать код более понятным и связным, если бы мы могли регистрировать такие прослушиватели исключений локально для сеанса илипроизводитель, так как они являются своего рода прямым ответом на попытку отправки сообщения.
Конечно, было бы также возможно реализовать локальных слушателей исключений через уровень соединения и локальную структуру потока локальных слушателей, но мне интересно, еслиJMS или Spring уже предоставляют такую возможность сеансу или производителю, которые напрямую узнают, что их сообщение не было авторизовано, так что они отвечают в восходящем направлении на вызов микросервиса, а не повторно пытаются отправить его, например.
Мы используем постоянные сообщенияно не уверены, делаем ли мы синхронную или асинхронную отправку.Я полагаю, что при асинхронной отправке, ExceptionListener некоторого вида будет вызываться при таком событии (исключение выдается в методе BrokerFilter.send).В то время как при синхронной отправке, возможно, исключение будет выброшено напрямую (но блокировка потока может снизить надежность микросервиса).
Это решаемо с помощью connection.setExceptionListener, но для нас это, вероятно, будет более удобным для сеанса.setExceptionListener или даже прослушиватель уровня запроса сообщений.
Мы хотели бы увидеть любые другие возможные варианты в Spring JMS, кроме регистрации прослушивателя исключений на уровне соединения и, кроме синхронной отправки, если возможны любые другие такие параметры.