[Building Sakai] How to find undocumented properties in code

Fri May 20 11:07:07 PDT 2011

I actually am going to propose something for 2.9, I don't have the idea
fully jelled yet, but I think it would help to alleviate some of this, and
the bigger issue of having to restart Sakai to push out changes.

What if, the SakaiConfigurationService had a registration component to it.
 You could register a property and document what it used for, and whether or
not it can be dynamic reloaded.

Then components and tool developers could start migrating code to use this
(it wouldn't be required).  So as people sort through how they handle
properties, they can refactor to make there code support dynamic loading,
and at least document things.

I think probably we could even support the bean at type properties by plugging
into the Spring lifecycle, and maybe some fancy aop or something that can
handle rechecking for changed values in an inobstrusive and performance
friendly way.

I'm going to write up some more details and float it out there, but testing
the waters on support for such an idea.

You could then see how an admin tool could sit on top of this to allow you
to, further document stuff and change values.  Maybe we just build that into
the config viewer, it would turn into the config manager I guess.

On Thu, May 19, 2011 at 9:41 AM, Matthew Jones <jonespm at umich.edu> wrote:

> Tracking down properties is for sure a pain and one that should be
> improved, but it takes a decent amount of time to get a *great* solution
> going.
>
> A similar script to Brian's is in the config viewer project under utils.
> [1] (simplePropertyFind.sh) There are also extractors for bean style
> properties like the one John mentioned (generate_bean_list.sh). I haven't
> ran these in awhile, and most of them were ones that Tony Atkins wrote.
>
> I was also thinking of adding some logging to ServerConfigurationService so
> that whenever a property was set it would put out a debug message which
> could be logged by someone by turning up to that level to make it easier to
> track down what properties are set to. There were also some changes I'd
> talked about at the  Denver conference about things that would be nice for
> config viewer, but I haven't had time to do them yet. If you want to talk
> about it off list or at the LA conference I'll be there! I'm still
> interested in this topic. ;)
>
> Config viewer at least *works* with newer versions of Sakai, but the
> properties it knows about haven't been updated since 2.6. ;(
>
> Task for 2.8 properties - https://jira.sakaiproject.org/browse/CNFV-20
> Task for 2.7 properties - https://jira.sakaiproject.org/browse/CNFV-17
>
> [1] https://source.sakaiproject.org/contrib/config-viewer/trunk/utils/
>
>
> On Thu, May 19, 2011 at 11:47 AM, Stephen Jaegle <sjaegle at gmail.com>wrote:
>
>>
>> Thank you both. In another communication, someone also pointed out that
>> the
>> otherwise outdated Sakai Config Viewer project may have useful methodology
>> in it as well.
>>
>> --Steve
>>
>>
>> Bryan Holladay wrote:
>> >
>> > I've done some work with this for the 2.8 release and here is a helpful
>> > bash script I ran to find all the properties (checked out the source
>> code
>> > and searched through it):
>> >
>> > Script
>> >
>> > #!/bin/sh
>> >
>> > grep -ilR "import
>> > org.sakaiproject.component.api.ServerConfigurationService" . | grep
>> java$
>> > > filesListTmp.txt
>> > grep -ilR "import
>> > org.sakaiproject.component.cover.ServerConfigurationService" . | grep
>> > java$ >> filesListTmp.txt
>> >
>> > echo > sakaiProps.txt
>> > for line in `cat filesListTmp.txt`
>> > do
>> >     grep -iR -A 1 "confi.*Servic.*.getString" $line >> sakaiProps.txt
>> >         grep -iR -A 1 "confi.*Servic.*.getBoolean" $line >>
>> sakaiProps.txt
>> >         grep -iR -A 1 "confi.*Servic.*.getInt" $line >> sakaiProps.txt
>> > done
>> >
>> >
>> >
>> >
>> > Instructions
>> >
>> > Run this script in the root folder for each source you want to compare.
>> > Creates two files:
>> >
>> > filesListTmp.txt
>> > This is a list of all the java files that have sakai properties
>> >
>> > sakaiProps.txt
>> > This is the code that shows the sakai properties.  Use this file to
>> > compare with the other source to find differences.
>> >
>> >
>> >
>> > -Bryan
>> >
>> >
>> > On May 18, 2011, at 7:05 PM, John Bush wrote:
>> >
>> >> This is not an easy problem to solve.  yes you can find some properties
>> >> by calls to ServerConfigurationService, but there is a whole other
>> >> mechanism that can also be used that bypasses that.
>> >>
>> >> Sakai properties can also be spring injected using this syntax:
>> >>
>> >> property at some.bean.name
>> >>
>> >> so basically every component.xml or other Spring file exposes a lot of
>> >> other properties.  You can't even get at these by looking at just the
>> >> spring files, because the real list would be looking at all the setters
>> >> in all of the beans prescribed by the spring config.
>> >>
>> >> Technically, I guess either some spring lifecycle component, or aop,
>> >> bytecode injection method could probably be created to create a full
>> >> list.
>> >>
>> >> On Wed, May 18, 2011 at 3:36 PM, Stephen Jaegle <sjaegle at gmail.com>
>> >> wrote:
>> >>
>> >> Hi:
>> >>
>> >> Some time ago I found the msg.displayEid property through considerable
>> >> searching effort; a web search
>> >> (http://www.google.com/search?q=%22msg.displayEid%22) reveals there
>> are
>> >> few
>> >> references to it anywhere as of this writing. Aside from searching
>> online
>> >> documentation such as the properties list on confluence and sample or
>> >> default properties files, from which relatively undocumented properties
>> >> such
>> >> as msg.displayEid are absent (see the search results url above), what
>> >> algorithms for finding otherwise undocumented properties in Sakai
>> source
>> >> code are better and more complete than simply refining a grep for
>> >> ServerConfigurationService.get? Do properties generally get passed in
>> >> ways
>> >> other than using ServerConfigurationService?
>> >>
>> >> Thanks,
>> >>
>> >> Steve
>> >> --
>> >> View this message in context:
>> >>
>> http://old.nabble.com/How-to-find-undocumented-properties-in-code-tp31651493p31651493.html
>> >
>> >> John Bush
>> >
>> >
>>
>> --
>> View this message in context:
>> http://old.nabble.com/Re%3A--Building-Sakai--How-to-find-undocumented-properties-in-code-tp31651656p31655704.html
>> Sent from the Sakai - Development mailing list archive at Nabble.com.
>>
>> _______________________________________________
>> 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"
>

-- 
John Bush
602-490-0470
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai-dev/attachments/20110520/875698f5/attachment.html 