aspose file tools*
The moose likes Web Component Certification (SCWCD/OCPJWCD) and the fly likes Question from HFJS 2nd Edition Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Web Component Certification (SCWCD/OCPJWCD)
Bookmark "Question from HFJS 2nd Edition" Watch "Question from HFJS 2nd Edition" New topic
Author

Question from HFJS 2nd Edition

Pramod Shivale
Greenhorn

Joined: Mar 26, 2008
Posts: 14
Need help regarding the question in HFJS 2nd Edition
This is a question from final mock exam on page 837 of HFJS 2nd Edition
Q. 19)
A Classic tag handler exists in legacy code. The author wrote a handler that evaluates its tag body hundred times, to be used in testing other tags that produce random content.
Given:
06. public class HundredTimesTag extends TagSupport {
07. private int iterationCount;
08.pricate int doTag() throws JspException {
09. iterationCount = 0;
10. return EVAL_BODY_INCLUDE;
11.}
12.
13.public int doAfterBody() throws JspException {
14. if(iterationCount < 100) {
15.iterationCount++;
16.return EVAL_BODY_AGAIN;
17.}else{
18.return SKIP_BODY;
19.}
20.}
21. }

What is incorrect about the code?

A. Tag handlers are not thread safe, so the iterationCount can become out of sync if multiple users are reaching the page at the same time.
B. The doAfterBody is never being called because it is not part of the tag handler lifecycle. The developer should have extended the IterationTagSupport class to include this method in the lifecycle.
C. The doTag method should be doStartTag. As written, the default doStartTag of TagSupport is called which simply returns SKIP_BODY, causing doAfterBody to never be called.
D. When doAfterBody returns EVAL_BODY_AGAIN the doTag method is called again. The doTag method resets iterationCount to 0, resulting in an infinite loop and a java.lang.OutOfMemoryError is thrown.

Answer: C

I think the answer should also include option A according to this snippet on page 541 of HFJS 2nd Edition.
BANG!
The Container can reuse classic tag handlers!
Watch out--this is completely different from SimpleTag handlers, which are definitely not reused.
That means you have to be very careful about instance variables--you should reset them in doStartTag.
Lakshmi Narayanan
Ranch Hand

Joined: Apr 29, 2008
Posts: 58
Tag Handlers are thread safe because
everytime you call simple tags they create new instance.
every time you call classic tags they get it from the pool of instances.

but important in classic tags we have to reset the instance variables in the doStartTag method.


Thanks<br />Lakshmi<br />SCJP 1.4 - 90%<br />SCWCD 5 - 89%
Marc Peabody
pie sneak
Sheriff

Joined: Feb 05, 2003
Posts: 4727

Originally posted by Lakshmi Narayanan:
but important in classic tags we have to reset the instance variables in the doStartTag method.

And if C is followed, the doStartTag method would reset the variable. So we should be safe.

I'm pretty sure this was one of my questions. *evil grin* It's great to see that you're really taking the time to analyze and research the answer options.


A good workman is known by his tools.
Pramod Shivale
Greenhorn

Joined: Mar 26, 2008
Posts: 14
if you are saying classic tags are thread safe, then why do you need to reset the variable in doStartTag? doesnt it mean that classic tags are not thread safe?
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Question from HFJS 2nd Edition
 
Similar Threads
Doubt in doAfterBody
custom tag lifecycle
doStartTag() retun Type
Question 19 in mock exam
Question 19 of HFSJ Final mocktest