Do it all in the interceptor. (For the record I suggest using the
custom ActionResolver route, probably on an early 1.5 trunk a few
I really wish there was a cleaner way to create the ActionBean, I generally
dislike inheritance and it seems heavy handed to force my ActionResolver on
someone. I really like constructor injection though, as it makes it trivial
to identify dependencies at test-time.
I did a test of this all-interceptor way once but I believe this was
generally how I did it:
You need to have your Interceptor run
@Before the LifecycleStage.ActionBeanResolution stage. This is where
you do your Guice constructor instantiation and save your new bean into
the request scope (or the session scope if you used the @SessionScope
annotation) using the proper key (string matching the URL
binding/path). After that call the usual proceed() method to continue
the lifecycle processing. The regular ActionBeanResolution stage
should check if your ActionBean already exists in the appropriate scope
and use it automatically.
I reviewed the AnnotatedClassActionResolver.getActionBean() method and
think you might find these calls useful for your Interceptor:
HttpServletRequest request = context.getRequest();
UrlBinding binding =
String path = binding.getPath();
// I think you would "Guice" create your bean here, then save it under
// Then set this variable request attribute as the Resolver's method
// Continue with regular processing
I really wish I at least had my test code to show you how I did this.
However, the above should get you most of the way there as the source
of the AnnotatedClassActionResolver class was very helpful the first
time around (and as a reference for jogging my memory).