Re: Configuration, take2

["Ilya A. Volynets-Evenbakh" <ilya@total-knowledge.com>]

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