jms | JMS Module : A portable extension

The component camel-servlet is not meant to be used in standalone mode as you are trying to do. It is meant to be used when you deploy your Camel application on a Servlet container or an Application Server.

In standalone mode, if you want to expose a rest endpoint, you should rather use a component like camel-undertow, camel-jetty, camel-netty-http or camel-platform-http (you can find the full list here).

Assuming that you want to use undertow, you will have to follow the next steps

In your pom file you need to replace camel-rest with camel-undertow, as next:

You should instantiate the fos-rest View manually and add a Context. On that Context you can set the serialization groups at runtime by evaluating the users roles.

Something like this should work:

Try this:

@JmsListener(destination = "${my-topic}")

You need to add the following dependency to your pom.xml:

The REST/JMS mapping doesn't offer any message browsing functionality.

However, it's worth noting that the REST/JMS mapping is independent of the management functionality exposed by Jolokia. Jolokia is an HTTP-JMX bridge so anything exposed via JMX can be accessed via HTTP (e.g. using curl). The DestinationViewMBean has various "browse" methods you can use, e.g.:

It's not possible to configure the broker to auto-create a dead-letter queue whose name contains the name of the queue where the message was originally sent. As noted in the documentation, the dead-letter queue is named according to the address where the message was originally sent along with any configured prefix and/or suffix.

However, the message itself will have a property named _AMQ_ORIG_QUEUE which will contain the name of the queue where the message was originally routed. This means you can use a consumer with a message selector (e.g. _AMQ_ORIG_QUEUE = 'ConsumerA') so that the consumer will only receive messages which were originally routed to a particular queue. This is functionally equivalent to having a dead-letter queue per-queue.

For what it's worth, what you're calling the "consumer name" isn't the name of the consumer at all, at least not from the broker's point of view. It's just the name of the queue.

Ultimately it's just not possible to configure a dead-letter queue per-queue. It's only possible to configure a dead-letter queue per address. This is true whether the resources are create manually (e.g. via broker.xml) or automatically.

JMS topics, generally speaking, provide publish-subscribe semantics in which every consumer/subscriber gets every message sent to the topic. However, there is a way to get point-to-point semantics with multiple consumers on a JMS topic - shared subscriptions.

Shared subscriptions are available from JMS 2 onward. When using this feature multiple consumers/subscribers can share the same subscription and only one of those consumers will receive a given message.

The simplest way to create a shared subscription is by using javax.jms.Session.createSharedConsumer(). This will create a shared, non-durable subscription and unlike when creating a durable subscription setting the client ID on the connection is optional. There are other related methods for creating shared, durable subscriptions, using selectors, etc.

In short, as long as all the consumers are creating a shared subscription using the same subscription name then you can get the point-to-point semantics you need.

It should technically be possible to convert a javax.jms.TextMessage to a javax.jms.ObjectMessage, but it may be cumbersome. Here are some important things to note:

• javax.jms.TextMessage, javax.jms.ObjectMessage, and org.apache.activemq.artemis.api.core.Message are all just interfaces. The javax version is what you use on the client and Message is what is used on the broker. The data for each type of message is stored differently in the underlying message implementation.
• The class for the Java object that you wish to put into the ObjectMessage will need to be on the broker's classpath. This isn't required under normal circumstances as the broker itself will never serialize or deserialize the object.
• You should really try to avoid ObjectMessage whenever possible. ObjectMessage objects depend on Java serialization to marshal and unmarshal their object payload. This process is generally considered unsafe (and slow!), because a malicious payload can exploit the host system. Lots of CVEs have been created for this. For this reason, most JMS providers force users to explicitly whitelist packages that can be exchanged using ObjectMessage messages. For example, here's the related documentation for ActiveMQ Artemis. There are a number of other issues with using JMS ObjectMessage not related to security that you should read about.

Granted you understand all that you should be able to convert the message using code something like this:

The JNDI feature was added into Log4j 2.0-beta9.

Log4j 1.x thus does not have the vulnerable code.