Hi Matt, This behavior is configured in container.js in the "gadgets.features" object. If you look for "osapi" and "osapi.services", you'll see some comments about this configuration and the behavior. features/container/service.js is where this configuration is used and where the osapi services are instantiated. As you've seen, Shindig introspects to find available services by default.
If I knew at one point why this behaves this way, I've since forgotten. There is a system.listMethods API[1] defined in the Core API Server spec that this might simply be re-using to discover the available services. I hope that helps. -Stanton [1] http://opensocial.github.io/spec/trunk/Core-API-Server.xml#System-Service-ListMethods On Tue, Aug 19, 2014 at 8:13 AM, Merrill, Matt <mmerr...@mitre.org> wrote: > Good morning, > > I’m hoping some shindig veterans can help shed some light into the reason > that Shindig makes HTTP rpc calls to itself as part of the gadget rendering > process. Why is this done as opposed to retrieving information via > internal Java method calls? We hare having lots of issues where this > approach seems to be causing a cascading failure when calls get hung up in > the HTTPFetcher class. > > Also, I’m curious what calls are made in this manner and how can they be > configured? I have seen retrieval of viewer data done this way, as well as > application data. > > I’ve looked for documentation on this topic before and have not seen any. > Any help is much appreciated. > > Thanks! > -Matt Merrill >
