jsp:include vs include directive

[Jeff Storey]

Hi, I've done some reading on the difference between jsp:include and the include directive and I've seen examples where they can be different, but I'm still a little confused. I have a site where each page includes an a file that checks if the user is logged in:

<%if(!"yes".equals(request.getSession().getAttribute("loggedin")) {%>
<jsp:forward page="/login.do"/>
<%}%>

This redirects the user to the login page if they are not logged in. However, what I've found is that this seems to behave the same way whether I use the include directive or jsp:include. Could someone help me understand why this is? Or if they shouldn't behave the same?

Thanks,
Jeff

[Bear Bibeault]

Originally posted by Jeff Storey:
I have a site where each page includes an a file that checks if the user is logged in

Rather than having to include this in each and every page, investigate the use of a Servlet filter for such.

However, what I've found is that this seems to behave the same way whether I use the include directive or jsp:include. Could someone help me understand why this is? Or if they shouldn't behave the same?

Why would you expect different observable behavior? The file includes run-time activity so whether this activity is executed as part of an embedded script or run-time included script will yield no observable differences.

The differences between them become obvious when you are including compile-time directives.
[ August 10, 2008: Message edited by: Bear Bibeault ]

[Jeff Storey]

Thanks for the clarification. The tip on servlet filters is a good one, thanks!

Also, in terms of why I might expect different behavior...the examples I've seen mentioned deal with if you have an include file that prints out the current timestamp, that won't change if you include it using the include directive, but it will with jsp include. I'm not really sure I understand how these are different. Could you explain in a little more detail what you mean by compile time directive?

Thanks,
Jeff

[Bear Bibeault]

Originally posted by Jeff Storey:
Thanks for the clarification. The tip on servlet filters is a good one, thanks!

Filters are the preferred way to perform common actions across a range of requests rather than embedding the same code (even include code) in each and every page. Additionally, when you progress to using modern best practices for web app structure -- in which page controllers gain access first before JSP pages -- includes are no longer a feasible way to perform "up front" actions.

the examples I've seen mentioned deal with if you have an include file that prints out the current timestamp, that won't change if you include it using the include directive, but it will with jsp include. I'm not really sure I understand how these are different.

Sounds like a poor example to me. Any run-time action, such as obtaining a timestamp -- will execute just the same in either scenario.

Could you explain in a little more detail what you mean by compile time directive

Let's say that you are going to use a bunch of custom tag libraries in your JSPs. So you collect all the necessary declarations into a single file that you can include on multiple pages. As these are required at compile-time, using the include action will not work because the included file will be processed at run-time rather than included at translation time when it is needed.

Also be aware that in JSP 2.0, the utility of the include action is seriously eclipsed by tag files.

[Jeff Storey]

I'm starting to understand now about the compile time directives, thanks for the help. One last question that is still getting me a little. What would happen if you tried to include a file containing the custom tag library delcarations with the include directive as opposed to jsp:include. Would this just cause an error during deployment? Could there be a case that if you use the wrong type of include that data on the page will not update properly as you might expect?

Lastly, the reason I'm having these issues is because I tried to include my login page (while I now know I can use filters, let's just assume this is on a single page and not a login include on every page) using the jsp:include tag and I got an exception in Tomcat about the stream being closed. Some research led me to this article http://today.java.net/pub/a/today/2005/08/04/jspcomponents.html?page=3#jsp_servlets_compatibility so I'm not really sure what else to do aside from using the include directive.

Thanks,
Jeff

[Bear Bibeault]

Originally posted by Jeff Storey:
What would happen if you tried to include a file containing the custom tag library delcarations with the include directive as opposed to jsp:include.

Other way around. if you are going to include directives that the page needs to compile, you must use the include directive. Trying to use the action will result in a translation error.

P.S. You might also investigate the prelude facility of the deployment descriptor to prefix all JSPs with a common include file. Another way to avoid having to include goo at the start of each page.

Lastly, the reason I'm having these issues is because I tried to include my login page (while I now know I can use filters, let's just assume this is on a single page and not a login include on every page) using the jsp:include tag and I got an exception in Tomcat about the stream being closed. Some research led me to this article http://today.java.net/pub/a/today/2005/08/04/jspcomponents.html?page=3#jsp_servlets_compatibility so I'm not really sure what else to do aside from using the include directive.

Yes, you can't forward or redirect after a response has been committed. Yet another reason to use filters and to adopt modern best-practice web constructs. These patterns were created and adopted not just to make things complicated, but to solve real-world problems such trying to make decisions (like forwarding) way too late in the request/response cycle as you are running up against.

You might want to read through this article.
[ August 10, 2008: Message edited by: Bear Bibeault ]

[Jeff Storey]

I think I've got it now, thanks again.