On Jul 22, 2013, at 10:10 AM, Mark Thomas <ma...@apache.org> wrote: > On 21/07/2013 18:36, Jeremy Boynes wrote: > ... >> In the meantime, I'm going to look at refactoring the TLD support as >> described above. > > Nice. See my note about TLD processing in the TOMCAT-NEXT.txt file in > the root on trunk.
I've taken the first step on this in http://svn.apache.org/r1512826 which moves the TLD processing from TldConfig into Jasper's ServletContainerInitializer. There are a couple of implications for this: 1) Jasper's SCI needs to be activated to use TLDs This should cause no impact when ContextConfig is used to configure a web application in the normal way is Jasper is on the class path. When using Context directly in embedded mode, JasperInitializer now need to be added to enable JSP functionality which will automatically TLD processing to add listeners. Previously, TLDs would be scanned automatically unless the processTld property on StandardContext was explicitly set false. IOW, TLDs will only be processed if JSP functionality is added, and don't need to be turned off if it is not. 2) As part of the change for processTlds I deprecated the operations on Context to set/get TLD processing properties (for validation and namespace) as they are can't be used by Jasper's SCI. If there are no objections to an API change at this stage I will go ahead and remove them completely. XML validation for TLDs can now be controlled via the "org.apache.jasper.validateDescriptors" initParam for the ServletContext; namespace processing is always on as we require >3.0 (due to the SCI etc.) which uses namespaces anyway 3) TldScanner parses TLDs as it goes creating a cache of parsed values keyed off TLD URI. It should probably create a second mapping from "TLD resource path" to the parse result in order to handle taglib directives that specify paths. I'll look at that when refactoring the Jasper side. That will also allow the second scan to be removed. Cheers Jeremy
signature.asc
Description: Message signed with OpenPGP using GPGMail
