CODEWITHSUNDEEP
springjsf-2naming-conventionsjavabeans
Vladimir Matveev
Vladimir Matveev

Reputation: 128081

JSF 2 managed beans and their methods naming convention when used in EL expressions (in conjunction with Spring)

As far as I know, standard JavaBeans convention for converting properties/class names is used in JSF EL, i.e. method pairs (get|is)Property + setProperty are converted to just property:

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

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

The same goes for bean names (unless these names are directly specified in @ManagedBean annotation):

@ManagedBean
public class UsefulBean {
    ...
}

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

This behavior is mostly documented. However, I couldn't manage to find anything about conversion conventions when bean or properties names are started with an acronym, something like

@ManagedBean
public class URLManagerBean {
}

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

What should go instead of ellipsis in the previous snippet?

Surprisingly, but there is little to no information on the internet on this. Almost all examples of JSF managed beans usage use bean names without multiple adjacent capital letters in the beginning. In the few places I've managed to find it is suggested that bean names started with multiple capital letters should not be converted in any way, i.e. it would be URLManagerBean in the previous code snippet.

Unfortunately, we have a project where a lot of beans are named that way. And everywhere these beans are used they follow this weird, to the least extent, convention:

class URLManagerBean -> uRLManagerBean

That is, only the first letter of the acronym is decapitalized. The project seems to be working well, so this convention somehow works. But IntelliJ IDEA does not like this; it thinks that JSF beans really should be named like URLManagerBean unless I rename it explicitly through the annotation.

I tried changing usage of class URLManagerBean from uRLManagerBean to URLManagerBean, but apparently this does not work - those pages where I tried it stopped working.

Now I think that the reason behind such weird convention is that we're using Spring integration via SpringBeanFacesELResolver. However, this behavior is not documented anywhere.

Is there some explanation for this behavior?

Upvotes: 2

Views: 1820

Answers (1)

M. Deinum
M. Deinum

Reputation: 125232

Which @ManagedBean annotation are you using? The one from javax.faces.bean or javax.annotation?

In the first case Spring has nothing to do with it as it will be a JSF managed bean and will follow the conventions as specified by JSF.

The value of the name() attribute is taken to be the managed-bean-name. If the value of the name attribute is unspecified or is the empty String, the managed-bean-name is derived from taking the unqualified class name portion of the fully qualified class name and converting the first character to lower case. For example, if the ManagedBean annotation is on a class with the fully qualified class name com.example.Bean, and there is no name attribute on the annotation, the managed-bean-name is taken to be bean. The fully qualified class name of the class to which this annotation is attached is taken to be the managed-bean-class. Source: @ManagedBean javadocs

In the second case Spring is in the mix and then the behavior differs based on which spring version and/or configuration option you use. Using the AnnotationConfigApplicationContext the AnnotationBeanNameGenerator is used which follows the guidelines (and would result in 'URLManagerBean ' as a bean name). Using other means you might end up with the DefaultBeanNameGenerator which has a much simpler algorithm.

Simply said it might depend on which spring version and which annotation you use.

Links

Upvotes: 2

Related Questions