Created attachment 29687 [details] Patch for TagPluginManager.java Currently, tagPlugins.xml can only be put in a WAR. However, if the configuration can be put into a web framework, so web application don't need to care about this.
Comment on attachment 29687 [details] Patch for TagPluginManager.java No objections in principle. Some comments on the proposed solution: 1. I don't see a need for a system property here. Servlet context initialization parameters are a better choice. 2. No documentation. 3. Patch doesn't follow Tomcat coding standards.
For this implementation to work, one would need to put the configuration file into classpath. I think that is not a good place for a configuration file. If it were implemented via context initialization parameters or parameters of JspServlet, I wonder how it will behave during offline generation of JSPs (aka the jspc tool of Jasper). Some testing is needed.
TagPlugin is good for making tag libraris more efficently. The target for tag libraries is to share between multiple web applications. Same as TagPlugin. Imagine that one enterprise has many web applications. It's better to share same tagPlugins & tagPlugins.xml for all applications. So that all applications can benifit from it. Currently the solution is putting the tagPlugins.xml under WEB-INF. It is not good for shareing this tagPlugins.xml with other applications. Now the solution still supports tagPlugins.xml under WEB-INF. Instead, it also supports an system level tagPlugins.xml. This tagPlugins.xml might be packaged with those implementations of TagPlugin. I think TagPlugin implementations must provide such kind of configuration file. That's the idea of Zero-Configuration for web applications.
(In reply to comment #3) Your way goes to multiple tag libraries. If each one is self-contained, it could configure itself, without a global tagPlugin file. I do not know whether API is available in TagPluginManager, but there are already hooks to plug libraries in a container: a) support for a Listener in Tag Library Descriptor (TLD) file b) ServletContainerInitializer in Servlet 3.0 specification
Yes. Maybe it needs separated tagPlugins.xml for every tld file. So the solution can be like this, 1. Check all resources in classpath with name "META-INF/jasper/tagPlugins.xml" 2. Parse them one by one and put all the tagPlugins into tagPluginManager. 3. Load tagPlugins configurations from "WEB-INF/tagPlugins.xml" if it existed. With this new solution. TagPlugin declared in "META-INF/jasper/tagPlugins.xml" can be override by WebApp. Tag library provider can also provide its own tagPlugins configurations for tag library. What's your opinion ? (In reply to comment #4) > (In reply to comment #3)
Created attachment 29737 [details] Patch for TagPluginManager.java
Created attachment 29738 [details] A TagPlugin for testing
Created attachment 29739 [details] A tag for testing
Created attachment 29740 [details] Test case fo TagPluginManager
Hi Mark, I made a little changes for Konstantin's concern. And refined the code and uploaded the test case. Please take a look. Thanks, Sheldon
I like the idea of using the existing mechanisms (such as ServletContainerInitializer) but that would require other changes since: - TagPluginManager is not created at the point where the SCI runs - There is no mechanism to expose the TagPluginManager to the SCI Given that changes would have to be made and that Tag plug-ins are a Tomcat specific extension, I don't have an issue with a Tomcat specific mechanism to configure these plug-ins. I like the META-INF/japser approach as it means a plug-in JAR can be dropped into CATALINA_BASE/lib and be used by all web applications on that instance. I'll be working on applying this patch for 7.0.35.
Thanks for the patch and test case. This has been applied to trunk and 7.0.x and will be included in 7.0.35 onwards.