[Building Sakai] Proposal for dynamic loading of ServerConfigurationService and component manager primitives

[Duffy Gillman]

I think this complexity was the point of registering the properties. (Please
correct me if I'm wrong, John) One can already change these values at
runtime but there is no guarantee that the code that uses the properties
will re-read the values. But, if one is forced to register properties as
dynamic presumably inspection and changes to code can be done on a per-tool
or per-component basis. One registers a property as dynamic only when one is
sure that the code it supports is prepared to handle changes to the
property's value. For properties whose change would require
re-initialization of resources or whose change might cause inconsistency one
might opt not to make those properties dynamic.

My $.02...

   Duffy Gillman

   Sr. Software Engineer
   The rSmart Group, Inc.

On Fri, May 27, 2011 at 6:43 AM, Charles Hedrick <hedrick at rutgers.edu>wrote:

> I agree that this is a good idea. We *really* like to avoid restarts.
>
> I note that it's possible already to set properties dynamically. Here's a
> JSP that will look at and change a property. In many cases it works. The
> problem is that a lot of code reads properties when the service initializes.
> So doing this for real will involve changing code throughout Sakai so that
> it reads the configuration when it needs it. In many cases the change is
> easy. I'm sure there are a few where other decisions depend upon the
> configuration, and can't easily be changed midstream. (The reason for
> getClass().getMethod().invoke() is that getProperties is a private method.
> By using introspection you can access and use private attributes and methods
> from classes that shouldn't be able to access them.)
>
> <%@ page import="org.sakaiproject.component.api.ServerConfigurationService"
> %><%
> %><%@ page import="org.sakaiproject.component.cover.ComponentManager" %><%
> %><%@ page import="java.beans.Introspector" %><%
> %><%@ page import="java.util.Properties" %><%
>
> // example of how to change a config parameter without restarting
>
> ServerConfigurationService serv = (ServerConfigurationService)
> ComponentManager
>     .get(ServerConfigurationService.class);
>
> Properties props =
> (Properties)serv.getClass().getMethod("getProperties",null).invoke(serv,null);
>
> out.println(props.get("content.html.forcedownload"));
> //out.println(props.setProperty("content.html.forcedownload", "false"));
> //out.println(props.get("content.html.forcedownload"));
>
> %>
>
>
>
> On May 26, 2011, at 3:11 PM, John Bush wrote:
>
> > Please see https://jira.sakaiproject.org/browse/KNL-739 for more
> > detail.  I've started thinking about a way we could optionally let
> > folks register properties and allow for changes without a tomcat
> > restart. Its still a work in progress, welcome feedback and thoughts
> > on this.
> >
> > The working doc is here:
> >
> https://docs.google.com/a/rsmart.com/document/pub?id=1uR11MvnG4Ja60plH8QPpVJnsHklB6_mRZ6hcNSEXqYw
> >
> > --
> > John Bush
> > 602-490-0470
> > _______________________________________________
> > sakai-dev mailing list
> > sakai-dev at collab.sakaiproject.org
> > http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
> >
> > TO UNSUBSCRIBE: send email to
> sakai-dev-unsubscribe at collab.sakaiproject.org with a subject of
> "unsubscribe"
>
> _______________________________________________
> sakai-dev mailing list
> sakai-dev at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>
> TO UNSUBSCRIBE: send email to
> sakai-dev-unsubscribe at collab.sakaiproject.org with a subject of
> "unsubscribe"
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai-dev/attachments/20110527/bb5558d6/attachment.html