It is confusing. You shouldn't have to pass in a config, my latest response explains the bug here.
The problem before is that '/rpc' was always registered. Always. It just never stuck because the service had already been registered. My change changed that so it could be overridden by the config (necessary for cross domain container loading). Now /rpc is taking hold, overriding the previously set service. I didn't see this because we typically do not deploy on non-root contexts. So the workaround is to specify the path in the config, but I think there should be a JIRA for this so that we don't hardcode the default '/rpc' but instead somehow use the value that was used to register the service first. Or not register the service at all if the path/host has not been specified in the config. From: daviesd <[email protected]> To: <[email protected]>, Date: 09/21/2011 04:07 PM Subject: Re: Metadata Am I just confused here? Was I always suppose to be passing a config object to the container and I just lucked out because /rpc was the "winner"? When you run as non-root are you required to specify these values? Maybe it's just my misunderstanding. doug On 9/21/11 3:58 PM, "daviesd" <[email protected]> wrote: > The context root is correct (/opensocial). The request for metadata still > tries to use /rpc. If I change it to /opensocail/rpc (by passing it in > config) it works fine. > > new osapi.container.Container({apiPath:'/opensocial/rpc'}); > > This tells me the method that got registered was the /opensocial/rpc one. > > doug > > > On 9/21/11 3:32 PM, "Stanton Sievers" <[email protected]> wrote: > >> That sounds plausible to me. It might be worth setting a breakpoint in >> org.apache.shindig.config.JsonContainerConfigLoader.addHostAndPortToDefaultCo>> n >> tainer(List<Map<String, >> Object>>, String, String, String) and seeing what the Context Root value >> is being set to. >> >> -Stanton >> >> >> >> From: daviesd <[email protected]> >> To: <[email protected]>, >> Date: 09/21/2011 15:27 >> Subject: Re: Metadata >> >> >> >> Dan, >> >> I think what might be happening is that the osapi method use to register >> as >> /rpc and then the duplicate /opensocial/rpc came along and was "skipped" >> (at >> least that was I see in my console). Now that you changed it to last one >> wins it now registers as /opensocial/rpc but the problem is the config >> value >> still thinks it's /rpc. I'm not sure the config value EVER used the >> correct >> value even though it's in container.js as >> >> //%host%${CONTEXT_ROOT}/rpc >> >> So probably the duplicate calls were hiding the fact that the config value >> was never being used. Sound plausible? >> >> doug >> >> >> On 9/21/11 3:05 PM, "daviesd" <[email protected]> wrote: >> >>> Dan, >>> >>> I mentioned in an earlier thread that apiPath is coming back /rpc (for >>> non-root webcontext). However... It does this in the earlier build too >> and it >>> WORKS. So I'm confused. I'm gonna do some more debugging because I >> really >>> need another fix Stanton just resolved (the encodeToken one), so I'm >> gonna >>> need to pull trunk artifacts again at some point. >>> >>> Thanks, >>> doug >>> >>> >>> On 9/21/11 1:45 PM, "Dan Dumont" <[email protected]> wrote: >>> >>>> Sorry coming late to the thread, but I was the one working on the code >>>> change that seems to have broken you. >>>> >>>> The change was necessary because when loading the container >> cross-domain, >>>> we needed to be able to override some of the endpoints. >>>> var config = {}; >>>> config[osapi.container.ServiceConfig.API_PATH] = '/rpc'; >>>> config[osapi.container.ServiceConfig.API_HOST] = >> window.location.protocol >>>> + '//' + window.location.hostname + locationOfProxyToShindig(); >>>> config[osapi.container.ContainerConfig.RENDER_DEBUG] = '1'; // TODO: >> for >>>> now >>>> var cc = this.statics.cc = new osapi.container.Container(config); >>>> >>>> Can you check to see that service.js is pulling the correct value from >>>> your config here: >>>> /** >>>> * @type {string} >>>> * @private >>>> */ >>>> this.apiPath_ = String(osapi.container.util.getSafeJsonValue(config, >>>> osapi.container.ServiceConfig.API_PATH, '/rpc')); >>>> >>>> It gets used later in this call: >>>> /** >>>> * Initialize OSAPI endpoint methods/interfaces. >>>> */ >>>> osapi.container.Service.prototype.registerOsapiServices = function() { >>>> var endPoint = this.apiHost_ + this.apiPath_; >>>> >>>> >>>> >>>> >>>> From: daviesd <[email protected]> >>>> To: <[email protected]>, >>>> Date: 09/21/2011 12:54 PM >>>> Subject: Re: Metadata >>>> >>>> >>>> >>>> Stanton (and Ryan), >>>> >>>> I found the issue. It was the 1171551 commit on Friday. Change >>>> osapi._registerMethods to 'last one in wins'. >>>> >>>> If I roll back to the older osapi.js things work. >>>> >>>> Ideas? Again, this is only an issue when running as non-root. >>>> >>>> FYI though I did log the apiPath in both the old and new and it >> reported >>>> /rpc. So my guess is that the metadata request is ALWAYS made to /rpc, >>>> but >>>> with this change the /rpc method was not registered, only the >>>> /opensocial/rpc. So maybe the wrong config value is being used. >> Confused. >>>> >>>> doug >>>> >>>> >>>> >>>> On 9/21/11 8:12 AM, "Stanton Sievers" <[email protected]> wrote: >>>> >>>>> Hi Doug, >>>>> >>>>> Can you set a breakpoint on >>>>> osapi.container.Service.prototype.registerOsapiServices and see what >> the >>>>> values of apiHost_ and apiPath_ are? It is in this function that the >>>>> endpoints for metadata are registered and that looks like where this >> is >>>>> getting off track. From there you can backtrack and check the config >>>> that >>>>> comes into osapi.container.Service, as it should be defining the >> values >>>> of >>>>> apiHost_ and apiPath_ >>>>> >>>>> -Stanton >>>>> >>>>> >>>>> >>>>> From: daviesd <[email protected]> >>>>> To: <[email protected]>, >>>>> Date: 09/20/2011 18:14 >>>>> Subject: Re: Metadata >>>>> >>>>> >>>>> >>>>> I've been able to reproduce the metadata call failing on non-root web >>>>> contexts. Here's the best way to demonstrate the issue. >>>>> >>>>> Modify container/sample1.html to this >>>>> >>>>> <html> >>>>> <body onload="init();"> >>>>> <div id="gadget-wrapper"></div> >>>>> </body> >>>>> </html> >>>>> >>>>> <script type='text/javascript' >>>>> >>>> >> src='/gadgets/js/container:rpc.js?c=1&debug=1&nocache=1&container=default'>< >>>>> /script> >>>>> >>>>> <script type="text/javascript"> >>>>> >>>>> function init() { >>>>> >>>>> var gadgetXml = >> 'http://www.labpixies.com/campaigns/todo/todo.xml'; >>>>> var container = new osapi.container.Container({}); >>>>> var gadgetSite = container.newGadgetSite( >>>>> document.getElementById('gadget-wrapper') ); >>>>> container.navigateGadget( gadgetSite, gadgetXml, [], { view: >> 'home' >>>> } >>>>> ); >>>>> } >>>>> >>>>> </script> >>>>> >>>>> Startup shindig (mvn -Prun) and hit >>>>> >>>>> http://localhost:8080/container/sample1.html >>>>> >>>>> Gadget renders just fine. >>>>> >>>>> (clear your browser cache) >>>>> >>>>> Now switch the contextPath. Modify contextPath in root pom.xml to >>>>> >>>>> <contextPath>/opensocial</contextPath> >>>>> >>>>> And modify this line in sample1.html >>>>> >>>>> <script type='text/javascript' >>>>> >>>> >> src='/opensocial/gadgets/js/container:rpc.js?c=1&debug=1&nocache=1&container >>>>> =default'></script> >>>>> >>>>> Now restart (mvn -Prun) and hit the sample1 page again. >>>>> >>>>> http://localhost:8080/opensocial/container/sample1.html >>>>> >>>>> You'll now see a 404 failure on the metadata request >>>>> >>>>> http://localhost:8080/rpc?st=-1%3A-1%3A*%3A*%3A*%3A0%3Adefault >>>>> >>>>> >>>> >> [{"method":"gadgets.metadata","id":"gadgets.metadata","params":{"container": >>>>> "default","ids":["http://www.google.com/ig/modules/horoscope.xml >>>>> "],"fields": >>>>> >>>> >> ["iframeUrl","modulePrefs.*","needsTokenRefresh","userPrefs.*","views.prefer >>>>> >>>> >> redHeight","views.preferredWidth","expireTimeMs","responseTimeMs"],"language >>>>> ":"en","country":"US","userId":"@viewer","groupId":"@self"}}] >>>>> >>>>> (I'm not sure why I was seeing the 400 error, it might have been the >>>>> wrapper >>>>> I had around the call). >>>>> >>>>> At any rate... Does this seem broken? If I go back to the 9/13 >> release >>>> ( >>>>> r1170371) this same scenario works. So some recent change has >> modified >>>>> the >>>>> behavior. >>>>> >>>>> Doug >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On 9/20/11 12:51 PM, "daviesd" <[email protected]> wrote: >>>>> >>>>>> Yes. This was working until sometime late last week. We pull the >>>>> shindig >>>>>> artifacts and assemble our own war file. >>>>>> >>>>>> doug >>>>>> >>>>>> >>>>>> On 9/20/11 12:14 PM, "Henry Saputra" <[email protected]> wrote: >>>>>> >>>>>>> Are you trying to deploy Shindig as non root app? >>>>>>> >>>>>>> - Henry >>>>>>> >>>>>>> 2011/9/20 daviesd <[email protected]>: >>>>>>>> I rolled back to the 3.0.0-20110913.224653 snapshot and my stuff is >>>>> working >>>>>>>> again. ?So I'm still suspecting something checked in last Thurs or >>>> Fri >>>>> is >>>>>>>> causing us problems. ?As time permits I'll try and track this down, >>>>> but >>>>>>>> maybe something will jump out at someone. ?Again it appears that >> the >>>>>>>> metadata call is not honoring the CONTEXT_ROOT. >>>>>>>> >>>>>>>> doug >>>>>>>> >>>>>>>> >>>>>>>> On 9/20/11 10:02 AM, "daviesd" <[email protected]> wrote: >>>>>>>> >>>>>>>>> What's weird is it seem to be trying to use /rpc and not >>>>>>>>> ${CONTEXT_ROOT}/rpc >>>>>>>>> for the metadata request. ?We run our shindig as non-root. >>>>>>>>> >>>>>>>>> We're gonna try an older snapshot and see if it works. >>>>>>>>> >>>>>>>>> doug >>>>>>>>> >>>>>>>>> >>>>>>>>> On 9/19/11 8:26 PM, "Henry Saputra" <[email protected]> >> wrote: >>>>>>>>> >>>>>>>>>> Hi Doug, >>>>>>>>>> >>>>>>>>>> Just pull latest from trunk and I did curl for gadget metadata >> and >>>>> got >>>>>>>>>> this response: >>>>>>>>>> >>>>>>>>>> curl -H "Content-Type: application/json" --data-binary ' >>>>>>>>>> >>>>>>>> >>>>> >>>> >> [{"method":"gadgets.metadata","id":"gadgets.metadata","params":{"container":> >>>>>>> >>>>> >>>>> " >>>>>>>>>> >>>>>>>> d >>>>>>>>>> >>>>>>>> >>>>> efault","ids":["http://www.google.com/ig/modules/horoscope.xml >>>>> "],"fields":[">>> >>>>> i >>>>>>>>>> >>>>>>>> f >>>>>>>>>> >>>>>>>> >>>>> >>>> >> rameUrl","modulePrefs.*","needsTokenRefresh","userPrefs.*","views.preferredH> >>>>>>> >>>>> >>>>> e >>>>>>>>>> >>>>>>>> i >>>>>>>>>> >>>>>>>> >>>>> >>>> >> ght","views.preferredWidth","expireTimeMs","responseTimeMs"],"language":"en"> >>>>>>> >>>>> >>>>> , >>>>>>>>>> >>>>>>>> " >>>>>>>>>> country":"US","userId":"@viewer","groupId":"@self"}}]' >>>>>>>>>> http://localhost:8080/rpc >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>> [{"id":"gadgets.metadata","result":{" >>>>> http://www.google.com/ig/modules/horosc>>> >>>>> o >>>>>>>>>> >>>>>>>> p >>>>>>>>>> >>>>>>>> >>>>> >>>> >> e.xml":{"userPrefs":{"day":{"dataType":"HIDDEN","orderedEnumValues":[],"name> >>>>>>> >>>>> >>>>> " >>>>>>>>>> >>>>>>>> : >>>>>>>>>> >>>>>>>> >>>>> >>>> >> "day","required":false,"displayName":"day","defaultValue":""},"month":{"data> >>>>>>> >>>>> >>>>> T >>>>>>>>>> >>>>>>>> y >>>>>>>>>> >>>>>>>> >>>>> >>>> >> pe":"HIDDEN","orderedEnumValues":[],"name":"month","required":false,"display> >>>>>>> >>>>> >>>>> N >>>>>>>>>> >>>>>>>> a >>>>>>>>>> >>>>>>>> >>>>> >>>> >> me":"month","defaultValue":""},"selectedTab":{"dataType":"HIDDEN","orderedEn> >>>>>>> >>>>> >>>>> u >>>>>>>>>> >>>>>>>> m >>>>>>>>>> >>>>>>>> >>>>> >>>> >> Values":[],"name":"selectedTab","required":false,"displayName":"selectedTab"> >>>>>>> >>>>> >>>>> , >>>>>>>>>> >>>>>>>> " >>>>>>>>>> >>>>>>>> >>>>> >>>> >> defaultValue":"0"},"uid":{"dataType":"HIDDEN","orderedEnumValues":[],"name":> >>>>>>> >>>>> >>>>> " >>>>>>>>>> >>>>>>>> u >>>>>>>>>> >>>>>>>> >>>>> >>>> >> id","required":false,"displayName":"uid","defaultValue":""},"selectedFriend"> >>>>>>> >>>>> >>>>> : >>>>>>>>>> >>>>>>>> { >>>>>>>>>> >>>>>>>> >>>>> >>>> >> "dataType":"HIDDEN","orderedEnumValues":[],"name":"selectedFriend","required> >>>>>>> >>>>> >>>>> " >>>>>>>>>> >>>>>>>> : >>>>>>>>>> >>>>>>>> >>>>> >>>> >> false,"displayName":"selectedFriend","defaultValue":"0"}},"needsTokenRefresh> >>>>>>> >>>>> >>>>> " >>>>>>>>>> >>>>>>>> : >>>>>>>>>> >>>>>>>> >>>>> >>>> >> false,"expireTimeMs":1316478556657,"views":{"home":{"preferredHeight":0,"qui> >>>>>>> >>>>> >>>>> r >>>>>>>>>> >>>>>>>> k >>>>>>>>>> >>>>>>>> >>>>> >>>> >> s":true,"preferredWidth":0},"default":{"preferredHeight":0,"quirks":true,"pr> >>>>>>> >>>>> >>>>> e >>>>>>>>>> >>>>>>>> f >>>>>>>>>> >>>>>>>> >>>>> >>>> >> erredWidth":0},"preview":{"preferredHeight":0,"quirks":true,"preferredWidth"> >>>>>>> >>>>> >>>>> : >>>>>>>>>> >>>>>>>> 0 >>>>>>>>>> >>>>>>>> >>>>> >>>> >> },"canvas":{"preferredHeight":0,"quirks":true,"preferredWidth":0}},"modulePr> >>>>>>> >>>>> >>>>> e >>>>>>>>>> >>>>>>>> f >>>>>>>>>> >>>>>>>> >>>>> s":{"screenshot":" >>>>> http://www.gstatic.com/ig/modules/horoscope/horoscope.cach>>> >>>>> e >>>>>>>>>> >>>>>>>> . >>>>>>>>>> >>>>>>>> >>>>> >>>> >> png","authorEmail":"[email protected]> >>>>>>> >>>>> >>>>> o >>>>>>>>>> >>>>>>>> m >>>>>>>>>> >>>>>>>> >>>>> >>>> >> ","width":0,"authorLink":"","links":{},"scaling":false,"author":"csindia-gad> >>>>>>> >>>>> >>>>> g >>>>>>>>>> >>>>>>>> e >>>>>>>>>> ts","directoryTitle":"Daily >>>>>>>>>> Horoscopes","title":"Today's >>>>>>>>>> >>>>>>>> >>>>> Horoscope","height":200,"thumbnail":" >>>>> http://www.gstatic.com/ig/modules/horos>>> >>>>> c >>>>>>>>>> >>>>>>>> o >>>>>>>>>> >>>>>>>> >>>>> pe/horoscope-thm.cache.png","titleUrl":" http://www.dailyhoroscope.com/ >>>>> ","scr>>> >>>>> o >>>>>>>>>> >>>>>>>> l >>>>>>>>>> ling":false,"description":"Daily >>>>>>>>>> horoscopes and Astrosync courtesy of >>>>>>>>>> >>>>>>>> >>>>> >>>> >> tarot.com","features":{"dynamic-height":{"name":"dynamic-height","params":{}> >>>>>>> >>>>> >>>>> , >>>>>>>>>> >>>>>>>> " >>>>>>>>>> >>>>>>>> >>>>> >>>> >> required":true},"views":{"name":"views","params":{},"required":true},"setpre> >>>>>>> >>>>> >>>>> f >>>>>>>>>> >>>>>>>> s >>>>>>>>>> >>>>>>>> >>>>> >>>> >> ":{"name":"setprefs","params":{},"required":true},"core":{"name":"core","par> >>>>>>> >>>>> >>>>> a >>>>>>>>>> >>>>>>>> m >>>>>>>>>> >>>>>>>> >>>>> >>>> >> s":{},"required":true},"settitle":{"name":"settitle","params":{},"required":> >>>>>>> >>>>> >>>>> t >>>>>>>>>> >>>>>>>> r >>>>>>>>>> >>>>>>>> >>>>> >>>> >> ue},"tabs":{"name":"tabs","params":{},"required":true}},"categories":["",""]> >>>>>>> >>>>> >>>>> , >>>>>>>>>> >>>>>>>> " >>>>>>>>>> >>>>>>>> >>>>> >>>> >> authorPhoto":""},"responseTimeMs":1316478256657,"iframeUrl":"//localhost:808> >>>>>>> >>>>> >>>>> 0 >>>>>>>>>> >>>>>>>> / >>>>>>>>>> >>>>>>>> >>>>> >>>> >> gadgets/ifr?url=http%3A%2F%2Fwww.google.com%2Fig%2Fmodules%2Fhoroscope.xml&c> >>>>>>> >>>>> >>>>> o >>>>>>>>>> >>>>>>>> n >>>>>>>>>> >>>>>>>> >>>>> >>>> >> tainer=default&view=%25view%25&lang=%25lang%25&country=%25country%25&debug=%> >>>>>>> >>>>> >>>>> 2 >>>>>>>>>> >>>>>>>> 5 >>>>>>>>>> >>>>>>>> >>>>> >>>> >> debug%25&nocache=%25nocache%25&sanitize=%25sanitize%25&v=81c0125ea88602827eb> >>>>>>> >>>>> >>>>> e >>>>>>>>>> >>>>>>>> 7 >>>>>>>>>> >>>>>>>> >>>>> >>>> >> 788ff5921e1#up_day=%25up_day%25&up_month=%25up_month%25&up_selectedTab=%25up> >>>>>>> >>>>> >>>>> _ >>>>>>>>>> >>>>>>>> s >>>>>>>>>> >>>>>>>> >>>>> >>>> >> electedTab%25&up_uid=%25up_uid%25&up_selectedFriend=%25up_selectedFriend%25"> >>>>>>> >>>>> >>>>> } >>>>>>>>>> >>>>>>>> } >>>>>>>>>> }] >>>>>>>>>> >>>>>>>>>> Looks ok to me. >>>>>>>>>> >>>>>>>>>> - Henry >>>>>>>>>> >>>>>>>>>> On Mon, Sep 19, 2011 at 4:55 PM, daviesd <[email protected]> >> wrote: >>>>>>>>>>> Is there anything that would have changed since last Thursday or >>>> so >>>>> that >>>>>>>>>>> would be causing the metadata call to fail with a 400 error? >>>>>>>>>>> >>>>>>>>>>> I grabbed the latest artifacts today and I¹m getting a 400 when >>>>> making >>>>>>>>>>> the >>>>>>>>>>> metadata request. >>>>>>>>>>> >>>>>>>>>>> >>>>> >>>> >> [{"method":"gadgets.metadata","id":"gadgets.metadata","params":{"containe>>>> >>>>>>> >>>>> >>>>> r >>>>>>>>>>> ": >>>>>>>>>>> >>>>> "default","ids":["http://www.google.com/ig/modules/horoscope.xml >>>>> "],"field>>>>>> >>>>> s >>>>>>>>>>> ": >>>>>>>>>>> >>>>> >>>> >> ["iframeUrl","modulePrefs.*","needsTokenRefresh","userPrefs.*","views.pre>>>> >>>>>>> >>>>> >>>>> f >>>>>>>>>>> er >>>>>>>>>>> >>>>> >>>> >> redHeight","views.preferredWidth","expireTimeMs","responseTimeMs"],"langu>>>> >>>>>>> >>>>> >>>>> a >>>>>>>>>>> ge >>>>>>>>>>> ":"en","country":"US","userId":"@viewer","groupId":"@self"}}] >>>>>>>>>>> >>>>>>>>>>> This was working late last week. ?It almost seems like it¹s >>>> getting >>>>>>>>>>> garbage >>>>>>>>>>> back from the request. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Doug >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> >>>> >> >> >> >> >>
