setting properties in mvc:annotation-driven AnnotationMethodHandlerAdapter class?

After years on spring 2.5 for the web I am working on 3.0 and love it.

I am not sure if anybody has run into this issue. I am trying to set properties on the default AnnotationMethodHandlerAdapter class that is created by using the mvc:annotation-driven namespace. This is created in the

org.springframework.web.servlet.config.AnnotationD rivenBeanDefinitionParser
parsing class which is great. However I want to set attributes on that bean itself. Do I need to create my own beanfactory to do this? I would prefer NOT to define my AnnotationMethodHandlerAdapter in my spring config as we will have two instances of this class in the spring container and I would have to re-build the bean up from scratch with all the nice components in there. I might have to bean processor to handle this after init to inject my own beans/props into the AnnotationDrivenBeanDefinitionParser instance.

I guess this is a more general question for all things spring related but since it was in the mvc namespace i thought i would ask.

m

It doesn't appear the namespace config tag allows you to modify much of what it actually creates. If you define your own AnnotationMethodHandlerAdapter in the config file, it will override the one supplied by the shortcut tag. I suppose the tag is there to provide useful defaults, and probably isn't good for situations like yours where you need different settings.

Just got hit by this. To set both AnnotationMethodHandlerAdapter and DefaultAnnotationHandlerMapping to "alwaysUseFullPath", and configure custom interceptor (localeChangeInterceptor) context config file got much larger. Since I very frequently use these settings, mvc:annotation-driven isn't as much of a help as IMO it could be. Wish mvc:annotation-driven was more configurable, like http from security namespace.

We had to end up rolling out own. Its not really a pain as we have one master mvc-config file but it is a drag that you can not easily extend the name space handlers or inject arbitrary beans into the handler in some way. Some of these handlers are very good for bootstrapping a quick app but once you customize something the mvc one falls right apart unfortunately.