Kin-Man pointed me to this thread and I figured I'd contribute my interpretation.
For reference, the JSP 2.0 specification, JSP.7.3.1 states:
"Tag library descriptor files have names that use the
extension .tld, and the extension indicates a tag library
descriptor file. When deployed inside a JAR file, the tag
library descriptor files must be in the META-INF directory, or
a subdirectory of it. When deployed directly into a web
application, the tag library descriptor files must always be in
the WEB-INF directory, or some subdirectory of it. TLD files
should not be placed in /WEB-INF/classes or /WEB-INF/lib."A few notes:
1. The intent of this guideline is that the container can but need not recognize .tld files elsewhere. This is a requirement on the application, not the container. In other words, an application that places its TLD file in any other location is in violation of the specification, and a container can but need not handle that application.
2. The specification does not state that an error occurs if a TLD file appears elsewhere. It leaves it up to the container.
3. The specification says "should" not be placed in /WEB-INF/classes or /WEB-INF/lib, not "must", so the requirement for these two locations is even less strong.
So it seems we're free to do what we want in Tomcat. My recommendation would be to either leave it the way it was or log a warning to the user that the application is not spec-compliant.
I don't like producing an error here - if prior versions of Tomcat handled this, I see no reason to go out of our way to change this and break applications that once worked. However, it might be appropriate to log a friendly warning to the user since the application is not following the specification.
--- Mark Roth, Java Software JSP 2.0 Co-Specification Lead Sun Microsystems, Inc.
Mark Thomas wrote:
Larry,
AFAIK Tomcat behaviour does not depend on the version of the deployment descriptor schema apart from during the interpretation of the descriptor. On this basis, I am against setting a precedent here.
Further, my understanding is that each version of Tomcat is written to support a single defined version of the spec. It is not written to support multiple spec versions. If a version of the spec is not 100% backwards compatible with the previous version I believe that this is a spec issue, not a tomcat issue.
It is inevitable that in each new version of the spec there will be a number of areas that will cause problems with migrating applications from a previous version.
I would be interested to hear the views of other tomcat developers on this issue.
Mark
On Tuesday, January 06, 2004 3:27 PM, Larry Isaacs [SMTP:[EMAIL PROTECTED] wrote:
Mark,
For backwards compatibility, I think the restrictions to the TLD location need to follow the spec level used by the web application. Since JSP 1.1 didn't include much in the way of restrictions, I know of some legacy Servlet 2.2/JSP 1.1 webapps that would fail these restrictions if deployed to Tomcat 5 with this change (or Tomcat 4.1 with the port of this change). If you want, I can take a look at fixing this.
Cheers, Larry
-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Saturday, January 03, 2004 8:57 AM To: [EMAIL PROTECTED] Subject: cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/reso urces messages.properties
markt 2004/01/03 05:56:39
Modified: jasper2/src/share/org/apache/jasper/compiler TagLibraryInfoImpl.java jasper2/src/share/org/apache/jasper/resources messages.properties Log: - Fix bug 11069. Check that the location of the TLD file is spec compliant.
Revision Changes Path 1.50 +11 -4 jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/comp iler/TagLibraryInfoImpl.java
Index: TagLibraryInfoImpl.java =================================================================== RCS file: /home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/j asper/compiler/TagLibraryInfoImpl.java,v retrieving revision 1.49 retrieving revision 1.50 diff -u -r1.49 -r1.50 --- TagLibraryInfoImpl.java 3 Jan 2004 12:17:18 -0000 1.49 +++ TagLibraryInfoImpl.java 3 Jan 2004 13:56:38 -0000 1.50 @@ -5,7 +5,7 @@ * * The Apache Software License, Version 1.1 * - * Copyright (c) 1999 The Apache Software Foundation. All rights + * Copyright (c) 1999,2004 The Apache Software Foundation. All rights * reserved. * * Redistribution and use in source and binary forms, with or without @@ -200,6 +200,13 @@ } } catch (FileNotFoundException ex) {
err.jspError("jsp.error.file.not.found", location[0]); + } + + // Check TLD file location conforms to JSP.7.3.1 + if (!location[0].startsWith("/WEB-INF/") + || location[0].startsWith("/WEB-INF/classes/") + || location[0].startsWith("/WEB-INF/lib/")) { + err.jspError("jsp.error.tld.invalid.location", location[0]); }
parseTLD(ctxt, location[0], in, null);
1.138 +2 -1 jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/reso urces/messages.properties
Index: messages.properties =================================================================== RCS file: /home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/j asper/resources/messages.properties,v retrieving revision 1.137 retrieving revision 1.138 diff -u -r1.137 -r1.138 --- messages.properties 11 Dec 2003 18:24:21 -0000 1.137 +++ messages.properties 3 Jan 2004 13:56:39 -0000 1.138 @@ -187,6 +187,7 @@ jsp.error.tld.unable_to_read=Unable to read TLD \"{1}\" from JAR file \"{0}\": {2} jsp.error.tld.unable_to_get_jar=Unable to get JAR resource \"{0}\" containing TLD: {1} jsp.error.tld.missing_jar=Missing JAR resource \"{0}\" containing TLD +jsp.error.tld.invalid.location=\"{0}\" is not a valid location for a TLD as per JSP specification JSP.7.3.1 jsp.error.webxml_not_found=Could not locate web.xml jsp.cmd_line.usage=Usage: jsptoservlet [-dd <path/to/outputDirectory>] [-keepgenerated] \ <.jsp files>
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
