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

Aaron Zeckoski azeckoski at unicon.net
Thu Oct 31 08:17:40 PDT 2013


Definitely major improvements to this. I still think we need to possibly
address some comments from UM and most likely that means floating the way
it works out on the list for comment (especially around the loading of all
config items into the database even if it is not being used). Good progress
being made anyway.


On Thu, Oct 31, 2013 at 11:01 AM, Earle Nietzel <enietzel at anisakai.com>wrote:

> 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
>>
>
>
> _______________________________________________
> cle-release-team mailing list
> cle-release-team at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/cle-release-team
>
>


-- 
Aaron Zeckoski - Software Architect - http://tinyurl.com/azprofile
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai-dev/attachments/20131031/5a9a96b5/attachment.html 


More information about the sakai-dev mailing list