[Building Sakai] Proposal Server wide stats property was Re: [cle-release-team] Additional Sakai 10 property questions

[Matthew Jones]

Yea, that would be nice. I think in a perfect Sakai world we'd only have
them one way or another, but there's no easy road to getting rid of spring
properties. That would involve someone going in there and adding a sakai
style property in every place there is a spring property called. Something
that is near the as minor as priority gets.

Also, as far as sitestats goes, it kind of set a pattern for using spring
style properties as it has them all like that, all 50 or so, so this
property has been there awhile, along with the rest.
https://confluence.sakaiproject.org/display/STAT/Configuration+Options

The biggest problem with bean style properties is that it can bomb out
startup if there's a property that doesn't match as setter. (KNL-791) Seems
like we needed some kind of pre processor to figure out if the value of the
setter actually exists for every property before spring tries to go and set
it. And they are a little trickier to change in a running instance (for a
feature like KNL-1063), but are still possible.


On Wed, Jan 15, 2014 at 12:11 PM, Cris J Holdorph <holdorph at unicon.net>wrote:

> This is not a vote one way or another.  This is just a comment/question.
>
> In other places I thought it was recommended policy to not encourage use
> of the attribute at beanname method of setting properties.  Instead for
> properties that we really intended system administrators to set, that
> normal vanilla "propertyname" properties would be created instead.  Is
> this still the case?  If so, then should we instead be referring to a
> better property name for this setting instead of the form shown below?
>
> ---- Cris J H
>
> On 01/15/2014 09:55 AM, Neal Caidin wrote:
> > Hey,
> >
> > Let's make this official. Lazy consensus should work.
> >
> > Proposal:  Turn on
> > serverWideStatsEnabled at org.sakaiproject.sitestats.api.StatsManager by
> > default in Sakai 10 . Following standard process we would update the
> > default property to true in source code and document it in the
> > sakai.properties file.
> >
> > If you have an objection, please respond by close of business (your time
> > zone) , Friday, January 17, 2014.
> >
> > Cheers,
> > Neal
> >
> >
> >> Neal Caidin <mailto:neal.caidin at apereo.org>
> >> January 14, 2014 at 6:47 AM
> >> Right, sorry. My bad. That is the property I meant to reference.
> >>
> >>
> >> serverWideStatsEnabled at org.sakaiproject.sitestats.api.StatsManager
> >>
> >>
> >>
> >> Steve Swinsburg <mailto:steve.swinsburg at gmail.com>
> >> January 13, 2014 at 6:51 PM
> >> I was actually talking about server wide stats, not site presence.
> >>
> >>
> >> serverWideStatsEnabled at org.sakaiproject.sitestats.api.StatsManager
> >>
> >>
> >>
> >> Neal Caidin <mailto:neal.caidin at apereo.org>
> >> January 13, 2014 at 7:42 AM
> >> So that seems like two "votes" for
> >> enableSitePresences at org.sakaiproject.sitestats.api.StatsManager to be
> >> on by default. Any objections or concerns?
> >>
> >> -- Neal
> >>
> >>
> >>
> >> Steve Swinsburg <mailto:steve.swinsburg at gmail.com>
> >> January 12, 2014 at 8:26 PM
> >>
> >> Turn server wide stats on, it's a useful feature that is often
> overlooked.
> >>
> >> Neal Caidin <mailto:neal.caidin at apereo.org>
> >> January 10, 2014 at 10:17 AM
> >> Hi All,
> >>
> >> By default, we are now turning on features by default [a]. However, in
> >> QA testing we ran into a few properties that are not turned on by
> >> default and prevented us from verifying some Jiras.
> >>
> >> 1) Proposal: Turn on ical.experimental to true by default, and change
> >> the name to calendar.ical.enabled ?  This seemed to be the sense of
> >> folks attending the Sakai release team meeting. It appears to have
> >> been in experimental status for about 5 years [b]
> >>
> >> 2) Keep
> >> enableSitePresences at org.sakaiproject.sitestats.api.StatsManager off by
> >> default? Turning it on would also require display.users.present=true
> >> [c].  There were mixed comments about whether to turn this on by
> >> default. The concern raised is that this has potential performance and
> >> security issues, which based on our criteria would mean that this
> >> should stay off by default.
> >>
> >> 3) serverWideStatsEnabled at org.sakaiproject.sitestats.api.StatsManager
> >> keep default off?   Couldn't find much documentation on this one [d]
> >>
> >>
> >>
> >> [a] Decision for Properties : "We plan on turning on all new features
> >> for Sakai 10 in source code, by default, except for features with
> >> performance or security concerns, or settings which are too ambiguous
> >> to guess at a standard need across institutions."
> >>
> >> [b] ical.experimental -
> >> https://confluence.sakaiproject.org/display/SCHED/Home?src=search
> >>
> >> [c] enableSitePresences at org.sakaiproject.sitestats.api.StatsManager -
> >>
> https://confluence.sakaiproject.org/display/STAT/Configuration+Options?src=search
> >>
> >>
> >> [d] serverWideStatsEnabled at org.sakaiproject.sitestats.api.StatsManager
> >> - https://jira.sakaiproject.org/browse/STAT-61  and a comment on
> >>
> https://confluence.sakaiproject.org/display/STAT/Configuration+Options?focusedCommentId=68162034#comment-68162034&src=search
> >>
> >>
> >>
> >> Thanks,
> >> Neal
> >>
> >
> > --
> > Neal Caidin
> > Sakai Community Coordinator
> > Apereo Foundation
> > neal.caidin at apereo.org
> > Skype me! (but let me know in advance for the first interaction) -
> nealkdin
> >
> >
> >
> > _______________________________________________
> > 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/20140115/3ec37b02/attachment.html