With theXmlViewResolver/ResourceBundleViewResolver you could have multiple instances of it and provide and XML application context to configure the views. This comes in handy when allowing 1 controller to render 2 different things like an Excel or a PDF depending on the requested Content-Type. Those are now deprecated and there is no real replacement for this.
Prior to this commit the BeanNameViewResolver would always resolve the views from the configuration it was defined in. Passing in a pre-configured application context would result in an error at runtime. Now it is possible to pass in an application context through the constructor which will be used to resolve the views from. Making it possible to have multiple instances and have the functionality as with multiple XmlViewResolver/ResourceBundleViewResolver with a ContentNegotiatingViewResolver.
Closes: #29383
Comment From: mdeinum
Instead of shoehorning this into the existing BeanNameViewResolver it might make sense to introduce a better variant of the XmlViewResolver but then for Java Configuration classes instead of XML. That would be a minor refactoring of the removed XmlViewResolver to work with Java based configuration. While still keeping the original BeanNameViewResolver else it might change the existing behavior or make it do 2 things instead of 1 it currently does.
Comment From: rstoyanchev
Thanks for the thought. You're right that we are in effect creating an XmlViewResolver replacement but for Java config. That said we don't have to repeat the exact previous arrangement. I would argue, BeanNameViewResolver and XmlViewResolver were very close, both looking up a View bean, with XmlViewResolver being more specialized in terms the configuration it uses, but aside from that their actual lookup methods mirror each other, and the two could have been a parent-child from the start. This is the proposal now to make BeanNameViewResolver the common base class for such view resolvers.
Comment From: rstoyanchev
On further thought, the hierarchical approach isn't a strict goal. Re-imagining XmlViewResolver for Java config is a good place to start for continuity. We can decide on whether to turn it into a hierarchy.
Comment From: rstoyanchev
Scheduled for 6.1 M1 if you decide to give it a try, and push an updated version.
Comment From: sbrannen
@mdeinum, and updates on this?
Comment From: mdeinum
Haven't done anything for this, swamped with work and personal stuff :(.
Comment From: sbrannen
Haven't done anything for this, swamped with work and personal stuff :(.
No problem.
Do you think you'll find time to include it in 6.1 M2?
If not, we can move this issue to a backlog.
Comment From: mdeinum
I probably have some time on my hands before 6.1 M2 to polish this request.
Comment From: mdeinum
Closed in favor of a new PR https://github.com/spring-projects/spring-framework/pull/30772
I managed to mess up the rebase (not sure how). It was quicker to create a new PR then to try to fix the rebase.