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. 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]
