4
votes

With all the research I've done on creating managed beans, what I've not noticed (or what I may have overlooked) is when to use explicit naming of the bean e.g. @Named(name = "someBean").

I guess what it hard for me to understand is why you would want to name the bean anything other than your class name:

@Named(name = "someBean")
public class SomeBean implements Serializebale {
}

With all the examples I've seen, some use the the explicit name and some just use @Named to leave the default class name. What none of these examples explained was why they used the explicit naming. It just seems more confusing to try and access the bean with anything other than the class name.

So I guess question is, is there any rule of thumb or convention as to when you would want provide an access name different from your class name, or do people just do it if they have a long class name that they want to be able to access with less typing?

1
You're asking the equivalent of why would someone call you by a nickname. Maybe company policy states that all beans must end with CompanyServiceBean, and you think it clutters up things. Maybe the bean is poorly named, but you can't rename it, so you use a better name by specifying it here. It doesn't matter really. You can name the bean, but you don't have to.Kayaman
that pretty much answers my questionPaul Samsotha

1 Answers

6
votes

Your question regards the Convention over configuration design paradigm. To fight with mistakes from the past that among others concerned necessity for extensive configuration, many defaults have been introduced since the last releases of many Java frameworks/APIs, etc. JSF/CDI is no exception in this case.

For example, it's enough to annotate a bean with @ManagedBean to let it be @RequestScoped and let it be available in EL scope by simpleClassName:

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.

The scope of the managed bean is declared using one of NoneScoped, RequestScoped, ViewScoped, SessionScoped, ApplicationScoped, or CustomScoped annotations. If the scope annotations are omitted, the bean must be handled as if the RequestScoped annotation is present.

The same applies to CDI beans, EJBs, JPA Entity classes, etc. So, the only reason I see to put lines of the type @ManagedBean(name = "myBean") public class MyBean is to explicitly repeat the generated name of the managed bean either for yourself, or for the unexperienced audience.

It is also worth noting that from time to time developers tend to name the bean not after the simple name of its class, but refer to some explicit short self-explaining names like in the following line: @ManagedBean(name = "settings") public class UserDefinedSettingsBean.