I hate to be a pest, but does anyone have an update on this? I¹m still only
seeing 12/26 as the latest artifact. This is affecting my daily build.
Thanks,
doug
On 1/9/12 1:28 PM, "daviesd" wrote:
> Any ideas on this? I¹m still showing 12/26 as the last builds
Any ideas on this? I¹m still showing 12/26 as the last builds at
https://repository.apache.org/content/groups/public/org/apache/shindig/shind
ig-common/3.0.0-SNAPSHOT/
Also, ideas when we might see a beta5?
doug
On 1/6/12 9:58 AM, "daviesd" wrote:
> Thanks. Are snapshots happe
dee7df54b12e
> Author: Paul Lindner
> Date: Mon Dec 26 10:44:42 2011 +
>
> fix deprecated usage for httpclient
>
> git-svn-id:
> https://svn.apache.org/repos/asf/shindig/trunk@122470813f79535-47bb-0310-9956-
> ffa450edef68
>
>
> On Tue, Jan 3, 201
Did this change again recently? The ssl certificate error is back.
doug
On 11/7/11 1:45 PM, "Ryan J Baxter" wrote:
> I have been seeing SSL exceptions being thrown relating to certificates
> not matching in builds from trunk recently. I have traced this back to a
> httpclient upgrade from 4.
I¹ve implemented my own OAuth2Encrypter and wired it up. However, I never
see the secret being encrypted in my persistent store. I noticed
OAuth2TokenPersistence has a encryptedSecret (and encryptedMacSecret), but
they don¹t really seem to serve any purpose. When my persister¹s
insertToken/updat
I have a question about the Oauth 2.0 popup flow. I¹m looking at OAuth¹s
1.0 flow, because I¹m not seeing corresponding documentation for 2.0.
http://shindig.apache.org/shindig-1.1.x/shindig-features/jsdoc/symbols/gadge
ts.oauth.Popup.html
Anyway... 1 of my questions is... WHO closes the popup w
Li. Thanks again for committing my changes. This is gonna really help our
implementation. Do I need to close out the review and jira?
doug
On 12/12/11 3:10 PM, "Li Xu" wrote:
> ah, I see, no worry. I can clean up the code style when committing it.
> thanks.
not really possible to
> make a recommendation without knowing all the variables in your production
> environment. I can say that from my personal experience (deploying shindig
> into a clustered environment) it was necessary to implement more robust
> caching of the OAuth2Accessor.
>
I understand that OAuth2Cache provides a mechanism for implementing a cache
that the OAuth2Store uses to limit requests to the OAuth2Persister.
However, if my OAuth2Persister implementation uses JPA or some other
persistence model that already has caching built-in, the OAuth2Cache is
redundant and
Li, revision submitted. Cleaned up the code to use Maps, used the Eclipse
formatters, and added a junit test.
Thanks for your help.
doug
On 12/12/11 3:10 PM, "Li Xu" wrote:
> ah, I see, no worry. I can clean up the code style when committing it.
> thanks.
Awesome Li! As far as the code style comment. I'm an IntelliJ person.
Anyone have the templates for that? If not, I'll see about moving over to
Eclipse to do the edits.
doug
On 12/12/11 2:50 PM, "Li Xu" wrote:
> Thanks for the patch, Doug! It looks pretty good to me. only a few minor
> thin
Hmmm... I included 2 NEW files in the diff, but they didn't get added to the
review. How do I do this?
doug
On 12/12/11 11:18 AM, "daviesd" wrote:
> I have submitted a revision to the review (3064) that implements the
> OAuth2RequestParameterGenerator class. I look forw
I have submitted a revision to the review (3064) that implements the
OAuth2RequestParameterGenerator class. I look forward to your responses and
getting this integrated as quickly as possible.
Thanks for the guidance,
doug
On 12/8/11 3:50 PM, "Li Xu" wrote:
> I see. Just a thought, Inject an
We were having the same discussion here. Stayed tune... I have my project
for tomorrow. :)
doug
On 12/8/11 3:50 PM, "Li Xu" wrote:
> I see. Just a thought, Inject an OAuth2RequestParameterGenerator here might
> be helpful...It could provide a function to generate parameter based on
> HttpRequ
I guess my disconnect is that OUR implementation of the GrantRequestHandler
used the security token to PULL OUT the value we needed. In other words our
container had set the security token with trustedJson that held the extra
parameters we needed. Thus when the intial makeRequest happened, the 's
Thanks Li. That was my initial implementation (to add something to the
accessor). However I backed off because I was trying to be the least
intrusive.
Mike and I will go back and see if there is a better way to do this. Just
not sure how you'd make it generic enough to figure out what request
p
the CodeGrantTypeHandler.
If/when this gets integrated into shindig trunk we¹ll switch over.
Thanks,
doug
On 12/6/11 6:48 PM, "daviesd" wrote:
> I see where my misunderstanding was. I thought the
> ClientAuthenticationHandler was called to set authentication values before the
I'll look into what it
would take to "patch" the code in order for the handler to have access to
the original request or security token.
doug
On 12/6/11 5:19 PM, "daviesd" wrote:
> Argh! Not so great. The security token seems to be null even though I see
> the st
pass along a bit of information from the
token onto the authorization code request.
Ideas?
doug
On 12/6/11 10:02 AM, "daviesd" wrote:
> I didn¹t notice that the request coming into addOAuth2Authentication wasn¹t a
> HttpServletRequest but instead a org.apache.shindig.gadgets.
Li, thanks for the response.
Ya, it's just unfortunate I have to overwrite the entire class. I tried to
extend the class and overwrite the method, but since it's static that isn't
going to work (guice complains about it already being bound). I noticed on
this link
http://docs.opensocial.org/dis
ClientAuthenticationHandler (it has
geClientAuthenticationType, instead of get). That means my implementation
also has to use the incorrect spelling.
Thanks,
doug
On 12/5/11 3:21 PM, "daviesd" wrote:
> Ah, now I see that the accessor clientAuthenticationType is the thing that
> dictates whi
this.
Thanks,
doug
On 12/5/11 2:29 PM, "daviesd" wrote:
> According to this
>
> http://docs.opensocial.org/display/OSD/Client+Authentication
>
> If I want to add additional request header values to the ³authorization code
> request² I would need to add another c
According to this
http://docs.opensocial.org/display/OSD/Client+Authentication
If I want to add additional request header values to the ³authorization code
request² I would need to add another client authentication handler. Am I
understanding this correctly? Do all the handlers get called, so f
Thanks Paul. Looks good!
doug
On 11/29/11 10:07 PM, "Paul Lindner" wrote:
> +1 from me...
>
> With four +1 votes the release is approved. I will publish the artifacts
> shortly.
>
>> afternoon..
>>
>>
>> On Tue, Nov 22, 2011 at 11:44 AM, daviesd wrote:
>>
>>> Any status on this? Thanks. If it's after the Thanksgiving break that's
>>> fine. Was just looking to resolve our https issue before going on break.
>>&
Any status on this? Thanks. If it's after the Thanksgiving break that's
fine. Was just looking to resolve our https issue before going on break.
doug
On 11/21/11 3:45 PM, "Paul Lindner" wrote:
> If no one objects I'll kick off beta4 later today.
>
> 2011
PM
>> To: shindig
>> Subject: RE: SecurityTokenKeyFile
>>
>>> -Original Message-
>>> From: daviesd [mailto:davi...@oclc.org]
>>> Sent: Tuesday, November 22, 2011 2:14 PM
>>> To: shindig
>>> Subject: SecurityTokenKeyFile
>>>
>&
I know there was a change recently (SHINDIG-1636) that changed the way the
token encryption key was loaded. I use to have
"gadgets.securityTokenKeyFile" : "res://tokenkey.txt"
But this appears to be broken now. tokenkey.txt would be in the root of my
classes directory. I was able to get this t
So how does a gadget know what service name to use since every container
could define facebook differently.
doug
On 11/21/11 2:34 PM, "Ryan J Baxter" wrote:
> Mike, usually the provider information is configured before hand. Your
> container could choose to allow gadget developers to register
On Thu, Nov 10, 2011 at 9:44 AM, Henry Saputra
>> wrote:
>>
>>> Yeah I think its not in the beta3 snapshots and since the release is
>>> out we need to either deliver beta3-1 or wait for beta4
>>>
>>> - Henry
>>>
>>> On Thu, Nov
r can't easily work with the
> current behavior, write up a patch :)
>
>
>
> From: daviesd
> To: ,
> Date: 11/17/2011 11:34 AM
> Subject:Re: siteId from element id
>
>
>
> Rereading I may not have been totally clear. We are NO
Rereading I may not have been totally clear. We are NOT using the
auto-generated number. We are using a sequence number from our database
(which correlates to our gadget space). It is always the same number for an
installed gadget.
I guess my question was... Is using an html element attribute t
Right now the siteId gets set to the id of the element you pass to
newGadgetSite (or the next sequence number if not provided). We are using
the siteId to correlate to our gadgetId, so that when user_prefs is called
(one of the parameters is the siteId) we can use that to store/retrieve data
on be
iver beta3-1 or wait for beta4
>>
>> - Henry
>>
>> On Thu, Nov 10, 2011 at 9:37 AM, daviesd wrote:
>>> I¹m seeing the same error. I assume this didn¹t make it into the beta3
>>> snapshot? We try not to use trunk artifacts in our build process. Am I
I¹m seeing the same error. I assume this didn¹t make it into the beta3
snapshot? We try not to use trunk artifacts in our build process. Am I
gonna have to wait until another beta?
Thanks,
doug
On 11/7/11 8:14 PM, "Ryan J Baxter" wrote:
> Looks good so far Paul. I will do some more testing
Error injecting constructor,
org.apache.shindig.gadgets.oauth2.persistence.OAuth2PersistenceException:
java.io.FileNotFoundException: Can not locate resource: config/oauth2.json
I added my own config/oauth2.json and it works fine. Is this file really
only necessary for the samples or is it someth
I¹m using the shindig-3.0.0-beta3 artifacts. I see that shindig-gadgets has
oauth.json included. Should oauth2.json also be included or is it up to me
to create this in my project? I¹m having issue getting my server to startup
because of the missing file. I was previously using a pre-oauth2 sna
Today I was updating to 3.0.0-beta3 and it busted my SecurityTokenFactory
class I had created. It used the BlobCrypterSecurityToken encrypt method as
well as the setters (setOwnerId, setViewerId, setTrustedJson) to generate an
encrypted token string. It appears as part of SHINDIG-1645 that this c
then
looking for that DIV and decorating it with the chrome.
Thanks,
doug
On 10/26/11 3:42 PM, "Dan Dumont" wrote:
> Could you share more of your current gadget minus the document.write?
>
> Maybe put it on http://pastebin.com/ so we can try loading it locally?
>
>
&
Ok, I¹m just gonna go home and crawl under a rock. Turns out it was the
chrome I put around my gadget. It does some DOM manipulation to wrap it,
which I think is causing the iframe to render again. My bad! Sorry.
doug
On 10/26/11 2:17 PM, "daviesd" wrote:
> I apologize. It h
/26/11 1:57 PM, "daviesd" wrote:
> I¹m having something strange happen. If I use document.write in my gadget it
> seems to have issues loading
>
> http://locahost:8080/opensocial/gadgets/ifr?url=...
>
> It just spins and spins (I see 2 ifr requests one after the oth
I¹m having something strange happen. If I use document.write in my gadget
it seems to have issues loading
http://locahost:8080/opensocial/gadgets/ifr?url=...
It just spins and spins (I see 2 ifr requests one after the other, one
succeeds the other spins the gadget renders but there is an outst
nfig.
> Wondering why you changed this to https:// instead of //
>
> Starting a url with // should use the protocol being used by the page. was
> it not working for https in your case?
>
> I'm not sure why shindig proxies to itself... I'm sure there's som
*bump*
The last time I posted this message it didn¹t gain any traction. However
this is now affecting us in a production environment and forces us to import
the certificate of the load balancer into our shindig server. Ideas?
On 6/1/11 3:33 PM, "Davies,Douglas" wrote:
> Our shindig server ru
Dan,
Fix looks good and works for me.
Thanks!
doug
On 10/11/11 3:00 PM, "Dan Dumont" wrote:
>
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/2348/
> --
doug
On 9/30/11 4:07 PM, "daviesd" wrote:
> Ryan,
>
> We had created our own shindig snapshot back on 9/23 because we were hitting a
> deadline and didn't want things to change. So I thought that might be the
> problem. But I just synched up with the latest shind
soon. Under a deadline to get our patches
> reviewed and delivered.
> I'm pretty sure we have this working fine internally, I'll see what I can
> set up and check.
>
>
>
>
> From: daviesd
> To: ,
> Date: 09/30/2011 03:40 PM
> Subject:
Dan,
I went back to an example we've used for a while to demonstrate changing
views and it no longer works either. I wonder if something changed recently
that broke this?
doug
On 9/30/11 3:12 PM, "daviesd" wrote:
> My bad... I wasn't passing the second parameter co
My bad... I wasn't passing the second parameter correctly (the gadget url).
I am doing it correctly now. Firebug errors go away, but the view still does
not change.
On 9/30/11 3:04 PM, "daviesd" wrote:
> I don't have a public accessible site, sorry.
>
> Here
d in RenderParam)?
> Do you have a public url that I could look at?
>
>
>
> From: daviesd
> To: ,
> Date: 09/30/2011 02:45 PM
> Subject:Re: Switching views
>
>
>
> Thanks Dan. Ya, even with those suggestions I'm not getting it to switch.
&g
e reference.
>
> Also, params are case sensitive. It's safest, though not always necessary
> to use the constance defined in the render params object;
> var renderParams = {}
> renderParams[osapi.container.RenderParam.VIEW] = 'canvas';
> ...
>
>
>
What is the common container way of switching the view of an already
rendered gadget?
I tried this
var renderParams = { view: 'canvas' };
gadgetSite.container_.navigateGadget(gadgetSite, gadget, {},
renderParams);
But it¹s not doing anything.
doug
What is the right way to create a Person if your shindig implementation is
abstracted away from your authentication model?
For example, we have a website that authenticates and sets some
cookie/session information. We cannot plug into the authentication flow in
order for it to create an entry int
9/28/11 10:27 AM, "daviesd" wrote:
> We are specifiying nocache on our javascript fetch (shindig 3.0.0)
>
> /gadgets/js/oclccontainer:rpc.js?c=1&debug=1&nocache=1&container=default
>
> However the gadget iframe url looks like
>
> /gadgets/ifr?u
We are specifiying nocache on our javascript fetch (shindig 3.0.0)
/gadgets/js/oclccontainer:rpc.js?c=1&debug=1&nocache=1&container=default
However the gadget iframe url looks like
/gadgets/ifr?url=http%3A%2F%2Fdl.dropbox.com%2Fu%2F445894%2Fgadget.xml&conta
iner=default&view=default&lang=en&coun
Thanks for getting this committed. I am now able to store my other info in
trustedJson and have accessible in the gadget security token. Nice!
doug
On 9/21/11 4:24 PM, "Henry Saputra" wrote:
> Doug, your vote count, thanks =)
>
> Any review to help patches better is welcomed.
>
> - Henry
>
gister the service first.
> Or not register the service at all if the path/host has not been specified
> in the config.
>
>
>
> From: daviesd
> To: ,
> Date: 09/21/2011 04:07 PM
> Subject:Re: Metadata
>
>
>
> Am I just confused here? Was
Not that I'm allowd to vote, but yes I'd love to have this in the next build
asap.
doug
On 9/21/11 2:13 PM, "Henry Saputra" wrote:
>
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/1981/
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, &
o common container or
>> use the new Gadgets metadata APIs so didnt have this problem ... yet
>> =)
>>
>> I am thinking about adding a common property to the SecurityToken
>> interface itself to support fields extension like this.
>>
>> Let me know if you want
fields extension like this.
>
> Let me know if you want to take a stab at it otherwise I could propose
> something later today.
>
> - Henry
>
> On Wed, Sep 21, 2011 at 6:38 AM, daviesd wrote:
>> Yesterday I sent a message to the listserv describing what we have done
>
Yesterday I sent a message to the listserv describing what we have done with
our SecurityToken implementation. We¹ve extended SecurityToken and created
OurBlobCrypterSecurityToken. It has 1 new field that is a complex structure
(stored as json). This was not added to the SecurityToken interface,
Now that we¹ve patched BlobCrypterSecurityTokenCodec so that gadget security
tokens are being returned on the iframe url, I¹m wondering how to get
certain token fileds set. I know there is work going on to get moduleId
(siteId) correctly set. What is the proper way to get appId set? We assign
ou
I've run into a problem with this in OUR implementation (yours is fine). We
add a couple of fields to the security token (OurBlobCrypterSecurityToken).
Thus I really need to cast to MY implementation to retrieve those values.
But I can't cast the proxy. I don't want to add the getters to the base
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" wrote:
> Are you trying to deploy Shindig as non root app?
>
> - Henry
>
> 2011/9/20 daviesd :
>
s that the
metadata call is not honoring the CONTEXT_ROOT.
doug
On 9/20/11 10:02 AM, "daviesd" 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 old
t;googlemodules+gadgetfactory_horoscope+201107...@google.com
> ","width":0,"authorLink":"","links":{},"scaling":false,"author":"csindia-gadge
> ts","directoryTitle":"Daily
> Horoscopes","title":&qu
;links":{},"scaling":false,"author":"csindia-gadge
> ts","directoryTitle":"Daily
> Horoscopes","title":"Today's
> Horoscope","height":200,"thumbnail":"http://www.gstatic.com/ig
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":{"conta
Stanton,
Here¹s my thread questioning the same thing
http://shindig-dev.markmail.org/search/?q=blobcryptersecuritytoken#query:blo
bcryptersecuritytoken%20order%3Adate-backward+page:1+mid:tvrxdvi4vsdaxbep+st
ate:results
Here¹s what I ended up doing
/**
* Overridden to work around casting
Jesse (and Dan offline),
I'm glad I'm not the only one questioning this. I wondered if I was doing
something wrong. Dan suggested a ON CONFLICT UPDATE solution on the db
side. Looking at that. But we may also go with the locking mechanism.
Thanks for the feedback.
doug
On 9/14/11 11:11 AM,
We¹ve implemented our own userprefs osapi service (yes, we dumped the whole
idea of sitting on top of appdata). As I understand it the calls to our
service will be asynchronous. Recently Dan Dumont made some changes to the
common container layer to support a callback for GET_PREFERENCES so that w
E
> D))
> .toInstance(Boolean.TRUE);
>
>
> Since the SocialApiGuiceModule is listed later than PropertiesModule,
> it overrides the binding of the shindig.allowUnauthenticated property.
>
> - Henry
>
> On Wed, Aug 3, 2011 at 12:51 PM, daviesd wrote:
>> I¹m
rning off Anonymous ST will
> make osapi libs do not load properly.
>
> - Henry
>
> 2011/8/3 daviesd :
>> Hmmm... good observation. However, I switched them around, still no
>> success... I wonder if this has to do with
>>
>> https://issues.apache.org/jira/b
dule is listed later than PropertiesModule,
> it overrides the binding of the shindig.allowUnauthenticated property.
>
> - Henry
>
> On Wed, Aug 3, 2011 at 12:51 PM, daviesd wrote:
>> I¹m trying to figure out how to prohibit rpc calls (gadgets.metadata, etc.)
>> from being made unles
I¹m trying to figure out how to prohibit rpc calls (gadgets.metadata, etc.)
from being made unless shindig.auth.updateSecurityToken has been called. If
I enable secure tokens and I set the token to something in clear text, it
denies the rpc requests as it should. Providing the encrypted token the
erParams[RenderParam.USER_PREFS] =
this.config_[ContainerConfig.GET_PREFERENCES](site.getId(),
gadgetUrl);
}
Any way to work around this if I¹m calling appdata? Or should you be using
a callback here?
doug
On 8/2/11 3:39 PM, "daviesd" wrote:
> Ok, I¹m just gonna go home :) See tha
er changing the id of the element or site after the
> fact?
>
> When I get back from vacation, I'll take a peek and see if it's anything in
> the common container code changing the id of the site.
>
> -daviesd wrote: -
> To:
> From: daviesd
> Date: 08
(per gadget url instance), then you'll need to keep track of the
> site (the auto generated ids are less helpful), if you wish to provide
> "per gadget url" preferences you can just ignore they siteid and return or
> persist the preferences for all gadgets coming from that u
Thanks. Works
On 8/1/11 5:18 PM, "Michael Hermanto" wrote:
> http://codereview.appspot.com/4816065/
>
> On Mon, Aug 1, 2011 at 2:13 PM, daviesd wrote:
>
>> If anyone discovers a quick fix to get by in the meantime, please post. I
>> just recently moved off
If anyone discovers a quick fix to get by in the meantime, please post. I
just recently moved off of 3.0.0-beta2 to pick up some of the recent common
container changes. It'd be nice if maybe we get a beta3 once this is stable?
doug
On 8/1/11 4:55 PM, "Ryan J Baxter" wrote:
> Cool thanks John.
Phil,
This possibly might be the same issue I reported
https://issues.apache.org/jira/browse/SHINDIG-1549
The common container doesn¹t render gadgets that don¹t have a default view.
When I try this gadget I get
[{"id":"gadgets.metadata","result":{"http://www.labpixies.com/campaigns/todo
/todo.
to gadget 1's preferences?
>
> -Ryan
>
> Email: rjbax...@us.ibm.com
> Phone: 978-899-3041
> developerWorks Profile
>
>
>
> From: daviesd
> To: ,
> Date: 07/28/2011 11:55 AM
> Subject:Re: Example implementation for user prefs?
>
>
Argh... Nevermind... I wasn't removing my up_siteid_ prefix from the
get_pref value before returning it. This is working beautifully Dan. Nice
job!
doug
On 7/28/11 12:19 PM, "daviesd" wrote:
> Dan,
>
> Are you sure about this? I am having an issue now where I
number.
>
> If you wish to persist preferences for a particular occurrence of a
> gadget(per gadget url instance), then you'll need to keep track of the
> site (the auto generated ids are less helpful), if you wish to provide
> "per gadget url" preferences you can j
e 2.0 spec and couldn't find any language
> to support that).
>
> Can anyone confirm or deny that to actually be the case (and maybe provide a
> reference to where it's specified)?
>
>> From: daviesd
>> To: ,
>> Date: 07/27/2011 03:22 PM
>>
dget url instance), then you'll need to keep track of the
> site (the auto generated ids are less helpful), if you wish to provide
> "per gadget url" preferences you can just ignore they siteid and return or
> persist the preferences for all gadgets coming from that url.
>
rack of the
> site (the auto generated ids are less helpful), if you wish to provide
> "per gadget url" preferences you can just ignore they siteid and return or
> persist the preferences for all gadgets coming from that url.
>
>
>
>
> From: daviesd
> To:
he gadget site element, so that named locations for specific gadgets can
> have preferences persisted accordingly.
>
> If you are going to be providing a default preference persistence impl, it
> would be great if you could hook into this :)
>
>
>
> From: daviesd
> To
you write this up a patch so we can make this the default
> implementation? This is something I've been meaning to do for months.
>
> On Wed, Jul 27, 2011 at 8:58 AM, daviesd wrote:
>
>> Actually, I was lazy and went with the approach of layering use
Actually, I was lazy and went with the approach of layering userprefs on top
of appdata as follows:
container.rpcRegister('set_pref', function(rpcArgs, data) {
var prefName = rpcArgs['a'][1];
var prefKey = 'up_' + prefName;
var prefValue = rpcArgs['a'][2];
var
Jasha,
I am seeing exactly the same thing now that I've enabled "secure". The
encodeToken in BlobSecurityTokeCodec throws an exception because the token
is of type Proxy and not BlobCrypterSecurityToken. Not sure how to get this
cast so that it can be encrypted. This only happened once I used a
Ryan,
I agree that the security token in the gadget holder should be done on the
navigate. It appears this was the intention, but I think there are a few
things about security tokens that haven¹t been completed in the common
container (I wish these holes were documented). My first attempt WAS to
I¹m looking into implementing userPrefs with the commoncontainer, but I¹m
unclear as to what is implemented and what just needs to be extended.
My first step is to implement set_pref and register it with rpc. I¹m
thinking of implementing this using the appData api (as I¹ve seen other
threads alon
de should be fixed to get scheme from
> request...will look further.
>
> For the other property:
> "defaultShindigTestHost":"//%authority%",
>
> I haven't seen any side effects yet... I'd like to suggest to update that
> property first if there&#x
If I remove the scheme then the server-side fails during listMethods (it
uses the same js value that is used client side).
org.apache.shindig.gadgets.render.DefaultServiceFetcher retrieveServices
SEVERE: Failed to fetch services methods from endpoint
//myshindigserver:8443/shindig/rpc. Error Missi
Agreed. beta2 pretty much has all the recent patches we are dependent on.
Great release.
On 6/17/11 9:10 AM, "Ciancetta, Jesse E." wrote:
> We've moved our dependency to 3.0.0-beta2 and its working well.
>
> Thanks for getting this done Paul -- it's much appreciated!
>
>> -Original Messag
It looks like there is a shindig.properties value you can set to get the
same behavior without code changes.
shindig.urlgen.use-templates-default=false
Hope this helps.
doug
On 6/14/11 1:59 PM, "daviesd" wrote:
> Not sure the protocol for bumping¹ on this listserv. If I
Not sure the protocol for bumping¹ on this listserv. If I just broke a
cardinal rule, please ream me now. :)
If not... bump!
Does anyone have any ideas on this? If the common container guys are aware
of this and have something in mind that¹s fine. I really hate having 1
patched file that I ha
>
> I'd be happy to extend the patch to handle scheme automatically from
> request as well... However schemeless url seems to be another alternative.
> is there any reason we couldn't remove the scheme here?
>
> thanks!
> li
>
>
>
>
> From:
> dav
101 - 200 of 210 matches
Mail list logo
