[Building Sakai] How to find undocumented properties in code

Thomas Amsler tpamsler at ucdavis.edu
Fri May 20 11:21:22 PDT 2011 

John,

We might be able to reuse some of the DynamicConfigurationService that
we used to run at UC Davis. A couple of years ago, Tony and I talked
about integrating the ConfigViewer and the
DynamicConfigurationService. Just a thought ...

-- Thomas

On Fri, May 20, 2011 at 11:07 AM, John Bush <john.bush at rsmart.com> wrote:
> 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
>
> _______________________________________________
> 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"
>

More information about the sakai-dev mailing list