Hi Alen, it works like a charm! Thanks! Mario
Ps: by the way, I reverted to use AspectJ load-time-weaving instead of interceptors (but, of course, injection is ... troublesome in this case): I'm glad to know that interceptors have become a viable solution once again :) On 26 Nov, 12:04, Alen Vrečko <[email protected]> wrote: > Maybe you have already solved this. If not...This is what happens: > > After the return null happens the invocation chain goes one step back > since there is no proceed call. The index-- happens[1]. Then the > thread invokes proceed but the index is at -1. It just calls invoke on > method interceptor again. This repeats and repeats... > > The most simple solution is to manually increment the chain position > to compensate for the return null. In the thread do > > Field field = methodInvocation.getClass().getDeclaredField("index"); > field.setAccessible(true); > field.setInt(methodInvocation,field.getInt(methodInvocation)+1); > > before calling proceed > > I can think of one more solution with invokespecial but that is > another story. > > Cheers > Alen > > [1]http://code.google.com/p/google-guice/source/browse/trunk/src/com/goo... > > On Nov 15, 11:52 pm, Mario Scalas <[email protected]> wrote: > > > > > I'm using Guice in my Eclipse application. In my architecture the > > controller calls View's methods in order to update it: Eclipse (based > > on the SWT Eclipse toolkit) requires calls to be performed in the > > single GUI thread and provides specific API (similar to the Swing > > EventQueue.invokeLater()), which may not be the case when I perform > > long jobs in the background in another thread. > > > So my idea to avoid boiler plate code is to wrap View methods with > > @SWTThread annotation and let the interceptor do the job. In the past > > I've already an AspectJ aspect that does the job but making it benefit > > of Guice injection is a bit hard and I thought I could use the same > > approach with an AOP Alliance method interceptor which, instead, is > > supported by Guice. So I've written something like : > > > public class SWTThreadInterceptor implements MethodInterceptor { > > > @Inject > > private Provider<Display> displayProvider; > > > @Override > > public Object invoke( final MethodInvocation invocation ) throws > > Throwable { > > // If we are in the SWT Thread then avoid wrapping > > (otherwise the > > interceptor will go in infinite > > // recursive call) > > Display display = displayProvider.get(); > > > executeAsynch( display, invocation ); > > return null; > > } > > > private void executeAsynch( Display display, final MethodInvocation > > invocation ) { > > display.asyncExec( new Runnable() { > > public void run() { > > try { > > invocation.proceed(); > > } catch (Throwable e) { > > throw new SWTThreadException( e ); > > } > > } > > }); > > } > > > } > > > My problem is that the invocation.proceed() method is invoked > > recursively from within the UI thread! Anybody with more experience > > may provide more insights? I guess that the proxied method is being > > invoked again and again (instead of the actual class method, which is > > invoked if I call invocation.proceed() directly) but don't know how to > > access it (tried getThis() but had no luck). > > > Please help me! :) > > Regards > > Mario -- You received this message because you are subscribed to the Google Groups "google-guice" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-guice?hl=en.
