can somebody explain this with eg

[Anonymous]

JSP.7.3.6.1 Computing TLD Locations
and
JSP.7.3.6.2 Computing the TLD Resource Path

[Peter den Haan]

Well, let's just go through the spec!

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 �/�.

In other words, the tag library configuration might look like

<taglib>
    <taglib-uri>javaranch</taglib-uri>
    ....
</taglib>

for 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 like

<taglib>
    <taglib-uri>http://javaranch.com/TAGLIB/1.0</taglib-uri>
    ....
</taglib>

which 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.

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 �/�).

So this means a complete map entry, corresponding to the first case above, might look like

<taglib>
    <taglib-uri>javaranch</taglib-uri>
    <taglib-location>/WEB-INF/javaranch.tld</taglib-location>
</taglib>

This 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 be

<taglib>
    <taglib-uri>javaranch</taglib-uri>
    <taglib-location>javaranch.tld</taglib-location>
</taglib>

The 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.

JSP.7.3.6.2 Computing the TLD Resource PathThe following describes how to resolve a taglib directive to compute the TLD resource path.

In other words: the JSP compiler encounters a directive like

<%@taglib uri="http://javaranch.com/TAGLIB/1.0" prefix="ranch"%>

and now it needs to decide which TLD file this corresponds to.

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.

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.

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.

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:

<%@taglib uri="/WEB-INF/javaranch.tld" prefix="ranch"%>

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 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.

An example of this would be

<%@taglib uri="javaranch.tld" prefix="ranch"%>

The 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.
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:

<taglib>
    <taglib-uri>javaranch</taglib-uri>
    <taglib-location>/WEB-INF/lib/javaranch.jar</taglib-location>
</taglib>

or

<%@taglib uri="/WEB-INF/lib/javaranch.jar" prefix="ranch"%>

will 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?
- Peter
[ April 12, 2002: Message edited by: Peter den Haan ]

[Anonymous]

Thanks a TON .. Thanks for showing patience to a newbie like me.
Thanks man!!! thanks!!!