How does EL statement: ${person.dog.name} know that attribute "person" is of type Person?

Question

I have these pictures from Head First book:

---

I want you to pay attention to code that replaces ${person.dog.name}. Only thing I want to know is how does it know that attribute "person" is object of type Person? Of course, getAttribute() returns Object, so it must be casted to Person, but how does it know that it is made from Person class?

I guess this code uses findAttribute() previously, to find scope where attribute with value "person" is stored. Later it tries to get it using getAttribute(). So after it finds it, it gets it - but it still doesn't know what it is getting in reality. So how/where did it "figure out" that it is of type Person?

Answer 1

It doesn't. The properties are resolved using reflection, by looking for a method getDog() on whatever object person resolves to, and then repeating that process.

Answer 2

the EL engine sees person and looks it up in the glorified HashMap (which is what request.setAttribute is filling - that glorified hashmap).

It finds an object there, because you set it. It gets this object and invoked .getClass() on it, which returns Person.class. It then runs a capitalizer function on dog to produce getDog. It then scans for all fields using .getFields() as well as all methods using .getMethods(), looking for either a field named dog or a no-args instance method named getDog. It finds the method, and invokes it.

Repeat this principle for how it ends up dealing with the .name part.

Now EL has an object (the result of invoking getName on whatever object wsas returned by reflectively invoking getDog on whatever person was), and toStrings that into place.

I don't think it's HTML escaping it, so this is a book that is 'helpfully' informing you how to use obsolete technology (JSP) to create security holes. Great.

You got a newer book? You might wanna get something that is less than 10 years old :)