@RequestMapping and @PreAuthorize not compatible?

I'm running into an issue with Spring 3.0.5 trying to use MVC and security annotations at the same time. Without the security annotations, everything works fine. But once I add the security annotations the paths aren't mapped anymore and I get 404 Not Found errors. Are the two types of annotations not compatible?

Snippet from spring-servlet.xml:

Code:

---

    <context:component-scan base-package="foo" />
   
    <sec:global-method-security pre-post-annotations="enabled">
        <sec:expression-handler ref="expressionHandler"/>
    </sec:global-method-security>
   
    <mvc:annotation-driven />
    <bean class="org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor"/>

---

My log messages are interesting, too:

Code:

---


05/25/11 14:19:33 INFO - : - AbstractUrlHandlerMapping.registerHandler(411) | Mapped URL path [/foo/] onto handler 'fooController'
05/25/11 14:19:33 DEBUG - : - AbstractBeanFactory.doGetBean(242) | Returning cached instance of singleton bean 'fooController'
05/25/11 14:19:33 INFO - : - AbstractUrlHandlerMapping.registerHandler(411) | Mapped URL path [/foo2/] onto handler 'fooController'
05/25/11 14:19:33 DEBUG - : - AbstractBeanFactory.doGetBean(242) | Returning cached instance of singleton bean 'fooController'
05/25/11 14:19:33 INFO - : - AbstractUrlHandlerMapping.registerHandler(411) | Mapped URL path [/foo3/] onto handler 'fooController'
05/25/11 14:19:33 DEBUG - : - AbstractBeanFactory.doGetBean(242) | Returning cached instance of singleton bean 'fooController'
05/25/11 14:19:33 INFO - : - AbstractUrlHandlerMapping.registerHandler(411) | Mapped URL path [/foo4/] onto handler 'fooController'

---

But then later...

Code:

---

05/25/11 14:19:37 DEBUG - : - PrePostAnnotationSecurityMetadataSource.findAnnotation(93) | @org.springframework.security.access.prepost.PreAuthorize(value=isAuthenticated()) found on specific method: public org.springframework.web.servlet.ModelAndView Foo.getFoo(long,javax.servlet.http.HttpServletRequest,javax.servlet.http.HttpServletResponse)
05/25/11 14:19:37 DEBUG - : - DelegatingMethodSecurityMetadataSource.getAttributes(66) | Adding security method [CacheKey[Foo; public org.springframework.web.servlet.ModelAndView Foo.getProfileInfo(long,javax.servlet.http.HttpServletRequest,javax.servlet.http.HttpServletResponse)]] with attributes [[authorize: 'isAuthenticated()', filter: 'null', filterTarget: 'null']]
05/25/11 14:19:37 DEBUG - : - AbstractAutoProxyCreator.buildAdvisors(537) | Creating implicit proxy for bean 'userController' with 0 common interceptors and 1 specific interceptors
05/25/11 14:19:37 DEBUG - : - JdkDynamicAopProxy.getProxy(113) | Creating JDK dynamic proxy: target source is SingletonTargetSource for target object [Foo@5f44426c]
05/25/11 14:19:37 DEBUG - : - AbstractAutowireCapableBeanFactory.createBean(458) | Finished creating instance of bean 'fooController'

---

and finally...

Code:

---

05/25/11 14:19:37 DEBUG - : - AbstractDetectingUrlHandlerMapping.detectHandlers(86) | Rejected bean name 'fooController': no URL paths identified

---

So is it just not possible to use MVC and security annotations in the same class?

Thanks,
Drew

This has to do with proxying (and afterwards not being able to find the @RequestMapping). I recently read it somewhere (not sure if it is the spring security reference guide or the spring reference guide). Solution is to use/force classproxying instead of JdkDynamic proxies.

We've run into this same error before. The solution for us was to create an interface for the controller. We've set the @RequestMapping and @PreAuthorize annotations in the interface and just have the controller impl override the declared methods in the interface.

Hi,

I found a solution on this post : http://stackoverflow.com/questions/1...ment-exception
Just had in your app-context.xml :

<security:global-method-security secured-annotations="enabled" proxy-target-class="true" />

It saved me (spring 3.1, security 3.1)

Regards,
Hope it'll help others.

The link proved to be quite useful. Thanks for the link dude.