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.7.3.6.1 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.7.3.6.2 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.
Peter den Haan | peterdenhaan.com | quantum computing specialist, Objectivity Ltd
Consider Paul's rocket mass heater. |