[Deploying Sakai] [Building Sakai] What do you think about Config Viewer?

[Anthony Whyte]

Looks like you might consider leveraging the Apache commons  
configuration project which provides a generic interface for reading  
configuration info.  It would allow one to mix configurations from a  
heterogeneous collection of configuration objects, providing, I would  
think, the flexibility to tackle the problem outlined below at a  
measured pace as opposed to a massive refactoring over a narrow time  
frame of all system/tool property handling.

http://commons.apache.org/configuration/

Cheers,

Anth


On Jan 7, 2010, at 2:39 PM, Matthew Jones wrote:

> I echo most of what Noah has said, mostly because I've spent quite a  
> bit of time discussing with him and Anthony on this issue. I'm very  
> interested in easier configuration and annoyed with the current  
> state of sakai configuration. There are some properties that I only  
> discover by searching through JIRA's or even worse, through source  
> code. This is not something that the average or even above average  
> user is likely to do. There are many advanced features of tools  
> people don't even know about.
>
> I'm lucky because I sit right next to the developers of many of the  
> sakai tools and also go pay more attention to the jiras so if I have  
> questions I *usually* can just ask them. ;)
>
> The effort that Tony put into assembling the original config viewer,  
> looking at it was pretty impressive. There's a properties file  
> containing 429 properties that list all of the current known  
> configuration variables available at the time of release. Yes, at  
> *least* 429 settings that you can alter in sakai.properties.
>
> There are a few steps on the top of my head to getting this under  
> control because maintaining this property file is not something that  
> anyone can do for the future, though the structure is nice.
>
> Here's what I'd propose (I'll flesh this out a little more),  
> comments obviously welcome, I'm just throwing this out there so we  
> have some discussion?
>
> Once this is done, making a system for viewing AND runtime cluster- 
> wide modification of properties for sakai 2 (and most likely 3 if it  
> uses a similar system) will be easier to handle.
>
> The people that know the properties best are the individual tool  
> developers. Most of this work can be accomplished relatively quickly  
> if undertaken by multiple people that know the tools, and it's  
> mostly just some code cleanup
>
> 1) Get the properties names associated with the tools they modify.
>  - *Nearly* tools have to go through registration and have an id  
> (sakai.configviewer). For these tools the property should be
>   <toolid>.propertyname (i.e. sakai.configviewer.enabled)
> - The tools that use beans are named fine and can stay as they are
> (allowGroupAssignments at org.sakaiproject.assignment.api.AssignmentService 
> )
> - For non tools (Like portal?) We'll have to come up with some base  
> names for these.
>
> 2) Either create a new properties files deployed with the tool  
> (webapps/<tool package>/tool.properties) that has a properties  
> definition like (3). Either that or possibly add it as XML to the  
> tools.xml registration for the tool. This seems like it would be  
> easier than adding new code to take care of it. This way the tool  
> can be responsible for defining the properties it has and each  
> maintainer can keep this file up-to-date
>
> 3) Note the properties files are defined in configViewer like this.
> properties.name.1=affiliatesubjects
> properties.type.1=getStrings
> properties.tool.1=site-manage
> properties.version.1=2.2,2.3,2.4,2.5,2.6
> properties.configurable.1=N
> properties.rule.1=none
> properties.qualifier.1=affiliate subjects
> properties.nullable.1=N
>
> -- Note: There will still the same properties types. Integer(s)/ 
> Boolean(s)/String(s).
>
> In XML it would of course look like
> <properties>
> <property>
> <name>affiliatessubjects</name>
> . . .
> </property>
> </properties>
>
> . . . Maybe this is better?
>
> I can do the initial work and split this large properties files into  
> individual project tool files, so nobody would have to do anything  
> yet.
>
> Anyway, I just wanted to throw that out there to let people know  
> that we *are* thinking about it, but it's not the highest priority.
>
> -Matthew
>
> On Thu, Jan 7, 2010 at 1:14 PM, Noah Botimer <botimer at umich.edu>  
> wrote:
> I'll let others be pragmatic. What I'd be most interested in for the  
> 2.8 timeline is an honest look at our configuration mechanism. I  
> would consider improving it and just reflecting on what it does well  
> and less well (for future) to be valuable outputs.
>
> Some have heard my complaints about the "just make another property"  
> practice and some the other configuration friction. Let me try to  
> phrase this as a positive-looking request...
>
> I would like to see an easy way to establish and document the  
> existence of possible settings in one pass, with valid data types/ 
> ranges indicated. I would like there to be some categorization (if  
> only one level for "section"/tool/whatever). I would like to see  
> differentiation between "system-level" things like hostname or other  
> nuts&bolts startup parameters from things that deal with the runtime  
> application. I would like to see a live, consolidated control panel,  
> maybe a la Webmin. I would like there to be effective cluster-wide  
> propagation of these runtime settings.
>
> So, while I will not disregard enthusiasm for maintaining a good  
> tool, I ask that we pause and consider what it means to maintain a  
> community-evolved enterprise application on campus on a daily basis.  
> Much of this conversation parlays into understanding how we want our  
> world to be in the next round (Sakai 3).
>
> Thanks,
> -Noah
>
>
> On Jan 7, 2010, at 12:25 PM, Jean-Francois Leveque wrote:
>
> Hi all,
>
> It's been 12 months since Tony Atkins released the last tag for Config
> Viewer. I really like this tool and I've heard others also do.
>
> Matthew Jones has contributed useful fixes in trunk and in a  
> umich_2.6.x
> branch.
>
> I think we can do better as a community if we want to be able to use
> this tool in the future.
>
> Are you using it in production?
>
> Do you want it to be maintained?
>
> Would you like it to be part of Sakai 2.8.0?
>
> Would you like to help?
>
> My answer to all these questions is yes. What do you think?
>
> Cheers,
>
> Jean-François Lévêque
> _______________________________________________
> 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"
>
>
>
>
> _______________________________________________
> production mailing list
> production at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/production
>
> TO UNSUBSCRIBE: send email to production-unsubscribe at collab.sakaiproject.org 
>  with a subject of "unsubscribe"

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/production/attachments/20100107/c4a1cdd9/attachment.html