Contradictory explanations of MVC in JSF

I'd starting to learn JSF, but first I'd like to understand the big picture of it as an MVC framework.

There are several answers with many upvotes explaining what are MVC layers in JSF, but they usually contradict themselves.

BalusC's answer: What components are MVC in JSF MVC framework?

In the big architectural picture, your own JSF code is the V:

M - Business domain/Service layer (e.g. EJB/JPA/DAO)
V - Your JSF code
C - FacesServlet

In the developer picture, the architectural V is in turn dividable as below:

M - Entity
V - Facelets/JSP page
C - Managed bean

Jigar Joshi's answer in the same thread:

M odel would be your ManagedBean

V iew would be jsp,XHTML (well you can accommodate various views here )

C ontroller will be FacesServlet

Here, another view on the problem:

In JSF you don't implement a controller. Consequently, a backing bean or any other kind of managed bean is NOT the controller.

Yet another, not from Stackoverflow this time:

In JSF, the master Controller is always the FacesServlet. Sub-Controllers are incorporated into the various control element tag implementations. You almost never write controller code in JSF, because it's all pre-supplied. So you only have to supply the View templates (xhtml) and the Models (backing beans).

A lot of people think that the action logic in backing beans makes them Controllers. This is incorrect. A Controller is a component whose sole purpose in life is to synchronize the Model and View. In JSF, that task is performed by the FacesServlet and the controls. You may have Validators and Converters performing adjunct functions, but the actual synchronization (updating) is part of the JSF core.

I know MVC has many variants depending on if it's a desktop application, web aplication etc. so it's difficult to define MVC (try to find two sources with identical explanation of MVC).

I'm mostly concerned with Managed beans here. Are they M or C? Managed beans are apparently used to retrieve data from Model layer (the Model layer on the highest level of abstraction - big architectural picture as in BalusC's answer, that is EJB, JPA and DAO) and store the result to be used by the view. Controller layer in MVC is the one responsible for handling commands from the view, communicating with model layer and retrieving data from the model layer. Is managed bean used to communicate with Model layer? Yes, and it also makes the retrieved data available for the view. For me it belongs to controller layer, not a model, because it doesn't contain logic used to retrieve the data, or the data itself, but only calls the appropriate model layer methods (take a look at BalusC's code sample).

So what's the source of my confusion? Could anyone explain this once and for all so that it's clear for beginners in JSF?

I'm mostly concerned about Managed beans here. Are they M or C?

People consider them M when they look like this:

@ManagedBean
public class Bean {

    private String username; // +getter+setter
    private String password; // +getter+setter

    @Resource
    private DataSource dataSource;

    public void login() {
        try (
            Connection connection = dataSource.getConnection();
            PreparedStatement statement = connection.prepareStatement("SELECT * FROM User WHERE username = ? AND password = MD5(?)");
        ) {
            statement.setString(1, username);
            statement.setString(2, password);

            try (ResultSet resultSet = statement.executeQuery()) {
                if (resultSet.next()) {
                    // Login.
                }
            }
        }
    }

    // ...
}

But people consider them C when they look like this:

@ManagedBean
public class Bean {

    private User user // +getter

    @EJB
    private UserService userService;

    public void login() {
        if (userService.find(user) != null) {
            // Login.
        }
    }

    // ...
}

This is also mentioned in the very same MVC answer you found:

Note that some starters and even some —very basic— tutorials mingle/copy/flatten the entity's properties in the managed bean, which would effectively make the controller a model. Needless to say that this is poor design (i.e. not a clean MVC design).