Re: Configuration, take2

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

Come to think of it - it may make sense - i.e. in large cluster,
where bunch of app servers share config...
Don't know.. Maybe it doesn't...

Alexey Parshin wrote:

> 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
> >