Am 2020-01-28 um 22:56 schrieb Mark Thomas:
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.
This is basically what I have assumed to be done. I will go with the
simplest approach first: context-only.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
