Intercepting Operations | ActiveMQ Artemis Documentation

- Introduction
- 1. Legal Notice
- 2. Preface
- 3. Project Info
- 4. Messaging Concepts
- 5. Architecture
- 6. Using the Server
- 7. Using JMS
- 8. Using Core
- 9. Mapping JMS Concepts to the Core API
- 10. The Client Classpath
- 11. Examples
- 12. Routing Messages With Wild Cards
- 13. Understanding the Apache ActiveMQ Artemis Wildcard Syntax
- 14. Filter Expressions
- 15. Persistence
- 16. Configuring Transports
- 17. Detecting Dead Connections
- 18. Detecting Slow Consumers
- 19. Resource Manager Configuration
- 20. Flow Control
- 21. Guarantees of sends and commits
- 22. Message Redelivery and Undelivered Messages
- 23. Message Expiry
- 24. Large Messages
- 25. Paging
- 26. Queue Attributes
- 27. Scheduled Messages
- 28. Last-Value Queues
- 29. Message Grouping
- 30. Extra Acknowledge Modes
- 31. Management
- 32. Security
- 33. Resource Limits
- 34. The JMS Bridge
- 35. Client Reconnection and Session Reattachment
- 36. Diverting and Splitting Message Flows
- 37. Core Bridges
- 38. Duplicate Message Detection
- 39. Clusters
- 40. High Availability and Failover
- 41. Graceful Server Shutdown
- 42. Libaio Native Libraries
- 43. Thread management
- 44. Logging
- 45. REST Interface
- 46. Embedding Apache ActiveMQ Artemis
- 47. Spring Integration
- 48. AeroGear Integration
- 49. VertX Integration
- 50. Intercepting Operations
- 51. Protocols and Interoperability
- 52. Tools
- 53. Maven Plugin
- 54. Troubleshooting and Performance Tuning
- 55. Configuration Reference
- Published using GitBook

# ActiveMQ Artemis Documentation

# Intercepting Operations

Apache ActiveMQ Artemis supports interceptors to intercept packets entering and exiting the server. Incoming and outgoing interceptors are be called for any packet entering or exiting the server respectively. This allows custom code to be executed, e.g. for auditing packets, filtering or other reasons. Interceptors can change the packets they intercept. This makes interceptors powerful, but also potentially dangerous.

## Implementing The Interceptors

An interceptor must implement the `Interceptor interface`:

    package org.apache.artemis.activemq.api.core.interceptor;

    public interface Interceptor
    {
       boolean intercept(Packet packet, RemotingConnection connection) throws ActiveMQException;
    }

For stomp protocol an interceptor must implement the `StompFrameInterceptor class`:

    package org.apache.activemq.artemis.core.protocol.stomp;

    public interface StompFrameInterceptor
    {
       public abstract boolean intercept(StompFrame stompFrame, RemotingConnection connection);
    }

The returned boolean value is important:

- if `true` is returned, the process continues normally

- if `false` is returned, the process is aborted, no other interceptors will be called and the packet will not be processed further by the server.

## Configuring The Interceptors

Both incoming and outgoing interceptors are configured in `broker.xml`:

    <remoting-incoming-interceptors>
       <class-name>org.apache.activemq.artemis.jms.example.LoginInterceptor</class-name>
       <class-name>org.apache.activemq.artemis.jms.example.AdditionalPropertyInterceptor</class-name>
    </remoting-incoming-interceptors>

    <remoting-outgoing-interceptors>
       <class-name>org.apache.activemq.artemis.jms.example.LogoutInterceptor</class-name>
       <class-name>org.apache.activemq.artemis.jms.example.AdditionalPropertyInterceptor</class-name>
    </remoting-outgoing-interceptors>

The interceptors classes (and their dependencies) must be added to the server classpath to be properly instantiated and called.

## Interceptors on the Client Side

The interceptors can also be run on the client side to intercept packets either sent by the client to the server or by the server to the client. This is done by adding the interceptor to the `ServerLocator` with the `addIncomingInterceptor(Interceptor)` or `addOutgoingInterceptor(Interceptor)` methods.

As noted above, if an interceptor returns `false` then the sending of the packet is aborted which means that no other interceptors are be called and the packet is not be processed further by the client. Typically this process happens transparently to the client (i.e. it has no idea if a packet was aborted or not). However, in the case of an outgoing packet that is sent in a `blocking` fashion a `ActiveMQException` will be thrown to the caller. The exception is thrown because blocking sends provide reliability and it is considered an error for them not to succeed. `Blocking` sends occurs when, for example, an application invokes `setBlockOnNonDurableSend(true)` or `setBlockOnDurableSend(true)` on its `ServerLocator` or if an application is using a JMS connection factory retrieved from JNDI that has either `block-on-durable-send` or `block-on-non-durable-send` set to `true`. Blocking is also used for packets dealing with transactions (e.g. commit, roll-back, etc.). The `ActiveMQException` thrown will contain the name of the interceptor that returned false.

As on the server, the client interceptor classes (and their dependencies) must be added to the classpath to be properly instantiated and invoked.

## Example

See the examples chapter for an example which shows how to use interceptors to add properties to a message on the server.