I notice in the struts.jar that the tld's are kept in META-INF/tlds, rather than any WEB-INF I'm using an include file in my JSPs that contains the <%@ taglib prefix="html" uri="/WEB-INF/tld/struts-html.tld" %>
Since I'm not using too many, I just include thist tagdecl.jspf in all my JSPs
I'm using maven and I'd like to avoid all that versioning stuff in the
web.xml, for example:
<taglib>
<taglib-uri>/WEB-INF/tld/struts-html.tld</taglib-uri>
<taglib-location>/WEB-INF/tld/struts-html-1.1.tld</taglib-location>
</taglib>
Note that the <taglib-location> you provide can have any value ... whether or not you include a version number is up to you.
it's far more convenient to just use the taglibs that comes with the struts-#.jar
So, two questions:
1)
<taglib>
<taglib-uri>/META-INF/tld/struts-html.tld</taglib-uri>
<taglib-location>/META-INF/tld/struts-html-1.1.tld</taglib-location>
</taglib>
On a JSP 1.2 or later container, tag library declarations are automatically recognized by the container if they are present in the "META-INF" directory (or any of its subdirectories) in a JAR file that is loaded with the application. Thus, on such a container, you do not *have* to use <taglib> directives in web.xml at all.
The key to making this work is that the URI attribute on your <%@ taglib %> directives must match the <uri> element embedded within the TLD itself. The following lines illustrate the standard tag library URIs for Struts tlds:
<%@ taglib prefix="bean" uri="http://jakarta.apache.org/struts/tags-bean"; %>
<%@ taglib prefix="html" uri="http://jakarta.apache.org/struts/tags-html"; %>
<%@ taglib prefix="logic" uri="http://jakarta.apache.org/struts/tags-logic"; %>
<%@ taglib prefix="nested" uri="http://jakarta.apache.org/struts/tags-nested"; %>
<%@ taglib prefix="tiles" uri="http://jakarta.apache.org/struts/tags-tiles"; %>
For more information on automatic TLD identification, see Section 7.3 of the JSP Specification.
2) Is struts going to continue to keep the taglibs in META-INF, or is this a
temporary thing?
It's permanent, but can only be taken advantage of (as described above) on a JSP 1.2 or later container. Of course, the original mechanism still works as well.
Craig
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
