Re: Configuration, take2

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

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