With this one line addition, the listvideos.jsp no longer displays. I added the line immediately after a page directive that executes the java imports, right after the <html> tag and before the <head> tag,
1) Why does this link bring up http://www.oracle.com/technetwork/java/index.html ? I was concerned that perhaps the link given in the taglib example might be obsolete, but I notice that many recent questions on the JavaRanch JSP forum also use this uri, so that makes me wonder if there is something else that I have configured incorrectly.
2) I placed the jstl.jar in the directory "lib/development", alongside servlet-api.jar (being used in place of j2ee.jar). Is this correct? I am curious why the ANT build is set up so that only jr.jar (placed in "lib/production") is included in the .war's WEB-INF/lib file directory. (Note: putting jstl.jar in "lib/production" and doing an ant build does not result in jstl.jar being in the .war "lib" file.)
Any ideas as to why the taglib directive is causing the page to fail?
You're doing great, though it may not feel like it right now! There is a difference between servlet-api.jar and jstl.jar. servlet-api.jar is provided by Tomcat and is available to all deployed web applications. You need it in your classpath in order to compile your servlet classes, but you don't need to make it part of the war file you will deploy. The jstl.jar is not provided by Tomcat, and so for a web app to use it, the web app's war has to carry the jar in its lib folder.
The build.xml as written uses the jars in the development folder for compiling, but doesn't deploy them, so the development folder is the right place for servlet-api.jar. When building a war, the build.xml looks into the production folder, and archives the jars there into the war, so that's the right place for jr.jar, jstl.jar, and also standard.jar, which you will need to get JSTL to work correctly.
I encourage you to look at the war once it's built to see its full structure. You can do that from the command line with:
jar -tvf videos.war
You should see those three jars in the WEB-INF/lib folder, and any classes you've compiled, including servlets, under the WEB-INF/classes folder. You can also use something like WinZip to view a war's contents. Like a jar file, it is just an uncompressed archive in zip format.
Joined: Sep 01, 2010
Thanks for the much needed encouragement! This assignment has been very challenging.
As I had stated, I did try placing jstl.jar in "lib/production" and it did not turn up in the .war file. After double checking this was true, I took a closer look at the build.xml script provided with the assignment to see if I could figure out why it wasn't showing up. In that file, there was a suspicious line, in the section that starts " <target name='war' ":
I found a site with api info for FileSet, and noted that the "includes" attribute is optional, and that when omitted, all files in the specified directory ("dir" attribute) will be "included" in the operation. So, I tried deleting the "includes" attribute and rebuilding. This time, the jstl.jar and standard.jar (finding that was a challenge, too!) which were placed in with the jr.jar in "lib/production" all showed up in the "lib" file in the .war.
Further, when I restored the taglib command and ran the new .war, the listvideos.jsp ran successfully. Phew!
So, onward with the task of using the jstl c:forEach instead of a for loop.
Meanwhile, more questions:
Why does the build.xml that comes with the assignment have these "includes" attributes if they are not part of the solution? Are we supposed to run into this problem and track it down and fix it, as part of the intended learning process? Is it a side effect of switching from Orion to Tomcat? Or have I done something off the intended learning path or something wrong?
Note that there are also "includes" attributes with references to j2ee.jar. I've been using servlet-api.jar instead. Are these "includes" attributes in build.xml dubious as well?
Thanks for your help. I was really stymied and thrashing around until I got your suggestions.
Oops, no, that wasn't meant as a trap. It's good you found a solution on your own though. What doesn't kill you makes you stronger, right?
The problems you're running into aren't because of the Orion to Tomcat migration per se, but because we are trying to modernize the assignments at the same time. This change is particularly apparent in the JSPs. The old assignments relied heavily on scriptlets, which is Java code embedded right into the page. Scriptlets are considered extremely poor form these days. Noted author and JavaRanch Marshal, Bear Biebeault, rails against them with particular vehemence.
I didn't really decide to introduce JSTL to the assignments until Kimberley submitted her solution to the Videos assignment a few weeks ago. That made me realize that it's worth the extra configuration headaches the students will have to go through to configure it.