We would like to expose services in the form :
It appears that we can send just one @Payload argument - we get runtime errors when passing more than one.
I'd like to avoid passing in a Map or one of the alternative options for this interface, or using @Header parameters, as this forces restrictions on the API - namely that subsequent arguments must be String.
An alternative is to use wrappers but this detracts from the simplicity spring integration provides. I've tried using expressions but wasn't able to make this work and in any case would like to avoid this type of complexity and favour compile time support. Finally I did consider an aspect to intercept, however the runtime proxies that implement spring integration cannot be subject to AOP - or seemingly the classes they instantiate directly. Inspecting the code at runtime it appears that the JmsTemplate and MessageConverter classes are hardwired into the GatewayProxy class, providing no hooks to override the behaviour of SimpleMessageConverter.
Ideally would like the api to not expose the internals of JMS marshalling (by this i mean the requirement that only one 'parent' object can be passed in as the payload) and support multi parameter interface methods as part of JMS Gateways. If I've missed a trick please let me know; I'd like a generic solution rather than plumbing that becomes required for each method.
New to this but have looked at the docs. I am keen to avoid creating either a layer of DTO classes to wrap individual messages or having to create an extra layer of BusinessDelegate classes to expose the public API we want.
Not sure why the framework can't reflect on the argument list, convert to a map, pass across the gateway, unroll the map and call the service based on signature, with some disambiguation to avoid confusion with direct map inputs. Although some complexity implies by the implementation would produce and some runtime cost with reflection, this would be small in relation to the messaging IO and allow framework clients using the gateway interface to provide a simple and expressive APIs.
Suggestions appreciated.
Thanks,
Alex
Code:
public interface AccountGateway {
@Gateway(...)
List<Account> getUserAccounts(Customer customer, AccountFilter accountFilter);
}I'd like to avoid passing in a Map or one of the alternative options for this interface, or using @Header parameters, as this forces restrictions on the API - namely that subsequent arguments must be String.
An alternative is to use wrappers but this detracts from the simplicity spring integration provides. I've tried using expressions but wasn't able to make this work and in any case would like to avoid this type of complexity and favour compile time support. Finally I did consider an aspect to intercept, however the runtime proxies that implement spring integration cannot be subject to AOP - or seemingly the classes they instantiate directly. Inspecting the code at runtime it appears that the JmsTemplate and MessageConverter classes are hardwired into the GatewayProxy class, providing no hooks to override the behaviour of SimpleMessageConverter.
Ideally would like the api to not expose the internals of JMS marshalling (by this i mean the requirement that only one 'parent' object can be passed in as the payload) and support multi parameter interface methods as part of JMS Gateways. If I've missed a trick please let me know; I'd like a generic solution rather than plumbing that becomes required for each method.
New to this but have looked at the docs. I am keen to avoid creating either a layer of DTO classes to wrap individual messages or having to create an extra layer of BusinessDelegate classes to expose the public API we want.
Not sure why the framework can't reflect on the argument list, convert to a map, pass across the gateway, unroll the map and call the service based on signature, with some disambiguation to avoid confusion with direct map inputs. Although some complexity implies by the implementation would produce and some runtime cost with reflection, this would be small in relation to the messaging IO and allow framework clients using the gateway interface to provide a simple and expressive APIs.
Suggestions appreciated.
Thanks,
Alex