Re: Terminate the Apache Shindig Project

Super big frowny face. > On Oct 7, 2015, at 2:31 PM, Ryan Baxter wrote: > > Hi fellow Shindig Devs, > > I would like to let you all know that the Shindig PMC has voted to > terminate the Shindig project and move it to the attic. I have already > informed the Apache board

appId vs appUrl

I’m trying to figure out why BlobCrypterSecurityToken uses the appUrl in the getter for appId. It looks like I’ve had this discussion before http://markmail.org/message/v2csm3vrxoddeztg I don't even remember going down this path 4 years ago… but now it’s causing me issues because with the

Re: missing osapi endpoints

by calling through the rpc endpoint on the target server, rather than just internally introspecting? I guess I could just define the osapi.servcies to prevent the rpc call by removing the osapi.endPoints configuration. doug On Jun 2, 2015, at 9:50 AM, Davies,Douglas davi

Re: missing osapi endpoints

I guess this old thread http://markmail.org/message/n7t2xicqvwu2sfio alludes to my same issue. doug On Jun 2, 2015, at 10:28 AM, Davies,Douglas davi...@oclc.org wrote: I do see this in the logs INFO: https://myserver/opensocial/rpc?method=system.listMethodsst

implementing container token refresh

(I’m not sure this ever posted yesterday… so pardon me if it comes through twice) I’m looking into implementing container token refresh using the container.config_[osapi.container.ContainerConfig.GET_CONTAINER_TOKEN] mechanism. This function would then either call back to my application or to

Re: implementing container token refresh

Perhaps I can inject a AuthenticationHandler that allows certain endpoint to be bypassed by generating an anonymous security token. doug On May 13, 2015, at 9:05 AM, Davies,Douglas davi...@oclc.orgmailto:davi...@oclc.org wrote: (I’m not sure this ever posted yesterday… so pardon me

Re: getActiveSiteHolder

I have submitted bug https://issues.apache.org/jira/browse/SHINDIG-1994 and a proposed fix in review https://reviews.apache.org/r/33940 The issue has to do with the new module id stuff and the callback in gadget_site:navigateTo being called before the setModuleId_ method competes. I

Re: getActiveSiteHolder

[3] https://github.com/apache/shindig/blob/trunk/features/src/main/javascript/features/container.util/constant.js#L170 On Tue, May 5, 2015 at 9:29 AM, Davies,Douglas davi...@oclc.org wrote: Hi Stanton, Thanks for the feedback. Here’s a working (or non-working) example of the problem

Re: getActiveSiteHolder

= + gadgetSite.getActiveSiteHolder()); }, 1000); }); activeSiteHolder is undefined on the first getter (even though I’m in the callback function). If I removed the 2nd line and not set the MODULE_ID render param then it works. I’ll see if I can dig into why. doug On May 6, 2015, at 9:36 AM, Davies,Douglas davi

Re: getActiveSiteHolder

holder? [1] https://issues.apache.org/jira/browse/SHINDIG-1965 On Wed, Apr 29, 2015 at 11:39 AM, Davies,Douglas davi...@oclc.orgmailto:davi...@oclc.org wrote: Has anyone had any inconsistencies with gadgetSite.getActiveSiteHolder() not being initialized immediately after

Re: getActiveSiteHolder

, at 9:41 AM, Ryan Baxter rbaxte...@apache.orgmailto:rbaxte...@apache.org wrote: On Tue, May 5, 2015 at 2:29 PM, Davies,Douglas davi...@oclc.orgmailto:davi...@oclc.org wrote: Hi Stanton, Thanks for the feedback. Here’s a working (or non-working) example of the problem. Just drop this in your

Re: appId, moduleId, siteId

instance-specific information. Shindig's default implementation of moduleId is naive (it's always 0!) but a ModuleIdManager implementation can be injected that handles them more intelligently. I hope that helps! On Fri, Apr 24, 2015 at 4:10 PM, Davies,Douglas davi...@oclc.orgmailto:davi

Re: appId, moduleId, siteId

, 27 Apr 2015 13:30:47 + schrieb Davies,Douglas davi...@oclc.orgmailto:davi...@oclc.org: Stanton, Thanks for the rundown on the different ids and what they are. That’s helpful (and along the same lines as the conclusion I came to). So I tried changing ModuleIdManagerImpl to return 1234L

Re: appId, moduleId, siteId

If I set renderParams[osapi.container.RenderParam.MODULE_ID] = -1 per http://comments.gmane.org/gmane.comp.web.shindig.devel/8498 * You can now request that a new moduleId be generated for a gadget when asking for a new token by setting it's moduleId to a negative number and fetching a new

