Mark, Thanks for the clarification. I must confess I has missed the 'should' and read it as 'must'. I'll revert my previous patch and modify the bugzilla report to an enhancement request to log a warning.
Mark On Tuesday, January 06, 2004 11:45 PM, Mark Roth [SMTP:[EMAIL PROTECTED] wrote: > Hi Mark, > > 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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
