[Building Sakai] [cle-release-team] KNL-1063 status?

[Earle Nietzel]

Hi Neal,

I've implemented the features that were mentioned in the CLE-TEAM call from
2 weeks ago.

During testing a few additional issues were found and opened.

KNL-1130 <https://jira.sakaiproject.org/browse/KNL-1130>

SCS is setting defaulted=true for ConfigItems with empty default
values<https://jira.sakaiproject.org/browse/KNL-1130>
KNL-1132 <https://jira.sakaiproject.org/browse/KNL-1132>

NPE in ServerConfigurationService in getInt and
getBoolean<https://jira.sakaiproject.org/browse/KNL-1132>
KNL-1134 <https://jira.sakaiproject.org/browse/KNL-1134>

ServerConfigurationService changed listener is always being called using
getStrings <https://jira.sakaiproject.org/browse/KNL-1134>
KNL-1135 <https://jira.sakaiproject.org/browse/KNL-1135>

Mark config found in security.properties as
secured<https://jira.sakaiproject.org/browse/KNL-1135>
KNL-1137 <https://jira.sakaiproject.org/browse/KNL-1137>

ServerConfigurationService is not setting the appropriate type when only
setting a defaultValue <https://jira.sakaiproject.org/browse/KNL-1137>

KNL-1130, KNL-1132, KNL-1134 has been fixed (Thanks Aaron).

I've included a patch as a possible solution to KNL-1135
KNL-1137 still needs to be fixed

Earle



On Sat, Oct 26, 2013 at 10:24 AM, John Bush <jbush at anisakai.com> wrote:

> The benefit is that staring in Sakai 10, we be able to make changes to
> configuration without having to restart a tomcat, in places where the
> calling code supports it.  For things like turning on a new feature,
> or turning off a feature that is causing some issue, this is super
> handy, especially in a large cluster.
>
> There won't be a front end tool to make these changes right way, but
> even without that it would be easy for a sysadmin to make change in
> the db directly, or low effort for someone to make REST service that
> could do it to support tooling eventually.
>
> In addition, the benefit is that configuration/deployment wise, it
> opens up some new ways of managing deployments.  For example, when
> upgrading, or moving an instance from one node to another becomes less
> error prone because you won't necessarily have to rely on
> configuration on the file system getting lost, or messed up.  In a
> large cluster this is especially convenient.
>
> Yes its not a feature end users will really experience directly,
> except for maybe less downtime, or less config mistakes.  But it is a
> feature those managing Sakai instances might find really useful.
>
> On Fri, Oct 25, 2013 at 6:42 AM, Neal Caidin <neal.caidin at apereo.org>
> wrote:
> > Hi ,
> >
> > Can someone please bring me up to speed on ...
> >
> > https://jira.sakaiproject.org/browse/KNL-1063 ?
> >
> > It seems like this is making good technical progress, but I remember a
> > question at the 17 October 2013 CLE Release meeting asking what the
> primary
> > benefit of this change will be for the 2.10 release. Did this get
> resolved
> > to everyone’s satisfaction so that it can move forward?
> >
> > Thanks,
> > Neal
> >
> >
> >
> > Neal Caidin
> > Sakai CLE Community Coordinator
> > neal.caidin at apereo.org
> > Skype: nealkdin
> > Twitter: ncaidin
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > _______________________________________________
> > cle-release-team mailing list
> > cle-release-team at collab.sakaiproject.org
> > http://collab.sakaiproject.org/mailman/listinfo/cle-release-team
> >
>
>
>
> --
> John Bush
> 602-490-0470
>
> ** This message is neither private nor confidential in fact the US
> government is storing it in a warehouse located in Utah for future
> data mining use cases should they arise. **
> _______________________________________________
> cle-release-team mailing list
> cle-release-team at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/cle-release-team
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai-dev/attachments/20131031/11d96c88/attachment.html