Altering GatewayProxyFactoryBean behaviour when Proxying a Method with no Arguments

[alza]

Hi all,

When using GatewayProxyFactoryBean, I noticed that it's behaviour when proxying a method with no arguments is to wait for an incoming message via receive(...), without actually sending a message.

I wanted different behaviour in this case; specifically, I wanted the proxy to send a message anyway for a method with no args, via sendAndReceive(...). After examining the code, I came up with the following quick workaround which is currently meeting my requirements:

Step 1 - annotate the desired gateway interface method with a payload annotation, that uses a SpEL expression to create a payload instance:

@Payload("new Item()")
List<Item> findAllItems();

Step 2 - annotate a corresponding service implementation method with a service activator annotation:

@ServiceActivator
public List<Item> findAllItems() {
...
}

Step 3 - Copy the source of GatewayProxyFactoryBean (v2.0.4) into a new class, e.g. NoArgMethodCapableGatewayProxyFactoryBean (in the same package) and comment out lines 264-270. This ensures that sendAndReceive(...) is called instead of receive(...) with an empty args Object array, in the case where the method has no arguments.

Step 4 - Define a spring application context to wire up a gateway proxy using the above implementation to a service bean, via a channel and service activator as usual.

The above is currently working for me, personally I think it would be great if the GatewayProxyFactoryBean behaviour for a no-arg method could be configurable, either use the current receive(...) behaviour, or use sendAndReceive(...) if a payload is configured either by a method annotation as above, or by xml configuration.

Any feedback would be appreciated.

Thanks

Alex.

[oleg.zhurakousky]

Could you please explain your use case? I am just afraid that there is a much simpler solution to what you are trying to accomplish.
The idea behind MessagingGateway is to provide a POJO interface to a Messaging System and it follows certain contract
1. Method with void return and arguments will be treated as send(Message) where arguments will be converted to a Message
2. Method with return value and arguments will be treated as sendAndRecieve(Message) where arguments will be converted to a Message and reply Message converted to a POJO
3. Method with return value and no-arguments will be treated as receive() where a Message received from the reply-channel will be converted to a POJO

I am truly wondering about your use case that made you do what you described

[Cleric]

Hello
alza
Maybe it is enough to send ApplicationEvent?

class MyGataway implements ApplicationEventPublisherAware {
public void send() {
              applicationEventPublisher.publishEvent(new MyEvent(true));
    }
}

And SI config:

 <channel id="myChannel"/>

<event:inbound-channel-adapter channel="myChannel"
                                   event-types="com.my.proj.MyEvent"/>

<service-activator input-channel="myChannel" ref="myService"/>

And service-method must have only one parameter Object o

is it appropriate?

Or it is very simple:

List<Item> findAllItems(Boolean b);

If your payload will be null that Message will never go

Artem