Re: appId, moduleId, siteId

the correct wiki is anymore and whether this falls under common container info or what. Thanks! doug On Apr 27, 2015, at 11:35 AM, Davies,Douglas davi...@oclc.org wrote: If I set renderParams[osapi.container.RenderParam.MODULE_ID] = -1 per http://comments.gmane.org

Re: appId, moduleId, siteId

doesn’t seem to call this endpoint either. Thanks, doug On Apr 22, 2015, at 12:49 PM, Davies,Douglas davi...@oclc.orgmailto:davi...@oclc.org wrote: I’ve been combing through past conversations and wikis, but I’ve yet to find a good explanation of the difference between appId, moduleId, and siteId

Re: appId, moduleId, siteId

. Thanks, doug On Apr 24, 2015, at 2:15 PM, Davies,Douglas davi...@oclc.org wrote: Ok, I think I’ve figured this out (at least our use-case). We are using the siteId all over the place in the container and having to pass it along to the userPrefs calls. I’m guessing I shouldn’t be doing

appId, moduleId, siteId

I’ve been combing through past conversations and wikis, but I’ve yet to find a good explanation of the difference between appId, moduleId, and siteId. Does anyone know where I can find a good explanation of where I should be using each one? Right now I think the default ModuleIIdManager

Re: container security tokens v.s. gadget security tokens

, or setting a timeout in your callback is working. You're allowing updateContainerSecurityToken to finish and actually call shindig.auth.updateSecurityToken via the refresh method. Hopefully that makes sense. :) On Wed, Apr 8, 2015 at 2:20 PM, Davies,Douglas davi...@oclc.org wrote: I got

container security tokens v.s. gadget security tokens

