Uploaded image for project: 'Sakai'
  1. Sakai
  2. SAK-39667

Add documentation and dynamic loading features to the ServerConfigurationService and component manager



    • Type: Task
    • Status: CLOSED
    • Priority: Major
    • Resolution: Duplicate
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: Kernel
    • Labels:



      Sakai's configuration service requires a restart in order for changes to be reflected. This causes scheduled downtimes and efficiencies when doing QA or development work at the recycling time becomes expensive. In addition, identifying configuration options within the system is difficult as properties as not always documented. Identifying configuration options often requires searching the code base.

      The config viewer was Sakai's first attempt to address the documentation problem. The issue is that the config viewer data requires folk to manually update the config view dataset. This data set does not include local extensions or contributed tool properties, as typically its only maintained against core Sakai properties.

      Sakai's configuration mechanism comes in two flavors. The ServerConfigurationService is aware of properties in local.properties, sakai.properties, or other custom properties files. In addition, Sakai's component manager uses configuration from Spring bean files. The component manager can be made aware of configuration in the properties files by using the propertyName@beanName syntax. The issue is that the ServerConfigurationService is not typically consulted for setting these values at runtime, instead these values are accessed directly by the component manager at startup time and loaded into the Spring lifecycle. Any solution that addresses the runtime setting of configuration or documentation needs to consider both these mechanisms.

      One major consideration concerning setting properties dynamically, is that consumers of properties in Sakai are free to consult the configuration data at initialization time, or in a reoccuring fashion. We can't force the entire code base to change its way of doing business.

      The logical solution is to extend the ServerConfigurationService to expose a registration method. This method would allow consumers to register properties, setting meta data about the property, as well as indicating whether or not the property can be changed dynamically. This way consumers are free to say my property can be changed at runtime, and then its up to the consumers to insure their code asks for the configuration data not as init time, but at consumption time, in order to provide that the data can change.

      Such a solution would allow the code base to slowly migrate properties that can be set dynamically, but not enforce such a change globally. One of the goals, would be to make it easy for people to move towards using dynamic loading of properties but not require it.

      It is expected that many properties will not be able to be dynamic modified, as that would reak havoc in a live system. For example, you wouldn't want to swap out a database connection, or an active socket connection. But for configuration that simply control UI components that expose or don't expose certain features, or timeouts, that sort of thing can be adjusted at runtime. This would be a very handy service. One of the cavets is that people either do not locally cache the config, or register a notifier to deal with the change. The proposal goes over some of the options in our first thinking about this.

      See the working proposal concept for more detail.

      Some discussion on list:

        Gliffy Diagrams





                jbush John Bush
                jbush John Bush
                1 Vote for this issue
                4 Start watching this issue



                    Git Integration