Win a copy of Functional Reactive Programming this week in the Other Languages forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

<jsp:useBean> standard action type and class confusion

 
Luis Centeno
Ranch Hand
Posts: 46
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Ranchers...

I've been looking at standard actions and <jsp:useBean> is really confusing to me...
I wrote some code to clear my doubts but I am confused about type and class attributes.
Pleas take a look at my example code:

I wrote three classes:





And a servlet in order to instantiate the Person class and send different references to the jsp as a request-scoped attribute.



Now...I wrote a jsp for the fields to be shown in the view and I noticed particular behaviors...

When I used

I got both values in the view and the following code is generated by the container


When I used

I got an error since id field is not part of Movable interface...

When I used...

I got both values in the view and the following code is generated by the container


My doubt is about the way the container handles type and class attributes.

I noticed that when class attribute is defined, its value is used to cast the attribute found by _jspx_page_context.findAttribute("person3"), even though the attribute bound to the request is not of this type. And when class attribute is not defined, it tries to use the type attribute value, in my code example it does not work though...

Is this the expected behavior from the container? Is class attribute value intended to do this casting as well? Am I missing something?
 
Ankit Garg
Sheriff
Posts: 9529
33
Android Google Web Toolkit Hibernate IntelliJ IDE Java Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hmm this is interesting. I read the JSP spec 2 times regarding this and it mentions that if you specify both type and class attributes of jsp:useBean tag, and if the object is found, then the object must be of the type specified by the type attribute, there is no compulsion that the object be of type specified by the class attribute. So basically if I have a tag
Now if there is an attribute named movable in the page scope, then its not compulsory that it must be of type com.lagc.bean.Person. So the container should allow you to only access properties of Movable class and not Person class as the actual object might not be of type Person. Maybe I missed something or the container which you are using (I'm using Tomcat 6 and the behavior is the same as your container) is not showing the correct behavior...
 
Seetharaman Venkatasamy
Ranch Hand
Posts: 5575
Eclipse IDE Java Windows XP
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I agree with Ankit
 
Luis Centeno
Ranch Hand
Posts: 46
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

I read the JSP spec 2 times regarding this and it mentions that if you specify both type and class attributes of jsp:useBean tag, and if the object is found, then the object must be of the type specified by the type attribute, there is no compulsion that the object be of type specified by the class attribute...

...So the container should allow you to only access properties of Movable class and not Person class as the actual object might not be of type Person.


I absoultely agree with you and this was the way I had understood this concept, but if this is true, my container (Tomcat 5.5) is not doing what it is supposed to do.
Unless, this concept is regarding the actual object, I think the container checks the object class (based on class attribute value) bound to the scope (request in this case) rather than relying on the type attribute value.
Hence, this case is valid since I am binding a Movable reference type referring to a Person object on the heap. This could justify this behavior from the container (shown below) but, again, it is just a supposition.



What do you guys think?
 
Chinmaya Chowdary
Ranch Hand
Posts: 434
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi, Luis.

During translation time, jsp:setProperty and jsp:getProperty checks the jsp:useBean attributes and translates accordingly.
1. Suppose if we use 'type' attribute without using 'class' attribute, the translation for jsp:useBean will be
In the above gets the 'person3' attribute that was set in 'request' scope. If 'person3' object is not available, it throws 'InstantiationException' indicating 'bean person3 not found within scope'.

Suppose if we use then page will be translates into

Here casting will be done by using 'type' attribute 'com.lagc.bean.Movable'. Suppose if the container casts it with 'com.lagc.bean.Person', there is no meaning it will never available.

2. If we use both 'type' and 'class' attribute:
it wil be translates into


Suppose if we use jsp:getProperty like then page will be translates into

The important point to notice here is that it will not cast it with 'com.lagc.bean.Movable' instead it casted with 'com.lagc.bean.Person' eventhough the jsp:useBean uses 'type' attribute. Because there is a chance of jsp:getProperty to get the 'person3' attribute. In the above translated code if 'person3' attribute is not available, there is chance of creating Person object. Because of this possibility jsp:getProperty casts it with 'Person' class. It behaves intelligently according to jsp:useBean attributes. I tested this in Tomcat5.5.9. I think(I am guessing) this behaviour is guranateed. This makes sense.
 
Luis Centeno
Ranch Hand
Posts: 46
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thank you guys for your help...

Chinmaya: Now it is all clearer, I had not thought about the object creation using the class attribute vaue and consecuences at translation time as well as differences when you only specify one or both attributes of <jsp:useBean>. You are right it all makes sense now, when the object is not found in the scope, it is created with the class attribute value, so it is retrieved with this value as well...
 
Prashant Shiralkar
Greenhorn
Posts: 19
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello,

This is regarding an example from the "Be the Container" from Head First Servlets & JSP Edition 2, page#: 358, 420
Person is an abstract class with setName() and getName(). Employee is a subclass of Person.

I tried implementing the following code (I excluded the package):

In a test servlet:


In JSP that tries to access this attribute bean:

This code works fine and also follows the concept as explained by Chinmay. But the answer in the book says that this code fails at request time. Hence, this makes me wonder if its an error in the book or I am implementing & interpreting it in an incorrect way. Can someone help me clarify this?
 
Frits Walraven
Creator of Enthuware JWS+ V6
Saloon Keeper
Pie
Posts: 2451
96
Android Chrome Eclipse IDE
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
That is just a trick question: the tag is used wrongly, no space is allowed between the jsp: and useBean
so:

should be:


regards,
Frits
 
Chinmaya Chowdary
Ranch Hand
Posts: 434
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi, Prashant.

This works fine. See errata .
 
Prashant Shiralkar
Greenhorn
Posts: 19
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks Frits and Chinmay!

While implementing the problem, I put Person.class and Employee.class in /WEB-INF/classes directory. When I request the JSP page for the first time, I can see that the container (Tomcat 5.5) generates the corresponding servlet (.java) file, but it fails to compile it giving an exception:
(X & Y are placeholders here for line# and jsp page respectively.)

This implies that the container fails to locate the Employee.class file. I don't see a reason why it cannot find it in the directory mentioned above. Earlier, I got around this by manually placing the .class files in the same place where the container puts the translated servlet (just in order to focus on the main problem first). Any idea for container's this kinda behavior?
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic