Before JSP 2.0, the developer had to specify a mapping between the <uri> in the TLD and the actual location of the TLD file. So when a JSP page had a taglib directive like this:

<%@ taglib prefix="mine" uri="randomThings"%>

The Deployment Descriptor (web.xml) had to tell the Container where the TLD file with a matching <uri> was located. You did that with a <taglib> element in the DD.

The OLD (before JSP 2.0) way to map a taglib uri to a TLD file

<web-app>
...
 <jsp-config>
   <taglib>
     <taglib-uri>randomThings</taglib-uri>
     <taglib-location>/WEB-INF/myFunctions.tld</taglib-location>
   </taglib>
</jsp-config>
</web-app>

The NEW (JSP 2.0) way to map a taglib uri to a TLD file

No <taglib> entry in the DD!

The Container automatically builds a map between TLD files and <uri> names, so that when a JSP invokes a tag, the Container knows exactly where to find the TLD that describes the tag.

How? By looking through a specific set of locations where TLDs are allowed to live. When you deploy a web app, as long as you put the TLD in a place the Container will search, the Container will find the TLD and build a map for that tag library.

If you do specify an explicit <taglib-location> in the DD (web.xml), a JSP 2.0 Container will use it! In fact, when the Container begins to build the <uri>-to-TLD map, the Container will look first in your DD to see if you’ve made any <taglib> entries, and if you have, it’ll use those to help construct the map. For the exam, you’re expected to know about <taglib-location>, even though it’s no longer required for JSP 2.0.

So the next step is for us to see where the Container looks for TLDs, and also where it looks for the tag handler classes declared in the TLDs.