This week's book giveaway is in the Agile and Other Processes forum.
We're giving away four copies of The Little Book of Impediments (e-book only) and have Tom Perry on-line!
See this thread for details.
Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

does the jsp engine look for the declared/actual type before instantiating javabean ?

 
Rasika Chitnis
Ranch Hand
Posts: 131
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Before creating an instance of a java bean, the jsp engine looks for an object of same name as the value of id attribute, in the specified scope (or in 'page' scope if no scope is specified). Does it also look for the declared type or actual type of the existing bean ?
After reading the type-cast problem given on page 258 of SCWCD exam study kit, it looks like jsp engine looks only for the name, not the type. If it looked for both the name and the type, the type-cast problem would not arise.
In the following code :
in Residential.jsp
<jsp:useBean id="address" scope="session" class="ResidentialAddressBean" />
in Business.jsp
<jsp:useBean id="address" scope="session" class="BusinessAddressBean" />
if Business.jsp, is accessed after Residential.jsp it would throw ClassCastException because it tries to cast an existing bean of type ResidentialAddressBean in the session scope to BusinessAddressBean.
 
k space
Ranch Hand
Posts: 104
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
What if BusinessAddressBean is the super-class of ResidentialAddressBean?
Of course, you will get the same exception if the sequence is the other way round, i.e. first Business.jsp then Residential.jsp.
 
Rasika Chitnis
Ranch Hand
Posts: 131
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
the real issue is BusinessAddressBean and ResidentialAddressBean both are unrelated.
 
Vedhas Pitkar
Ranch Hand
Posts: 445
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
That's precisely why you must specify type="AddressBean"
 
Maha Annadurai
Ranch Hand
Posts: 87
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Rasika,
I understand your doubt. The important point here is , "how the lookup coding is done?". As you said, the generated servlet looks for an object with the same name as of 'id' attribute in the given scope with given class. How it is really coded is the key here.
Tomcat does its coding something like below.

The SCWCD book also assumes the coding will be done like above in order to find the object. I guess we can use object.instanceOf(aType)
way also to make the decision. In that case, we will not get any ClassCastException at all. Something like below:


Is this what your doubt Rasika?
Any comments on this? Others ?
Thanks!
Regards,
Maha Anna
[ December 16, 2002: Message edited by: Maha Annadurai ]
 
Bernd Stransky
Ranch Hand
Posts: 47
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello,
You are correct, the JSP container uses only the name of the attribute, given by id, in a specific scope.
class and type are not considered in 'finding' the attribute in a scope.
Assuming you know about the class/type combination in jsp:useBean, my understanding is that you use the following construct somewhere in your web app when you create the bean:
<jsp:useBean id="address"
type="AddressBean"
class="BusinessAddressBean"
scope="session" />
This will create a new instance of type BusinessAddressBean (assuming it does not exist yet).
The following construct in other parts just refer to an existing bean instance:
<jsp:useBean id="address"
type="AddressBean"
scope="session" />
This will not create a new bean, just access an existing one. Now in this case, variable address can point to beans of type AddressBean or any subclass like BusinessAddressBean or ResidentialAddressBean, you can't tell from here - you have JSP code that utilizes the power of object orientation.

Hope this helps,
Bernd
SCJP
 
Maha Annadurai
Ranch Hand
Posts: 87
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
After my above post, I looked into the Jsp Spec carefully and found that the JSP spec clearly says that as a first step, an attempt is made to locate an object with the given 'id' in the given scope. In this first step the container should not care about the class or type.
Here is the spec info:
Section Jsp 4.1
---------------
Semantics
The actions performed in a jsp:useBean action are:
1. An attempt to locate an object based on the attribute values id and scope . The
inspection is done synchronized per scope namespace to avoid non-deterministic
behavior.
1. A scripting language variable of the specified type (if given) or class (if type
is not given) is defined with the given id in the current lexical scope of the
scripting language.
2. If the object is found, the variable�s value is initialized with a reference to the located object, cast to the specified type . If the cast fails, a java.lang.ClassCastException
shall occur
. This completes the processing of this jsp:useBean action.
3. If the jsp:useBean element had a non-empty body it is ignored. This completes
the processing of this jsp:useBean action.
4. If the object is not found in the specified scope and neither class nor beanName
are given, a java.lang.InstantiationException shall occur. This completes the
processing of this jsp:useBean action.

So Tomcat is implementing the 'find logic' according to spec.
Regards,
Maha Anna
[ December 16, 2002: Message edited by: Maha Annadurai ]
 
Rasika Chitnis
Ranch Hand
Posts: 131
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks all, for your posts. Thanks, Maha Anna, for both your posts. As you said, a simple check for type of existing bean using instanceOf will avoid cast exception.
 
Peter den Haan
author
Ranch Hand
Posts: 3252
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
But you don't want to avoid the ClassCastException. If a type mismatch occurs, you're apparently binding two completely different things under the same name. This is likely to be a programming error. Re-instantiating the beans if the existing copy is of the wrong type will probably not remove the problem. But it will probably make the problem hard to spot and hunt down.
The earlier an exception is thrown, the better.
- Peter
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic