Question

据我所知，JSF EL中使用了转换属性/类名的标准JavaBeans约定，即方法对(get|is)Property + setProperty仅转换为property：

public class SomeComponent {
    public String getAttribute() { ... }
    public void setAttribute(String attribute) { ... }
}

<h:outputText value="#{comp.attribute}" />

bean名称也是如此（除非这些名称直接在@ManagedBean注释中指定）：

@ManagedBean
public class UsefulBean {
    ...
}

<h:outputText value="#{usefulBean.doSomething()}" />

此行为主要记录在案。但是，当使用首字母缩略词启动bean或属性名称时，我无法找到有关转换约定的任何内容，例如

@ManagedBean
public class URLManagerBean {
}

<h:outputText value="#{...ManagerBean.doSomething()}" />

在上一个代码段中应该使用什么代替省略号？

令人惊讶的是，但互联网上几乎没有任何信息。几乎所有JSF托管bean使用的例子都使用bean名称，而不是在开头有多个相邻的大写字母。在我设法找到的少数地方，建议以多个大写字母开头的bean名称不应以任何方式转换，即在前面的代码片段中为URLManagerBean。

不幸的是，我们有一个项目，其中很多bean都以这种方式命名。在任何地方使用这些豆类时，它们都遵循这种奇怪的，至少是公约：

class URLManagerBean -> uRLManagerBean

也就是说，只有首字母缩略词的第一个字母才是资本化的。该项目似乎运作良好，所以这个大会在某种程度上有效。但IntelliJ IDEA并不喜欢这样;它认为JSF bean真的应该被命名为URLManagerBean，除非我通过注释显式地重命名它。

我尝试将class URLManagerBean的使用情况从uRLManagerBean更改为URLManagerBean，但显然这不起作用 - 我尝试过的那些页面停止了工作。

现在我认为这种奇怪惯例背后的原因是我们通过SpringBeanFacesELResolver使用Spring集成。但是，此行为未在任何地方记录。

这种行为有什么解释吗？

Answer 1

您使用的是哪个@ManagedBean注释？来自javax.faces.bean或javax.annotation的那个？

在第一种情况下，Spring与它无关，因为它将是一个JSF托管bean，并将遵循JSF指定的约定。

name（）属性的值被视为managed-bean-name。如果未指定name属性的值或为空String，则从获取完全限定类名的非限定类名部分并将第一个字符转换为小写来派生managed-bean-name。例如，如果ManagedBean批注位于具有完全限定类名com.example.Bean的类上，并且批注上没有name属性，则managed-bean-name将被视为bean。附加此批注的类的完全限定类名称将被视为托管bean类。资料来源：@ManagedBean javadocs

在第二种情况下，Spring处于混合状态，然后根据您使用的弹簧版本和/或配置选项，行为会有所不同。使用AnnotationConfigApplicationContext AnnotationBeanNameGenerator遵循指南（并将导致'URLManagerBean'作为bean名称）。使用其他方法，您最终可能会得到DefaultBeanNameGenerator，它具有更简单的算法。

简单地说，这可能取决于您使用的弹簧版本和注释。

链接

@ManagedBean Java Documentation
生成beanname（参考实现）的ManagedBeanConfigHandler的来源

在EL表达式中使用时，JSF 2托管bean及其方法命名约定（与Spring一起使用）

1 个答案: