Re: svn commit: r1544165 - XML validation
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 26/11/2013 05:05, Jeremy Boynes wrote: > It seems to me the original behaviour from JSP6.2.4 is the best we > can do: * parse with no validation * if a DOCTYPE is found, restart > with DTD validation on * never attempt XSD validation > > This would eliminate the need for the > "org.apache.jasper.XML_VALIDATE_DOC" option and related context > property so I propose we back that change out. Having looked at this some more, I agree with that view. I'll revert the validation option for *.jspx/*.tagx files. Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSlKiDAAoJEBDAHFovYFnnFUkQAN7votj4grrFf/EqvFpDOMBB lckEskz9cDrI80rGFKtGZpcALBeHMoyh+Lbn1oQKXK738mzsW4IWSPw5oq8KWG6d mlYzk6hXhpjujLXI2/SKqcTndy5VAdWAg5j4m2ASDT6U89dOriUDn97CMbA2QNrQ OgwA/MoxmyNMluBh7iuPMuV7nRgfhdX/Mp8H2E1gPUvK7TZnp/AzhE0R6C+8V5KI ZCoTLQpl5vtfZsEFsoSfOKNWkhOTUpcWb7u8tEJXL08g5leiTIuda2jCFKSj0x1Q fUpuo58a+D+lelwYrUAI6DCV5hkK83LDpUyLXsRY1mjGoTq68rst/eauQmeVJ1Y/ 1I3hQs3iKWgfolVvQRUiqwjgfkT++iY39PViE7BfDf8DvM8W3SXctxIZzzMOrFak KRL0Q0Tn2i9APonpbVuYCsMIsxsf96nziIkXMZhUQHnR4znlyoPPYUWNsHp5LXR+ eiTGqUHGpDa6uRssrOngmyTcdPzd2RUb+/ogOsVT6NPMHC+S/DperOnnilZWMdgL U1mqHprXFKsq25ufiddcriyLGVjLHUYYtUOyIB6BJSqP1pzVl3puSTF4fPL1FFz4 0921afkqEQMpWwE48mR4lgjMq2ExtD1S3eKYTcFMAOeP/E3iRnw2cYaOVVOn3UBJ sCNPA/FXvUroERMxbTGT =kfgS -END PGP SIGNATURE- - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1544165 - XML validation
On Nov 21, 2013, at 7:16 PM, Jeremy Boynes wrote: > On Nov 21, 2013, at 4:59 AM, ma...@apache.org wrote: > >> Author: markt >> Date: Thu Nov 21 12:59:36 2013 >> New Revision: 1544165 >> >> URL: http://svn.apache.org/r1544165 >> Log: >> Extend the reach of the Context attribute xmlValidation to cover XML parsing >> by Jasper the JSP engine. >> Fix a TODO and enable validation (if required) for implicit TLD files. > > JSP 6.2.4 raises issues around attempting to validate JSP Documents (.jspx > and .tagx) due to the mixin's from the jsp: namespace. This could perhaps be > enabled using a separate option from validation of the descriptors so users > can validate the standard files but not need to add anything to the > DOCTYPE/XSD for the application content. This may not be that simple, and I think I've some other issues in this area, see http://svn.apache.org/r1545537 The test there fails because the schema cannot be found. JspDocumentParser is not setting the baseURI for the document being parser and its implementation of URI resolver always returns null. This means it cannot resolve the systemId "valid.xsd" relative to the document, tries using the current working directory, does not find it there and hence fails because it cannot find the schema to validate against. If I replace the relative URI with a absolute location then it attempts to validate but fails because the element is not valid in the "string" simple type of root. If I do not enable validation in JspDocumentParser, the .jspx evaluates correctly and the client is able to parse and validate the XML document response (showing the XSD and XSI are valid). If I disable XSD validation but leave DTD validation on then it fails because there is no DOCTYPE in the .jspx It seems to me the original behaviour from JSP6.2.4 is the best we can do: * parse with no validation * if a DOCTYPE is found, restart with DTD validation on * never attempt XSD validation This would eliminate the need for the "org.apache.jasper.XML_VALIDATE_DOC" option and related context property so I propose we back that change out. I'd been meaning to update JspDP to be a DefaultHandler2 to match the XML refactoring in Digester so I'll fix the baseURI issue as part of that. Cheers Jeremy signature.asc Description: Message signed with OpenPGP using GPGMail
Re: svn commit: r1544165 - XML validation
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 22/11/2013 16:10, Jeremy Boynes wrote: > On Nov 22, 2013, at 1:28 AM, Mark Thomas wrote: > > Still catching up on the changes but this jumped out: >> >>> Looks like JasperInitializer now reads to read an attribute >>> not an init-param. In trunk, I'd been trying to decouple Jasper >>> from Catalina so having the latter set a jasper-specific >>> attribute reverts that - in TC7 this is controlled for each >>> JspServlet using a "validating" init-param (i.e. it does not >>> inherit from the Context). >> >> There are multiple aspects to this. >> >> Jasper needs to be usable in other containers so it can't depend >> on Catalina. Both attributes and init-params allow this. >> >> There are some things - like XML validation - that apply to both >> Catalina and Jasper and users shouldn't have to configure this >> in multiple places. attributes vs. init-params are really just >> the mechanism used to pass config from Catalina to Jasper in this >> case. I think it is easier to do this with attributes than >> init-params. > > The issue with magic attributes though is that that container > needs to set them, whereas init-params can be set in a descriptor > supplied with the application. I think attributes are easier as > well but think there's benefit in the other container case of > having Jasper's configuration be standalone not need container > support. > > Ideally this configuration would be exposed to an SCI in way > defined by the spec (e.g. a javax. attribute or method on > ServletContext). You've convinced me. I'll move them from attributes to init-params. Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSj4XnAAoJEBDAHFovYFnnmz4QANs83fGZJZ3xfei1w9tyPrAq CCodms1rROEUMpXIX27PHiMm/5910EIMvC3Jdl2NzM7acyZTJJbhU+dk8vC/W9/L H51aMYYiB9BGIcUi9qIptG2bwI8tc/Rtc9toB64yPeGOXtU5wI+ssixENe/rPwBV hDSozIxqs6J4Kl59O9fg4T6U/KGzmuiUiLmVDFVEvEQDXw8ew51NqA5DjJ8bFNkV q0A9oWAsCDULvper1QdQGL3by1SPRJNnU/+5FON7i8pA1a1oCTqO9ZoLb5gkIwTr CsT7QsH2hNkjOl2oiUdELJJkOHZLKKbSQr4rKiFkv1lC2TWrVibC18tm7D3wU5I7 vDvGC8I83xocnJkpkIHlu2tzyIT1WM5eO1Lp5PdovreiQLDrSbwMzkVEresepRRd OrTmh8UM9W8bLH2zHGXsz75q9rjGBmOHVUqqhwE3G8Lb9DK8XHWK+gNOvaahtcsb jkm2AchJywyN2C/CaZyamrICxLUbSlGyde0BVLh5WoljRhZdwPKuW2ceRaJSn9Mo 0QmZhALJb0/C8tTmoxKmzBhH15OQ+9NMFwV1PVmloJwo9bhp5myvF/XtClGhVoab 8++pXIzGkZ69OKhdjXyGINFupTFn4AN8DVzHv1gcgaWFuwW9TKX0INTrseSgUpSq HkYbwnJn37QvRPmAdGJg =uwdw -END PGP SIGNATURE- - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1544165 - XML validation
On Nov 22, 2013, at 1:28 AM, Mark Thomas wrote: Still catching up on the changes but this jumped out: > > > Looks like JasperInitializer now reads to read an attribute not an > > init-param. In trunk, I'd been trying to decouple Jasper from > > Catalina so having the latter set a jasper-specific attribute > > reverts that - in TC7 this is controlled for each JspServlet using > > a "validating" init-param (i.e. it does not inherit from the > > Context). > > There are multiple aspects to this. > > Jasper needs to be usable in other containers so it can't depend on > Catalina. Both attributes and init-params allow this. > > There are some things - like XML validation - that apply to both > Catalina and Jasper and users shouldn't have to configure this in > multiple places. attributes vs. init-params are really just the > mechanism used to pass config from Catalina to Jasper in this case. I > think it is easier to do this with attributes than init-params. The issue with magic attributes though is that that container needs to set them, whereas init-params can be set in a descriptor supplied with the application. I think attributes are easier as well but think there's benefit in the other container case of having Jasper's configuration be standalone not need container support. Ideally this configuration would be exposed to an SCI in way defined by the spec (e.g. a javax. attribute or method on ServletContext). Thanks Jeremy signature.asc Description: Message signed with OpenPGP using GPGMail
Re: svn commit: r1544165 - XML validation
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 22/11/2013 03:16, Jeremy Boynes wrote: > On Nov 21, 2013, at 4:59 AM, ma...@apache.org wrote: > >> Author: markt Date: Thu Nov 21 12:59:36 2013 New Revision: >> 1544165 >> >> URL: http://svn.apache.org/r1544165 Log: Extend the reach of the >> Context attribute xmlValidation to cover XML parsing by Jasper >> the JSP engine. Fix a TODO and enable validation (if required) >> for implicit TLD files. > > JSP 6.2.4 raises issues around attempting to validate JSP Documents > (.jspx and .tagx) due to the mixin's from the jsp: namespace. This > could perhaps be enabled using a separate option from validation of > the descriptors so users can validate the standard files but not > need to add anything to the DOCTYPE/XSD for the application > content. I'd forgotten about that. A separate option (XmlValidateJspDoc ?) would work here. > Looks like JasperInitializer now reads to read an attribute not an > init-param. In trunk, I'd been trying to decouple Jasper from > Catalina so having the latter set a jasper-specific attribute > reverts that - in TC7 this is controlled for each JspServlet using > a "validating" init-param (i.e. it does not inherit from the > Context). There are multiple aspects to this. Jasper needs to be usable in other containers so it can't depend on Catalina. Both attributes and init-params allow this. There are some things - like XML validation - that apply to both Catalina and Jasper and users shouldn't have to configure this in multiple places. attributes vs. init-params are really just the mechanism used to pass config from Catalina to Jasper in this case. I think it is easier to do this with attributes than init-params. > I've been thinking of adding a descriptor file for Jasper (e.g. > META-INF/jasper.xml to go alongside context.xml) which would > contain configuration of the JSP engine that is currently split > between context init-params, per-servlet init-params, and system > properties. How about we configure validation there? I'm all for anything that reduces the number of system properties we use. I also like the idea of everything being configured in one place. You might also want to consider: - - a global CATALINA_BASE/conf/jasper.xml as well - - an option to ignore any META-INF/jasper.xml similar to deployXML My main concern is for those settings like xmlValidation where Catalina needs to pass the configuration option to Jasper. There needs to be a way to do this and there are times when this setting needs to override the setting in META-INF/jasper.xml. I still think attributes are the best way to do this. Cheers, Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSjyOuAAoJEBDAHFovYFnnZoMP+wW/0PN5OnjKfNtUAk+cpJtz /F8IxG2KjXFMeDmQmPfyGZCBvzSbTxvLRwjzKkws+xJLKOOzcjgC9wa5Rq4SxzXe JRlP/rJ6Nd3Cyda2V4DyVjhRBR20gGr3x3O0i0oxBRVJu//D5Sz0bO4SsOPApytN Cgix5Xbkh2MiVJh+kI+oeeAzzsxiLlgORVKekj5M8WuKSuNI0FUawpTK5m8Wbr4Q qShUm60ZV05w003G263O7k3FS4uCmLZ29lf8+0nqV5nzb9HnUH8zYFCqmKKqZT+V o0Hf2FOas0AOClW3xGENrYsIa5/3w6eDB0DpPOxScqwdPZhk9x9U4FdsuPbbLTCw ZQG6rQGHX95EO8ETfytY8VvYZ8xQUUxbsns4H9zYnTLl0q9CDmVbhwcBvMTkpG/H /tfr+8zOPJvoMOP8Uui0cyb6rSxIy8Kpoup6u5AaLA5x2kocgU2C4CWj7W/15dBp vLt/dB+X/NTdQHILnbRyWnuUd/J0KyxS9cZ8bsyPFoZTh3XJSu9d2jKmAJ10ccJZ Zb2Yo2fF2OBjxC3q1A2B+yMdpSXgE3K3t4dCvhzzp1D8NT05EWFJPMV+jvU+yb/Y YR/+/izLMd+W2i4mob6RQ0QJJOpe5TZF5kJvRELmuFlIXCWzq5RMXCOl2IAQYLZV seuWB6XbaaQ3dRwkT5qa =wkwu -END PGP SIGNATURE- - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1544165 - XML validation
On Nov 21, 2013, at 4:59 AM, ma...@apache.org wrote: > Author: markt > Date: Thu Nov 21 12:59:36 2013 > New Revision: 1544165 > > URL: http://svn.apache.org/r1544165 > Log: > Extend the reach of the Context attribute xmlValidation to cover XML parsing > by Jasper the JSP engine. > Fix a TODO and enable validation (if required) for implicit TLD files. JSP 6.2.4 raises issues around attempting to validate JSP Documents (.jspx and .tagx) due to the mixin's from the jsp: namespace. This could perhaps be enabled using a separate option from validation of the descriptors so users can validate the standard files but not need to add anything to the DOCTYPE/XSD for the application content. Looks like JasperInitializer now reads to read an attribute not an init-param. In trunk, I'd been trying to decouple Jasper from Catalina so having the latter set a jasper-specific attribute reverts that - in TC7 this is controlled for each JspServlet using a "validating" init-param (i.e. it does not inherit from the Context). I've been thinking of adding a descriptor file for Jasper (e.g. META-INF/jasper.xml to go alongside context.xml) which would contain configuration of the JSP engine that is currently split between context init-params, per-servlet init-params, and system properties. How about we configure validation there? Cheers Jeremy signature.asc Description: Message signed with OpenPGP using GPGMail
