On 12/08/2013 16:20, Jeremy Boynes wrote: > On Aug 12, 2013, at 7:46 AM, Mark Thomas <ma...@apache.org> wrote: > >> On 10/08/2013 23:20, Jeremy Boynes wrote: >>> 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. >> >> Don't forget the above :) > > Not forgotten, just a work in progress :) > >> >>> 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. >> >> Isn't the SCI discovered if Jasper is on the classpath when running >> in embedded mode? If not, do we know why not? > > The SCI will be discovered if the embedder adds an application as > that runs ContextConfig which does the scan. However, if they > construct the context directly (without running ContextConfig) they > will need to make sure the SCI is added to use JSP functionality. > This is slightly different to now where TldConfig would scan for and > add listeners from TLDs even if Jasper was not on the classpath > (TldConfig would be added by StandardContext's initInternal method > unless explicitly disabled by setting processTlds false). IMO, the > new behaviour maintains a cleaner separation as it means embedders > just using Servlet functionality are not impacted by JSP-related > features. > > There was one test case where we added a context directly but used > JSPs. I had to add the SCI for that one. All other tests using the > embedded server were fine.
Thanks for clarifying this. I'm wondering about adding enableWebSockets() and enableJSPs() methods to Tomcat which would automatically add the relevant SCI to any Context created via one of the addContext(...) methods. Thoughts? >>> 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 >> >> Remove them. At this point in Tomcat 8 we should be removing >> anything that is no longer used. > > Will do. When I do that I'll also add the "removed in 8" deprecation > warnings to tc7.0.x. Great. >> On a related note, I am now seeing a number of warnings about using >> a deprecated API. It looks like this is because Jasper is still >> using the old code. What is the timescale for switching Jasper to >> use the SCI? > > I would estimate the next week or so depending on real-world > commitments (aka work). I can remove the deprecation tags in trunk if > that would help. No need to remove the deprecation warnings. I would like to get 8.0.0-RC2 tagged in about the same sort of timeframe (I have some non-blocking IO issues to fix first) and it would be good although not necessary to get this finished by then. >>> 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. >> >> This is touched upon in the TOMCAT-NEXT.txt file. > > I managed to add more in this area after sending this, splitting the > scan results and removing the second scan. The next step is to retain > the TLD content loaded during the scan to pre-load a cache to avoid > reloading each TLD every time a JSP is translated. That will need > stronger dependency tracking to invalidate entries if TLDs or tag > files change. It will take me a while though to figure out the code > around TagLibraryInfoImpl as it's a bit convoluted. If you think it is bad now... :) I appreciate the problem. I spent a long time refactoring the Jasper and Catalina code just to get them consistent. It is definitely worth taking the time to figure out the code as that sometimes allows you to see a way to simplify it. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
