Re: Configuration, take2

[Alexey Parshin <alexeyp@gmail.com>]

Well, since we figured out - it would be one such object in the
memory, SQL implementation doesn't make sense anymore.

On 4/29/05, Ilya A. Volynets-Evenbakh <ilya@total-knowledge.com> wrote:
> Since it is two days after tomorrow already, I'm making executive-level
> desision ;-)
> 1. We'll have Configuration as "main" object. That is it'll create all
> application containers,
>     load/unload servlets, etc.
> 2. Configuration is going to be an abstract interface, that will be
> extended to provide
>     persistant storage interface
> 3. There will be semi-rigid structure for now
>     Global server params
>        Application
>           AppName (used as session cookie name)
>           SessionTimeout
>           Param
>           Param
>           ...
>           Servlet
>               Param
>               Param
>               ...
>           Servlet
>           ...
>        Application
>           AppName (used as session cookie name)
>           SessionTimeout
>           Param
>           Param
>           ...
>           Servlet
>               Param
>               Param
>               ...
>           Servlet
>           ...
>        ...
> 4. I'll write one implementation (probably similar to web.xml)
> 5. HSquirrel will write SQL-based implementation
> 
> Today is still not too late to object - tomorrow there will be too much
> code written ;-)
> 
> 
> Alexey Parshin wrote:
> 
> >.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
> >>
> >>
> >>
> >>
> >
> >
> >
> >
> 
> --
> Ilya A. Volynets-Evenbakh
> Total Knowledge. CTO
> http://www.total-knowledge.com
> 
> 


-- 
Alexey Parshin,

Senior DBA,
Tactical Telesolutions,
San Francisco