Am 2020-01-25 um 12:13 schrieb Mark Thomas:
On 23/01/2020 10:29, Michael Osipov wrote:
<snip/>
Design questions:
* Shall this remain a listener or do we want to introduce a new
interface for that? If yes, how should it look like?
Given the use cases (could apply at various levels) a LifecycleListener
looks like a reasonable design choice to me.
I don't see the need for an additional interface (although I could be
persuaded if someone else makes an argument for one)
* Where can this element be placed? Only in context.xml? Also in
server.xml? If yes, at which level are contexts available to be
modified? Can this be placed in server.xml at all?
LifecycleListener can be placed on most elements so it gives plenty of
flexibility.
If it remains as a listener, I would be willing to donate my listener to
the Tomcat codebase and add support for file:// or other stuff required.
Fantastic. Thank you. Take a look at the ConfigFileLoader. All Tomcat
config should be loaded through that.
From my understanding, the mapping source can be arbitrary: inline,
database, file, etc.
Agreed.
Great, I will pick this up next month and have a look how the
ConfigFileLoader works. I hope I can cover at least all current cases.
I wonder now which of the components implementing Container should be
subject to this listener?
Engine, Host, Context? Context is trivial, but the rest? They start
before the contexts, I cannot simply say Host#findChildren() at
CONFIGURE_START_EVENT. It does not make sense logically.
At the moment the Context seems to be the only viable place unless the
mappings are held in memory unless all contexts load and query them.
This would require to change the Container interface.
Comments?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
