Jay Tse

If a page is not buffered, (i.e. directive used is <%@page buffer="none"%>
then all the output to the JspWriter is automatically written to out and there is no need of flushing since there is no buffer to flush.

In this case, the flush=true does not make a difference.
An IllegalStateException is not thrown with <jsp:include>, it is only thrown with <jsp:forward> and RequestDispatcher.forward if the buffer is flushed (i.e. response is commited).

This brings up an interesting question the answer to which I don't know.
What if the page is buffered (which is the default for JSP pages with buffer size="8kb") and autoFlush="true" ?(which is also the default) In this case what if the buffer is automatically flushed by the container (because the buffer has grown to a size > "8kb") and then a <jsp:forward> or RequestDispatcher.forward is executed? Will this result in an IllegalStateException even though the user has not commited/flushed the response?

Sorry I'm answering your question with another question and making it more confusing.

I would appreciate it if someone would answer this query I have. (BTW, I'm not sure if this kind of question can be on the exam - its really tricky - I hope not)

Questions:
1. Is RequestDispatcher.include() on the exam? (HFSJ says no but I'm not sure)
2. Are the <jsp:include> action and the RequestDispatcher.include() pretty much the same in terms of functionality?
3. What happens when a page is buffered and jsp:include is executed with flush=false? Will the buffer be cleared before the included page or is the output of the included page added to the buffer?

Thank You.

Thank you Satou kurinosuke and Vishnu Prakash for the answers.

I also checked the errata for HFSJ and it says that the "bang" box on page 261 is incorrect. So you guys were correct. Thank you again.

Yes we can, but it does not get included during the translation phase.

the directive <%@include file %> gets included during the translation phase before the JSP is compiled into a servlet class.

The <jsp:include> action will include the resource, static or dynamic, during runtime.

Hi Mayank,

Also answer (3) is not correct.

If the <session-timeout> is set to "0" or "-1" in the DD, the session will never expire.

In the case of a servlet, setMaxInactiveInterval has to be set to "-1" only in order for the session to not expire. Setting it to "0" will expire the session immediately.

The DD and servlet are not consistent when it comes to setting the timeout of the session.

I learned this by answering one of the coffee cram exams in HFSJ.

It's a little confusing since the HttpSessionAttributeListener has a method called attributeReplaced that gets called for an object implementing the HttpSessionAttributeListener interface.

But, I guess if the replaced attribute object implements the HttpSessionBindingListener, then its "valueBound" method would get called when it is added to the session.

Is it true that both HTTPSessionBindingListener and HTTPSession ActivationListner
cannot be configured in web.xml?

I thought only HTTPSessionBindingListener does not need to be in web.xml.

I think the WEB-INF part has to be in uppercase - i.e. tagdir="/WEB-INF/tags"

See if that works. Also, the quotes can be single or double quotes.

Also make sure that you have a tag file named "Header.tag" under WEB-INF/tags

(Note: everything is case-sensitive)

A Tag File is not the same as a JSP page. It is a JSP fragment. Some of the differences between Tag Files and JSP pages are the directives they use. Tag Files do not use the Page directive, but add three more directives - variable, attribute and tag. Also, when a Tag File is used in a JSP page, its body cannot have any scripting elements, just like Simple Tags. Similarly, because of the internal (web container) implementation of Tag Files, they share more in common with Simple Tags than Classic Tags. Hence, they have access to the JspContext (like Simple Tags) instead of PageContext (like Classic Tags) implicit object.

Hope this helps.

Answer is 1) Password is transferred as text.

Since Base64 is a common way of encoding (and not encrypting) the data, and since the decoding algorithm is commonly available, it is not secure.

I think that when you are print it out inside the table, you need to use
${item} instead of ${var}, since item is the name of the variable you have declared (with var="item") to hold the value.