JMS Outbound Channel Adapter and dynamic destinations defined at runtime?

[spug8e]

Hi,

Is it possible to dynamically set a jms destination at runtime when using Spring Integrations jms outbound_channel_adapter? i.e. is it possible to make use of the send(destination_name, message) method in jmsTemplate via Spring Integration?

Cheers,
Andy.

[Mark Fisher]

Andy,

Thus far, we have considered any 'channel-adapter' or 'gateway' to be relatively fixed to a given destination. For example, the "ws" and "http" outbound adapters also refer to a single URL. However, that single *logical* location may be dynamic in terms of the *physical* location in certain situations. For example, with the "ws" outbound-gateway, you can provide a DestinationProvider strategy (defined by Spring-WS). Likewise, with the "jms" outbound adapters, you can provide a DestinationResolver (defined by the Spring Framework).

We have been considering runtime, per-invocation, dynamic destinations, but this seems like a slightly different component type than our current adapters. For example, you can refer to the discussion here, which is quite relevant even though it is about Web Service URIs:
http://jira.springframework.org/browse/INT-612

That said, for JMS, it seems that the most common need for dynamic destinations to be resolved at runtime is for checking the "JMSRreplyTo" property of the inbound JMS Message. That *is* currently supported by our JMS "inbound-gateway" (it can send a reply to the dynamically determined JMS Destination based on that property being present on an inbound message). Is that your use-case? If not, I would like to know more about it, and we can add it within the same category as the INT-612 issue I mentioned above.

Thanks,
Mark

[spug8e]

Hi Mark,

Thanks for the quick reply. The scenario in which I'd like to dynamically set a jms destination is as follows:

I have some legacy code that provides the user with a GUI to specify a jms destination name associated with a "delivery job". I also have some legacy code that has the ability to extract that jms destination name from a database based on the delivery job name. I would now like to add functionality to this to reuse a spring jmsTemplate to send to the various destinations. I realise this can be done easily enough without Spring Integration just be using convertAndSend(destination,message) on the jmsTemplate, but I'm interested in seeing if a similar thing is possible in SI.

I'm guessing I'd have a SI gateway as the entry point into SI from the legacy code and then a jms outbound channel adapter. Even if its possible to set a custom destination resolver on the channel adapter, I'm not sure how, in this scenario, I'd be able to hook that back into the legacy code so that it has enough information to perform the jms destination lookup from the database.

Thanks,
Andy.

[Mark Fisher]

Andy,

When they specify the JMS Destination name in the GUI, is it a dropdown list? or do they just type in the name?

I'm wondering if there is there an actual list of valid destination names somewhere or if Destinations are actually created dynamically. If the actual destinations are fixed, how many are there?

Thanks,
Mark

[spug8e]

At present it is not a drop down list... users will be able to enter a destination name as free text - It'll be up to the code that tries to send on that destination to handle any rubbish destinations nicely

[Mark Fisher]

Okay, but it does sound like a "fixed" list of valid Destinations. How many are there?

[sjlloyd]

I realise that this is an old thread, but I have a use case which requires JMS destinations to be resolved dynamically at runtime, and at the moment it is seeming like I am going to have to use Camel instead of Spring Integration to achieve what I am after. I'm hoping to be proven wrong, if for no other reason than that we are already using Spring, so just adding SI on top would be fairly minor.

Our use case specifically involves ActiveMQ, which can dynamically create topics and queues at runtime. We want to be able to send objects to destinations based on the type of each object - in this way we can subscribe to particular event types (and hierarchies) using destination wildcards (again, specific to ActiveMQ). To do this in Camel is very straightforward - we can simply set the JMS destination in the message exchange header in an interceptor/filter on the way out.

Is there any way to achieve this using Spring Integration? (using 2.0.0 M6 at the moment).

[Mark Fisher]

Our Channel Adapters and Gateways are really intended to be *addressable* endpoints, i.e. they are connected to some concrete destination (or file directory, or URI, etc.). The way we view something like a JMS outbound-channel-adapter is that we are literally connecting a Spring Integration MessageChannel to a JMS Destination. You can send a generic Message to that endpoint, and it will be converted into a JMS Message and then sent to the JMS Destination.

Now, under the covers, that adapter is simply using JmsTemplate to accomplish that conversion and sending of the JMS Message. Any solution that requires dynamic resolution of Destinations at runtime can easily rely on JmsTemplate and can just as easily be used from within a Spring Integration application.

As an aside, the type of dynamic behavior you are describing sounds like a good fit for AMQP Topic Exchanges. Have you considered that alternative?

[keerthib]

Hi,

I have a requirement similar to dynamic destinations.
In spring integration, its possible to intercept channels and wire-tap to logging channel. Is it possible to stop this logging channel during run time?

This is my adapter:
'logging-channel-adapter'(id:'wireTapLogger', level:'INFO', 'log-full-message':true)

[Mark Fisher]

The adapter implements Lifecycle, so you can call stop() on it. You can also expose it as an MBean for JMX - or you can use the Control Bus and send a Message whose payload is 'adapterName.stop()'. In this particular case, it looks like you are using the adapter "id" without a "channel" - so the adapter's name is going to be "wireTapLogger.adapter" since the Message Channel's name is "wireTapLogger".

Hope that helps,
Mark