JMS Remoting does not currently support async calls nor does it support invocation of methods with void return types. This patch address both issues.
Async invocation is used automatically where the invoked method has void return type and no declared Exceptions. I simply set the replyTo queue to null and properly handle that through the invocation. Obviously I do not wait for any reply in the control flow.
To properly handle methods with checked exceptions but void return type, I inserted support for returning null from a remoting call.
This is a good idea but the "void plus no checked exception" policy feels a bit unclean - what if you're waiting for runtime exceptions, or just for a general "call returned so I know it happened" status?
I'd prefer to introduce this aligned with a general @Async annotation that clearly indicates a method as asynchronously invoked in the interface. The semantic contract is much clearer for the user as well as for the invocation infrastructure then, and may apply to other kinds of invocations as well - not just JMS invoker.
I modeled the runtime annotation support in my latest patch after the org.springframework.jmx.export.annotation package. Specifically, I extended the current JMSInvoker classes using the naming convention Annotation<Parent Class> and dropped the new child classes in tiger/src.