no pollable reply channel has been configured

[robgratz]

The Service Activator has nothing to do with this gateway unless its output-channel is the QueueChannel from which you are polling Messages with the Gateway.

This is exactly what I'm trying to do. I have a gateway whose output channel is the channel that the service activator is listening on and whose reply channel is where the service activator is writing to.

All I'm trying to do is implement a "getter" method with one side using a gateway and the other using a service-activator. It is a synchronous call and polling won't work. Maybe I'm trying to fit a square peg into a round hole using messaging where a webservice call might be more appropriate, but I wanted to establish a consistent communication mechanism between subsystems and I thought using spring-integration would allow me to do that. I still don't feel like I have a concrete example of how to do this.

[oleg.zhurakousky]

You can use ws-outbound-gateway to make a webservice call whose output will go to the repolyChannel and downstream and I think that is what you want.
I'd suggest to look at our samples especially this one: https://github.com/SpringSource/spri...tbound-gateway

<chain input-channel="fahrenheitChannel" output-channel="celsiusChannel">
		<ws:header-enricher>
			<ws:soap-action value="http://tempuri.org/FahrenheitToCelsius"/>
		</ws:header-enricher>
		<ws:outbound-gateway uri="http://www.w3schools.com/webservices/tempconvert.asmx"/>
	</chain>

	<!-- The response from the service is logged to the console. -->
	<stream:stdout-channel-adapter id="celsiusChannel"/>

As you can see its a basic chain that has header-enricher to enrich a request with SOAP Action header, makes a SOAP request and the output goes to the output-channel which in this sample is logger but you can stick your service-activator and do whatever you want with it.
Now, the example above is SOAP, you can do the same with REST, just look at 'http' sample

[robgratz]

If I understand this correctly, the fahrenheitToCelcius method has a parameter passed to it which falls into the scenario that I already have working.

If for instance the exposed method was "getTemperature()", would this still work? And if so, would you have to explicitly send a message on the request channel or could you hide that behind a gateway interface?

This is what I want:
Subsystem1 -> getTemperature() -> Gateway --> [SOAP or JMS or REST or...] --> ServiceActivator -> SubSystem2.getTemperature() {return 98.6;}

This is what it sounds like you are proposing
Subsystem1 -> channel.send(new GenericMessage()) --> [SOAP or JMS or REST or...] --> ServiceActivator -> SubSystem2.getTemperature() {return 98.6;}

[oleg.zhurakousky]

As you said you are still trying to fit square peg in the round hole. If getTemperature is a SOAP service which takes no parameters that so be it. The same for REST where all you might need to do is hit a URL with no parameters, but now that has nothing to do with the GatewayProxyFactoryBean that you were trying to use earlier.
So i guess it would be better if you explain your use case outside of scope of what you have tried to do so far.

[oleg.zhurakousky]

May be this is what you are looking for. We have an issue slated for 2.1.M2 https://jira.springsource.org/browse/INT-2089. Let us know

[robgratz]

That is exactly what I'm looking for as long as it's not limited to just "send" messages but also able to handle "send/receive" if the method return type is not void.

[robgratz]

What is the current estimation of when 2.1 will be released?

[oleg.zhurakousky]

The first Milestone M1 should be shortly (few days). The issue I pointed out is scheduled for M2 so that one wil be several weeks away, but I am sure it will be in the snapshot much quicker than M2 so you can actually try it before M2 is released.

[robgratz]

Will the new functionality include send/receive or will it strictly be send?

[oleg.zhurakousky]

Well send/receive is there already. I think in your case since you have a no-arg method it resembles more of a trigger so i think the proper way of describing it would be trigger/receive. If so than the answer is yes, this is what we are discussing