Currently the BeanNameViewResolver supports finding beans by name from the sameApplicationContext 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.
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.