Type detection fails for child bean if parent bean has been resolved before [SPR-10374]

[spring-projects-issues]

Franz Neumann opened SPR-10374 and commented

After update on Spring 3.2.2 following controllers aren't initialized:

 
<bean id="mainPageController" class="com.euroit.militaryshop.web.controller.MainPageController" 
		parent="baseTrolleyAwareController">
	<property name="productService" ref="productService"/>
	<property name="categoryService" ref="categoryService"/>
</bean>	

<bean id="baseTrolleyAwareController" class="com.euroit.militaryshop.web.controller.base.BaseTrolleyAwareController">
	<property name="trolley" ref="trolley"/>
</bean>

The class MainPageController:

@RequestMapping("/")
public class MainPageController extends BaseTrolleyAwareController {
..
}

So after ininilazation there is no "/" mapping. With Spring 3.2.1 it worked.

---

Affects: 3.2.2

Issue Links:

• AbstractAutowireCapableBeanFactory.predictBeanType returns parent type instead of class="<real class>" value [SPR-10507] #15139 AbstractAutowireCapableBeanFactory.predictBeanType returns parent type instead of class="" value ("is duplicated by")
• Introduce a pre-resolved target type in RootBeanDefinition [SPR-10335] #14969 Introduce a pre-resolved target type in RootBeanDefinition

Referenced from: commits 070103b, 239a7cd

[spring-projects-issues]

Rossen Stoyanchev commented

Sorry to hear that. Since not much has changed in the Spring MVC with this regard, we'll need a little more information to figure out what's going on.

The given example only shows a type-level request mapping. It doesn't show what methods would handle the request. It could be an @RequestMapping method or an implementation of the Controller interface. This is important because ultimately I need to know what HandlerMapping/HandlerAdapter pair is expected to process the request?

Typically at startup, the mappings are logged at DEBUG level. Is this controller listed at all?

[spring-projects-issues]

Franz Neumann commented

So the controller method, I use name of a tiles configuration in ModelAndView return object.

@RequestMapping("/")
public class MainPageController extends BaseTrolleyAwareController {
	private static final Logger LOG = LoggerFactory.getLogger(MainPageController.class);

	static final String PRODUCT_LIST = "productList";

	static final String CATEGORY_LIST = "categoryList";
	
	ProductService productService;	

	CategoryService categoryService;

	public void setProductService(ProductService productService) {
		this.productService = productService;
	}

	public void setCategoryService(CategoryService categoryService) {
		this.categoryService = categoryService;
	}
	
	@RequestMapping(method = RequestMethod.GET)
	public ModelAndView show() {
		ModelAndView mav = new ModelAndView("mainPage");
		List<ProductDto> listProductDto = productService.getVisibleProducts();
		mav.addObject(PRODUCT_LIST, listProductDto);
		List<CategoryDto> listCategoryDto = categoryService.getAllCategories();
		mav.addObject(CATEGORY_LIST, listCategoryDto);

		return mav;
	}
}

There are some logs with mapping at startup, but there are no logs for the controller and for all controller, which have parent in xml-config (I think so).

[spring-projects-issues]

Rossen Stoyanchev commented

I've created a small repro project that mimics the above. The controller is registered as expected at startup:

2013-03-14 09:47:35,967 INFO [org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerMapping] - <Mapped "{[/],methods=[GET],params=[],headers=[],consumes=[],produces=[],custom=[]}" onto public org.springframework.web.servlet.ModelAndView org.springframework.issues.MainPageController.show()>

Please, take a look and help reproduce the issue. Thanks!

[spring-projects-issues]

Franz Neumann commented

Maybe BaseTrolleyAwareController implementation and config essential here.
Please don't pay attention to Component and Autowired annotation. It's used only for tests. Productive I use only spring xml-configuration.

So:

@Component
public class BaseTrolleyAwareController implements TrolleyAware {

    protected Trolley<BaseTrolleyItemDto> trolley;

    @Override
    @Autowired
    public void setTrolley(Trolley<BaseTrolleyItemDto> trolley) {
        this.trolley = trolley;
    }

    @ModelAttribute
    public Trolley<BaseTrolleyItemDto> initTrolley() {
        return trolley;
    }
}

and Trolley is a session scope bean:

<!-- Session scope beans -->
<bean id="trolley" class="com.euroit.militaryshop.bean.impl.TrolleyImpl" scope="session">
         <aop:scoped-proxy proxy-target-class="true"/>
</bean>

[spring-projects-issues]

Rossen Stoyanchev commented

I updated the sample. Still not able to reproduce it.

[spring-projects-issues]

Rossen Stoyanchev commented

Try checking out the sample and see if you can get it to fail.

[spring-projects-issues]

Franz Neumann commented

I spent a lot of time trying to reproduce it in your sample, but unfortunatelly no way. When I just turn off in my project parent attribute for <bean id="mainPageController" class="com.euroit.militaryshop.web.controller.MainPageController"/> the mapping is initialized, and isn't when its on.
When you could take a look on the error in my project (https://github.com/icehockeystar/militaryshop) it would be great. Just check dev branch out and change version in pom property org.springframework.version on 3.2.2

[spring-projects-issues]

Rossen Stoyanchev commented

This doesn't seem related to Spring MVC. What I observed through debugging is that a call to getApplicationContext().getType(beanName)) in AbstractHandlerMethodMapping (line 106) with beanName="mainPageController" returns BaseTrolleyAwareController, which is the type of the parent bean definition rather than MainPageController. As a result Spring MVC is unable to find the @Controller annotation and ignores the controller. In 3.2.1 it works ok.

[spring-projects-issues]

Juergen Hoeller commented

This turned out to be a side effect of 3.2.2's #14969, with the container accidentally reusing the parent's targetType on merge of a child bean definition. This was dependent on resolution order: It only failed when the parent bean's type was resolved first.

Fixed for 3.2.3 and 4.0 M1 now.

Juergen