[Building Sakai] How to find undocumented properties in code

John Bush john.bush at rsmart.com
Mon May 23 09:30:41 PDT 2011 

yeah, I'm going to try to articulate some ideas this week, I'll put them up
in confluence and share it around once I get to it.  Our 2.8 release is
coming out in a week, so I'm pretty bogged down with the right now.

On Mon, May 23, 2011 at 7:09 AM, Earle Nietzel <earle.nietzel at gmail.com>wrote:

> +1 for this John.
>
> I would be willing to help in this effort as well.
>
> Would it make sense to start a confluence page?
>
> Earle
>
> On Fri, May 20, 2011 at 2:07 PM, 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"
> >
>



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

More information about the sakai-dev mailing list