On 13/11/2013 08:04, Jeremy Boynes wrote: > On Nov 12, 2013, at 8:53 AM, Mark Thomas <ma...@apache.org> wrote:
>> >> I was planning on completing the removal of TldLocation. I'm >> currently working my way through understanding what that means. > > I'd started by trying to remove the parsing code from > TagLibraryInfoImpl, making a thin decorator for a TaglibXml that > could be shared (given the TLIImpls are page/compilation specific > due to both prefix and the reference to other TLIs). I was thinking along the same lines. > IIRC, that worked for tags but there was a coupling somewhere in > the TagFileProcessor call used to populate the TagInfo for a tag > file. I was trying to figure out why > ctxt.setTagFileJarResource(path, jar); was needed in before calling > it and how #46471 had been fixed. I hadn't got this far but good to have the pointer for when I do. > In investigating, I was also tempted to try and separate the > directive and load processing (visitors) in TagFileProcessor and > see if there was a way to only do that once. That is probably more than I am likely to do. > I should have more time to contribute over the next couple of > weeks and could pick this up again if you've not got too far. Great. I'm currently looking at tracking changes so we can avoid re-scanning the TLDs unless we have to. The tricky part is how this interacts with the new resources implementation. The scanner returns URLs to TLDs but the new resources implementation could map a resource with a higher priority to the same location and with just the URL you have no way of knowing this. You need to know the path to the resource in the web application. I'm experimenting with having the scanner report the web application path as well as the URL. I'm not entirely happy with what I have at the moment. I'm thinking about a new JarScannerResult type that encapsulates webapp path and URL but I haven't convinced myself that is the right way to go yet. Mark > > Cheers Jeremy > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
