Redirect vs Forward

Redirect sends a response to the browser that forces the browser to make a new request. From the server point of view, the browser just makes a new request. Some characteristics of a redirect:

• The existing parameters and attributes are disposed, a new request is formed with the parameters you specify in the URL.
• The new URL is visible in the browser, the user can bookmark it.
• It takes a trip to the browser and back, so it can be slower.

A forward happens on the server. The browser is not involved in this. Some characteristics of the forward:

• New parameters are added or overwrite existing parameters. So the existing parameters cannot be removed from the request.
• Stuff can be added in request context, it will remain available. You can pass information in this way.
• The URL is not changed in the browser, for the browser the original address remains intact.
• You can only forward to another URL in the same application.

The difference between the Include Directive and the Include Action

Directive:

<%@ include file="somePage.jsp" %>

• Only one servlet is executed at run time.
• Scriptlet variables declared in the parent page can be accessed in the included page (remember, they are the same page).
• The included page does not need to able to be compiled as a standalone JSP. It can be a code fragment or plain text. The included page will never be compiled as a standalone. The included page can also have any extension, though .jspf has become a conventionally used extension.
• One drawback on older containers is that changes to the include pages may not take effect until the parent page is updated. Recent versions of Tomcat will check the include pages for updates and force a recompile of the parent if they're updated.
• A further drawback is that since the code is inlined directly into the service method of the generated servlet, the method can grow very large. If it exceeds 64 KB, your JSP compilation will likely fail.

Action:

• Each included page is executed as a separate servlet at run time.
• Pages can conditionally be included at run time. This is often useful for templating frameworks that build pages out of includes. The parent page can determine which page, if any, to include according to some run-time condition.
• The values of scriptlet variables need to be explicitly passed to the include page.
• The included page must be able to be run on its own.
• You are less likely to run into compilation errors due to the maximum method size being exceeded in the generated servlet class.

Guidelines for tag lifecycle management

1) Properties are expected to remain consistent. This means that:

- no user code should call a setXXX() accessor of a tag handler
- the tag handler's code itself should not modify properties that are
set by a setXXX() method
- tag handlers should not perform invocation-specific logic in a
setXXX() method. That is, the setting of a property should
have no side effects.

2) Private, invocation-specific state must be managed manually.
Implications include that:

- release() is not necessarily called between invocations, which
means that tag logic should not count on private invocation-
specific state being reset by release()
- doEndTag() is not necessarily called at the end of every invocation
(in cases of abnormal termination -- e.g., an exception thrown inside
a tag's body or by one of its methods)
- private invocation-specific state is thus best initialized in
doStartTag()

- doFinally() *is* always called for tag handlers that implement
TryCatchFinally, so this method should be used if any invocation-
specific resources need to be released
- release() *is* always called at least once for a tag handler before
it is garbage-collected, so this method can and should be used to
release any long-term resources