javax.el.ELException: Error reading 'foo' on type com.example.Bean

Question

I am reading the following tutorial:

The expression used in the h:dataTable/@value normally specifies a property name for which a getter was defined, which means that in the controller BookController class a property books is defined (optional) as well as a method named getBooks (this is mandatory). In this particular case it is just sufficient to define the getBooks method since there is no need of the books property in the controller class

I have been trying to work such an idea in my eclipse and tomcat 7. but it keeps tilling me:

javax.el.ELException: /views/books/listAll.xhtml @9,60 value="#{bookController.books}": Error reading 'books' on type pl.ctrl.BookController

My question is, is it possible to have:

<h:dataTable value="#{bookController.books}" var="b">

While there is no books property but just getBooks() getter method in #{bookController} managed bean?

Celik

So, where is your code? BTW, If you define a public getBooks() method, you effectively define a books property. What you don't necessarily define is the books field. A field and a property are not the same thing. – Desolate

Answer 1

Your problem is different than what the book tells. If JSF/EL couldn't find the getter method in its entirety, you would have gotten the below exception:

javax.el.PropertyNotFoundException: Property 'books' not found on type pl.ctrl.BookController

Or if it couldn't find the bean itself in its entirety:

javax.el.PropertyNotFoundException: Target Unreachable, identifier 'bookController' resolved to null

But instead you got:

javax.el.ELException: Error reading 'books' on type pl.ctrl.BookController

This means that the bean and the getter method was found, but invoking the getter method threw an exception. Basically, the following is happening under JSF/EL's covers:

try {
    Object result = bookController.getBooks();
} catch (Exception e) {
    throw new ELException("Error reading 'books' on type pl.ctrl.BookController", e);
}

Note the e being passed as cause of the ELException. The original exception must thus be visible as "Caused by" further down in the stack trace which you didn't post anywhere in the question. The bottommost one is the root cause of all and is the answer to your concrete problem. In case you're unable to interpret it, simply copypaste the exception type and message into a decent search engine to find answers and clues.

---

Unrelated to the concrete problem, an exception thrown from a getter method in turn indicates fishy code. A getter method isn't supposed to do any exception sensitive business logic. Namely, it can be invoked multiple times per bean's life and repeating the very same business logic over and over during all bean's life is plain inefficient. Stop doing that and move the business logic to an one time initialization or action/event listener method. The getter method must merely return the already-prepared property. See also Why JSF calls getters multiple times and How and when should I load the model from database for h:dataTable.

Yokoyokohama

What if the getter is e.g. protected? or private? Curious to the error then... I'll try later (or is that the cause and you want OP to find out ;-)) – Karenkarena

@Kukeltje: just PropertyNotFoundException. It's a technical requirement already. – Yokoyokohama

@BalusC: you are right. Caused by: javax.el.PropertyNotFoundException: Property 'books' not found on type pl.ctrl.BookController the getter is have argument and it looks like: public List<Book> getBooks(EntityManager em) { return Book.getAllObjects(em); and the related method in the entity class is : @SuppressWarnings( "unchecked") public static List<Book> getAllObjects( EntityManager em) { Query query = em.createQuery( "SELECT b FROM Book b", Book.class); List<Book> books = query.getResultList(); return books; } any help!!. – Celik

That's indeed wrong on your side. Click the last link in bottom of the answer for the right way to do business logic (and the link in bottom of that answer for more detail, etc). – Yokoyokohama