tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Roth <Mark.R...@Sun.COM>
Subject Re: cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/resources messages.properties
Date Wed, 07 Jan 2004 00:56:56 GMT
No problem, Mark.

Thanks,
---
Mark Roth, Java Software
JSP 2.0 Co-Specification Lead
Sun Microsystems, Inc.


Mark Thomas wrote:
> 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:Mark.Roth@Sun.COM] 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:Larry.Isaacs@sas.com] 
>>>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: markt@apache.org [mailto:markt@apache.org]
>>>>>Sent: Saturday, January 03, 2004 8:57 AM
>>>>>To: jakarta-tomcat-jasper-cvs@apache.org
>>>>>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: tomcat-dev-unsubscribe@jakarta.apache.org
>>>>>For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>>>>>
>>>>>
>>>>
>>>>---------------------------------------------------------------------
>>>>To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
>>>>For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>>>>
>>>
>>>
>>>
>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
>>>For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>>>
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>>
> 
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org


Mime
View raw message