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

[Thomas Amsler]

If the tool/service stores the property locally, then you won't be
able to change them dynamically. Tools and services would have to be
adjusted to always get the property per access. We did that for all
the tools/services for which we needed dynamic property loading.
-- Thomas

On Fri, May 27, 2011 at 9:51 AM, Duffy Gillman <duffy at rsmart.com> wrote:
> 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"
>
>
> _______________________________________________
> 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"
>