On 28/01/2020 21:50, Christopher Schultz wrote: > Michael, > > On 1/28/20 3:51 PM, Michael Osipov wrote: >> 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? > > I think this only makes sense at the <Context> level because the > security-roles are all defined at the context-level as well. They may > be shared across a bunch of applications, but that's just a coincidence. > > Mapping this across multiple <Context>s won't be a huge burden, given > the other options. > > Another option might be to allow a LifecycleListener to attach some > information to a <Host> (not sure where that might be) and then you > can have /another/ LifecycleListener attached to the <Context>. The > global one defines the mapping but doesn't actually take any action. > The <Context>-attached LifecycleListener then looks-up the tree to > parent components looking for the mappings, and applies them as the > context is being deployed. > > Seems more work than necessary, though. Just have admins bless each > <Context> and be done with it.
You can add something to a host and then have it do something every time a child (i.e. Context) is added. Looking at the code for MapperListener might give you some ideas of the sort of thing you can do. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
