From 626a5fe4eb329dc86cd57c4454bcb9141bd2fba0 Mon Sep 17 00:00:00 2001
From: Juergen Hoeller <jhoeller@vmware.com>
Date: Wed, 13 Aug 2014 14:57:40 +0200
Subject: [PATCH] BeanNameViewResolver ignores non-View beans

Issue: SPR-12079
---
 .../servlet/view/BeanNameViewResolver.java    | 49 ++++++++++++-------
 1 file changed, 30 insertions(+), 19 deletions(-)

diff --git a/spring-webmvc/src/main/java/org/springframework/web/servlet/view/BeanNameViewResolver.java b/spring-webmvc/src/main/java/org/springframework/web/servlet/view/BeanNameViewResolver.java
index dcc73a88ad4..37880798029 100644
--- a/spring-webmvc/src/main/java/org/springframework/web/servlet/view/BeanNameViewResolver.java
+++ b/spring-webmvc/src/main/java/org/springframework/web/servlet/view/BeanNameViewResolver.java
@@ -1,5 +1,5 @@
 /*
- * Copyright 2002-2012 the original author or authors.
+ * Copyright 2002-2014 the original author or authors.
  *
  * Licensed under the Apache License, Version 2.0 (the "License");
  * you may not use this file except in compliance with the License.
@@ -26,25 +26,24 @@ import org.springframework.web.servlet.View;
 import org.springframework.web.servlet.ViewResolver;
 
 /**
- * Simple implementation of ViewResolver that interprets a view name
- * as bean name in the current application context, i.e. in the XML
- * file of the executing DispatcherServlet.
+ * A simple implementation of {@link org.springframework.web.servlet.ViewResolver}
+ * that interprets a view name as a bean name in the current application context,
+ * i.e. typically in the XML file of the executing {@code DispatcherServlet}.
  *
- * <p>This resolver can be handy for small applications, keeping all
- * definitions ranging from controllers to views in the same place.
- * For normal applications, XmlViewResolver will be the better choice, as
- * it separates the XML view bean definitions into a dedicated views file.
- * View beans should virtually never have references to any other
- * application beans - such a separation will make this clear.
+ * <p>This resolver can be handy for small applications, keeping all definitions
+ * ranging from controllers to views in the same place. For larger applications,
+ * {@link XmlViewResolver} will be the better choice, as it separates the XML
+ * view bean definitions into a dedicated views file.
  *
- * <p>This ViewResolver does not support internationalization.
- * Consider ResourceBundleViewResolver if you need to apply different
- * view resources per locale.
+ * <p>Note: Neither this {@code ViewResolver} nor {@link XmlViewResolver} supports
+ * internationalization. Consider {@link ResourceBundleViewResolver} if you need
+ * to apply different view resources per locale.
  *
- * <p>Note: This ViewResolver implements the Ordered interface to allow for
- * flexible participation in ViewResolver chaining. For example, some special
- * views could be defined via this ViewResolver (giving it 0 as "order" value),
- * while all remaining views could be resolved by a UrlBasedViewResolver.
+ * <p>Note: This {@code ViewResolver} implements the {@link Ordered} interface
+ * in order to allow for flexible participation in {@code ViewResolver} chaining.
+ * For example, some special views could be defined via this {@code ViewResolver}
+ * (giving it 0 as "order" value), while all remaining views could be resolved by
+ * a {@link UrlBasedViewResolver}.
  *
  * @author Juergen Hoeller
  * @since 18.06.2003
@@ -63,7 +62,7 @@ public class BeanNameViewResolver extends WebApplicationObjectSupport implements
 
 	@Override
 	public int getOrder() {
-		return order;
+		return this.order;
 	}
 
 
@@ -71,7 +70,19 @@ public class BeanNameViewResolver extends WebApplicationObjectSupport implements
 	public View resolveViewName(String viewName, Locale locale) throws BeansException {
 		ApplicationContext context = getApplicationContext();
 		if (!context.containsBean(viewName)) {
-			// Allow for ViewResolver chaining.
+			if (logger.isDebugEnabled()) {
+				logger.debug("No matching bean found for view name '" + viewName + "'");
+			}
+			// Allow for ViewResolver chaining...
+			return null;
+		}
+		if (!context.isTypeMatch(viewName, View.class)) {
+			if (logger.isDebugEnabled()) {
+				logger.debug("Found matching bean for view name '" + viewName +
+						"' - to be ignored since it does not implement View");
+			}
+			// Since we're looking into the general ApplicationContext here,
+			// let's accept this as a non-match and allow for chaining as well...
 			return null;
 		}
 		return context.getBean(viewName, View.class);