Interceptor properties

Service interceptor properties are defined using the properties element in the @Interceptor annotation. These properties allow developers and administrators to configure runtime behavior without hardcoding values, making the interceptor more reusable and flexible.

Defining properties

Properties are supplied as key-value pairs using the syntax:

1
2
3
4
5
6
7
@Interceptor (
    name = "AuditLogInterceptor",
    displayName = "Enterprise Interceptor",
    description = "Logs service access events for auditing.",
    urlPatterns = {"/services"},
    properties = {"logLevel=INFO", "trackUser=true"}
)

In the above example:

• logLevel controls the verbosity of audit logs

• trackUser turns user-level tracking on or off

Accessing properties in code

Inside your interceptor implementation, use the IInterceptorConfig interface to access these properties. The getProperties() method returns a Map<String, String> of all configured values.

1
2
3
4
5
6
7
8
9
10
@Override
    public void init(IInterceptorConfig config,
                    IServerServicesInterceptorHelper helper,
                    IServerInterceptorLogger logger) {

    String logLevel = config.getProperties().get("logLevel");
    String trackUser = config.getProperties().get("trackUser");

    logger.info("AuditLogInterceptor initialized with logLevel: " + logLevel + " and trackUser: " + trackUser);
}

This pattern makes it easy to implement dynamic behavior, such as enabling features, specifying thresholds, and configuring filters, in your interceptor.

When developing a service interceptor, use property-driven configuration to maintain a flexible and environment-agnostic implementation. Define clear, meaningful property keys in the @Interceptor annotation and access them through IInterceptorConfig. Always validate property values at runtime and provide sensible defaults to ensure reliability and consistency. Document the expected properties and their impact to help administrators configure them correctly. Avoid hardcoding logic where configurable parameters can improve reusability and ensure property names are unique enough to prevent conflicts in complex deployments. Consider default values in your logic in case a property is not set.