Yes, the last register call is done using your value that you specified.
Ohhh... I can't believe I missed that. Check out the first email I sent
you.
>>> this.apiPath_ = String(osapi.container.util.getSafeJsonValue(config,
>>> osapi.container.ServiceConfig.API_PATH, '/rpc'));
This is the culprit. If the API_PATH is not set in the config, we
probably should not be setting it to '/rpc'.
Furthermore, we probably shouldn't be registering an endpoint here:
>>> /**
>>> * Initialize OSAPI endpoint methods/interfaces.
>>> */
>>> osapi.container.Service.prototype.registerOsapiServices = function() {
>>> var endPoint = this.apiHost_ + this.apiPath_;
if this.apiHost_ isn't defined.
Actually I think the best idea would be if we could find the injected
endpoint and use that as a default if not provided in the passed in config
object.
From: daviesd <[email protected]>
To: <[email protected]>,
Date: 09/21/2011 03:59 PM
Subject: Re: Metadata
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.addHostAndPortToDefaultCon
> 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
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>>
>
>
>
>
>
