Re: Configuration, take2

[Alexey Parshin <alexeyp@gmail.com>]

.zZz. :)

Let's talk tomorrow..

On 4/26/05, Ilya A. Volynets-Evenbakh <ilya@total-knowledge.com> wrote:
> After even more thought, there is yet another question:
> who will monitor config changes, and who will trigger reload of relevant
> parts?
> i.e. we could make ServerConfigElement class, that provides
> registerChangeListener
> interface, and have all interested parties (like RequestDispatcher,
> ServletContainer etc.)
> register listeners and reload servlet on config change.
> Or we could have ServerConfig class actually be the one that *creates*
> all the objects,
> and feeds them to RequestDispatcher (i.e. through addServlet function).
> Then it would
> be ServerConfig implementer's responsibility to make sure all relevant
> servlets are reloaded
> on configuration change.
> 
> Can someone think of real-life scenarios? I'm too sleeppy right now ;-)
> 
>     Ilya.
> 
> Ilya A. Volynets-Evenbakh wrote:
> 
> >Wait wait... Why are we even talking about "changing". Generally I presume
> >that if config is changed, it is changed by admin, and then whole domain
> >that
> >change affected gets reloaded. I.E. if it was servlet-specific param,
> >servlet is reloaded
> >and if app-level, then all servlets in that app... In case of Java-based
> >app servers,
> >whole app is always reloaded (and in case you change one of server
> >config files,
> >it's your job as admin to make sure server finds out about that).
> >
> >In that light, it makes no sense to keep config itself (as in "XML DOM")
> >in memory. Instead there
> >are certain objects that get created as a result, and they exist as long
> >as their domain exists.
> >i.e. right now I only have one ServletContext - it's just a static
> >variable that is initialized on startup.
> >However, when we create whole "Application" support, there will be
> >multiple contexts - one per app.
> >App-level parameters will be kept there. Then there is ServletContainer
> >object - these can keep per-servlet
> >params. etc.
> >
> >Alexey Parshin wrote:
> >
> >
> >
> >>I'm not that concerned about enforcing yet. However the speed and ease
> >>of use for the 1 is the best. We keep everything in memory, we save
> >>changes from time to time. Every changed option group can be
> >>validated, and we can always define the validation routine.
> >>
> >>
> >>
> 
> --
> Ilya A. Volynets-Evenbakh
> Total Knowledge. CTO
> http://www.total-knowledge.com
> 
> 


-- 
Alexey Parshin,

Senior DBA,
Tactical Telesolutions,
San Francisco