I have a question about refreshing container and gadget security tokens. When I call updateContainerSecurityToken on the container, do I then need to call forceRefreshAllTokens for the gadgets? I was looking at OpenSocial Explorer (http://opensocial.github.io/explorer — Stanton and Ryan) and

Re: container security tokens v.s. gadget security tokens

. I hope that helps! -Stanton On Wed, Apr 8, 2015 at 1:27 PM, Davies,Douglas davi...@oclc.org wrote: I have a question about refreshing container and gadget security tokens. When I call updateContainerSecurityToken on the container, do I then need to call forceRefreshAllTokens

Re: container security tokens v.s. gadget security tokens

if (callback) { // No refresh needed, run the callback because the token is fine. callback(); } }; })(); doug On Apr 8, 2015, at 1:55 PM, Davies,Douglas davi...@oclc.orgmailto:davi...@oclc.org wrote: Thanks Stanton. That’s what I am attempting to do, but it seems like I have to go

Re: container security tokens v.s. gadget security tokens

I got it to work. Not sure why I was using the callback flavor of updateContainerSecurityToken. If I change to this container.updateContainerSecurityToken(null, token, 1800); container.forceRefreshAllTokens(); it works fine. doug On Apr 8, 2015, at 2:15 PM, Davies,Douglas davi

Re: EL expressions, Substituters, and Shindig

, Doug On Mar 27, 2015, at 4:41 PM, Davies,Douglas davi...@oclc.orgmailto:davi...@oclc.org wrote: Thanks. It seems like Substituters worked on the entire gadget spec (replacing any __MODULE_xxx__, __UP_xxx__, etc.). The templates stuff seems to only work in “text/os-data” nodes and no way to plug

Re: EL expressions, Substituters, and Shindig

, 2015, at 4:09 PM, Ryan Baxter rbaxte...@apache.org wrote: Sorry Doug, I never really looked at this portion of Shindig. Maybe someone else knows? On Wed, Mar 25, 2015 at 4:18 PM, Davies,Douglas davi...@oclc.org wrote: Hi All, I want to make a value available to my gadget via

EL expressions, Substituters, and Shindig

Hi All, I want to make a value available to my gadget via substitution of a regular expression. I know the old format was something like this __MODULE_ID__. I was able to get my own value working by writing my own Substituter and injecting it. So for example __MODULE_MY_KEY__ (I couldn’t

not getting messages

I haven’t gotten any messages from this listserv since 1/14. Looking at markmail is see there are a few from 1/29. Is anyone aware of any issue? Also, I’m a bit concerned about the lack of traffic. Has the move to w3c changed things? I guess I’m asking because my company is thinking of

renderDebug

Hi guys. While working up a solution for SHINDIG-1984 I noticed that in commoncontainer that renderDebug is set as follows testConfig[osapi.container.ContainerConfig.RENDER_DEBUG] = '0'; and then in container.js it does this this.renderDebug_ = (typeof param === 'undefined') ?

repo down

Is http://svn.apache.org/repos/asf/shindig/trunk/ down? It appears maybe all apache repos are down. doug

Re: [VOTE] Release Apache Shindig version 2.5.2

I imagine everyone is gone on vacation, but if there is any chance of getting a 2.5.2 release before the holidays I'd appreciate it. Otherwise, see ya when you get back. doug On Nov 23, 2014, at 7:42 PM, Paul Lindner lind...@inuus.com wrote: +1 - ship it On Mon Nov 10 2014 at 5:41:48 PM

Re: [VOTE] Release Apache Shindig version 2.5.2

I found an issue with the updated guava version conflicting with our bonecp version, but I've fixed it in our end. So still a +1 and looking forward to the release. doug On Nov 15, 2014, at 10:55 AM, Ryan Baxter rbaxte...@gmail.com wrote: +1 from me. I one other PMC member could check

Re: [VOTE] Release Apache Shindig version 2.5.2

Correct. On Nov 19, 2014, at 3:10 PM, Ryan Baxter rbaxte...@gmail.com wrote: Doug, I assume this is a dependency in your own implementation?

Re: [VOTE] Release Apache Shindig version 2.5.2

+1 On Nov 10, 2014, at 8:41 PM, Ryan Baxter rbaxte...@apache.org wrote: Hi, We solved 6 issues: https://issues.apache.org/jira/issues/?jql=project%20%3D%20SHINDIG%20AND%20fixVersion%20%3D%202.5.2%20AND%20status%20%3D%20Resolved%20ORDER%20BY%20priority%20DESC There are still a couple of

Re: 2.5.2 release?

%20Resolved%20ORDER%20BY%20priority%20DESC On Fri, Nov 7, 2014 at 9:26 AM, Davies,Douglas davi...@oclc.org wrote: It's been about 8 months since the last release. I see there are only about 6 out of the 25 tickets that have been resolved for 2.5.2. What is the roadmap for releasing 2.5.2

2.5.2 release?

It's been about 8 months since the last release. I see there are only about 6 out of the 25 tickets that have been resolved for 2.5.2. What is the roadmap for releasing 2.5.2? Is it determined by timeframe or bugs fixed? I have a patch I contributed that we'd really like to get into our

Re: Shindig Logo Design - Please Vote for your Choice

Wow, these are really great. I vote for 09. doug

Re: caching and 500 errors

the nocache in the render parameters but that will result in ALL calls bypassing the cache and not just your particular service calls. Regards, -Stanton On Wed, Aug 20, 2014 at 11:18 AM, Davies,Douglas davi...@oclc.orgmailto:davi...@oclc.org wrote: Hi Guys, It’s Doug Davies. Been a while since

Re: [VOTE] Release Apache Shindig version 2.5.0-update1

Any update on this? doug On 10/5/13 6:13 PM, Ryan Baxter rbaxte...@apache.org wrote: Hi, We solved 5 issues: https://issues.apache.org/jira/issues/?jql=project%20%3D%20SHINDIG%20AND%2 0fixVersion%20%3D%20%222.5.0-update1%22%20ORDER%20BY%20priority%20DESC Staging repo:

Re: startup error

. I have to do some more reading about ehcaches to see if there is another solution, but this seems to be my best bet right now. doug On 8/30/13 9:11 AM, Davies,Douglas davi...@oclc.org wrote: We have another ehcache manager (not provider) that seems to be conflicting with the shindig one

Re: startup error

keys nor values look like the thing from the log entry you posted. Thanks, -Stanton On Wed, Aug 28, 2013 at 1:14 PM, Davies,Douglas davi...@oclc.org wrote: Ok, I spoke too soon about us upgrading to 2.5.0 smoothly. :) Our container includes the shindig artifacts but also relies on Spring

startup error

Ok, I spoke too soon about us upgrading to 2.5.0 smoothly. :) Our container includes the shindig artifacts but also relies on Spring and a few other internal libraries. If I startup under Tomcat 7 things are working fine. If I run under Jetty I'm seeing this 2013-08-28 12:59:15,682 ERROR

smooth

Hi guys, Been a while since I participated in the group. Just wanted to let you know we upgraded our container to the release of shindig-2.5.0 (we had been at beta4 for quite a while) and it went really smooth. Beside the ImmediateFuture stuff, we had to change very little. Thanks for all

Re: iGoogle

Ya, I saw that thread but the answer seemed kind of vague. It's still unclear to me what other google products are utilizing opensocial and whether they'll be abandoning it as well. I guess whether google is supporting it or not at this point is irrelevant, but there are concerns around my

redirect_uri

In shindig.properties there is a value “shindig.oauth2.global-redirect-uri” for the default oauth2 callback uri to use if a client doesn’t configure one. There is also one for oauth1 “shindig.signing.global-callback-url”. OAuth1 also has one in container.js

URGENT: Shindig snapshots

Paul, can you help out here? Thanks, Doug On Jun 12, 2012, at 9:01 PM, Ryan J Baxter rjbax...@us.ibm.com wrote: Doug, I am not really familiar how this all works. Paul is probably your best bet. -Ryan From: daviesd davi...@oclc.org To: shindig dev@shindig.apache.org,

Re: URGENT: Shindig snapshots

Lindner lind...@inuus.com wrote: Hmm, looks like the java.net download of the JVM failed on hudson.inuus.com (my home server). I'll fix it up.. On Tue, Jun 12, 2012 at 6:30 PM, Davies,Douglas davi...@oclc.org wrote: Paul, can you help out here? Thanks, Doug On Jun 12, 2012, at 9:01 PM

Re: Does data-pipelining in proxied content require oauth to be configured?

Thanks Ryan. Hmmm... So any idea what we might be doing wrong? Doug Sent from my iPad On Apr 26, 2012, at 6:38 PM, Ryan J Baxter rjbax...@us.ibm.com wrote: Doug, I have not tried this in a while, but last time I did OAuth was not required. -Ryan From: daviesd davi...@oclc.org

Re: Shindig running on different domain than container REVISITED

Thanks Stanton. So no rpc_relay setup etc.? Seems last time I did this I ran into that. Doug Sent from my iPhone On Mar 21, 2012, at 3:43 PM, Stanton Sievers ssiev...@us.ibm.com wrote: Hi Doug, Yes, things work just fine running the container page and shindig on different domains.

Re: Features css

Thanks Paul. And if you get a chance can you check out my message about JsonUtil and it's use of the guava collections? I'm having issues with it. Thanks. Doug On Mar 11, 2012, at 1:01 AM, Paul Lindner lind...@inuus.com wrote: No specific way afaik. This js injection of css works pretty

Re: Errors with gadgets.views.requestNavigateTo

Possibly. I don't know enough about what the functionality should be. I was surprised there wasn't a default implementation of requestNavigateToHandler either. I posted my implementation earlier and would be willing to submit a patch for that if people think its appropriate. Doug Sent from

Re: BlobCrypterSecurityTokenCodec relies on instanceof in the face of Proxy

Stanton, I've had exactly the same problem (in fact I think I posted an earlier question on this and there is also an open jira -- sorry I don't have the number offhand). I have a patched version that doesn't do the instanceof check, but I don't like it. So I too am looking for the correct

