Upgrade BeanNameViewResolver to support XML and Java Config bean definitions [SPR-14022]

[spring-projects-issues]

Paul Chapman opened SPR-14022 and commented

Currently the BeanNameViewResolver supports finding beans by name from the same ApplicationContext that it is defined in. This can lead to lots of View beans in the context that only the BeanNameViewResolver needs to know about. It also means that a given view name can only be resolved to a single View bean. If I have a PDF generating bean and an Excel generating bean I can't use this approach.

The XmlViewResolver solves this problem by allowing the View beans to be specified in a dedicated bean XML file, just for the View beans, reducing bean-clutter. By having two such resolvers I can have two view Beans with the same name. But, as the name implies, this resolver only supports beans defined using XML.

I propose enhancing the BeanNameViewResolver to optionally support both beans defined in XML files and/or in dedicated Java Configurations. This enhancement would make the XmlViewResolver obsolete.

I anticipate something like this:

@Configuration {

    @Bean ViewResolver bnvr() {
        return new BeanNameViewResolver(ExcelViewBeans.class, PdfViewBeans.class);
    }
}

I would expect BeanNameViewResolver to provide both constructors and setLocation() methods that take an array of Resource (for XML bean files) or an array of @Configuration classes.

The default behaviour of the BeanNameViewResolver can remain the same to ensure backwards compatibility.

The ViewResolverRegistry should be enhanced similarly to provide beanName(Resource ...) and beanName(Class<?>...).

And the equivalent change to <mvc:resolvers>.

---

Reference URL: #987

[rstoyanchev]

XmlViewResolver has been deprecated in 5.3 and I'm not sure it makes sense to enhance BeanNameViewResolver with this functionality. Between view resolver implementations that match to the request path and those that use serialize to non-HTML content types like JSON, I'd expect the number view beans to be manageable with the current functionality of BeanNameViewResolver.