The <uri> element in the TLD is a unique name for the tag library. That’s it. It does NOT need to represent any actual location (path or URL, for example). It simply has to be a name—the same name you use in the taglib directive.

“But,” you’re asking, “how come with the JSTL it gives the full URL to the library?” The taglib directive for the JSTL is:

The web Container doesn’t normally try to request something from the uri in the taglib directive. It doesn’t need to use the uri as a location! If you type that as a URL into your browser, you’ll be redirected to a different URL, one that has information about JSTL. The Container couldn’t care less that this particular uri happens to also be a valid URL (the whole “http://...” thing). It’s just the convention Sun uses for the uri, to help ensure that it’s a unique name. Sun could have named the JSTL uri “java_foo_tags” and it would have worked in exactly the same way. All that matters is that the <uri> in the TLD and the uri in the taglib directive match!

As a developer, though, you do want to work out a scheme to give your libraries unique <uri> values, because <uri> names need to be unique for any given web app. You can’t, for example, have two TLD files in the same web app, with the same <uri>. So, the domain name convention is a good one, but you don’t necessarily need to use that for all of your in-house development.

Having said all that, there is one way in which the uri could be used as a location, but it’s considered a really bad practice—if you don’t specify a <uri> inside the TLD, the Container will attempt to use the uri attribute in the taglib directive as a path to the actual TLD. But to hard-code the location of your TLD is obviously a bad idea, so just pretend you don’t know it’s possible.