Win a copy of The Java Performance Companion this week in the Performance forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Question from HFJS 2nd Edition

 
Pramod Shivale
Greenhorn
Posts: 14
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 58
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Marc Peabody
pie sneak
Sheriff
Posts: 4727
Mac Ruby VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Pramod Shivale
Greenhorn
Posts: 14
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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?
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic