Issues with interceptors since upgrading to Spring 3.1

[digitalsanctum]

I'm having a couple of issues related to interceptors since upgrading to 3.1. In version 3.0.x and earlier I used the following pattern to intercept Spring MVC controllers:

1. Create an interface called something like RoleAware which defines one or more setters.
2. Have one or more controllers implement the interface
3. Register a new global interceptor which does a "handler instanceof RoleAware" check in the preHandle
4. If the interceptor is an instanceof RoleAware, then set one or more objects on the implementing controller

The first issue is that something changed in 3.1 so the instanceof check fails. I've fixed this by using the new explicit <mvc:mapping/> elements in my servlet context configuration. Not a big deal and a bit cleaner approach than the instanceof check.

The second issue is that when I attempt to cast the handler (Controller) to my RoleAware interface I get a ClassCastException.

I'd like a solution that will enable me to continue to arbitrarily set objects on the intercepted controllers. For example, set a Role object on any Controllers that are intercepted. Also, I'd like to know more about the changes in 3.1 that is causing this to break.

Thanks in advance.

[digitalsanctum]

I got my question answered via http://stackoverflow.com/questions/8...an-interceptor

[Marten Deinum]

Was about to type that answer .

I would also like to warn you as there seems to be a big flaw in your approach! Remember the controller is a singleton now imagine I'm working with that controller (updating something or whatever) and now you come along re-setting those role objects. Which basically means I'm now (judging from the controllers point of view) that I'm you. Now that seems to me not something you want and imagine what can happen with 100s or 1000s of users.

[digitalsanctum]

Can you elaborate on the issue you pointed out with setting objects on the controller? I'm also interested in alternative recommended approaches to providing objects to controllers from interceptors. Should I instead set the objects as request objects?

[Marten Deinum]

The issue is quite clear..

1 instance of a controller 100 uses settings 1 instance variable so you basically don't know which instance is set (or cleared which might lead to null pointers). So you either want them as request objects or maybe request scoped objects (I suggest a read on scoped proxies).