Tim Funk wrote: > Now I am more confused. So tldDigester is static. The init method sets > setTldValidation and setTldNamespaceAware based on the first Context it > encountered. (As well as the first StandardHost) So if another > Context/StandardHost have different settings, they are ignored. (Which > sounds like a different pre-existing "bug") In which case, not much to > worry about.
The web.xml and context.xml digesters have the same problem (see ContextConfig). Given the lack of bug reports, I suspect no-one uses these settings or if they do, they set them the same for all hosts/contexts. Mark And since only one instance of tldDigester would exist > (instead of one per context) - its not the end of the world with respect > to memory waste. > > -Tim > > Mark Thomas wrote: >> Tim Funk wrote: >>> Unless I am missing something - we will now have a one TldConfig per >>> Context. >> That is how it was before. >> >>> And each TldConfig will have its own tldDigester. >> No, tldDigester is static. >> >>> But the >>> tldDigester is only used once on startup to find all the listeners. >>> >>> So tldDigester only needs to live for the life of execute() where >>> eventType=Lifecycle.START_EVENT. >>> >>> Long story short: >>> I think tldDigester can now be a local variable in the execute() method. >>> That way the tldDigester can be deallocated after startup by how the >>> variable is scoped. >> I'm not against that change although it may slow start-up slightly. I >> haven't tested how expensive creating the parser is. It would also fix an >> unreported bug that the xml validation settings are taken from the first >> context and used for all contexts. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
