使用多个控制器类和DefaultAnnotationHandlerMapping时,我们遇到了使用
Spring Portlet MVC 3.1的问题.

背景

>我们正在使用带有注释的Spring Portlet MVC 3.1 for Render&行动阶段
>我们正在使用JBoss EPP 5.1.1

问题

>对于带有params的Portlet呈现请求,将在portlet中呈现不正确的页面

原因

> Spring Portlet MVC对@RenderMapping使用的方法与使用正确注释的预期方法不同

技术分析

>我们所有的控制器都包含@RenderMapping和@ActionMapping注释,并且所有控制器都有“params”参数,以确保根据我们的portlet URL中的参数集调用预期的方法.对于默认渲染,我们有一个方法,它有一个没有“params”参数的@RenderMapping注释,当请求不包含参数时,我们使用它来渲染空白JSP.
>根据本书第7章和第8章的内容,我们了解到Dispatcher Portlet尝试获取传入请求的相应处理程序映射,并将其发送到配置的控制器bean中的相应方法.我们的假设是我们的默认@RenderMapping注释(没有参数)只有在检查控制器中没有其他方法与注释匹配特定请求参数之后才会被调用.
>但是,我们已经调试认识到这种假设是不正确的. DefaultAnnotationHandlerMapping似乎以某种预定义的顺序遍历Controller bean中可用的注释列表.这意味着如果具有默认@RenderMapping注释(没有参数)的控制器bean出现在列表之前,则将调用具有默认@RenderMapping注释(没有参数)的方法,而不是在列表中更下方的正确方法.

表现错误

我们正在Windows环境中开发并部署到Linux环境.在Windows中,我们看到处理程序按字母顺序循环遍历控制器bean,因此我们最初通过在控制器中添加@RenderMapping带注释的方法来解决我们的问题,其中bean名称最接近’Z’.

但是,在Linux中,似乎以不同的顺序检测到控制器bean.我已经附上了下面的Spring日志以突出显示该问题. no params @RenderMapping注释位于YourDetailsController中,正如您在Windows日志中看到的那样,它出现在列表的最后,而在Linux中却没有.这意味着如果我们尝试访问列表中的YourDetailsController之后出现的其中一个控制器,我们总是会在YourDetailsController中找到no params注释.

问题

>我们的假设不正确吗？
>我们的诊断是否反映了预期行为？或者它是Spring Portlet MVC的错误？
>是否有不同的方法来扫描注释以形成处理程序映射bean列表？
>使用xml配置(而不是注释)会删除我们的问题吗？
>我们能够定义多个处理程序映射和顺序,以便默认处理程序映射是调度程序portlet使用的最后一个处理程序映射吗？

如果您对此问题有任何想法或建议,将不胜感激.

最佳答案 麦克风.我遇到了完全相同的问题.我正在使用JDK 7,Spring 3.1.1.RELEASE和Hibernate 4.1.3.Final.我正在开发Linux(Fedora)并在Linux上部署(Fedora和SL).

我被卡住了,因为我确信这些碎片(控制器)一次只能工作一个,但是随机忽略了对渲染请求的调用.有时候改变某些东西会使渲染请求上的东西再次起作用,但它们从未一起工作过.

正如Walter建议的那样,当我在其自己的包中隔离仅包含默认呈现请求的控制器时,只留下其中的默认呈现请求(在我有删除/查看请求之前)并将portlet的XML配置中的控制器扫描分开.两个跟其他人一起扫描默认控制器后,突然一切都像魅力一样.

看看这个bug是否在Spring跟踪器中会很有趣……