[Building Sakai] How to find undocumented properties in code

John Bush john.bush at rsmart.com
Fri May 20 11:31:36 PDT 2011 

Yeah, for sure.  I definitely don't want it to be a new service but
something we could bring into the existing service and use optionally. I'm
sure there is stuff that could be reused from what you guys did.

On Fri, May 20, 2011 at 11:21 AM, Thomas Amsler <tpamsler at ucdavis.edu>wrote:

> 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"
> >
>



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

More information about the sakai-dev mailing list