-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 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. - -chris -----BEGIN PGP SIGNATURE----- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl4wrKwACgkQHPApP6U8 pFjKxw/7BNjDmsU1BHXUqEXbyxKcpHsP3x+iz++ECzkFiSse2kfSff018KSsqjYk nosqP9TVTGbFA/7UV94TBNY8s2UbzN+bJAOveLweIU1CPTo8bcI9lpBwnnGezBci PBMhw7BtAOcf9rCrSTZQSOeU1AkGHvoF+ikMfoqPGdbm0vbV9PJWZwcTbM/ILM9Q jKkbZPTnaQyKmoJWZnMiJaa+JnzhJebCmQljQI+6E7r9mH2XixBiExG0ZljwwU8c HvpObmOy/rjibUeR2XUZ/QtRYoBVWEBBa8dvysr63m9t9Vrz5kqMDUMkdSloc/6i 8I4/ZQWZ0FHjfM/3KB+Ng0L5rXzmeD6zasyTW6QTOQ9y9Uk+7EsGo9dCB+ei2yWv 3/PP0rTurt5/KycUKKUxHnTLPeYZ/RM62FPruxjmGhIy9MVpltTc22dLeTWgIEpg Ztcc+tNAEkZ6WKNYMGiCUQkhh/LlZjgIWTqdq+GEFETzFVukekqjmqp32PUMZS8P apAGiPvvzPzpRzJnxbB0hDQqFMd6uNpMVIQfZwfLJ9Ja1qLXak3NItwg87doYazj tUYFofam73LIJ0CbIC2maIRInIP9+OfNVEZfZQTkCIZn4onb+MY8VKM5U3Z/41mt xI6ewxcaxoX3pJ7I+BP3A8yxj2+nbMMz36Q9J+cWwEUNUoNcRco= =1DpC -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
