Passing complex domain objects between producers and consumers through JMS typically relies on Java serialization. Apache ActiveMQ implements this capability via the ObjectMessage interface. However, standard deserialization is inherently risky and has historically been exploited for remote code execution attacks. Starting with versions 5.12.2 and 5.13.0, ActiveMQ enforces a strict serialization validation policy. Applications attempting to transmit or consume unregistered classes will immediately fail with a SecurityException indicating that the target class lacks trust as an ObjectMessage payload.

Broker-Level Configuration

To permit cross-process object exchange, administrators must explicitly register application namespaces in a global allowlist. This is managed through the SERIALIZABLE_PACKAGES system property. The most reliable approach is injecting this parameter into the broker startup environment via the ACTIVEMQ_OPTS variable, typically located in the ${ACTIVEMQ_HOME}/bin/env script.

ACTIVEMQ_OPTS="$ACTIVEMQ_OPTS -Dorg.apache.activemq.SERIALIZABLE_PACKAGES=java.util,org.apache.activemq.transport,io.example.services"

The baseline includes standard JDK and transport utilities required for queue operations. Developers simply append their project-specific namespaces to this comma-separated list. Although a wildcard value (-Dorg.apache.activemq.SERIALIZABLE_PACKAGES=*) temporarily resolves the error by accepting all types, it nullifies the security boundary and is strongly discouraged for production environments.

Client-Side Configuration

Deserialization also occurs on the consumer endpoint when ObjectMessage.getObject() is invoked. Consequently, client applications require equivalent trust definitions. Rather than relying exclusively on JVM flags, modern clients support direct programmatic configuration through the ActiveMQConnectionFactory.

You can enforce namespace validation by assigning a curated list of trusted modules:

ConnectionFactory messagingFactory = new ActiveMQConnectionFactory("tcp://localhost:61616");
List<string> permittedModules = List.of(
    "io.example.services",
    "io.example.persistence"
);
messagingFactory.setTrustedPackages(permittedModules);</string>

For rapid prototyping or temporary troubleshooting, you can instruct the client to bypass validation checks entirely:

messagingFactory.setTrustAllPackages(true);

Externalized configuration is equally spuported. By mapping settings to a Properties object, deployment pipelines can inject values dynamically:

Properties clientConfig = new Properties();
clientConfig.setProperty("trustAllPackages", "true");

ConnectionFactory messagingFactory = new ActiveMQConnectionFactory("tcp://localhost:61616");
messagingFactory.setProperties(clientConfig);

Additional security tuning parameters and architectural guidance are available in the official Apache documentation.