Skip to main content

JBoss to GlassFish : taglib-location

Posted by sekhar on January 21, 2009 at 10:48 PM EST

Recently, I came across the following JBoss -> GlassFish migration issue involving taglib-location in web.xml. Here is how I dealt with it.

In a web-application's web.xml, <jsp-config> element can be used to provide configuration information for JSP files. The following fragment works on JBoss 4.3 (or so it was indicated to me) 

   <jsp-config>
     <taglib>
       <taglib-uri>example-html.tld</taglib-uri> 
       <taglib-location>WEB-INF/example-html.tld</taglib-location> 
     </taglib>
   </jsp-config>

But on GlassFish v2, the web application's deployment to failed with the following exception in GlassFish server.log file. 

     javax.servlet.ServletException: PWC3039: Invalid TLD resource path /WEB-INF/WEB-INF/example-html.tld

To fix error, prefix a / to taglib-location 

   <jsp-config>
     <taglib>
      <taglib-uri>example-html.tld</taglib-uri>
      <taglib-location>/WEB-INF/example-html.tld</taglib-location> 
     </taglib>	
   </jsp-config>

So is a leading / for taglib-location *required* ? After browsing through JSP & Servlet specs and xml schema files I interpreted that a / is not required but recommended. But I will defer to the Servlet spec lead for a more definite answer.

Related Topics >>
Blog Links >>

Comments

by kschneid - 2009-01-22 11:40

Of course, any TLD file sitting in WEB-INF or a subdirectory should be auto-discovered, so it's probably best to remove the entry all together and just use the value of the uri element in the TLD.

by kschneid - 2009-01-22 11:26

AFAICT, GlassFish seems to be doing the right thing. If a relative URI that does not start with a "/" is used, then the location should be resolved relative to "/WEB-INF/web.xml", which would result in "/WEB-INF/WEB-INF/example-html.tld". So, one other thing to try with GlassFish would be to just use "example-html.tld".

by mrmenace - 2009-06-08 13:44

Thanks, Sekhar. For others' reference, I also had the same exception, but my problem was that I was trying to have WEB-INF be a symbolic link to a common location. When I removed the symlink and copied the actual WEB-INF to my context root, the exception went away.