-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Mark,
On 1/28/20 4:56 PM, Mark Thomas wrote: > 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. Oh, that's interesting. - -chris -----BEGIN PGP SIGNATURE----- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl4xsi0ACgkQHPApP6U8 pFhXnxAAmrMtnIlzzsFEu1ihLXsogf7XuZ3hpOZH7VY90Zhn3p2aLvLcACCFvjOc +/ClAvddQbQtA/RVn65y1NLuTQeUtttlaeDAUWbh/iWcDo+wniNAlsPidesWHCAN kgxGDzOZyFH30HO16gJfb4dcWFTm/h15o0Ur7cL15Z4/NMGVZP9G3en9crH40qBW 7vSzbBm5j2wFM6jjsFd8lSqTeV+JK4NtiWXqb1nCkSZDJDzreJOpQcUjYoMaYWqw Ut5YLL35ukuph7rry/erfjM84BvT87U/mf1ZjLSs6YmZgbGrQ7/Yw95263j9Td0b bECMEkJnqBprDt/b5LPesMs48D3JTUdAluHTI0BzKa9Qsk8Ypsuy6dkB3A7oHgop 6I/Ry5LSZmkQt2HIQPody0TOiCHCYrdQMQtwgiyK5zOtl1v/L/sUKmw71K+wNwOh TjW+ZKaPNbZ7lwHDhgBG4cM2soycPge8euiyJZ1JHp4Tf7/7zUarnoohfKPUtgGP YWnXzcD99azoS5tohlFsZm+Gj3CYs46f01uQx0BqusC4YEUiYT3IYTyQqlGpSNs5 uCijLZZXLuwdzUWaFanOEKsmPKrgN13ZTCxvO67vPygOs3OSz5lO+UzEgbYu5SEg LN55Uqs1H/Le8n/+9PpZyETr8GEOPy1E9rvN0kTxbFpIlVKWd8k= =Vo/x -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
