Ah, I see. But it's a little trickier than that.
For Servlet 2 containers (for example,
Tomcat 6), you would indeed have to include a resolving servlet. WebJars provides one and you'd code the URL path to use it. That would also require require mapping a URL
pattern, for example, map "/webjars" to the webjars servlet.
Servlet 3 is different, however. I'd wager money that you could actually retro-fit Tomcat 6's default servlet, but why bother - user Tomcat 7 or later (or some other Servlet 3 container).
In Servlet 3, you do not have to provide a servlet mapping, so the resource is mapped to the root of the webapp. Any fine-tuning is optional.
I think that the webjars docs for Servlet 3 are defective. Based on what I saw of the static resource spec, the correct URL for their resource would not be:
Instead it should be:
Aside from the improper use of single-quotes in the tag, the Servlet 3 docs would imply that the JAR path /META-INF/resources/css/bootstrap.min.css would cause /css/bootstrap.min.css to be presented as a public URL.
Note that I haven't address the higher-level parts of the URL (server and context root and relative
versus absolute URL syntax). Just the internal resource path. I'll leave the rest to you.
Incidentally, the attribute syntax using the subtag "wj:locate" is presumably a custom JSP tag injected by the webjars infrastructure and which probably renders a webjars servlet path. I didn't find anything about it on the webjars site, though.
WebJars appears to be redundant in Servlet3, since the container's default servlet can already serve up WEB-INF/lib jar resources. Its primary virtue would appear to be for Servlet2 containers. So maybe their Servlet 3 example is actually correct, but is injecting and mapping a webjars servlet even though it's not necessary in Servlet 3. Which would presumably be for backwards compatibility.