RE: Common container rpc request uses wrong security token

call. I'd love to trickle this down to the jsonrpcrequest level, but I couldn't figure out how to get access to the gadget or gadget site at that level. doug From: Davies,Douglas Sent: Monday, July 18, 2011 10:52 AM To: 'dev@shindig.apache.org' Subject: Common container rpc request uses wrong

Common container rpc request uses wrong security token

I have opened https://issues.apache.org/jira/browse/SHINDIG-1557. The gadget security token is not being used on rpc calls. The container one is. Thus calls like appdata and userprefs do not have access to the gadget information as they need. In the meantime I'm going to try to work around

RE: jsonrpctransport.js

This bug https://issues.apache.org/jira/browse/SHINDIG-1432 kind of hints at something similar. If I could get a hold of the gadget object within jsonrpctransport, perhaps I could swap in the correct security token. doug -Original Message- From: Davies,Douglas Sent: Thursday, July 14

Re: jsonrpctransport.js

-899-3041 developerWorks Profile From: Davies,Douglas davi...@oclc.org To: dev@shindig.apache.org, Date: 07/13/2011 09:39 PM Subject:Re: jsonrpctransport.js Ryan, Thanks for responding. Was starting to wonder if my messages were making it to the mail list

jsonrpctransport.js

jsonrpctransport.js is using shindig.auth.getSecurityToken(). This is great if the json rpc request is coming from the container. However, not if it's coming from the gadget. For example let's say my gadget is calling userprefs osapi.appdata.update({ userid : '@me',

RE: jsonrpctransport.js

writer is not suppose to call updateSecurityToken (and shouldn't even know anything about it). I'm digging through the code to find out where this is set after the metadata request is made to get the iframe url. Does that make sense or am I on the wrong track? doug From: Davies,Douglas Sent

RE: jsonrpctransport.js

object. This must have to do with my set_pref being registered with the container (my set_pref is the one using appdata). I'm not sure how to get the osapi calls to use the gadget security token. doug From: Davies,Douglas Sent: Wednesday, July 13, 2011 11:05 AM To: 'dev@shindig.apache.org

Re: jsonrpctransport.js

Phone: 978-899-3041 developerWorks Profile From: Davies,Douglas davi...@oclc.org To: dev@shindig.apache.org, Date: 07/13/2011 03:04 PM Subject:RE: jsonrpctransport.js I put logging in my gadget and printed out the value of shindig.auth.getSecurityToken

RE: Implementing userPrefs with common container

the metadata/iframe calls. Again... any feedback from anyone who has been through this process is appreciated. doug From: Davies,Douglas Sent: Monday, June 27, 2011 9:59 AM To: 'dev@shindig.apache.org' Subject: Implementing userPrefs with common container I'm looking into implementing

RE: Implementing userPrefs with common container

, Davies,Douglas davi...@oclc.org wrote: I've implemented the set_pref rpc call and it's getting called appropriately from the gadgets. I've got this sitting ontop of appdata and it seems to be persisting my values fine. I am using the gadget url combined with the preference name to generate

Implementing userPrefs with common container

(I apologize if this posted to the dev group twice. My Entourage is acting up again and this didn't seem to post the first time) I'm looking into implementing userPrefs with the common container, but I'm unclear as to what is implemented and what just needs to be extended. My first step is

initializeGlobalVars

Could someone explain the initializeGlobalVars code? It looks for the last script tag and assumes it was the one doing the gadget javascript include (why???). I noticed issue SHINDIG-1533 addresses this by providing __CONTAINER_SCRIPT_ID to identify the correct script tag. However in YUI where I

Adding a new service. Should it always be wrapped by a feature?

We are adding a new service to our shindig server. After reading this article http://www.dr-chuck.com/csev-blog/2010/07/sending-data-to-a-server-side- service-with-shindig/ it appears to me that the service is then exposed through osapi. However... is this the interface we should be

Extending common container via features

I'm trying to extend the commoncontainer. I want to add a couple of new apis. I'm trying to do this by introducing a feature that adds the new functionality. In shindig.properties I have shindig.features.default=res://features/features.txt,res://features/oclc features.txt referencing

RE: Extending common container via features

Disregard. Turns out I am doing everything correctly, just had a maven build issue. I was trying to build a separate features project. Moving it into the server made it work, so I'll work out my build issue. At any rate... very nice how you can extend common container.

RE: HTTP / HTTPS question

some of those values in container.js as well. Thanks, doug -Original Message- From: Doug Ellison [mailto:doug.elli...@gmail.com] Sent: Thursday, April 21, 2011 10:37 AM To: Davies,Douglas Cc: dev@shindig.apache.org; John Hjelmstad; Niels van Dijk Subject: Re: HTTP / HTTPS question So I

RE: HTTP / HTTPS question

I am hitting this issue as well. I've tried most of the suggestions on this thread (except for the complete replacement of http for https). I had everything working great as http and had patched things to run as a non-root webcontext (/opensocial). The metadata call on the http version does

RE: Shindig and webapp on same host/domain or not?

Thanks Jesse, Isaiah, and everyone else that chimed in. We've successfully got this working using urlrewrite. Correct... I did not have the proxy type setup correcty (my co-worker mentioned this to me too). We also found we needed version 3.2.0 of urlrewritefilter for the proxy type to work.

RE: Shindig and webapp on same host/domain or not?

Isaiah, Were you successful on getting this to work? I tried a similar approach today using urlrewritefilter with the mapping: from/shindig/**/from to type=redirecthttp://myshindigserver/shindig/$1/to I see the request now changing using firebug

Shindig and webapp on same host/domain or not?

I want to follow up with an earlier thread I had about webroot that has taken me a different direction. Sorry for starting a new thread, but the listserv (or stupid entourage on the mac) is making it so that my messages have been posted as 'daviesd' and not 'davi...@oclc.org' and this seems to be

Root webapp?

Hello. I’m new to this listserv, so please correct any protocol/etiquette mistakes I might make. I’m pretty new to opensocial and shindig. I’ve played around with bringing the war file down and renaming it ROOT.war. I’ve also played around with creating a new webapp application archetype and