Allow a JmsOutboundGateway to not require a connectionFactory on initalisation [INT-3618]

[spring-operator]

Patrick Altaie opened INT-3618 and commented

With Spring Integration 4.1.2.RELEASE, it is not possible to configure a JmsOutboundGateway without a Connection Factory reference. This means that if I want to/can only figure out a Connection Factory at runtime, I need to supply some kind of fake, dummy or generic CF which will never be used, and I would then set the connection factory to whichever one it is that I need.

I think it would be fruitful to somehow be able to support not having the connectionFactory property set, such that this can be determined later on.

I see that the JmsOutboundGateway uses the JmsTemplate, which also has this limitation, so I'm not sure how feasible or easy to implement this would be.

---

Affects: 4.1.2

[spring-operator]

Artem Bilan commented

Sorry, you comment does not make sence for.

The JMS interaction isn't possible without javax.jms.ConnectionFactory.

What will be the reason to send messages to the JmsOutboundGateway within integration flow, if there is no normal real ConnectionFactory?

Maybe do you mean something like AbstractRoutingDataSource or org.springframework.amqp.rabbit.connection.AbstractRoutingConnectionFactory?

As you see there is no similar solution for JMS.

We are open for the discussion though.

Thank you!

[spring-operator]

Patrick Altaie commented

Artem,

Thanks very much for your prompt response! Sorry that I wasn't clear enough in my initial synopsis.

I don't wish to perform JMS interactions without a javax.jms.ConnectionFactory. I acknowledge that not much is possible without a CF.

What I am looking for, however, is a way to defer the setting of the connectionFactory property to runtime, instead of at bean init time.

I have a service which contains a step that can potentially send javax.jms.TextMessage's to a number of different javax.jms.Queue's sitting under a number of different CFs, using a custom class which extends JmsOutboundGateway to implement this routing.

My custom extension decides the destination CF and request and response queues at runtime by convention (e.g. "jms/qcf/endSystem/" + headers.get("countryCode"), depending on a org.springframework.integration.Message's header. This means that I don't (can't) really need to supply a ConnectionFactory at runtime, because my custom class will determine this at transport()-time. There's currently no way for me to do this without supplying a CF reference, because if I don't supply a CF reference to the JmsOutboundGateway, it won't init, and will throw a java.lang.IllegalArgumentException.

Another problem I have is that I don't know the complete set of CFs and queues that are available to me, because they can be dynamically made available at any time, so I can't set up the complete set and then user an <int:router>, for example.

Am I doing this wrong? What's the best way to route a message to a ConnectionFactory and Queue based on convention, and when the set of potential targets is not known?

Sorry about not being clear enough. The problem is kind of a complicated one, so it takes a few attempts to try to explain!

Thanks!

[spring-operator]

Artem Bilan commented

Thanks for the further explanation!

Yes, I understand your dynamic routing point.

Unfortunately the JmsOutboundGateway is enough comprehensive and we can't do runtime CF resolution so easy.
Yes, I see the point where it may be achieved: when we don't use replyContainer. Otherwise CF is required for any JmsAccessor.

For your case I think we don't have chioce unless build some custom service-activator which uses raw Spring JMS API, instead of those Spring Integration JMS adapters.

Is that appropriate for you?

[spring-operator]

Patrick Altaie commented

Thank you for your prompt response!

I was also thinking of using a Service Activator that utilises the JmsTemplate, but was wondering if there was interest to implement this kind of functionality within Spring Integration. But I guess as you say, the JmsOutboundGateway is comprehensive enough and probably doesn't need features like this.

Please feel free to close this ticket with the relevant status as you see fit.

[spring-operator]

Artem Bilan commented

I think we have some internal discussion on the matter, when Gary Russell will have come back.
There are a lot of similar components which may rely on the rutime low-level resource resolution.

Thank you for pointing that out!