I think my question was hinted at in a comment Raymond made in one post distinguishing btw. something like msg-based asynch and thread-base asynch......... but I couldn't find much in the mailling list archives, so let me go ahead and ask...
I want to experiment with a different approach to asyn on an ExternalService invocation of a Oneway operation. I don't want to have the AsyncInterceptor use a WorkManager to put me on a new thread as it does using the M1 code today. Instead, in certain cases, (say for an ES of certain binding type), my ES "invoker" is going to dispatch the method in some async manner (say it drops off the payload on a JMS queue). I want to keep the AsyncPolicyBuilder building the AsyncInterceptor in other cases, however. So I see there are a couple system components at work here. Up until now I've been relying on the DefaultWireFactoryService autowired into the ExternalServiceBuilderSupport that my binding-specific builder is extending, along with its autowired fields, DefaultPolicyBuilderRegistry and AsyncPolicyBuilder. I could imagine something like creating my own wire factory service modeled after DefaultWireFactoryService, and using my own policy builder registry modeled after DefaultPolicyBuilderRegistry but making sure AsyncPolicyBuilder did not get registered with this. Is there a better way someone who understood the intended extensibility points better than I would do this? I realize there is another issue which is what to do with the return value that I'd have to take care of but I'm assuming I could handle that. Finally, it doesn't necessarily kill me to be on a new thread, but I'm also trying to understand the extension points here with this as an example. Thanks, Scott Kurz
