In writing EJB3 Proxy, and to prioritize compliance w/ TCK, we've dropped support for asynchronous invocations. I'm now putting it back. The previous implementation worked like: * Get a traditional Proxy from JNDI * Cast that to an interface implemented by all Proxies, "JBossProxy" * Call Object myAsync = JBossProxy.getAsynchronousProxy(); * Cast myAsync to the the Business Interface to invoke * Cast myAsync to AsynchProvider (org.jboss.aspects.asynch.AsynchProvider) to get the Future (org.jboss.aspects.asynch.Future) ...it looks like: StatefulRemote tester = | (StatefulRemote) getInitialContext().lookup("StatefulBean/remote"); | assertEquals("Wrong return for stateful remote", 31, tester.method(31)); | | StatefulRemote asynchTester = (StatefulRemote)((JBossProxy)tester).getAsynchronousProxy(); | assertEquals("Wrong return value for stateful remote", 0, asynchTester.method(32)); | AsynchProvider ap = (AsynchProvider) asynchTester; | Future future = ap.getFuture(); | int ret = (Integer) future.get(); | assertEquals("Wrong async return value for stateful remote", ret, 32); I want to change the following: * Proxies should not be equipped with the facilities to return an asynchronous version of themselves. I'd rather see another component take an existing proxy and async-ize it. So async becomes a true add-on optional capability. * Remove use of org.jboss.aspects.asynch.Future in favor of java.util.concurrent.Future One hitch I see with Bill's Future implementations is that they directly support remoting via the AOP Dispatcher. I want to simplify the whole thing by making the async client-side interceptor act like a regular client which carries the invocation as a j.u.c.FutureTask. We'll see if I'm missing some reason why things were built as they were. S, ALR View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4184356#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...