On Wed, Jan 29, 2020 at 5:26 PM Christopher Schultz < ch...@christopherschultz.net> wrote:
> -----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. > I also added a FrameworkListener in the core package to be able to go crazy with listeners. It was based on the ThreadLocalLeakPreventionListener which was a better example than MapperListener (it works too, but it does too much and is too complex to be a good example). Rémy > > - -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 > >
