In other words, the tag library configuration might look likefor a relative URI ("javaranch") not starting with "/". Please note that this is a URI, not a URL. In other words, it is merely an identifier and does not need to point to a real resource such as a file or a web page. The configuration can also look likewhich specifies the absolute URI "http://javaranch.com/TAGLIB/1.0". Again, it may look like a URL but it isn't -- there doesn't need to exist anything at this location. The idea is that this absolute identifier should be globally unique. By using a domain name that we own ourselves (javaranch.com) we avoid clashes with any name someone else might come up with.
JSP.188.8.131.52 Computing TLD Locations
The taglib map generated in Sections JSP.7.3.3, JSP.7.3.4 and JSP.7.3.5 may contain one or more <taglib></taglib> entries. Each entry is identified by a TAGLIB_URI, which is the value of the <taglib-uri> subelement. This TAGLIB_URI may be an absolute URI, or a relative URI spec starting with �/� or one not starting with �/�.
So this means a complete map entry, corresponding to the first case above, might look likeThis tells the JSP container that the tag library with identifier "javaranch" corresponds to the TLD /WEB-INF/javaranch.tld (relative to the web-app root). An example of the second case might beThe specification is now relative to "web.xml"; in other words, the container will look for "javaranch.tld" in the /WEB-INF folder. This second example of specifying the location is equivalent to the first.
Each entry also defines a TAGLIB_LOCATION as follows:
If the <taglib-location> subelement is some relative URI specification that starts with a �/� the TAGLIB_LOCATION is this URI. If the <taglib-location> subelement is some relative URI specification that does not start with �/�, the TAGLIB_LOCATION is the resolution of the URI relative to /WEB-INF/web.xml (the result of this resolution is a relative URI specification that starts with �/�).
In other words: the JSP compiler encounters a directive likeand now it needs to decide which TLD file this corresponds to.
JSP.184.108.40.206 Computing the TLD Resource PathThe following describes how to resolve a taglib directive to compute the TLD resource path.
The taglib directive I used above is an example of this case. The JSP container will look for a URI "http://javaranch.com/TAGLIB/1.0". If it can't find it, that's a translation error. If it can find it, it might map to "/WEB-INF/javaranch.tld", for example, and I will be able to access all the tags defined in there using the "ranch:" prefix.
It is based on the value of the uri attribute of the taglib directive.
If uri is ABS_URI, an absolute URI: Look in the taglib map for an entry whose TAGLIB_URI is ABS_URI. If found, the corresponding TAGLIB_LOCATION is the TLD resource path. If not found, a translation error is raised.
This means that relative URIs can work in two different ways. They can work much like absolute URIs: you specify "/javaranch", it looks for "/javaranch" in the map and that resolves to a TLD. But a relative URI may also be used to directly specify the path to a TLD, completely bypassing the URI-to-location map we've been talking about so far:tells the JSP container that it should make all the tags in "/WEB-INF/javaranch.tld" available with a "ranch:" prefix. This is especially useful when you're quickly knocking together a JSP to try out a taglib: just give the path to the TLD (or the taglib jar), no need to modify web.xml or sort out URI identifiers.
If uri is ROOT_REL_URI, a relative URI that starts with �/�: Look in the taglib map for an entry whose TAGLIB_URI is ROOT_REL_URI. If found, the corresponding TAGLIB_LOCATION is the TLD resource path. If no such entry is found, ROOT_REL_URI is the TLD resource path.
An example of this would beThe JSP container will first try to interpret "javaranch.tld" as a URI. We haven't defined a "javaranch.tld" URI, so the next thing it tries is to find a "javaranch.tld" file relative to the JSP (in this case, in the same directory as the JSP itself). If it finds one, then that's where the tag definitions come from. In other words, this works exactly like the previous alternative, except that the TLD file is located relative to the JSP instead of relative to the web-app root.
If uri is NOROOT_REL_URI, a relative URI that does not start with �/�: Look in the taglib map for an entry whose TAGLIB_URI is NOROOT_REL_URI. If
found, the corresponding TAGLIB_LOCATION is the TLD resource path. If no such entry is found, resolve NOROOT_REL_URI relative to the current JSP page where the directive appears; that value (by definition, this is a relative URI specification that starts with �/�) is the TLD resource path.
One last thing. We have been talking about "a taglib map" all the time, and looking at the examples you might think that this actually means "the <taglib> entries in web.xml". That is only part of the truth. Yes, all <taglib> entries in web.xml become part of the taglib map. But as of JSP 1.2, the container also extracts the <uri> element from every *.tld file under /WEB-INF and puts it into the map (JSP.7.3.4). It also scans the jars in /WEB-INF/lib for TLDs. For many of us this removes the need to explicitly define taglib mappings in web.xml -- they are generated automatically for us. In addition to this the JSP container may come with some tag libraries and associated URIs built in.
Another last thing. In all of the examples above, the taglib location was a plain *.tld file. This means that the tag library consists of at least two parts: a tld descriptor file, and either a jar or a bunch of classes that implement the tags. There's an alternative, superior, way of packaging your tag library: create a jar with a TLD file called "META-INF/taglib.tld" in it. You can then refer to this jar in the same way you can refer to a TLD file:orwill use the "META-INF/taglib.tld" from the "javaranch.jar" file. Of course, in JSP 1.2, the container will already have examined this TLD file and, if it specifies a URI, added an entry to the map for it. It will have done this for any other TLD in the jar as well, making it possible to have multiple TLDs in the same jar -- great for versioning.
Does this help?
[ April 12, 2002: Message edited by: Peter den Haan ]