• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Whizlabs Mock Question

 
Kamal Tripathi
Ranch Hand
Posts: 86
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Source: Whizlabs Mock Test

What modification should be made in test.jsp to make the employee bean accessible within another.jsp?
Select one choice.



Choose one answer.

a. No modification is needed; the bean will be available in the included page also.
b. Modify the code to use the include directive instead of the include action.
c. Change the scope of the bean to session.
d. Change the scope of the bean to request.

Choice B is the correct answer.

By default, the scope of a bean is page, so the bean will not be available in the dynamically included page.

So choice A is incorrect. In a static inclusion, the two pages become one translation unit. So the bean will be available in the included page when the include directive is used. So choice B is correct.

Choices C and D are incorrect because even if the scope of the bean is changed to session or request, the bean instance would be available in the included JSP file only if that bean also contains a useBean declaration identical to the one in the including file.


Now I agree that option B is correct answer but option C or D too can be correct. If I change the scope to session/request in test.jsp. Then when @ runtime another.jsp is accessed jsp:getProperty too would be able to access it since it searches attribute based on pageContext.findAttribute and request and response objects of original jsp or servlet is available to including servlet/jsp. So even C or D could be correct here.
 
Harvinder Thakur
Ranch Hand
Posts: 231
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Yes i agree with you.
Choices b, c, d will be correct whether the desired attribute exists in any scope or not.

 
Lee Kian Giap
Ranch Hand
Posts: 213
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
In order for C and D to be correct , because when using jsp:include , the request and response object is pass to another.jsp ... for the jsp:getproperty to work, it need to map to the jsp:usebean id, else it can't get the employee attribute from the specified scope

the test.jsp page code need to have additional line , so need to become

//test.jsp
<jsp:usebean id="employee" class="EmployeeBean" scope="request"/>
<jsp:include page="another.jsp" />
//another.jsp
<jsp:usebean id="employee" class="EmployeeBean" scope="request"/>
<jsp:getproperty name="employee" property="salary" />

so , for that question , only Answer B is correct.

Hope this explained clearly , do ask if any doubt !

All the best !!! I'm on my way to SCWCD too !!!
 
Kamal Tripathi
Ranch Hand
Posts: 86
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Lee Kian Giap wrote:

the test.jsp page code need to have additional line , so need to become

//test.jsp
<jsp:usebean id="employee" class="EmployeeBean" scope="request"/>
<jsp:include page="another.jsp" />
//another.jsp
<jsp:usebean id="employee" class="EmployeeBean" scope="request"/>
<jsp:getproperty name="employee" property="salary" />


so , for that question , only Answer B is correct.



I am not getting your point completely. You added a line in another.jsp so that now you add attribute in another.jsp as well .... but my point is that hasn't this object already been previously added to request by the same line in test.jsp.

While including we are not making new request so with old request we still should have access to its attributes without adding it freshly anywhere else.
 
Kamal Tripathi
Ranch Hand
Posts: 86
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Ah, finally I found why is it wrong. Its bad HFSJ doesn't cover this.

This is from JSP Spec JSP.5.3 1-108
The object named by the name must have been “introduced” to the JSP processor using either the jsp:useBean action or a custom action with an
associated VariableInfo entry for this name. If the object was not introduced in this manner, the container implementation is recommended (but not required) to raise a translation error, since the page implementation is in violation of the specification.

Note – A consequence of the previous paragraph is that objects that are stored in, say, the session by a front component are not automatically visible to jsp:set- Property and jsp:getProperty actions in that page unless a jsp:useBean action, or some other action, makes them visible.

If the JSP processor can ascertain that there is an alternate way guaranteed to access the same object, it can use that information. For example it may use a scripting variable, but it must guarantee that no intervening code has invalidated the copy held by the scripting variable. The truth is always the value held by the pageContext object.


Hey Lee thnx, even after posting my last post, I was wondering you wouldn't have posted what you wrote without knowing something concrete and then I consulted the spec.
 
Harvinder Thakur
Ranch Hand
Posts: 231
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Aha....the answer is indeed B as per the specs even though my container behaves differently..
gud work kamal for digging it out....
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic