from:"Henry Saputra"

Re: Welcome to OpenDashboards!

2015-11-30 Thread Henry Saputra

Hi Chris,

Just found out about this effort. I was committer and PMC for Apache
Shindig and this is absolutely great news.

Thank you for leading the effort.

- Henry

On Monday, November 23, 2015, Chris Spiliotopoulos <
chrysanthos.spiliotopou...@gmail.com> wrote:

> Hi friends,
>
> after gathering all your wishes, proposals and votes on the recently
> created Trello  >
> board toady a new open source organization over at GitHub under the name of
> OpenDashboards  has been created
> that will be used as our common placeholder for all the things we want to
> see happening from now on.
>
> In order to send out invitations to anyone that wishes to join this new
> effort, please make sure you have a GitHub account and post it back to me
> either as a reply to this email or directly through our new Slack
>  space (channel *github-org*).  For
> those
> who still haven't signed up with the OpenDashboards Slack team, please send
> me your email as well and I will send you an invitation.
>
> Please keep in mind that although this new effort has started off as a
> shelter for the Apache Shindig project can clearly  have a bright future,
> since 'dashboarding' is and will be a common requirement for many
> companies, organizations and individual technology solutions.  Having
> stated that, I have a vision that OpenDashboards can easily become the next
> one-stop shop for diverse dashboarding solutions given the appropriate
> context and positioning in the technology space.
>
> I believe that we should all urge the companies we represent to join the
> effort and contribute to the evolution of an ecosystem we all could benefit
> from.  Also, we could start building collaborations with other open source
> projects and solutions in the same space, or even with various verticals in
> order to start getting attention and traction.
>
> Now that we have a new home, the next step is to transfer the Apache
> Shindig project to a new repository @ Github at its latest stable version.
> So, @Ryan can you give us the status from your side (and Apache's of
> course)?  Have you cleared things up regarding the transfer?
>
> Best regards,
> Chris
>
>
>
>
> --
> Chris Spiliotopoulos
>
> Solutions Architect | @LinkedIn
> | @Twitter
> 
>

Re: Terminate the Apache Shindig Project

2015-10-24 Thread Henry Saputra

I have met some good friends when working with Apache Shindig project.

Thanks all for the hard work and hope to see and work with you again
in other projects.

- Henry

On Thu, Oct 8, 2015 at 6:24 AM, Raj Janorkar  wrote:
> Thank you all, really helpful.
>
> In worst scenario if it closed,
> then lets move it to github.
>
> On Thu, Oct 8, 2015 at 11:21 PM, Chris Spiliotopoulos <
> chrysanthos.spiliotopou...@gmail.com> wrote:
>
>> Hi Ryan,
>>
>> thanks for the response - points taken.  Let's see what the future holds :)
>>
>> Best regards
>>
>> On Thu, Oct 8, 2015 at 4:07 PM, Ryan Baxter  wrote:
>>
>> > Hi Chris, thanks for the very thoughtful email.  In general I agree with
>> > what you are saying.  Some more comments inline.
>> >
>> > On Thu, Oct 8, 2015 at 5:54 AM Chris Spiliotopoulos <
>> > chrysanthos.spiliotopou...@gmail.com> wrote:
>> >
>> > > Hi all,
>> > >
>> > > instead of becoming emotional I prefer sharing some thoughts with
>> > everyone
>> > > in this thread.  Well, to be honest I think that everyone expected this
>> > to
>> > > happen at some point.  Of course not due to lack of support from the
>> dev
>> > > team - this had always been superb - but rather due to lack of
>> awareness
>> > > regarding this (IMHO) ground-breaking technology and I'm referring to
>> the
>> > > gadgets side of things.
>> > >
>> > > I've been using gadgets for quite a few years and I've managed to
>> > convince
>> > > people about the benefits of having a fully decoupled system with
>> > pluggable
>> > > apps either in-house or 3rd party.  Of course as I have stated in the
>> > past
>> > > this had always been a steep curve as very few people are aware of this
>> > > technology but in the end everybody would buy in after seeing the
>> > results.
>> > > During these years I have managed to 'tame the beast' as resources had
>> > > always been scattered and very few and eventually was able to put it to
>> > > work for producing great dashboard apps and in the future (I hope)
>> > > marketplaces as well.
>> > >
>> > > My personal feeling is that most of the people using Shindig for a long
>> > > time now are here for its gadget rendering capabilities and the
>> potential
>> > > it provides towards a fully decoupled architecture where app devs can
>> > work
>> > > independently from platform devs but eventually everything can work
>> > > together a a whole with minimum orchestration efforts.  This has been
>> my
>> > > personal experience so far anyways.  Having said that, I've always felt
>> > > that the Shindig project had always been to large / broad in
>> > functionality
>> > > lacking clearly not dev but rather promotional & awareness efforts.
>> > >
>> > > Another factor that always helped me rest assured in a way regarding
>> its
>> > > usefulness and future  is that major companies like Google, Atlassian
>> and
>> > > others with very popular products have also been using this technology
>> > as a
>> > > core component of their infrastructure until now.  Although Google who
>> > > open-sourced the tech seems that it progressively deprecates some of
>> > their
>> > > products who had major touch points with the gadgets spec, still keeps
>> it
>> > > alive in products like Gmail, Google apps, etc plus they have been
>> > hosting
>> > > the official Gadgets API site for a long time now.  One of the puzzling
>> > > questions though is why these companies (apart from the IBM people who
>> > kept
>> > > the project running) were never openly involved with the promotion and
>> > > support of the tech in order to reach broader audiences through
>> real-life
>> > > use cases?  Correct me if I'm wrong but I've come to the conclusion
>> that
>> > > these companies are maintaining probably ports of certain Shindig
>> > > components that have extended them in order to meet their requirements.
>> > > This is easy to speculate since reading the documentation of their
>> > products
>> > > shows clearly that there are extensions not supported by Shindig
>> > > out-of-the-box - once I had a chat with a guy working at Jive at the
>> time
>> > > and he told me that they wrote their own security layer around their
>> > gadget
>> > > containers.
>> >
>> >
>> > > I'll have to agree with Darren that due to the robustness of the
>> > framework
>> > > most integrators are more than ok with the standard features it has to
>> > > offer and therefore this might have caused the side-effect to the
>> > > maintainers to since there are no new requests / ticket activities then
>> > > this framework has fulfilled its purpose and has become out of fashion.
>> > I
>> > > personally think that gadget tech has a future and a lot to offer when
>> it
>> > > comes down to specific use cases - dashboards and marketplaces being a
>> > > couple for starters.  After I received this mail today morning, I had a
>> > > quick search on the web to see if there are any real alternatives but I
>> > > found none.

Re: missing osapi endpoints

2015-07-09 Thread Henry Saputra

Hmm interesting, at least container.listMethods should exist.

Need to clean up all the missing endpoints for osapi

- Henry

On Tue, Jun 2, 2015 at 6:50 AM, Davies,Douglas davi...@oclc.org wrote:
 Has anyone ever seen the osapi endpoints missing from the request for the 
 shindig js?  I occasionally get back javascript that is missing the endpoints 
 and all my osapi calls fail (undefined).  For example here is a good response

 osapi.services:{gadgets.rpc:[container.listMethods],//%host%/opensocial/rpc:spaces.update
  spaces.delete albums.create http.head gadgets.token 
 activitystreams.supportedFields messages.modify userprefs.create 
 activities.create permissions.hasPermission containersecuritytoken.refresh 
 userprefs.get applications.get http.get spaces.supportedFields 
 mediaItems.delete spaces.get people.get gadgets.supportedFields 
 gadgets.cajaSupportedFields mediaItems.update http.put appdata.create 
 activitystreams.delete http.delete cache.invalidate albums.delete 
 userprefs.delete applications.create messages.delete appdata.update 
 people.update activities.supportedFields applications.update http.post 
 albums.get gadgets.cajole gadgets.proxySupportedFields applications.delete 
 people.supportedFields gadgets.metadata albums.supportedFields albums.update 
 spaces.create activities.delete mediaItems.get groups.get 
 applications.supportedFields mediaItems.supportedFields gadgets.proxy 
 activities.update gadgetContext.get activitystreams.create 
 activitystreams.get messages.get activitystreams.update mediaItems.create 
 messages.create gadgets.jsSupportedFields gadgets.tokenSupportedFields 
 activities.get gadgets.js appdata.get appdata.delete userprefs.update 
 system.listMethods.split( “)}

 and a bad one

 osapi.services:{gadgets.rpc:[container.listMethods”]}

 It seems to be a timing issue and MAY have been introduced when I started 
 using updateContainerSecurityToken refreshing (but I can’t say that for sure 
 — I only started seeing this when I implemented the refresh logic).

 Ideas what to look for?

 doug

Re: Creating a Feature

2015-02-26 Thread Henry Saputra

Just saw this one. Great post!

On Mon, Dec 22, 2014 at 11:12 AM, Matthew Miller millerm...@outlook.com wrote:
 Here's a new blog post about creating Shindig features. It took me a while to 
 get a new feature with parameters working, so I hope others can find this 
 info useful.
 http://yovaly.com/?p=64
 Matt

Re: Apache support for W3C Open Social

2014-06-11 Thread Henry Saputra

Sorry for late reply but +1 from Apache community and Shindig contributor

On Monday, June 9, 2014, Andy Seaborne a...@apache.org wrote:

 Hi there,

 W3C are looking for support in creating an Open Social WG.

 ASF is a member of W3C and can express such support (I'm the W3C AC rep
 for Apache - I push web buttons).

 I've had a request from Harry Halpin to add support - if this projects
 wants me to go ahead and express support, please let me know - the deadline
 is
 23:59, Boston time on 2014-06-10.

 the question are below:

 Activity:
 http://www.w3.org/2013/socialweb/social-activity-proposal.html
 Working Group:
 http://www.w3.org/2013/socialweb/social-wg-charter.html
 Interst Group:
 http://www.w3.org/2013/socialweb/social-ig-charter.html

 The survey covers:

 Q1::Support for the Proposal

 (choose one - can add a comment):

 My organization:
 * supports this Activity Proposal as is.

 * suggests changes to this Activity Proposal, but supports the proposal
 whether or not the changes are adopted (your details below).

 * suggests changes to this Activity Proposal, and only supports the
 proposal if the changes are adopted [Formal Objection] (your details below).

 * opposes this Activity Proposal and requests that this group be closed
 [Formal Objection] (your details below).
 * abstains from this review.



 Q2:: Support for Deliverables of the group
 (choose any that apply - can add a comment)

 My organization:
 * intends to review drafts as they are published and send comments.
 * intends to develop experimental implementations and send experience
 reports (your details below).
 * intends to develop products based on this work (your details below).
 * intends to apply this technology in our operations.
 * would be interested in participating in any press activity connected
 with this group.

 Andy
 VP W3C Relations.

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

2013-10-21 Thread Henry Saputra

Thx for pushing the release, Ryan

On Monday, October 21, 2013, Ryan Baxter wrote:

 No we have not yet, but I have been running Shindig with that fix in
 it and haven't seen any issues.  I don't think we can be any worse off
 at this point.

 Binding votes: Stanton, Paul, Ryan, Henry

 Vote passed I will start releasing the artifacts.

 On Mon, Oct 21, 2013 at 4:41 PM, Henry Saputra 
 henry.sapu...@gmail.comjavascript:;
 wrote:
  Signature looks good.
  Simple gadgets rendered.
  REST and JSON RPC looks good for non auth setting.
  +1 based on theses.
 
  Ryan, did IBM get chance to test it with OAuth2 implementation fix
  that originally block original release vote?
 
  - Henry
 
  On Tue, Oct 15, 2013 at 6:45 PM, Ryan Baxter 
  rbaxte...@apache.orgjavascript:;
 wrote:
  Hi,
 
  We solved 9 issues:
 
 https://issues.apache.org/jira/browse/SHINDIG-1940?jql=project%20%3D%20SHINDIG%20AND%20fixVersion%20%3D%20%222.5.0-update1%22%20AND%20status%20in%20(Resolved%2C%20Closed)
 
  Staging repo:
 
 https://repository.apache.org/content/repositories/orgapacheshindig-183/
 
  Web site:
  http://shindig.apache.org/
 
  Vote open for 72 hours.
 
  [ ] +1
  [ ] +0
  [ ] -1

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

2013-10-11 Thread Henry Saputra

Good catch, wonder if we can add some kind of unit test for this

On Thu, Oct 10, 2013 at 6:08 PM, Ryan Baxter rbaxte...@gmail.com wrote:
 I found this pretty nasty bug [1] today.  I'm thinking we need to fix
 this for update1.  Let me know if anyone disagrees.

 [1] https://issues.apache.org/jira/browse/SHINDIG-1937

 On Thu, Oct 10, 2013 at 5:20 PM, Paul Lindner pmlind...@gmail.com wrote:
 +1 from here.  Release looks good.


 On Thu Oct 10 2013 at 11:57:39 AM, Davies,Douglas davi...@oclc.org wrote:

 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:
 https://repository.apache.**org/content/repositories/**
 orgapacheshindig-132/https://repository.apache.org/content/repositories/orgapacheshindig-132/
 
 Web site:
 http://shindig.apache.org/
 
 Vote open for 72 hours.
 
 [ ] +1
 [ ] +0
 [ ] -1

Re: Draft Board Report For Oct. 2013

2013-09-30 Thread Henry Saputra

+1

Thanks Ryan

On Sun, Sep 29, 2013 at 5:24 PM, Ryan Baxter rbaxte...@gmail.com wrote:
 Hi Everyone,

 Our board report is due this month (by Oct 9th).  Here is the draft
 [1] I have put together.  If anyone has anything to add please let me
 know.

 -Ryan

 [1] 
 https://cwiki.apache.org/confluence/display/SHINDIG/October+2013+Board+Report

Re: Review Request 14406: Review Request: JSON RPC servlet does not support CORS properly

2013-09-30 Thread Henry Saputra


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/14406/#review26513
---


Is this a complete patch? I am seeing 
com.thetransactioncompany.cors.CORSFilter in the web.xml changes as part of 
the diff

- Henry Saputra


On Sept. 30, 2013, 6:02 p.m., Mike Pawlowski wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/14406/
 ---
 
 (Updated Sept. 30, 2013, 6:02 p.m.)
 
 
 Review request for shindig.
 
 
 Bugs: https://issues.apache.org/jira/browse/SHINDIG-1927
 
 https://issues.apache.org/jira/browse/https://issues.apache.org/jira/browse/SHINDIG-1927
 
 
 Repository: shindig
 
 
 Description
 ---
 
 Attached a patch to implement full CORS support in Apache Shindig via the 
 open source CORS servlet filter:
 
 Name: CORS Filter
 Version: 1.7.1
 Homepage: http://software.dzhuvinov.com/cors-filter.html
 License(s): Apache License, Version 2.0 (License link is broken)
 Downloaded From: http://search.maven.org/#browse%7C540685910
 Notes: N/A
 
 Name: Java Property Utility 
 Version: 1.9
 Homepage: http://software.dzhuvinov.com/cors-filter-installation.html
 License(s): Apache License, Version 2.0 (License link is broken)
 Downloaded From: http://search.maven.org/#browse%7C-89813813
 Notes: Required dependency for CORS Filter
 
 See JIRA issue for details: https://issues.apache.org/jira/browse/SHINDIG-1927
 
 Please note that this patch relies on the patch attached to the following 
 JIRA issue:
 Remove partial implementation of CORS support
 https://issues.apache.org/jira/browse/SHINDIG-1934
 
 
 Diffs
 -
 
   http://svn.apache.org/repos/asf/shindig/trunk/java/server-resources/pom.xml 
 1526722 
   
 http://svn.apache.org/repos/asf/shindig/trunk/java/server-resources/src/main/webapp/WEB-INF/web.xml
  1526722 
 
 Diff: https://reviews.apache.org/r/14406/diff/
 
 
 Testing
 ---
 
 * Build was successful (except for a few unrelated build hiccups)
 * Manual testing was successful
   = Test environment: 
 - (I) Shindig server deployed as a stand alone app hosted on its own 
 domain; 
 - (II) Common container utilized by another app hosted on its own 
 domain
   = Cross domain POST HTTP request was successful
   - e.g. 
 http://localhost:9082/rpc?st=ownerId%3AviewerId%3Aappid%3Ashindig%3Aurl%3A0%3Adefault
 
 
 Thanks,
 
 Mike Pawlowski

Re: removing Caja from Shindig

2013-09-09 Thread Henry Saputra

+1 for removing it

On Mon, Sep 9, 2013 at 3:56 PM, felix feli...@gmail.com wrote:
 The Caja support in Shindig is many versions out of date and not
 particularly maintained. AFAIK nobody uses it.

 The Caja project is moving toward a purely client-side JS
 implementation of Caja that works in modern browsers, and we're
 planning on removing the server-side Java code sometime this year.
 Updating Shindig to use the newer Caja is plausible, but seems
 pointless if nobody is using it.

 Any objection to removing the Caja from Shindig? I can write up the patch.

Re: Review Request 13923: EhCache provider always uses a singleton cache manager, even if it is the wrong one

2013-09-02 Thread Henry Saputra


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/13923/#review25837
---

Ship it!


Ship It!

- Henry Saputra


On Sept. 1, 2013, 1:13 p.m., Stanton Sievers wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/13923/
 ---
 
 (Updated Sept. 1, 2013, 1:13 p.m.)
 
 
 Review request for shindig.
 
 
 Bugs: SHINDIG-1931
 https://issues.apache.org/jira/browse/SHINDIG-1931
 
 
 Repository: shindig
 
 
 Description
 ---
 
 Reported on the dev list[1].  The issue is that the 
 CacheManager.create(Configuration) APIs will always use the same singleton, 
 regardless of whether the provided Configuration defines a cache manager of a 
 different name then the existing singleton.  We should use the 
 CacheManager.newInstance(Configuration) APIs, as this will use a singleton 
 per cache manager name.  This will keep us from stomping on other cache 
 managers that exist in the environment.
 
 [1] 
 http://markmail.org/message/4adopzvvi3ltv7yq?q=Shindig+list:org.apache.shindig.dev+order:date-backwardpage=1
 
 
 Diffs
 -
 
   
 http://svn.apache.org/repos/asf/shindig/trunk/java/common/src/main/java/org/apache/shindig/common/cache/ehcache/EhCacheCacheProvider.java
  1519267 
 
 Diff: https://reviews.apache.org/r/13923/diff/
 
 
 Testing
 ---
 
 Unit tests continue to pass.  Shindig starts and samples load in the sample 
 container.
 
 
 Thanks,
 
 Stanton Sievers

Re: startup error

2013-08-28 Thread Henry Saputra

Hi Doug,

Is there anything in the log to indicate which cache causing this problem?
Do you use Ehcache backed with disk write for full cache?

- Henry


On Wed, Aug 28, 2013 at 10:14 AM, 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 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 [expressions.datahread]
 net.sf.ehcache.store.disk.DiskStorageFactory - Disk Write of
 //%host%${CONTEXT_ROOT}/rpc failed:
 java.io.NotSerializableException: de.odysseus.el.tree.Tree

 In the logs (a lot of them) on startup.

 I'm going through and synching up our web.xml, etc.  I do know that we
 create our own ehcache for another one of our libraries we include.  Could
 be a conflict there.

 This happened somewhere between beta5 and release.

 Any pointer on what to look for?  I've combed through the release notes.
  I do see something about configuring ehcache (
 https://issues.apache.org/jira/browse/SHINDIG-1912).

 Doug Davies

Re: smooth

2013-08-22 Thread Henry Saputra

W00t! Nice to hear that Doug

- Henry


On Wed, Aug 21, 2013 at 6:00 PM, Davies,Douglas davi...@oclc.org wrote:

 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 the hard work.  And congrats to Ryan!

 Doug Davies
 OCLC

Re: Shindig 2.5 generate html for dialog preferences

2013-08-22 Thread Henry Saputra

Hi Maxim,

I believe with the common container, you need to build your own user
preference dialog but I think there is a hook to do this.

I will try to look more into this later at home.

CC Shindig dev list for this.

- Henry


On Thu, Aug 22, 2013 at 11:36 AM, Maxim Ognev mog...@ruswizards.com wrote:

 Hello.

 In one of the email you wrote:

 This feature should have been removed with the new Shindig's common
 container support under features/container directory.


 
   Hi All,

 
  In the following script:
 
 
  features/src/main/javascript/features/shindig.container/shindig-container.js
 
  ... there is a script being inserted from iGoogle:
 
  http://www.gmodules.com/ig/gadgetsettings
 

 I looked features/container, but I didn't see function a similar 
 buildUserPrefsDialog  from shindig-container.js



 Please, explain to me how to create UI dialog preference gadget in my web 
 site.



 Does this functionality in shindig version 2.5? Or I must create html for UI 
 dialog preference it myself.




 I can get JSON object from container.preloadGadgets , get Preferences object 
 from it and create html. But I think this is not  right decision. I'm looking 
 for ready implementation.

 Sorry, for my english.


 Maxim Ognev
  ASP.NET/C# http://asp.net/C#  Developer



  RUS Wizards LLC




  Skype: m.ognev

Re: Shindig preference template feature problem questions

2013-08-16 Thread Henry Saputra

Hi Mike, so looks like this is regression from 2.5.0 beta6 release?

- Henry


On Fri, Aug 16, 2013 at 9:27 AM, Mike Pawlowski mpaw...@ca.ibm.com wrote:



 Hi,

 I'm experiencing an issue with the preference templating feature in Shindig
 and have a few questions regarding it.

 Environment

 * Shindig 2.5.0 (final) - Java version
 * Using common container (osapi.container)
 * Cross-domain deployment
= i.e. OpenSocial gadget containers hosted from one domain and the
 OpenSocial gadget renderer hosted from another domain
= e.g.
  - Examples application (OS gadget container):
 http://localhost:9081/examples/gadgets
  - Shindig application (OS gadget renderer):
 http://localhost:9082/rpc, http://localhost:9082/gadgets/ifr, etc.
= Got working via minor Shindig modification  CORS Java servlet
 filters
  - See issue for more details:
 https://issues.apache.org/jira/browse/SHINDIG-1927

 Problem

 Several external 3rd-party gadgets fail to render properly using the common
 container (don't think it was an issue for
 the deprecated shindig.container in the above environment using Shindig
 2.5.0 Beta 6)
 e.g.
 (1) The Daily Puppy - http://dailypuppy.com/gmod/thedailypuppy.xml
 (2) NYTimes.com Top Stories -
 http://widgets.nytimes.com/packages/html/igoogle/topstories.xml
 (3) YouTube: http://www.gstatic.com/ig/modules/youtube/v3/youtube.xml
 (4) Hamster:

 http://hosting.gmodules.com/ig/gadgets/file/112581010116074801021/hamster.xml

 These gadgets are used as part of our sanity test suites.

 See issue for more details
 https://issues.apache.org/jira/browse/SHINDIG-1926

 Solution (Verified)

 Disable preference templating feature by adding
 shindig.urlgen.use-templates-default=false to shindig.properties and
 rebuilding Shindig
 (Recommended by Ryan). By default the common container uses templates for
 preferences.

 Questions

 (1) Is there any documentation on the preference templating feature
 describing it's usage  behaviour?
   = e.g. Wiki documents, API doc, specification references, etc.

 (2) Are there any third-party (external) gadgets or sample (internal)
 gadgets that make use of the templates feature?
  = i.e. Examples demonstrating how to use this feature

 (3) Will disabling the shindig.urlgen.use-templates-default option
 adversely affect the rendering of other gadgets using the common container?

 (4) Should Shindig be built by default with the preference templating
 feature disabled (i.e. shindig.urlgen.use-templates-default=false)?
  = e.g. Since, it causes regressions in a number of external 3rd-party
 gadgets
  = I'm not sure what the commonality is between these gadgets that
 causes rendering issues


 Thanks,

 Mike

Re: [VOTE] New PMC Chair Ryan Baxter

2013-08-10 Thread Henry Saputra

+1


On Fri, Aug 9, 2013 at 4:38 PM, Paul Lindner lind...@inuus.com wrote:

 I'm officially resigning as Shindig PMC Chair.  Lucky for us Ryan Baxter
 has indicated his interest.  He's done a great job getting 2.5 out the door
 and I would be happy with him leading our group.

 And not to worry, I'll continue to be present, squeezing out some patches
 here and there.

 VOTE

 [  ] +1
 [  ] 0
 [  ] -1

 Vote open for 72h.

 Once approved by the PMC I will submit the change of Chair to the Apache
 Board.

 Cheers!
 Paul

 --
 Paul Lindner -- lind...@inuus.com -- profiles.google.com/pmlindner

Re: Shindig NEXT

2013-08-07 Thread Henry Saputra

The OpenSocial specs have major.minor.revision versioning scheme, so the
discussion is either we follow OpenSocial versioning up to the revision
or just major.minor.

If we want to follow up to the revision part then we need to add
-updateXXX or rXXX tail in Apache Shindig versioning which I think a
bit ugly (see Hadoop release versions, ugh)

- Henry


On Tue, Aug 6, 2013 at 10:30 PM, Marcel Offermans 
marcel.offerm...@luminis.nl wrote:

 Maybe it makes sense to use semantic versioning, as described here:
 http://semver.org/

 If indeed the specs are major.minor then you can implement with
 major.minor.patch

 Greetings, Marcel

 On Aug 7, 2013, at 7:14 AM, Craig McClanahan craig...@gmail.com wrote:

  FWIW an approach to version numbers I have seen a lot is that the
  major.minor version numbers match the spec being implemented (2.5 in this
  case), but anything after that is totally up to the implementation.  So,
  2.5.1 ... 2.5.2 ... etc. would be fine for improved implementations of
 the
  2.5 spec.
 
  It's also perfectly reasonable to think about 2.5.1-rc1 and 2.5.1-rc2
 (and
  so on) for release candidates of 2.5.1 before a final 2.5.1 release.
 
  Craig
 
 
  On Tue, Aug 6, 2013 at 2:03 PM, Ryan Baxter rbaxte...@gmail.com wrote:
 
  Henry does JSF use revision numbers or do they stick to major and
  minor version only?  If the revision numbers are not going to match
  anyways than maybe we shouldn't worry about calling the next Shindig
  release 2.5.1.
 
  On Mon, Aug 5, 2013 at 9:41 PM, Henry Saputra henry.sapu...@gmail.com
  wrote:
  The next version of Shindig will contain the first release without PHP.
  I believe that's worth a bump in revision part of the version to 2.5.1.
 
  @Ryan, I would love to keep it in-sync but Shindig will move faster
 than
  spec development and it would be hard to keep up with the exact
 version.
  I believe other projects like Apache Tomcat and Apache MyFaces (latest
  release is 2.1.12 that implement JSF 2.1) that also implement open
 specs
  follow its release version up to certain levels.
 
  I like @Matt's idea, we could release  2.5.1-alphaX releases but final
  release should be 2.5.1 but branching early to add minor emergency
 fixes
  with 2.5.0-update1.
 
  - Henry
 
 
 
  On Mon, Aug 5, 2013 at 5:08 PM, Matt Franklin 
 m.ben.frank...@gmail.com
  wrote:
 
 
  On Aug 5, 2013, at 20:03, Henry Saputra henry.sapu...@gmail.com
  wrote:
 
  I am actually still +1 for just 2.5.1. We agreed that Shindig version
  will
  adhere to OpenSocial specs up to minor version which in this case is
  2.5.x
 
  What about developing in trunk at 2.5.1-alphaX and branching for fixes
  in
  2.5.0-update1?
 
  I also think 2.5.1 should be relatively minor in changes to the
  software
  itself.  Ideally, only additions and no breaking changes to existing
  interfaces, etc.
 
 
 
  - Henry
 
 
  On Mon, Aug 5, 2013 at 4:50 PM, Ryan Baxter rbaxte...@gmail.com
  wrote:
 
  Here is what I found on version numbers [1].  From what I gather
  after
  reading that using 2.5.0.1 would be considered non-standard.  The
  only downside to this would be the version numbers would be compared
  as strings.  We could use 2.5.0-fix1 which would be considered
  standard, but I don't think that buys us anything with regards to
  version comparison.  I could pose a question to the Maven users list
  and see if they have any advice.
 
  [1]
 
 
 
 http://books.sonatype.com/mvnref-book/reference/pom-relationships-sect-pom-syntax.html
 
  On Mon, Aug 5, 2013 at 7:34 PM, Stanton Sievers 
 ssiev...@apache.org
 
  wrote:
  +1. Shindig-1924 is one such cleanup. I also agree with staying in
  line
  with the spec.
 
  I would just want to make sure we have no technical or process
  issues
  with
  maven artifacts (or the like) with 4 numbers in the version.
  On Aug 5, 2013 7:29 PM, Ryan Baxter rbaxte...@apache.org
  wrote:
 
  The current version of trunk is set to 2.5.1.  I am wondering what
  people think of changing that to 2.5.0.1?  There are a few cleanup
  changes that have already been identified that would be good to
 get
  out there.  At same time we want to stay in sync with the spec
  version
  so I don't think we want to release 2.5.1 yet.  What does everyone
  think?

Re: [ANN] Apache Shindig 2.5.0 Released

2013-08-05 Thread Henry Saputra

W00t! Thanks to Ryan to driving this home =)

- Henry


On Sun, Aug 4, 2013 at 11:00 AM, Ryan Baxter rbaxte...@apache.org wrote:

 The Apache Shindig team is proud to announce the release
 of Apache Shindig, version 2.5.0.

 Apache Shindig is a JavaScript container and
 implementations of the backend APIs and proxy required for hosting
 OpenSocial applications.

 http://shindig.apache.org/

 Enjoy,

 -The Apache Shindig Team

Re: [ANN] Apache Shindig 2.5.0 Released

2013-08-05 Thread Henry Saputra

With 2.5.0 out of the door I will proceed with moving PHP version to
Shindig's attic.

If anyone has issue or problem please say it now or forever hold your peace
=)

- Henry


On Sun, Aug 4, 2013 at 11:00 AM, Ryan Baxter rbaxte...@apache.org wrote:

 The Apache Shindig team is proud to announce the release
 of Apache Shindig, version 2.5.0.

 Apache Shindig is a JavaScript container and
 implementations of the backend APIs and proxy required for hosting
 OpenSocial applications.

 http://shindig.apache.org/

 Enjoy,

 -The Apache Shindig Team

Re: Shindig NEXT

2013-08-05 Thread Henry Saputra

I am actually still +1 for just 2.5.1. We agreed that Shindig version will
adhere to OpenSocial specs up to minor version which in this case is 2.5.x

- Henry


On Mon, Aug 5, 2013 at 4:50 PM, Ryan Baxter rbaxte...@gmail.com wrote:

 Here is what I found on version numbers [1].  From what I gather after
 reading that using 2.5.0.1 would be considered non-standard.  The
 only downside to this would be the version numbers would be compared
 as strings.  We could use 2.5.0-fix1 which would be considered
 standard, but I don't think that buys us anything with regards to
 version comparison.  I could pose a question to the Maven users list
 and see if they have any advice.

 [1]
 http://books.sonatype.com/mvnref-book/reference/pom-relationships-sect-pom-syntax.html

 On Mon, Aug 5, 2013 at 7:34 PM, Stanton Sievers ssiev...@apache.org
 wrote:
  +1. Shindig-1924 is one such cleanup. I also agree with staying in line
  with the spec.
 
  I would just want to make sure we have no technical or process issues
 with
  maven artifacts (or the like) with 4 numbers in the version.
  On Aug 5, 2013 7:29 PM, Ryan Baxter rbaxte...@apache.org wrote:
 
  The current version of trunk is set to 2.5.1.  I am wondering what
  people think of changing that to 2.5.0.1?  There are a few cleanup
  changes that have already been identified that would be good to get
  out there.  At same time we want to stay in sync with the spec version
  so I don't think we want to release 2.5.1 yet.  What does everyone
  think?

Re: Releasing 2.5.0

2013-07-10 Thread Henry Saputra

Did the patch for https://reviews.apache.org/r/9990/ already committed to
trunk? I saw Jame's JIRA ticket still open.

- Henry


On Wed, Jul 10, 2013 at 4:39 PM, Ryan Baxter rbaxte...@apache.org wrote:

 I think we are ready to do a release of 2.5.0.  If no one objects I
 will start the process.

 -Ryan

Re: Problem with hangout js APIs using Shindig

2013-06-27 Thread Henry Saputra

Do you know where does the API coming from? Shindig container will not have
those APIs.

- Henry


On Wed, Jun 26, 2013 at 2:50 AM, Sagar Shah
sagar.s...@agreeyamobility.netwrote:

  Hi All,

  I have a use-case where I want to run the hangout app in a standalone
 container instead of the Google Hangout.
 For that, I'm trying to run my Gadget XML inside the Shindig container.
 The Gadget XML consist of authentication with Google+ which works fine.
 After that I'm trying to access the hangout APIs. But, the APIs are
 returning false and empty values. (Attaching the sample XML file here).

  Code snippet for the first hangout api is,

function startMyApp() {
 console.log(Hurray API Ready);
   }

   function init() {
 try {
 gapi.hangout.onApiReady.add(**function (eventObj) {
 if (eventObj.isApiReady) {
 startMyApp();
 }
 });
 } catch (e) {
console.log(e.stack);
 }
   }

  Please let me know if there is anything additional handling required in
 the code?

  Thanks,
 Sagar.

 *Unified Collaboration and Communication for Office 365, SharePoint, and
 Lync*

 http://www.onvelop.com | Available on Android | iOS | Windows 8

Re: W3C / OpenSocial Workshop Meetup

2013-05-31 Thread Henry Saputra

Will you be in town? We should grab some beers =)

- Henry


On Fri, May 31, 2013 at 4:33 PM, Matt Franklin m.ben.frank...@gmail.comwrote:

 I just wanted to make sure everyone was aware of the upcoming workshop on
 social standards that will be taking place in San Francisco, CA on August
 7-8 [1].  This workshop will hopefully start to align some of the various
 specifications around the social web (OpenSocial, ActivityStreams, Open
 Graph, etc).  I imagine that we will see some discussion around the various
 app models (gadgets, widgets, etc).

 Prior to the Workshop, there is a meeting in Boston on June 18th [2] after
 the second day of Enterprise 2.0.

 I hope to see some of you there!

 [1]:  http://www.w3.org/2013/socialweb/Overview.html
 [2]:  http://socialbizstandards.eventbrite.com/

Re: Review Request: configurable to support different SHA algorithm

2013-05-31 Thread Henry Saputra


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/11299/#review21281
---


Any JIRA opened for these proposed changes?

- Henry Saputra


On May 29, 2013, 7:27 a.m., Zhi Hong Yang wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/11299/
 ---
 
 (Updated May 29, 2013, 7:27 a.m.)
 
 
 Review request for shindig, Ryan Baxter, Dan Dumont, Stanton Sievers, and 
 Rich Thompson.
 
 
 Description
 ---
 
 
 the following setting are added to support different algorithms:
 
 1) shindig.crypo.preferredHashAlgorithms = SHA, SHA-256, SHA-384, SHA-512 
 
 this setting is used to set string hash algorithm, all supported hash 
 Algorithms is listed and the first one is supported by default. 
 
 2) shindig.crypo.preferredHMACAlgorithms = 
 HMACSHA1,HMACSHA256,HMACSHA384,HMACSHA512
 
 this setting is used to set string encrypt/decrypt algorithm, all supported 
 HMA SHA algorithms is listed and the first one is supported by default
 
 
 Diffs
 -
 
   
 http://svn.apache.org/repos/asf/shindig/trunk/java/common/src/main/java/org/apache/shindig/auth/BlobCrypterSecurityTokenCodec.java
  1484375 
   
 http://svn.apache.org/repos/asf/shindig/trunk/java/common/src/main/java/org/apache/shindig/common/crypto/BasicBlobCrypter.java
  1484375 
   
 http://svn.apache.org/repos/asf/shindig/trunk/java/common/src/main/java/org/apache/shindig/common/crypto/Crypto.java
  1484375 
   
 http://svn.apache.org/repos/asf/shindig/trunk/java/common/src/main/java/org/apache/shindig/common/util/DigestType.java
  PRE-CREATION 
   
 http://svn.apache.org/repos/asf/shindig/trunk/java/common/src/main/java/org/apache/shindig/common/util/GenericDigestUtils.java
  PRE-CREATION 
   
 http://svn.apache.org/repos/asf/shindig/trunk/java/common/src/main/java/org/apache/shindig/common/util/HMACType.java
  PRE-CREATION 
   
 http://svn.apache.org/repos/asf/shindig/trunk/java/common/src/test/java/org/apache/shindig/auth/BlobCrypterSecurityTokenCodecTest.java
  1484375 
   
 http://svn.apache.org/repos/asf/shindig/trunk/java/common/src/test/java/org/apache/shindig/auth/BlobCrypterSecurityTokenTest.java
  1484375 
   
 http://svn.apache.org/repos/asf/shindig/trunk/java/common/src/test/java/org/apache/shindig/common/crypto/BlobCrypterTest.java
  1484375 
   
 http://svn.apache.org/repos/asf/shindig/trunk/java/common/src/test/java/org/apache/shindig/common/crypto/CryptoTest.java
  1484375 
   
 http://svn.apache.org/repos/asf/shindig/trunk/java/gadgets/src/main/java/org/apache/shindig/gadgets/DefaultGuiceModule.java
  1484375 
   
 http://svn.apache.org/repos/asf/shindig/trunk/java/gadgets/src/main/java/org/apache/shindig/gadgets/HashLockedDomainService.java
  1484375 
   
 http://svn.apache.org/repos/asf/shindig/trunk/java/gadgets/src/main/java/org/apache/shindig/gadgets/oauth/OAuthRequest.java
  1484375 
   
 http://svn.apache.org/repos/asf/shindig/trunk/java/gadgets/src/main/java/org/apache/shindig/gadgets/oauth2/handler/MacTokenHandler.java
  1484375 
   
 http://svn.apache.org/repos/asf/shindig/trunk/java/gadgets/src/main/java/org/apache/shindig/gadgets/uri/HashShaLockedDomainPrefixGenerator.java
  1484375 
   
 http://svn.apache.org/repos/asf/shindig/trunk/java/gadgets/src/test/java/org/apache/shindig/gadgets/oauth/testing/FakeOAuthServiceProvider.java
  1484375 
   
 http://svn.apache.org/repos/asf/shindig/trunk/java/social-api/src/main/java/org/apache/shindig/social/core/oauth/OAuthAuthenticationHandler.java
  1484375 
   
 http://svn.apache.org/repos/asf/shindig/trunk/java/social-api/src/test/java/org/apache/shindig/social/core/oauth/FakeOAuthRequest.java
  1484375 
   
 http://svn.apache.org/repos/asf/shindig/trunk/java/social-api/src/test/java/org/apache/shindig/social/core/oauth/OAuthAuthenticationHanderTest.java
  1484375 
 
 Diff: https://reviews.apache.org/r/11299/diff/
 
 
 Testing
 ---
 
 Done. 
 
 
 Thanks,
 
 Zhi Hong Yang

Re: W3C / OpenSocial Workshop Meetup

2013-05-31 Thread Henry Saputra

Dood, please file your travel request now :)

Henry

On Friday, May 31, 2013, Ryan Baxter wrote:

 If I make it there Henry I will def grab some beers with you guys!

 On Fri, May 31, 2013 at 8:51 PM, Henry Saputra 
 henry.sapu...@gmail.comjavascript:;
 wrote:
  Will you be in town? We should grab some beers =)
 
  - Henry
 
 
  On Fri, May 31, 2013 at 4:33 PM, Matt Franklin 
  m.ben.frank...@gmail.comjavascript:;
 wrote:
 
  I just wanted to make sure everyone was aware of the upcoming workshop
 on
  social standards that will be taking place in San Francisco, CA on
 August
  7-8 [1].  This workshop will hopefully start to align some of the
 various
  specifications around the social web (OpenSocial, ActivityStreams, Open
  Graph, etc).  I imagine that we will see some discussion around the
 various
  app models (gadgets, widgets, etc).
 
  Prior to the Workshop, there is a meeting in Boston on June 18th [2]
 after
  the second day of Enterprise 2.0.
 
  I hope to see some of you there!
 
  [1]:  http://www.w3.org/2013/socialweb/Overview.html
  [2]:  http://socialbizstandards.eventbrite.com/

Re: [Shindig Wiki] Trivial Update of VanizHigh by VanizHigh

2013-05-22 Thread Henry Saputra

Thats funny because I thought our wiki is in
https://cwiki.apache.org/SHINDIG and powered by Atlassian.

I dont think we have moinmoin wiki for
http://wiki.apache.org/shindighttp://wiki.apache.org/shindig/VanizHigh
 right?


- Henry


On Sun, Apr 14, 2013 at 5:12 PM, Ryan Baxter rbaxte...@gmail.com wrote:

 I deleted all the spam pages.  I found this page [1] which seems to
 indicate we should upgrade the wiki to help with the spam.

 [1] http://wiki.apache.org/shindig/BadContent

 On Sun, Apr 14, 2013 at 7:57 PM, Ian Boston i...@tfd.co.uk wrote:
  I am almost certain on other projects the PMC manages the spam. (or tries
  to).
  Ian
 
 
  On 15 April 2013 08:30, Ryan Baxter rbaxte...@apache.org wrote:
 
  Does anyone know if infra manages this wiki?  There seems to be a
  bunch of spam on there recently and I want to see if there is anything
  we can do?
 
  On Sat, Apr 13, 2013 at 8:18 PM, Apache Wiki wikidi...@apache.org
 wrote:
   Dear Wiki user,
  
   You have subscribed to a wiki page or wiki category on Shindig Wiki
  for change notification.
  
   The VanizHigh page has been changed by VanizHigh:
   http://wiki.apache.org/shindig/VanizHigh
  
   New page:
   There is nothing to tell about myself really.BR
   Feels good to be a member of this site.BR
   I just hope I am useful at allBR
   BR
   My web-site ... [[
 https://pipl.com/directory/name/Chekroun/Maurice/|justclick the up coming
 article]]

Re: [RESULT] [VOTE] Remove the Java sample project for Apache Shindig 2.5.0 release

2013-05-16 Thread Henry Saputra

VOTE is done:

2 +1 : Henry, Ryan
No 0
No -1

So I will create JIRA and remove the sample project from Shindig Java.

Thanks for participating!

- Henry


On Mon, May 13, 2013 at 12:37 PM, Henry Saputra henry.sapu...@gmail.comwrote:

 Since there is no more comment in the previous email discussion about the
 Java sample project I would like to propose VOTE to remove it.

 The reason for the proposal simply because there arent many contributors
 in Apache Shindig nor users to maintain this sub project.

 With our new initiative to keep up with the OpenSocial spec and be true to
 make Shindig as reference implementation, we need to make it easier to
 comply with the specs.

 So, this is  the VOTE to remove the Java/sample project from Apache
 Shindig.


 -1   [ ] I disagree because ...
 0[ ] I am ok with either
 +1  [ ] Let's do it!

 The VOTE is open for 72 hours. Only PMC votes are binding but all are
 encouraged to particiapte.


 Thanks,

 Henry

 P.S:

 Here is my vote: +1

Re: [RESULT] [VOTE] Remove the Java sample project for Apache Shindig 2.5.0 release

2013-05-16 Thread Henry Saputra

https://issues.apache.org/jira/browse/SHINDIG-1917


On Thu, May 16, 2013 at 1:36 PM, Henry Saputra henry.sapu...@gmail.comwrote:

 VOTE is done:

 2 +1 : Henry, Ryan
 No 0
 No -1

 So I will create JIRA and remove the sample project from Shindig Java.

 Thanks for participating!

 - Henry



 On Mon, May 13, 2013 at 12:37 PM, Henry Saputra 
 henry.sapu...@gmail.comwrote:

 Since there is no more comment in the previous email discussion about the
 Java sample project I would like to propose VOTE to remove it.

 The reason for the proposal simply because there arent many contributors
 in Apache Shindig nor users to maintain this sub project.

 With our new initiative to keep up with the OpenSocial spec and be true
 to make Shindig as reference implementation, we need to make it easier to
 comply with the specs.

 So, this is  the VOTE to remove the Java/sample project from Apache
 Shindig.


 -1   [ ] I disagree because ...
 0[ ] I am ok with either
 +1  [ ] Let's do it!

 The VOTE is open for 72 hours. Only PMC votes are binding but all are
 encouraged to particiapte.


 Thanks,

 Henry

 P.S:

 Here is my vote: +1

[VOTE] Remove the Java sample project for Apache Shindig 2.5.0 release

2013-05-13 Thread Henry Saputra

Since there is no more comment in the previous email discussion about the
Java sample project I would like to propose VOTE to remove it.

The reason for the proposal simply because there arent many contributors in
Apache Shindig nor users to maintain this sub project.

With our new initiative to keep up with the OpenSocial spec and be true to
make Shindig as reference implementation, we need to make it easier to
comply with the specs.

So, this is  the VOTE to remove the Java/sample project from Apache Shindig.


-1   [ ] I disagree because ...
0[ ] I am ok with either
+1  [ ] Let's do it!

The VOTE is open for 72 hours. Only PMC votes are binding but all are
encouraged to particiapte.


Thanks,

Henry

P.S:

Here is my vote: +1

[DISCUSS] Remove the java sample module for 2.5.0 (Previously: Getting Ready To Release 2.5.0)

2013-05-07 Thread Henry Saputra

I am trying to fix the JPA example but even the schema has changed since
the last time any code is committed. Too much work to maintain this module
when OpenSocial specs are moving as fast as it is right now.

I am proposing to dump this java-samples module because its getting harder
to maintain. We will rely on unit tests and sample app using the JSON
schema.

- Henry

On Fri, May 3, 2013 at 6:19 PM, Ryan Baxter rbaxte...@apache.org wrote:

I don't think so. I get test failures in that project not compile
errors. Although I just checked in changes for the compiler level to
move it to 1.6 so you might want to update and try again.

On Wed, May 1, 2013 at 2:55 AM, Henry Saputra henry.sapu...@gmail.com
wrote:
Hmm I got compile erro when tried to run mvn clean test in java/samples
dir:

[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-compiler-plugin:2.3.2:testCompile
(default-testCompile) on project shindig-samples: Compilation failure
[ERROR]

/Users/hsaputra/shindig/trunk/java/samples/src/test/java/org/apache/shindig/social/opensocial/jpa/spi/integration/JpaRestfulTestConfigHelper.java:[83,11]
cannot find symbol
[ERROR] symbol : method setJSONPAllowed(boolean)
[ERROR] location: class org.apache.shindig.protocol.DataServiceServlet
[ERROR] - [Help 1]
[ERROR]

Is this the same error?

- Henry

On Tue, Apr 30, 2013 at 5:23 PM, Ryan Baxter rbaxte...@apache.org
wrote:

Not really a blocker in my opinion, but I felt like we were close to
getting it in so I would at least try to make the effort ;)

On Tue, Apr 30, 2013 at 1:32 PM, Henry Saputra henry.sapu...@gmail.com

wrote:
Ugh sorry for late reply. No I did not have time to look at it.

I guess it is blocker for 2.5? I will take a look at it later today.

- Henry

On Fri, Apr 19, 2013 at 12:50 PM, Ryan Baxter rbaxte...@gmail.com
wrote:

Henry, have you had a sometime to look into this at all? Would like
to get this into 2.5.

On Mon, Mar 18, 2013 at 2:38 PM, Ryan Baxter rbaxte...@gmail.com
wrote:
Yes I just uploaded the newest patch from my workspace, if you
have a
chance take a look at the samples module. I am just not familiar
enough with JPA to know what is wrong...

On Mon, Mar 18, 2013 at 2:26 PM, Henry Saputra
henry.sapu...@gmail.com
wrote:
I fixed couple issues before. So the patches for the udpated data
model
is
in that review entry?

I can try it out.

- Henry

On Mon, Mar 18, 2013 at 11:02 AM, Ryan Baxter
rbaxte...@apache.org
wrote:

Henry I actually have most of the 2 patches integrated together
[1].
I need to some help with the JPA stuff some of the unit tests are
failing, are you familiar with that code at all?

[1] https://reviews.apache.org/r/9990/

On Mon, Mar 18, 2013 at 1:46 PM, Henry Saputra
henry.sapu...@gmail.com
wrote:
Yeah, I have been distracted with so many items so did not have
time
to
finish it =(

Do you guys think it is a blocker for 2.5.0 release?

- Henry

On Sun, Mar 17, 2013 at 1:51 PM, Ryan Baxter
rbaxte...@apache.org
wrote:

I dont think we have a list of them per-say. Looking through
the
JIRAs labeled with 2.5.0 I found SHINDIG-1539 [1] which tries
to
few
some gaps in the social data objects. I updated the patch
from
James
so it builds against trunk and created a review for it [2]. I
think
SHINDIG-1539 and SHINDIG-1878 are pretty much dups. We should
apply
one of the reviews and close both of them. I am try and see
if
there
are differences between the two.

The other gap I can think of is the External Services section
in
the
spec [3]. @Henry weren't you working on a patch for this?

[1] https://issues.apache.org/jira/browse/SHINDIG-1539
[2] https://reviews.apache.org/r/9990/
[3]

http://opensocial-resources.googlecode.com/svn/spec/trunk/Core-Gadget.xml#ExternalServices

On Sat, Mar 16, 2013 at 11:54 AM, Henry Saputra
henry.sapu...@gmail.com
wrote:
Not exactly, we have using JIRA to capture the differences.
Mostly the
differences come from the data model where new fields are
introduced
or
have name changes.

The big ticket AFAIK is SHINDIG-1878.

I am +1 and reccommend for 2.5.0 release. It is been long
overdue
and
everybody have been putting a lot of good work.

Thanks,

Henr

On Sat, Mar 16, 2013 at 7:34 AM, Matt Franklin
m.ben.frank...@gmail.com
wrote:

On Saturday, March 16, 2013, Ryan Baxter wrote:

Hey everyone,

2.5.0-beta6 is out the door (thanks everyone for their
hard
work)
and
I think we are at a point where 2.5.0 is pretty much
ready

Re: [DISCUSS] Remove the java sample module for 2.5.0 (Previously: Getting Ready To Release 2.5.0)

2013-05-07 Thread Henry Saputra

Not much but once we do it then we need to keep it up to date whenever new
schema changes occur. Even though we have Java devs in dev list maybe not
all play around with JPA and hibernate all day to be able to update the
sample Java module.

If I have do not hear any objection or comment for 72 hours about keeping
the Java sample project I will send VOTE thread to remove it for final
2.5.0 build.

Including users@ list for completion of this discussion.

- Henry

On Tue, May 7, 2013 at 1:09 PM, Ryan Baxter rbaxte...@apache.org wrote:

So it is going to be a lot of work to update the schema to make it
match the spec? I am not attached to samples in this case. I think
having proper documentation on how to provide your own implementations
is just as valuable as a sample in this case.

On Tue, May 7, 2013 at 1:42 PM, Henry Saputra henry.sapu...@gmail.com
wrote:
I am trying to fix the JPA example but even the schema has changed since
the last time any code is committed. Too much work to maintain this
module
when OpenSocial specs are moving as fast as it is right now.

I am proposing to dump this java-samples module because its getting
harder
to maintain. We will rely on unit tests and sample app using the JSON
schema.

- Henry

On Fri, May 3, 2013 at 6:19 PM, Ryan Baxter rbaxte...@apache.org
wrote:

I don't think so. I get test failures in that project not compile
errors. Although I just checked in changes for the compiler level to
move it to 1.6 so you might want to update and try again.

On Wed, May 1, 2013 at 2:55 AM, Henry Saputra henry.sapu...@gmail.com
wrote:
Hmm I got compile erro when tried to run mvn clean test in
java/samples
dir:

[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-compiler-plugin:2.3.2:testCompile
(default-testCompile) on project shindig-samples: Compilation failure
[ERROR]

Is this the same error?

- Henry

On Tue, Apr 30, 2013 at 5:23 PM, Ryan Baxter rbaxte...@apache.org
wrote:

Not really a blocker in my opinion, but I felt like we were close to
getting it in so I would at least try to make the effort ;)

On Tue, Apr 30, 2013 at 1:32 PM, Henry Saputra
henry.sapu...@gmail.com

wrote:
Ugh sorry for late reply. No I did not have time to look at it.

I guess it is blocker for 2.5? I will take a look at it later
today.

- Henry

On Fri, Apr 19, 2013 at 12:50 PM, Ryan Baxter rbaxte...@gmail.com

wrote:

Henry, have you had a sometime to look into this at all? Would
like
to get this into 2.5.

On Mon, Mar 18, 2013 at 2:38 PM, Ryan Baxter rbaxte...@gmail.com

wrote:
Yes I just uploaded the newest patch from my workspace, if you
have a
chance take a look at the samples module. I am just not
familiar
enough with JPA to know what is wrong...

On Mon, Mar 18, 2013 at 2:26 PM, Henry Saputra
henry.sapu...@gmail.com
wrote:
I fixed couple issues before. So the patches for the udpated
data
model
is
in that review entry?

I can try it out.

- Henry

On Mon, Mar 18, 2013 at 11:02 AM, Ryan Baxter
rbaxte...@apache.org
wrote:

Henry I actually have most of the 2 patches integrated
together
[1].
I need to some help with the JPA stuff some of the unit tests
are
failing, are you familiar with that code at all?

[1] https://reviews.apache.org/r/9990/

On Mon, Mar 18, 2013 at 1:46 PM, Henry Saputra
henry.sapu...@gmail.com
wrote:
Yeah, I have been distracted with so many items so did not
have
time
to
finish it =(

Do you guys think it is a blocker for 2.5.0 release?

- Henry

On Sun, Mar 17, 2013 at 1:51 PM, Ryan Baxter
rbaxte...@apache.org
wrote:

I dont think we have a list of them per-say. Looking
through
the
JIRAs labeled with 2.5.0 I found SHINDIG-1539 [1] which
tries
to
few
some gaps in the social data objects. I updated the patch
from
James
so it builds against trunk and created a review for it
[2]. I
think
SHINDIG-1539 and SHINDIG-1878 are pretty much dups. We
should
apply
one of the reviews and close both of them. I am try and
see
if
there
are differences between the two.

The other gap I can think of is the External Services
section
in
the
spec [3]. @Henry weren't you working on a patch for this?

[1] https://issues.apache.org/jira/browse/SHINDIG-1539

Re: Getting Ready To Release 2.5.0

2013-05-01 Thread Henry Saputra

Hmm I got compile erro when tried to run mvn clean test in java/samples dir:

[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-compiler-plugin:2.3.2:testCompile
(default-testCompile) on project shindig-samples: Compilation failure
[ERROR]
/Users/hsaputra/shindig/trunk/java/samples/src/test/java/org/apache/shindig/social/opensocial/jpa/spi/integration/JpaRestfulTestConfigHelper.java:[83,11]
cannot find symbol
[ERROR] symbol : method setJSONPAllowed(boolean)
[ERROR] location: class org.apache.shindig.protocol.DataServiceServlet
[ERROR] - [Help 1]
[ERROR]

Is this the same error?

- Henry

On Tue, Apr 30, 2013 at 5:23 PM, Ryan Baxter rbaxte...@apache.org wrote:

Not really a blocker in my opinion, but I felt like we were close to
getting it in so I would at least try to make the effort ;)

On Tue, Apr 30, 2013 at 1:32 PM, Henry Saputra henry.sapu...@gmail.com
wrote:
Ugh sorry for late reply. No I did not have time to look at it.

I guess it is blocker for 2.5? I will take a look at it later today.

- Henry

On Fri, Apr 19, 2013 at 12:50 PM, Ryan Baxter rbaxte...@gmail.com
wrote:

Henry, have you had a sometime to look into this at all? Would like
to get this into 2.5.

On Mon, Mar 18, 2013 at 2:38 PM, Ryan Baxter rbaxte...@gmail.com
wrote:
Yes I just uploaded the newest patch from my workspace, if you have a
chance take a look at the samples module. I am just not familiar
enough with JPA to know what is wrong...

On Mon, Mar 18, 2013 at 2:26 PM, Henry Saputra
henry.sapu...@gmail.com
wrote:
I fixed couple issues before. So the patches for the udpated data
model
is
in that review entry?

I can try it out.

- Henry

On Mon, Mar 18, 2013 at 11:02 AM, Ryan Baxter rbaxte...@apache.org
wrote:

Henry I actually have most of the 2 patches integrated together [1].
I need to some help with the JPA stuff some of the unit tests are
failing, are you familiar with that code at all?

[1] https://reviews.apache.org/r/9990/

On Mon, Mar 18, 2013 at 1:46 PM, Henry Saputra
henry.sapu...@gmail.com
wrote:
Yeah, I have been distracted with so many items so did not have
time
to
finish it =(

Do you guys think it is a blocker for 2.5.0 release?

- Henry

On Sun, Mar 17, 2013 at 1:51 PM, Ryan Baxter
rbaxte...@apache.org
wrote:

I dont think we have a list of them per-say. Looking through the
JIRAs labeled with 2.5.0 I found SHINDIG-1539 [1] which tries to
few
some gaps in the social data objects. I updated the patch from
James
so it builds against trunk and created a review for it [2]. I
think
SHINDIG-1539 and SHINDIG-1878 are pretty much dups. We should
apply
one of the reviews and close both of them. I am try and see if
there
are differences between the two.

The other gap I can think of is the External Services section in
the
spec [3]. @Henry weren't you working on a patch for this?

[1] https://issues.apache.org/jira/browse/SHINDIG-1539
[2] https://reviews.apache.org/r/9990/
[3]

http://opensocial-resources.googlecode.com/svn/spec/trunk/Core-Gadget.xml#ExternalServices

The big ticket AFAIK is SHINDIG-1878.

I am +1 and reccommend for 2.5.0 release. It is been long
overdue
and
everybody have been putting a lot of good work.

Thanks,

Henr

On Sat, Mar 16, 2013 at 7:34 AM, Matt Franklin
m.ben.frank...@gmail.com
wrote:

On Saturday, March 16, 2013, Ryan Baxter wrote:

Hey everyone,

2.5.0-beta6 is out the door (thanks everyone for their hard
work)
and
I think we are at a point where 2.5.0 is pretty much ready
for
a
release. Defects have been slow to come in over the past
few
weeks
and from my point of view things are pretty stable. I know
there
are
still some gaps between what is implemented in Shindig and
what is
in
the 2.5.0 OpenSocial spec

do we at least have these gaps captured anywhere?

but I think it is also important to get a
non-beta release out there for other projects to consume.
If
everyone
is OK with this our next release will be the official 2.5.0
release
and will not have a beta tag.

-Ryan

Re: Getting Ready To Release 2.5.0

2013-04-30 Thread Henry Saputra

Ugh sorry for late reply. No I did not have time to look at it.

I guess it is blocker for 2.5? I will take a look at it later today.

- Henry

On Fri, Apr 19, 2013 at 12:50 PM, Ryan Baxter rbaxte...@gmail.com wrote:

Henry, have you had a sometime to look into this at all? Would like
to get this into 2.5.

On Mon, Mar 18, 2013 at 2:38 PM, Ryan Baxter rbaxte...@gmail.com wrote:
Yes I just uploaded the newest patch from my workspace, if you have a
chance take a look at the samples module. I am just not familiar
enough with JPA to know what is wrong...

On Mon, Mar 18, 2013 at 2:26 PM, Henry Saputra henry.sapu...@gmail.com
wrote:
I fixed couple issues before. So the patches for the udpated data model
is
in that review entry?

I can try it out.

- Henry

On Mon, Mar 18, 2013 at 11:02 AM, Ryan Baxter rbaxte...@apache.org
wrote:

Henry I actually have most of the 2 patches integrated together [1].
I need to some help with the JPA stuff some of the unit tests are
failing, are you familiar with that code at all?

[1] https://reviews.apache.org/r/9990/

On Mon, Mar 18, 2013 at 1:46 PM, Henry Saputra
henry.sapu...@gmail.com
wrote:
Yeah, I have been distracted with so many items so did not have time
to
finish it =(

Do you guys think it is a blocker for 2.5.0 release?

- Henry

On Sun, Mar 17, 2013 at 1:51 PM, Ryan Baxter rbaxte...@apache.org
wrote:

I dont think we have a list of them per-say. Looking through the
JIRAs labeled with 2.5.0 I found SHINDIG-1539 [1] which tries to few
some gaps in the social data objects. I updated the patch from
James
so it builds against trunk and created a review for it [2]. I think
SHINDIG-1539 and SHINDIG-1878 are pretty much dups. We should apply
one of the reviews and close both of them. I am try and see if
there
are differences between the two.

The other gap I can think of is the External Services section in the
spec [3]. @Henry weren't you working on a patch for this?

[1] https://issues.apache.org/jira/browse/SHINDIG-1539
[2] https://reviews.apache.org/r/9990/
[3]

http://opensocial-resources.googlecode.com/svn/spec/trunk/Core-Gadget.xml#ExternalServices

The big ticket AFAIK is SHINDIG-1878.

I am +1 and reccommend for 2.5.0 release. It is been long overdue
and
everybody have been putting a lot of good work.

Thanks,

Henr

On Sat, Mar 16, 2013 at 7:34 AM, Matt Franklin
m.ben.frank...@gmail.com
wrote:

On Saturday, March 16, 2013, Ryan Baxter wrote:

Hey everyone,

2.5.0-beta6 is out the door (thanks everyone for their hard
work)
and
I think we are at a point where 2.5.0 is pretty much ready for
a
release. Defects have been slow to come in over the past few
weeks
and from my point of view things are pretty stable. I know
there
are
still some gaps between what is implemented in Shindig and
what is
in
the 2.5.0 OpenSocial spec

do we at least have these gaps captured anywhere?

but I think it is also important to get a
non-beta release out there for other projects to consume. If
everyone
is OK with this our next release will be the official 2.5.0
release
and will not have a beta tag.

-Ryan

Re: Getting Ready To Release 2.5.0

2013-03-18 Thread Henry Saputra

Yeah, I have been distracted with so many items so did not have time to
finish it =(

Do you guys think it is a blocker for 2.5.0 release?

- Henry

On Sun, Mar 17, 2013 at 1:51 PM, Ryan Baxter rbaxte...@apache.org wrote:

I dont think we have a list of them per-say. Looking through the
JIRAs labeled with 2.5.0 I found SHINDIG-1539 [1] which tries to few
some gaps in the social data objects. I updated the patch from James
so it builds against trunk and created a review for it [2]. I think
SHINDIG-1539 and SHINDIG-1878 are pretty much dups. We should apply
one of the reviews and close both of them. I am try and see if there
are differences between the two.

The other gap I can think of is the External Services section in the
spec [3]. @Henry weren't you working on a patch for this?

[1] https://issues.apache.org/jira/browse/SHINDIG-1539
[2] https://reviews.apache.org/r/9990/
[3]
http://opensocial-resources.googlecode.com/svn/spec/trunk/Core-Gadget.xml#ExternalServices

On Sat, Mar 16, 2013 at 11:54 AM, Henry Saputra henry.sapu...@gmail.com
wrote:
Not exactly, we have using JIRA to capture the differences. Mostly the
differences come from the data model where new fields are introduced or
have name changes.

The big ticket AFAIK is SHINDIG-1878.

I am +1 and reccommend for 2.5.0 release. It is been long overdue and
everybody have been putting a lot of good work.

Thanks,

Henr

On Sat, Mar 16, 2013 at 7:34 AM, Matt Franklin m.ben.frank...@gmail.com
wrote:

On Saturday, March 16, 2013, Ryan Baxter wrote:

Hey everyone,

2.5.0-beta6 is out the door (thanks everyone for their hard work) and
I think we are at a point where 2.5.0 is pretty much ready for a
release. Defects have been slow to come in over the past few weeks
and from my point of view things are pretty stable. I know there are
still some gaps between what is implemented in Shindig and what is in
the 2.5.0 OpenSocial spec

do we at least have these gaps captured anywhere?

but I think it is also important to get a
non-beta release out there for other projects to consume. If everyone
is OK with this our next release will be the official 2.5.0 release
and will not have a beta tag.

-Ryan

Re: Getting Ready To Release 2.5.0

2013-03-18 Thread Henry Saputra

I fixed couple issues before. So the patches for the udpated data model is
in that review entry?

I can try it out.

- Henry

On Mon, Mar 18, 2013 at 11:02 AM, Ryan Baxter rbaxte...@apache.org wrote:

Henry I actually have most of the 2 patches integrated together [1].
I need to some help with the JPA stuff some of the unit tests are
failing, are you familiar with that code at all?

[1] https://reviews.apache.org/r/9990/

On Mon, Mar 18, 2013 at 1:46 PM, Henry Saputra henry.sapu...@gmail.com
wrote:
Yeah, I have been distracted with so many items so did not have time to
finish it =(

Do you guys think it is a blocker for 2.5.0 release?

- Henry

On Sun, Mar 17, 2013 at 1:51 PM, Ryan Baxter rbaxte...@apache.org
wrote:

I dont think we have a list of them per-say. Looking through the
JIRAs labeled with 2.5.0 I found SHINDIG-1539 [1] which tries to few
some gaps in the social data objects. I updated the patch from James
so it builds against trunk and created a review for it [2]. I think
SHINDIG-1539 and SHINDIG-1878 are pretty much dups. We should apply
one of the reviews and close both of them. I am try and see if there
are differences between the two.

The other gap I can think of is the External Services section in the
spec [3]. @Henry weren't you working on a patch for this?

[1] https://issues.apache.org/jira/browse/SHINDIG-1539
[2] https://reviews.apache.org/r/9990/
[3]

http://opensocial-resources.googlecode.com/svn/spec/trunk/Core-Gadget.xml#ExternalServices

On Sat, Mar 16, 2013 at 11:54 AM, Henry Saputra
henry.sapu...@gmail.com
wrote:
Not exactly, we have using JIRA to capture the differences. Mostly the
differences come from the data model where new fields are introduced
or
have name changes.

The big ticket AFAIK is SHINDIG-1878.

I am +1 and reccommend for 2.5.0 release. It is been long overdue and
everybody have been putting a lot of good work.

Thanks,

Henr

On Sat, Mar 16, 2013 at 7:34 AM, Matt Franklin
m.ben.frank...@gmail.com
wrote:

On Saturday, March 16, 2013, Ryan Baxter wrote:

Hey everyone,

2.5.0-beta6 is out the door (thanks everyone for their hard work)
and
I think we are at a point where 2.5.0 is pretty much ready for a
release. Defects have been slow to come in over the past few weeks
and from my point of view things are pretty stable. I know there
are
still some gaps between what is implemented in Shindig and what is
in
the 2.5.0 OpenSocial spec

do we at least have these gaps captured anywhere?

but I think it is also important to get a
non-beta release out there for other projects to consume. If
everyone
is OK with this our next release will be the official 2.5.0 release
and will not have a beta tag.

-Ryan

Re: Getting Ready To Release 2.5.0

2013-03-16 Thread Henry Saputra

Not exactly, we have using JIRA to capture the differences. Mostly the
differences come from the data model where new fields are introduced or
have name changes.

The big ticket AFAIK is SHINDIG-1878.

I am +1 and reccommend for 2.5.0 release. It is been long overdue and
everybody have been putting a lot of good work.

Thanks,

Henr


On Sat, Mar 16, 2013 at 7:34 AM, Matt Franklin m.ben.frank...@gmail.comwrote:

 On Saturday, March 16, 2013, Ryan Baxter wrote:

  Hey everyone,
 
  2.5.0-beta6 is out the door (thanks everyone for their hard work) and
  I think we are at a point where 2.5.0 is pretty much ready for a
  release.  Defects have been slow to come in over the past few weeks
  and from my point of view things are pretty stable.   I know there are
  still some gaps between what is implemented in Shindig and what is in
  the 2.5.0 OpenSocial spec


 do we at least have these gaps captured anywhere?


  but I think it is also important to get a
  non-beta release out there for other projects to consume.  If everyone
  is OK with this our next release will be the official 2.5.0 release
  and will not have a beta tag.


  -Ryan

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

2013-03-13 Thread Henry Saputra

Thanks Ryan.

Copied binary jars to test web application. Gadget renders in common
container, both REST and JSON-RPC calls looks good.

No immediate failure.

+1

- Henry



On Tue, Mar 12, 2013 at 5:28 PM, Ryan Baxter rbaxte...@apache.org wrote:

 Hi,

 We solved 20 issues:

 https://issues.apache.org/jira/issues/?jql=project%20%3D%20SHINDIG%20AND%20fixVersion%20%3D%20%222.5.0-beta6%22%20AND%20status%20%3D%20Resolved%20ORDER%20BY%20priority%20DESC

 There are still a couple of issues left in JIRA:

 https://issues.apache.org/jira/issues/?jql=project%20%3D%20SHINDIG%20AND%20fixVersion%20%3D%20%222.5.0-beta6%22%20AND%20status%20%3D%20Open%20ORDER%20BY%20priority%20DESC

 Staging repo:
 https://repository.apache.org/content/repositories/orgapacheshindig-002/

 Web site:
 http://shindig.apache.org/

 Vote open for 72 hours.

 [ ] +1
 [ ] +0
 [ ] -1

Re: Review Request: Alternative database backend based on graph database neo4j

2013-03-07 Thread Henry Saputra

This is good news.

One immediate comment is about the package name.
Would it be possible to put it under org.apache.shindig rather than the
de.hofuniversity?

This would make the contributions uniform like from other companies and
organizations.

- Henry


2013/3/6 René Peinl rene.pe...@hof-university.de


 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/9773/
 ---

 Review request for shindig.


 Description
 ---

 Review for Shindig-1911
 Alternative database backend based on graph database neo4j
 Any comments welcome. We are committed to further improve this.


 This addresses bug Shindig-1911.
 https://issues.apache.org/jira/browse/Shindig-1911


 Diffs
 -

   /trunk/java/neo4j-backend/pom.xml PRE-CREATION

 /trunk/java/neo4j-backend/src/main/java/de/hofuniversity/iisys/graphbackend/Constants.java
 PRE-CREATION

 /trunk/java/neo4j-backend/src/main/java/de/hofuniversity/iisys/graphbackend/GraphAPIModule.java
 PRE-CREATION

 /trunk/java/neo4j-backend/src/main/java/de/hofuniversity/iisys/graphbackend/GraphConfig.java
 PRE-CREATION

 /trunk/java/neo4j-backend/src/main/java/de/hofuniversity/iisys/graphbackend/GuiceModule.java
 PRE-CREATION

 /trunk/java/neo4j-backend/src/main/java/de/hofuniversity/iisys/graphbackend/db/neo4j/INeo4jConnector.java
 PRE-CREATION

 /trunk/java/neo4j-backend/src/main/java/de/hofuniversity/iisys/graphbackend/db/neo4j/Neo4jConnector.java
 PRE-CREATION

 /trunk/java/neo4j-backend/src/main/java/de/hofuniversity/iisys/graphbackend/db/neo4j/Neo4jHAConnector.java
 PRE-CREATION

 /trunk/java/neo4j-backend/src/main/java/de/hofuniversity/iisys/graphbackend/db/neo4j/Neo4jRelTypes.java
 PRE-CREATION

 /trunk/java/neo4j-backend/src/main/java/de/hofuniversity/iisys/graphbackend/db/neo4j/Neo4jRestConnector.java
 PRE-CREATION

 /trunk/java/neo4j-backend/src/main/java/de/hofuniversity/iisys/graphbackend/model/ExtOrgPersonImpl.java
 PRE-CREATION

 /trunk/java/neo4j-backend/src/main/java/de/hofuniversity/iisys/graphbackend/model/ExtOrganizationImpl.java
 PRE-CREATION

 /trunk/java/neo4j-backend/src/main/java/de/hofuniversity/iisys/graphbackend/model/IExtOrgPerson.java
 PRE-CREATION

 /trunk/java/neo4j-backend/src/main/java/de/hofuniversity/iisys/graphbackend/model/IExtOrganization.java
 PRE-CREATION

 /trunk/java/neo4j-backend/src/main/java/de/hofuniversity/iisys/graphbackend/model/cypher/CypherActivityEntry.java
 PRE-CREATION

 /trunk/java/neo4j-backend/src/main/java/de/hofuniversity/iisys/graphbackend/model/cypher/CypherActivityObject.java
 PRE-CREATION

 /trunk/java/neo4j-backend/src/main/java/de/hofuniversity/iisys/graphbackend/model/cypher/CypherAttributesMessage.java
 PRE-CREATION

 /trunk/java/neo4j-backend/src/main/java/de/hofuniversity/iisys/graphbackend/model/cypher/CypherListFieldList.java
 PRE-CREATION

 /trunk/java/neo4j-backend/src/main/java/de/hofuniversity/iisys/graphbackend/model/cypher/CypherMessage.java
 PRE-CREATION

 /trunk/java/neo4j-backend/src/main/java/de/hofuniversity/iisys/graphbackend/model/cypher/CypherMessageCollection.java
 PRE-CREATION

 /trunk/java/neo4j-backend/src/main/java/de/hofuniversity/iisys/graphbackend/model/cypher/CypherPerson.java
 PRE-CREATION

 /trunk/java/neo4j-backend/src/main/java/de/hofuniversity/iisys/graphbackend/model/dto/ADataTransferObject.java
 PRE-CREATION

 /trunk/java/neo4j-backend/src/main/java/de/hofuniversity/iisys/graphbackend/model/dto/AccountDTO.java
 PRE-CREATION

 /trunk/java/neo4j-backend/src/main/java/de/hofuniversity/iisys/graphbackend/model/dto/ActivityDTO.java
 PRE-CREATION

 /trunk/java/neo4j-backend/src/main/java/de/hofuniversity/iisys/graphbackend/model/dto/ActivityEntryDTO.java
 PRE-CREATION

 /trunk/java/neo4j-backend/src/main/java/de/hofuniversity/iisys/graphbackend/model/dto/ActivityObjectDTO.java
 PRE-CREATION

 /trunk/java/neo4j-backend/src/main/java/de/hofuniversity/iisys/graphbackend/model/dto/AddressDTO.java
 PRE-CREATION

 /trunk/java/neo4j-backend/src/main/java/de/hofuniversity/iisys/graphbackend/model/dto/DTOHelper.java
 PRE-CREATION

 /trunk/java/neo4j-backend/src/main/java/de/hofuniversity/iisys/graphbackend/model/dto/GroupDTO.java
 PRE-CREATION

 /trunk/java/neo4j-backend/src/main/java/de/hofuniversity/iisys/graphbackend/model/dto/MediaItemDTO.java
 PRE-CREATION

 /trunk/java/neo4j-backend/src/main/java/de/hofuniversity/iisys/graphbackend/model/dto/MediaLinkDTO.java
 PRE-CREATION

 /trunk/java/neo4j-backend/src/main/java/de/hofuniversity/iisys/graphbackend/model/dto/MessageCollectionDTO.java
 PRE-CREATION

 /trunk/java/neo4j-backend/src/main/java/de/hofuniversity/iisys/graphbackend/model/dto/MessageDTO.java
 PRE-CREATION

 /trunk/java/neo4j-backend/src/main/java/de/hofuniversity/iisys/graphbackend/model/dto/OrganizationDTO.java
 PRE-CREATION

Re: [RESULT] [VOTE] Release Apache Shindig version 2.5.0 Beta 6

2013-03-05 Thread Henry Saputra

Cool! Looking forward to VOTE the next candidate build.

Thanks for all the hard work Ryan

- Henry


On Tue, Mar 5, 2013 at 5:56 PM, rbaxte...@gmail.com wrote:

 No problem Henry.  I dropped the release and removed the tag.

 I also committed that JIRA and identified one other change I think we
 should get in.  Working on that one and will hope to check it in tomorrow.

 On Mar 4, 2013, at 10:08 PM, Henry Saputra henry.sapu...@gmail.com
 wrote:

  I actually would like to have SHINDIG-1910 in beta6 release since it
 could
  be blocker to integration with other platforms.
 
  So -1 for this artifact release if its not too much work for Ryan for
 later
  to spin new beta6 candidate?
 
  - Henry
 
 
  On Mon, Mar 4, 2013 at 6:18 AM, Ryan Baxter rbaxte...@apache.org
 wrote:
 
  Hi,
 
  We solved 18 issues:
 
 
 https://issues.apache.org/jira/issues/?jql=project%20%3D%20SHINDIG%20AND%20fixVersion%20%3D%20%222.5.0-beta6%22%20AND%20status%20%3D%20Resolved%20ORDER%20BY%20priority%20DESC
 
  There are still a couple of issues left in JIRA:
 
 
 https://issues.apache.org/jira/issues/?jql=project%20%3D%20SHINDIG%20AND%20fixVersion%20%3D%20%222.5.0-beta6%22%20AND%20status%20%3D%20Open%20ORDER%20BY%20priority%20DESC
 
  Staging repo:
 
 
 https://repository.apache.org/content/repositories/orgapacheshindig-323/org/apache/shindig//
 
  Web site:
  http://shindig.apache.org/
 
  Vote open for 72 hours.
 
  [ ] +1
  [ ] +0
  [ ] -1

Re: [VOTE] Release Apache Shindig version 2.5.0 Beta 6

2013-03-04 Thread Henry Saputra

I actually would like to have SHINDIG-1910 in beta6 release since it could
be blocker to integration with other platforms.

So -1 for this artifact release if its not too much work for Ryan for later
to spin new beta6 candidate?

- Henry


On Mon, Mar 4, 2013 at 6:18 AM, Ryan Baxter rbaxte...@apache.org wrote:

 Hi,

 We solved 18 issues:

 https://issues.apache.org/jira/issues/?jql=project%20%3D%20SHINDIG%20AND%20fixVersion%20%3D%20%222.5.0-beta6%22%20AND%20status%20%3D%20Resolved%20ORDER%20BY%20priority%20DESC

 There are still a couple of issues left in JIRA:

 https://issues.apache.org/jira/issues/?jql=project%20%3D%20SHINDIG%20AND%20fixVersion%20%3D%20%222.5.0-beta6%22%20AND%20status%20%3D%20Open%20ORDER%20BY%20priority%20DESC

 Staging repo:

 https://repository.apache.org/content/repositories/orgapacheshindig-323/org/apache/shindig//

 Web site:
 http://shindig.apache.org/

 Vote open for 72 hours.

 [ ] +1
 [ ] +0
 [ ] -1

Re: Review Request: ProxyHandler does not forward User-Agent

2013-02-16 Thread Henry Saputra


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/8951/#review16685
---

Ship it!


Ship It!

- Henry Saputra


On Jan. 28, 2013, 4:51 a.m., Marshall Shi wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/8951/
 ---
 
 (Updated Jan. 28, 2013, 4:51 a.m.)
 
 
 Review request for shindig, Ryan Baxter, Dan Dumont, Stanton Sievers, and 
 Rich Thompson.
 
 
 Description
 ---
 
 The ProxyHandler currently does not forward the correct User-Agent to the 
 target server. We have certain cases that the target server needs to check 
 the User-Agent and decide the content of the response. 
 
 
 This addresses bug SHINDIG-1894.
 https://issues.apache.org/jira/browse/SHINDIG-1894
 
 
 Diffs
 -
 
   
 http://svn.apache.org/repos/asf/shindig/trunk/java/gadgets/src/main/java/org/apache/shindig/gadgets/http/AbstractHttpCache.java
  1406188 
   
 http://svn.apache.org/repos/asf/shindig/trunk/java/gadgets/src/main/java/org/apache/shindig/gadgets/servlet/ProxyHandler.java
  1406188 
   
 http://svn.apache.org/repos/asf/shindig/trunk/java/gadgets/src/main/java/org/apache/shindig/gadgets/servlet/ProxyServlet.java
  1406188 
   
 http://svn.apache.org/repos/asf/shindig/trunk/java/gadgets/src/test/java/org/apache/shindig/gadgets/http/AbstractHttpCacheTest.java
  1406188 
   
 http://svn.apache.org/repos/asf/shindig/trunk/java/gadgets/src/test/java/org/apache/shindig/gadgets/render/ProxyRendererTest.java
  1406188 
   
 http://svn.apache.org/repos/asf/shindig/trunk/java/gadgets/src/test/java/org/apache/shindig/gadgets/servlet/ProxyServletTest.java
  1406188 
 
 Diff: https://reviews.apache.org/r/8951/diff/
 
 
 Testing
 ---
 
 Done.
 
 
 Thanks,
 
 Marshall Shi

Re: Review Request: Do enhancement for FeatureRegistry to detect feature dependency loop problem

2013-02-04 Thread Henry Saputra


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/7497/#review16083
---


I thought the code completeNodeGraph is used to check dependency loop and 
discard A in case of A-B-C-A ?

- Henry Saputra


On Feb. 5, 2013, 3:18 a.m., Jiaqing Guo wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/7497/
 ---
 
 (Updated Feb. 5, 2013, 3:18 a.m.)
 
 
 Review request for shindig, Ryan Baxter, Dan Dumont, and Stanton Sievers.
 
 
 Description
 ---
 
 This patch is used to fix bug SHINDIG-1877.
 It will do a enhancement for FeatureRegistry to detect feature dependency 
 loop problem when it tries to complete dependency node graph for loaded 
 feature node.
 
 
 This addresses bug SHINDIG-1877.
 https://issues.apache.org/jira/browse/SHINDIG-1877
 
 
 Diffs
 -
 
   
 http://svn.apache.org/repos/asf/shindig/trunk/java/gadgets/src/main/java/org/apache/shindig/gadgets/features/FeatureRegistry.java
  1442011 
 
 Diff: https://reviews.apache.org/r/7497/diff/
 
 
 Testing
 ---
 
 
 Thanks,
 
 Jiaqing Guo

Re: BasicHttpFetcher without internet

2013-01-30 Thread Henry Saputra

Not sure if Rave need Shindig extras, if not then you could try to remove
Shindig extras module definition in the web.xml file.

- Henry


On Wed, Jan 30, 2013 at 7:57 AM, McCoey, John john.mcc...@lmco.com wrote:

 I'm using Shindig-2.5.0-beta1 as part of an Apache Rave installation where
 I have the system in a completely closed network with no access to outside
 internet.  On startup and initial login, I get a bunch of connection
 timeout errors from the BasicHttpFetcher that is trying to reach some
 javascript that is hosted externally (see example below).  After waiting 5
 or so minutes for all of the timeouts, I am logged in and can proceed as
 normal.  Is there any configuration I can change to either disable this
 feature or make it work with a locally-hosted version of the file so that I
 do not have to wait for the timeouts?

 Example:
 Jan 29, 2013 7:56:40 AM org.apache.shindig.gadgets.http.BasicHttpFetcher
 fetch
 INFO: The following exception occurred when fetching
 http://www.google-analytics.com/urchin.js: 55,095 ms elapsed.
 Jan 29, 2013 7:56:40 AM org.apache.shindig.gadgets.http.BasicHttpFetcher
 fetch
 INFO:
 org.apache.http.conn.ConnectTimeoutException: Connect to
 www.google-analytics.com:80http://www.google-analytics.com:80 timed out
 at
 org.apache.http.conn.scheme.PlainSocketFactory.connectSocket(PlainSocketFactory.java:125)
 at
 org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:148)
 at
 org.apache.http.impl.conn.AbstractPoolEntry.open(AbstractPoolEntry.java:149)
 at
 org.apache.http.impl.conn.AbstractPooledConnAdapter.open(AbstractPooledConnAdapter.java:121)
 at
 org.apache.http.impl.client.DefaultRequestDirector.tryConnect(DefaultRequestDirector.java:573)
 at
 org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:425)
 at
 org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:820)
 at
 org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:776)
 at
 org.apache.shindig.gadgets.http.BasicHttpFetcher.fetch(BasicHttpFetcher.java:359)
 at
 org.apache.shindig.gadgets.features.FeatureResourceLoader$UriResource.getContent(FeatureResourceLoader.java:290)
 at
 org.apache.shindig.gadgets.features.FeatureResourceLoader$UriResource.init(FeatureResourceLoader.java:269)
 at
 org.apache.shindig.gadgets.features.FeatureResourceLoader$UriResource.init(FeatureResourceLoader.java:255)
 at
 org.apache.shindig.gadgets.features.FeatureResourceLoader.loadUri(FeatureResourceLoader.java:134)
 at
 org.apache.shindig.gadgets.features.FeatureResourceLoader.load(FeatureResourceLoader.java:87)
 at
 org.apache.shindig.gadgets.features.FeatureRegistry.loadFeature(FeatureRegistry.java:484)
 at
 org.apache.shindig.gadgets.features.FeatureRegistry.loadResources(FeatureRegistry.java:423)
 at
 org.apache.shindig.gadgets.features.FeatureRegistry.register(FeatureRegistry.java:177)
 at
 org.apache.shindig.gadgets.features.FeatureRegistry.init(FeatureRegistry.java:109)
 at
 org.apache.shindig.gadgets.features.FeatureRegistry.init(FeatureRegistry.java:96)
 at
 org.apache.shindig.gadgets.features.FeatureRegistry$$FastClassByGuice$$536f6a5.newInstance(generated)
 at
 com.google.inject.internal.cglib.reflect.$FastConstructor.newInstance(FastConstructor.java:40)
 at
 com.google.inject.internal.DefaultConstructionProxyFactory$1.newInstance(DefaultConstructionProxyFactory.java:60)
 at
 com.google.inject.internal.ConstructorInjector.construct(ConstructorInjector.java:85)
 at
 com.google.inject.internal.ConstructorBindingImpl$Factory.get(ConstructorBindingImpl.java:254)
 at
 com.google.inject.internal.ProviderToInternalFactoryAdapter$1.call(ProviderToInternalFactoryAdapter.java:46)
 at
 com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1031)
 at
 com.google.inject.internal.ProviderToInternalFactoryAdapter.get(ProviderToInternalFactoryAdapter.java:40)
 at com.google.inject.Scopes$1$1.get(Scopes.java:65)
 at
 com.google.inject.internal.InternalFactoryToProviderAdapter.get(InternalFactoryToProviderAdapter.java:40)
 at
 com.google.inject.internal.SingleParameterInjector.inject(SingleParameterInjector.java:38)
 at
 com.google.inject.internal.SingleParameterInjector.getAll(SingleParameterInjector.java:62)
 at
 com.google.inject.internal.ConstructorInjector.construct(ConstructorInjector.java:84)
 at

Re: Review Request: ProxyHandler does not forward User-Agent

2013-01-27 Thread Henry Saputra


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/8951/#review15742
---


Hmm I remember there was an issue before to not forward user agent when 
proxying content. Could you try to find JIRA issue for it?

- Henry Saputra


On Jan. 28, 2013, 4:51 a.m., Marshall Shi wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/8951/
 ---
 
 (Updated Jan. 28, 2013, 4:51 a.m.)
 
 
 Review request for shindig, Ryan Baxter, Dan Dumont, Stanton Sievers, and 
 Rich Thompson.
 
 
 Description
 ---
 
 The ProxyHandler currently does not forward the correct User-Agent to the 
 target server. We have certain cases that the target server needs to check 
 the User-Agent and decide the content of the response. 
 
 
 This addresses bug SHINDIG-1894.
 https://issues.apache.org/jira/browse/SHINDIG-1894
 
 
 Diffs
 -
 
   
 http://svn.apache.org/repos/asf/shindig/trunk/java/gadgets/src/main/java/org/apache/shindig/gadgets/http/AbstractHttpCache.java
  1406188 
   
 http://svn.apache.org/repos/asf/shindig/trunk/java/gadgets/src/main/java/org/apache/shindig/gadgets/servlet/ProxyHandler.java
  1406188 
   
 http://svn.apache.org/repos/asf/shindig/trunk/java/gadgets/src/main/java/org/apache/shindig/gadgets/servlet/ProxyServlet.java
  1406188 
   
 http://svn.apache.org/repos/asf/shindig/trunk/java/gadgets/src/test/java/org/apache/shindig/gadgets/http/AbstractHttpCacheTest.java
  1406188 
   
 http://svn.apache.org/repos/asf/shindig/trunk/java/gadgets/src/test/java/org/apache/shindig/gadgets/render/ProxyRendererTest.java
  1406188 
   
 http://svn.apache.org/repos/asf/shindig/trunk/java/gadgets/src/test/java/org/apache/shindig/gadgets/servlet/ProxyServletTest.java
  1406188 
 
 Diff: https://reviews.apache.org/r/8951/diff/
 
 
 Testing
 ---
 
 Done.
 
 
 Thanks,
 
 Marshall Shi

Re: Review Request: allow container to exclude JSONP access

2013-01-14 Thread Henry Saputra


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/6652/#review15326
---

Ship it!


Ship It!

- Henry Saputra


On Oct. 9, 2012, 4:29 a.m., Marshall Shi wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/6652/
 ---
 
 (Updated Oct. 9, 2012, 4:29 a.m.)
 
 
 Review request for shindig, Ryan Baxter, Dan Dumont, Stanton Sievers, and 
 Rich Thompson.
 
 
 Description
 ---
 
 Shindig code base supports a 'callback' query parameter on a number of entry 
 points (RPC Servlet entry, DataServiceServlet and JsonRpcServlet) and thereby 
 provides JSONP support. However, Shindig has no place that uses this support.
 
 ALL containers based off of Shindig are now forced to protect themselves 
 against inappropriate JSONP usage (security issue).
 
 Why would Shindig ship unused functionality that FORCES all containers to do 
 extra work?
 
 The proposed improvement is to extract a setting so application can disable 
 JSONP feature. In the longer term, we can deprecate this feature and remove 
 it if no one is  depending on this feature.
 
 
 This addresses bug shindig-1837.
 https://issues.apache.org/jira/browse/shindig-1837
 
 
 Diffs
 -
 
   
 http://svn.apache.org/repos/asf/shindig/trunk/java/common/conf/shindig.properties
  1373213 
   
 http://svn.apache.org/repos/asf/shindig/trunk/java/common/src/main/java/org/apache/shindig/protocol/ApiServlet.java
  1373213 
   
 http://svn.apache.org/repos/asf/shindig/trunk/java/common/src/main/java/org/apache/shindig/protocol/DataServiceServlet.java
  1373213 
   
 http://svn.apache.org/repos/asf/shindig/trunk/java/common/src/main/java/org/apache/shindig/protocol/JsonRpcServlet.java
  1373213 
   
 http://svn.apache.org/repos/asf/shindig/trunk/java/common/src/test/java/org/apache/shindig/protocol/DataServiceServletTest.java
  1373213 
   
 http://svn.apache.org/repos/asf/shindig/trunk/java/common/src/test/java/org/apache/shindig/protocol/JsonRpcServletTest.java
  1373213 
   
 http://svn.apache.org/repos/asf/shindig/trunk/java/gadgets/src/main/java/org/apache/shindig/gadgets/servlet/RpcServlet.java
  1373213 
   
 http://svn.apache.org/repos/asf/shindig/trunk/java/gadgets/src/test/java/org/apache/shindig/gadgets/servlet/RpcServletTest.java
  1373213 
   
 http://svn.apache.org/repos/asf/shindig/trunk/java/samples/src/test/java/org/apache/shindig/social/opensocial/jpa/spi/integration/JpaRestfulTestConfigHelper.java
  1373213 
   
 http://svn.apache.org/repos/asf/shindig/trunk/java/social-api/src/test/java/org/apache/shindig/social/dataservice/integration/AbstractLargeRestfulTests.java
  1373213 
 
 Diff: https://reviews.apache.org/r/6652/diff/
 
 
 Testing
 ---
 
 Done
 
 
 Thanks,
 
 Marshall Shi

Re: Build failed in Jenkins: Shindig Trunk (JDK 1.5) #60

2013-01-10 Thread Henry Saputra

Jive already in 1.6. I believe liferay had concern about 1.5

Henry

On Thursday, January 10, 2013, Paul Lindner lind...@inuus.com wrote:
 Sadly looks like commons-io-2.2 and commons-codec-1.6 is the EOL for java
 1.5

 How important is 1.5 compatibility for everyone?



 -- Forwarded message --
 From: *Apache Jenkins Server*
 Date: Thursday, January 10, 2013
 Subject: Build failed in Jenkins: Shindig Trunk (JDK 1.5) #60
 To: comm...@shindig.apache.org


 See 
https://builds.apache.org/job/Shindig%20Trunk%20(JDK%201.5)/60/changes

 Changes:

 [ddumont] @Singleton
 Closure compiler should be a singleton

 [lindner] Update apache parent pom to v12, update source-code compatible

 --
 [...truncated 4242 lines...]
 [INFO] --- maven-source-plugin:2.1.2:jar (attach-sources) @
 shindig-features ---
 [INFO] META-INF already added, skipping
 [INFO] META-INF/NOTICE already added, skipping
 [INFO] META-INF/LICENSE already added, skipping
 [INFO] META-INF/DEPENDENCIES already added, skipping
 [INFO] Building jar: 

https://builds.apache.org/job/Shindig%20Trunk%20(JDK%201.5)/ws/features/target/shindig-features-2.5.0-SNAPSHOT-sources.jar

 [INFO] META-INF already added, skipping
 [INFO] META-INF/NOTICE already added, skipping
 [INFO] META-INF/LICENSE already added, skipping
 [INFO] META-INF/DEPENDENCIES already added, skipping
 mojoSucceeded
 org.apache.maven.plugins:maven-source-plugin:2.1.2(attach-sources)
 forkedProjectStarted org.apache.shindig:shindig-features:2.5.0-SNAPSHOT
 mojoStarted
org.apache.maven.plugins:maven-enforcer-plugin:1.0(enforce-java)
 [INFO]
 [INFO] --- maven-enforcer-plugin:1.0:enforce (enforce-java) @
 shindig-features ---
 mojoSucceeded
 org.apache.maven.plugins:maven-enforcer-plugin:1.0(enforce-java)
 Jan 11, 2013 1:25:20 AM hudson.maven.ExecutedMojo init
 WARNING: Failed to getClass for
 org.apache.maven.plugin.source.TestSourceJarMojo
 forkedProjectSucceeded org.apache.shindig:shindig-features:2.5.0-SNAPSHOT
 mojoStarted
 org.apache.maven.plugins:maven-source-plugin:2.1.2(attach-sources)
 [INFO]
 [INFO] --- maven-source-plugin:2.1.2:test-jar (attach-sources) @
 shindig-features ---
 [INFO] META-INF already added, skipping
 [INFO] META-INF/NOTICE already added, skipping
 [INFO] META-INF/LICENSE already added, skipping
 [INFO] META-INF/DEPENDENCIES already added, skipping
 [INFO] Building jar: 

https://builds.apache.org/job/Shindig%20Trunk%20(JDK%201.5)/ws/features/target/shindig-features-2.5.0-SNAPSHOT-test-sources.jar

 [INFO] META-INF already added, skipping
 [INFO] META-INF/NOTICE already added, skipping
 [INFO] META-INF/LICENSE already added, skipping
 [INFO] META-INF/DEPENDENCIES already added, skipping
 mojoSucceeded
 org.apache.maven.plugins:maven-source-plugin:2.1.2(attach-sources)
 mojoStarted
 org.apache.maven.plugins:maven-site-plugin:3.0(attach-descriptor)
 [INFO]
 [INFO] --- maven-site-plugin:3.0:attach-descriptor (attach-descriptor) @
 shindig-features ---
 mojoSucceeded
 org.apache.maven.plugins:maven-site-plugin:3.0(attach-descriptor)
 mojoStarted org.apache.maven.plugins:maven-jar-plugin:2.3.1(default)
 [INFO]
 [INFO] --- maven-jar-plugin:2.3.1:test-jar (default) @ shindig-features
---
 [INFO] Building jar: 

https://builds.apache.org/job/Shindig%20Trunk%20(JDK%201.5)/ws/features/target/shindig-features-2.5.0-SNAPSHOT-tests.jar

 mojoSucceeded org.apache.maven.plugins:maven-jar-plugin:2.3.1(default)
 mojoStarted org.apache.rat:apache-rat-plugin:0.8(default)
 [INFO]
 [INFO] --- apache-rat-plugin:0.8:check (default) @ shindig-features ---
 [INFO] Exclude: **/*.iml
 [INFO] Exclude: .gitignore
 [INFO] Exclude: .reviewboardrc
 [INFO] Exclude: release.properties
 [INFO] Exclude: **/.git/**/*
 [INFO] Exclude: **/README*
 [INFO] Exclude: **/target/**
 [INFO] Exclude: **/external/**
 [INFO] Exclude: **/features-extras/swfobject/swfobject.js
 [INFO] Exclude: **/features-extras/swfobject/Sending e-mails to:
comm...@shindig.apache.org javascript:;
 channel stopped



 --
 Paul Lindner -- lind...@inuus.com -- profiles.google.com/pmlindner

Re: Review Request: Recent rpc changes are breaking gadget to gadget communication

2013-01-08 Thread Henry Saputra


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/8894/#review15160
---

Ship it!


+1 Thanks for the fix! =)

- Henry Saputra


On Jan. 8, 2013, 7:47 p.m., Dan Dumont wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/8894/
 ---
 
 (Updated Jan. 8, 2013, 7:47 p.m.)
 
 
 Review request for shindig and Henry Saputra.
 
 
 Description
 ---
 
 This makes the search for target frames a bit more resilient.
 
 
 Diffs
 -
 
   
 http://svn.apache.org/repos/asf/shindig/trunk/features/src/main/javascript/features/rpc/rpc.js
  1430457 
 
 Diff: https://reviews.apache.org/r/8894/diff/
 
 
 Testing
 ---
 
 
 Thanks,
 
 Dan Dumont

Re: Review Request: Module-ID always returned as 0

2013-01-07 Thread Henry Saputra



 On Jan. 7, 2013, 11:07 p.m., Henry Saputra wrote:
  +1

Actually could you add test in the service_test.js to cover this?


- Henry


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/8870/#review15126
---


On Jan. 7, 2013, 9:20 p.m., Martin Höller wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/8870/
 ---
 
 (Updated Jan. 7, 2013, 9:20 p.m.)
 
 
 Review request for shindig.
 
 
 Description
 ---
 
 It seems the moduleID is not handled correctly in getGadgetToken().
 
 I'm totally unsure, if this patch is complete but at least the local 
 variables mid and url are set to reasonable values with the patch.
 
 
 This addresses bug SHINDIG-1891.
 https://issues.apache.org/jira/browse/SHINDIG-1891
 
 
 Diffs
 -
 
   /trunk/features/src/main/javascript/features/container/service.js 1416935 
 
 Diff: https://reviews.apache.org/r/8870/diff/
 
 
 Testing
 ---
 
 
 Thanks,
 
 Martin Höller

Re: Issue with SHINDIG-1816

2013-01-04 Thread Henry Saputra

Hi Dan,

Happy New Year to you.

Thanks for catching this. Sibling iframe should come from parent window =(
Super mea culpa from me.

Could you create a patch for this please?

Would be good reason to create new release.

- Henry



On Fri, Jan 4, 2013 at 6:16 AM, Dan Dumont ddum...@apache.org wrote:

 https://issues.apache.org/jira/browse/SHINDIG-1816

 Since this patch, it appears that gadget-to-gadget communication is no
 longer possible.  I believe that it's because of this change:

 - return window.top.frames[siblingId.id];
 + return window.frames[siblingId.id];

 When the gadgets go look up the target in the window, it's no longer
 finding it in the window's frames (cause it needs to check the top window's
 frames).
 Would a search of window.parent up to window.top be sufficient to recover
 from this issue and keep the fix for what you were trying to fix?

Re: Review Request: clean up swfobject feature

2012-12-14 Thread Henry Saputra

On Dec. 12, 2012, 7:20 p.m., Dan Dumont wrote:
Looking this over again, I'm not sure what to do here. This looks like a
library that we've gotten from the project
http://code.google.com/p/swfobject/
They wouldn't have code to our standards, and I'm not sure if we should
modify it (which would make tracking changes a bit more difficult).

It also appears that we have copied their pre-optimized file as a .opt file
so that our compiler can skip that step... it might be optimized better
than the basic optimization we perform during build.

Can someone else comment on what we should do here?
Paul?

Paul Lindner wrote:
I'm fine either way. swfobject.js hasn't been updated since 2009 so I'm
not concerned with upstream integration.

Dan Dumont wrote:
Ok. Marshall, is there a compelling reason (aside from general clean up)
to make this change?
I think I'd rather leave it as-is if there's no other reason to change
it, since it is 3rd party code.

Marshall Shi wrote:
No I don't have other compelling reasons. If this is an external project.
Would make more sense to move it out from shindig core feature to the extra
features?

Dan Dumont wrote:
I think that probably makes sense. Anyone else care to comment?

Stanton Sievers wrote:
+1 on moving to extras. From what I can tell no other features depend on
it.

+1 moving to extras

- Henry

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/8244/#review14365
---

On Dec. 4, 2012, 2:53 a.m., Marshall Shi wrote:

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/8244/
---

(Updated Dec. 4, 2012, 2:53 a.m.)

Review request for shindig, Ryan Baxter, Dan Dumont, Stanton Sievers, and
Rich Thompson.

Description
---

- The swfobject.opt.js should be removed from source code.
- The swfobject.js code format need some refinement to align with Shindig JS
code guideline.

This addresses bug SHINDIG-1887.
https://issues.apache.org/jira/browse/SHINDIG-1887

Diffs
-

http://svn.apache.org/repos/asf/shindig/trunk/features/pom.xml 1401141

http://svn.apache.org/repos/asf/shindig/trunk/features/src/main/javascript/features/swfobject/swfobject.js
1383189

http://svn.apache.org/repos/asf/shindig/trunk/features/src/main/javascript/features/swfobject/swfobject.opt.js
1383189

Diff: https://reviews.apache.org/r/8244/diff/

Testing
---

Done

Thanks,

Marshall Shi

Re: Guice Creation errors

2012-12-09 Thread Henry Saputra

Looks like this project has not been aligned nor updated for a while.

I would recommend to use the formal release artifacts or directly from
trunk.

Or would love to have contributions to align this to latest trunk and bring
the sandbox to trunk.

Thanks,

Henry


On Sat, Dec 8, 2012 at 6:42 PM, Leon Wu leon...@gmail.com wrote:

 Here is the link of svn.


 https://svn.apache.org/repos/asf/shindig/sandbox/trunk/shindig-spring-example/



 On Sat, Dec 8, 2012 at 1:51 PM, Ryan Baxter rbaxte...@apache.org wrote:

  Where did you download this from?
 
 
  On Sat, Dec 8, 2012 at 12:56 AM, Leon Wu leon...@gmail.com wrote:
 
   I downloaded Shindig Spring Example and imported it to Eclipse. But I
 got
   an error when I started Tomcat. Can you please help this out?
  
   Here is the error.
  
   SEVERE: Exception sending context initialized event to listener
 instance
  of
   class org.apache.shindig.common.servlet.GuiceServletContextListener
  
   com.google.inject.CreationException: Guice creation errors:
  
  
   1) No implementation for
   org.apache.shindig.social.opensocial.oauth.OAuthDataStore was bound.
  
 while locating
  org.apache.shindig.social.opensocial.oauth.OAuthDataStore
  
   for parameter 0 at
   org.apache.shindig.social.core.oauth.OAuthAuthenticationHandler.init(
   OAuthAuthenticationHandler.java:60)
  
 while locating
   org.apache.shindig.social.core.oauth.OAuthAuthenticationHandler
  
   for parameter 1 at
  
 
 org.apache.shindig.social.core.oauth.AuthenticationHandlerProvider.init(
   AuthenticationHandlerProvider.java:39)
  
 at
  org.apache.shindig.social.core.config.SocialApiGuiceModule.configure(
   SocialApiGuiceModule.java:73)
  
  
   1 error
  
   at
 com.google.inject.internal.Errors.throwCreationExceptionIfErrorsExist(
   Errors.java:354)
  
   at com.google.inject.InjectorBuilder.initializeStatically(
   InjectorBuilder.java:152)
  
   at com.google.inject.InjectorBuilder.build(InjectorBuilder.java:105)
  
   at com.google.inject.Guice.createInjector(Guice.java:92)
  
   at
  
  
 
 org.apache.shindig.common.servlet.GuiceServletContextListener.contextInitialized(
   GuiceServletContextListener.java:73)
  
   at org.apache.catalina.core.StandardContext.listenerStart(
   StandardContext.java:4791)
  
   at org.apache.catalina.core.StandardContext.startInternal(
   StandardContext.java:5285)
  
   at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
  
   at org.apache.catalina.core.ContainerBase$StartChild.call(
   ContainerBase.java:1559)
  
   at org.apache.catalina.core.ContainerBase$StartChild.call(
   ContainerBase.java:1549)
  
   at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
  
   at java.util.concurrent.FutureTask.run(FutureTask.java:138)
  
   at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(
   ThreadPoolExecutor.java:886)
  
   at java.util.concurrent.ThreadPoolExecutor$Worker.run(
   ThreadPoolExecutor.java:908)
  
   at java.lang.Thread.run(Thread.java:680)
  
   Dec 8, 2012 12:53:22 AM

Re: Review Request: Variable Substitution should support EL syntax

2012-12-06 Thread Henry Saputra


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/8184/#review14104
---

Ship it!


Ship It!

- Henry Saputra


On Dec. 6, 2012, 1:21 p.m., Zhi Hong Yang wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/8184/
 ---
 
 (Updated Dec. 6, 2012, 1:21 p.m.)
 
 
 Review request for shindig, Ryan Baxter, Dan Dumont, Stanton Sievers, and 
 Rich Thompson.
 
 
 Description
 ---
 
 Copied from https://reviews.apache.org/r/6695/
 
 The OpenSocial 2.0 specification now states that the old way of doing 
 variable subsitution is now deprecated in favor of using EL syntax. Add that 
 support to Shindig.
 
 
 For example, Gadget developer should be able to to use EL syntax to 
 1. Calculate value like ${1+2}
 2. get user preference values anywhere in the gadget XML by ${UserPrefs.xxx}
 
 
 This addresses bug shindig-1588.
 https://issues.apache.org/jira/browse/shindig-1588
 
 
 Diffs
 -
 
   
 http://svn.apache.org/repos/asf/shindig/trunk/content/samplecontainer/examples/ELInGadgetDemo.xml
  PRE-CREATION 
   
 http://svn.apache.org/repos/asf/shindig/trunk/content/samplecontainer/examples/commoncontainer/gadgetCollections.json
  1417305 
   
 http://svn.apache.org/repos/asf/shindig/trunk/java/gadgets/src/main/java/org/apache/shindig/gadgets/render/RenderingGadgetRewriter.java
  1417305 
   
 http://svn.apache.org/repos/asf/shindig/trunk/java/gadgets/src/main/java/org/apache/shindig/gadgets/templates/DefaultTemplateProcessor.java
  1417305 
   
 http://svn.apache.org/repos/asf/shindig/trunk/java/gadgets/src/test/java/org/apache/shindig/gadgets/render/RenderingGadgetRewriterTest.java
  1417305 
   
 http://svn.apache.org/repos/asf/shindig/trunk/java/gadgets/src/test/java/org/apache/shindig/gadgets/templates/DefaultTemplateProcessorTest.java
  1417305 
 
 Diff: https://reviews.apache.org/r/8184/diff/
 
 
 Testing
 ---
 
 Upload a Test Gadget with this patch
 
 
 Thanks,
 
 Zhi Hong Yang

Re: How to exchange UserPrefs with shindig

2012-11-16 Thread Henry Saputra

Ah ok, then you need backend service to do that. You can wired it from
common container by setting config
param osapi.container.ContainerConfig.SET_PREFERENCES that should make call
to your backend server.

Hope this help

- Henry


On Thu, Nov 15, 2012 at 10:48 PM, Martin Hoeller mar...@xss.co.at wrote:

 Hi Henry!

 Actually I don't know. I want the user to be able to configure a gadget
 (using the UserPref section in the gadget's XML specification). And I
 want those settings to be persisted somehow.

 We already have a database for our application, so ideally there would be
 some mechanism to plugin in and communicate the preferences with shindig.


 I found some older threads on the mailinglist mentioning services but
 some of the mentioned classes do no exist any more and I'm afraid I'd be
 using old/deprecated APIs again (like I did with the container). So could
 you please tell me the preferred way for doing this in shindig 2.5
 (beta-4).

 Many thanks,
 - martin

 On 15 Nov 2012, Henry Saputra wrote:

  Hi Martin, are you trying to push user preference dynamically when
 opening
  a gadget?
 
  Otherwise you can set user pref via gadget.xml in the UserPref section.
 
  And thanks for working on the archetype to use the common container,
 really
  appreciate it
 
  - Henry
 
 
  On Thu, Nov 15, 2012 at 7:13 AM, Martin Hoeller mar...@xss.co.at
 wrote:
 
   Hi!
  
   Finally I managed to use CommonContainer for rendering my gadgets (I'll
   try to update the archetype and send a patch once I've cleaned up the
   code). What I'd like to do next is find a way how to get the UserPrefs
   from shindig and how to provide them to shindig.
  
   I already found RenderParam.USER_PREFS. Is this the way to provide
   parameters for a gadget? What object should I pass?
  
   I also found ContainerConfig.GET_PREFERENCES. Can a method be specified
   to provide UserPrefs?
  
   Thanks in advance for your help,
   - martin

Re: How to exchange UserPrefs with shindig

2012-11-15 Thread Henry Saputra

Hi Martin, are you trying to push user preference dynamically when opening
a gadget?

Otherwise you can set user pref via gadget.xml in the UserPref section.

And thanks for working on the archetype to use the common container, really
appreciate it

- Henry


On Thu, Nov 15, 2012 at 7:13 AM, Martin Hoeller mar...@xss.co.at wrote:

 Hi!

 Finally I managed to use CommonContainer for rendering my gadgets (I'll
 try to update the archetype and send a patch once I've cleaned up the
 code). What I'd like to do next is find a way how to get the UserPrefs
 from shindig and how to provide them to shindig.

 I already found RenderParam.USER_PREFS. Is this the way to provide
 parameters for a gadget? What object should I pass?

 I also found ContainerConfig.GET_PREFERENCES. Can a method be specified
 to provide UserPrefs?

 Thanks in advance for your help,
 - martin

Re: Review Request: If metadata and tokens are preloaded, the security token TTL from the metadata is used

2012-11-05 Thread Henry Saputra

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/7857/#review13103
---

http://svn.apache.org/repos/asf/shindig/trunk/features/src/main/javascript/features/container/container.js
https://reviews.apache.org/r/7857/#comment28238

Small nit to update the comment header reflecting the actual param name
opt_tokenResponse

- Henry Saputra

On Nov. 4, 2012, 3:40 p.m., Stanton Sievers wrote:

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/7857/
---

(Updated Nov. 4, 2012, 3:40 p.m.)

Review request for shindig, Dan Dumont and Matt Franklin.

Description
---

From the Jira:
When using the preloadMetadatas and preloadTokens optional config when
constructing an osapi.container.Container, the token refresh schedule will be
based on the TTL of whatever is in preloadMetadatas and not preloadTokens.

This addresses bug SHINDIG-1880.
https://issues.apache.org/jira/browse/SHINDIG-1880

Diffs
-

http://svn.apache.org/repos/asf/shindig/trunk/features/src/main/javascript/features/container/container.js
1405426

http://svn.apache.org/repos/asf/shindig/trunk/features/src/test/javascript/features/container/container_test.js
1405426

Diff: https://reviews.apache.org/r/7857/diff/

Testing
---

Wrote some new JSUnits to cover this use case. These are included in the
patch. Some of the window.setTimeout code in the JSUnit is odd, but it's
the only way I could get it to not puke with reference errors saying that
setTimeout is undefined when it is called in
osapi.container.Container.scheduleRefreshTokens_.

Thanks,

Stanton Sievers

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

2012-10-27 Thread Henry Saputra

Signatures on common, gadgets, social-api, features are good.

Replace generated jars in the demo server and smoke test apps run looks good.
REST and JSON RPC looks ok for several endpoints with basic security token.

+1


Would like to have SHINDIG-1878 included but looks like we wont make
it. Looks like we need at least one more beta 2.5.0 before final
release.


- Henry

On Tue, Oct 23, 2012 at 4:48 AM, Ryan Baxter rbaxte...@apache.org wrote:
 Hi,

 I finished building the 2.5.0-beta5 release.  Please give it a try and
 vote on the release.

 Here are the draft release notes:
 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310741version=12323245


 Staging repo:
 https://repository.apache.org/content/repositories/orgapacheshindig-157/

 Web site:
 http://shindig.apache.org/

 Vote open for 72 hours.

 [ ] +1
 [ ] +0
 [ ] -1

 -Ryan

Re: Looks like Cobertura fail again at the Shidnig JDK1.6 CI ?

2012-10-27 Thread Henry Saputra

Thanks Stanton

- Henry

On Sat, Oct 27, 2012 at 4:15 PM, Stanton Sievers siever...@gmail.com wrote:
 Yes. I had emailed the Shindig and Rave dev lists earlier this week as both
 are affected.  For now I've disabled cobertura and the latest build
 passed.  I hope to have more time to investigate the root cause later this
 week.

 Thanks,
 -Stanton
 On Oct 26, 2012 8:42 PM, Henry Saputra henry.sapu...@gmail.com wrote:

 Looks like the Cobertura failing the CI builds again in the JDK 1.6
 builds? I am surprise the other builds dont fail.

 Could we disable Cobertura for 1.6 CI for a while? I am having problem
 logging in to the Apache CI.

 - Henry

Looks like Cobertura fail again at the Shidnig JDK1.6 CI ?

2012-10-26 Thread Henry Saputra

Looks like the Cobertura failing the CI builds again in the JDK 1.6
builds? I am surprise the other builds dont fail.

Could we disable Cobertura for 1.6 CI for a while? I am having problem
logging in to the Apache CI.

- Henry

Re: Releasing Shindig 2.5

2012-10-14 Thread Henry Saputra

Hi Ryan,

Did you run query for Fix Version/s of 2.5.0 to get the list?

- Henry


On Wed, Oct 10, 2012 at 6:20 AM, Ryan Baxter rbaxte...@gmail.com wrote:
 I think we might have to have 1 or 2 more betas for 2.5.  There are a few
 fixes I have come across that people want to go into 2.5.  Here is what I
 have so far...

 https://issues.apache.org/jira/browse/SHINDIG-1801
 https://issues.apache.org/jira/browse/SHINDIG-1871
 https://issues.apache.org/jira/browse/SHINDIG-1878
 https://issues.apache.org/jira/browse/SHINDIG-1821
 https://issues.apache.org/jira/browse/shindig-1588
 https://issues.apache.org/jira/browse/SHINDIG-1877
 https://issues.apache.org/jira/browse/SHINDIG-1863
 https://issues.apache.org/jira/browse/shindig-1720
 https://issues.apache.org/jira/browse/shindig-1837



 On Fri, Oct 5, 2012 at 7:29 AM, Ryan Baxter rbaxte...@gmail.com wrote:

 Awesome thanks Paul.


 On Thursday, October 4, 2012, Paul Lindner wrote:

 I can help too..  Will have a look at our deps and see if there's anything
 needed there.


 On Wednesday, October 3, 2012, Henry Saputra wrote:

  Yes +1.
 
  I could help sprint out fixes after next week.
 
  So we are targeting end of month of October for code complete of
  patches for 2.5?
 
  - Henry
 
  On Wed, Oct 3, 2012 at 9:48 AM, Ryan Baxter rbaxte...@apache.org
 javascript:;
  wrote:
   Everyone, I feel we are close to shutting down Shindig 2.5 and doing
 an
   official release.  Does anyone disagree?  I am going to go through the
  list
   of open JIRAs and reviews we have opeb against 2.5 and see what we
 want
  to
   do with them.  I know there a few that we would like to get in before
 2.5
   is released, like some OAuth 2.0 cleanup.  The purpose of this email
 is
  to
   see if there is anything that anyone wants to get in to 2.5 that they
  have
   not created a JIRA for at this point.  Please let me know by the end
 of
  the
   week so we can see where we are at.
  
   -Ryan
 


 --
 Paul Lindner -- lind...@inuus.com -- profiles.google.com/pmlindner

Re: Jboss deployment failure

2012-10-12 Thread Henry Saputra

Hmm thats weird.

The system.properties in the web.xml is used by Guice to be injected
to Java System.properties.

If these not set, then internally Shindig will try to use
ServletRequestContext to set the shindig.host and shindig.port
properties.

- Henry

On Fri, Oct 12, 2012 at 1:29 AM, Martin Höller mar...@xss.co.at wrote:
 Hi!

 Doug Ellison doug.ellison@... writes:

 Hi I'm trying to get Apache Shindig to run within Jboss AS 5.1.  I've
 run into a problem that I cannot seem to figure out.  I downloaded and
 ran the latest code and it builds successfully.  I am able to do mvn
 -Prun and get the Jetty server up and running and am able to do the
 same gadgets etc.  The problem becomes when I try to take the
 generated .war file for shindig-server-etcetcetc.war and deploy to
 Jboss.  I launch Jboss and remove the ROOT.war file from the default
 deploy directory.  I then rename / move the shindig war to deploy and
 watching the console logs it deploys successfully in the root context.
  When I use the same URL that worked with the Jetty server running
 http://localhost:8080/gadgets/ifr?
 url=http://www.labpixies.com/campaigns/todo/todo.xml
 it fails with an error

 org.apache.shindig.common.uri.Uri$UriException:
 java.lang.IllegalArgumentException: java.net.URISyntaxException:
 Illegal character in authority at index 7: http://localhost
 aKey=/shindig/gadgets/proxy?container=defaulturl= shindig.port=:8080

 Any light that someone can shed would be monumentally appreciated.
 I've wondered if it could be some kind of dependency issue with a jar
 that comes bundled with Jboss.  I did get rid of the original
 xercesimpl.jar that came with Jboss because initially I had problems
 with it launching and it was getting errors with SAX parsing.  Once
 again any help would be appreciated.

 It's been a while since this has been asked, but eventually the answer will 
 help
 someone finding it...

 In the web.xml shipped with shindig 2.5-beta-4 there is context-param named
 system.properties defined. Its value is this:
  ![CDATA[
 shindig.host=
 shindig.port=
 aKey=/shindig/gadgets/proxy?container=defaulturl=
  ]]
 I really don't know what it is needed for but just removing everything within
 CDATA solved the problem for me. Earlier I tried using valid hostname and port
 but this didn't solve the problem.

 hth,
 - martin

Re: [SHINDIG-1878] discrepancy between spec and code

2012-10-12 Thread Henry Saputra

Hi Jan,

Really appreciate potential contributions you could make. We are in
the middle of releasing Shindig 2.5 to comply with OpenSocial 2.5 spec
so any help is greatly appreciated.

As for your question, I think I am kind of loss on what your concerns are?

Could you give a bit more example of what conflict or confusion about
matching the fields for the Person data type with the spec?

- Henry

On Thu, Oct 11, 2012 at 11:32 PM, Jan Willem Janssen
janwillem.jans...@luminis.eu wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 Hi,

 A couple of days ago I created SHINDIG-1878 as I've found some
 discrepancies between the OpenSocial 2.5 specification and the current
 code. Most apparently, the Person entity appears to be quite a bit off
 with respect to the spec.

 I'd like to supply some patches to help out resolving this issue, but
 have some questions about how to proceed. For example: the
 inconsistent use of PluralFields in Person: should it be implemented
 as a simple ordered list, or a ListListField? Or the use of
 enumerations for, for example, the drinker-field, should those be
 converted back to strings?

 Anybody care to share their thoughts on this?

 - --
 Met vriendelijke groeten | Kind regards

 Jan Willem Janssen | Software Architect
 +31 631 765 814

 /My world is:/

 Luminis Technologies B.V.
 IJsselburcht 3
 6825 BS  Arnhem
 +31 88 586 46 30

 http://www.luminis-technologies.com
 http://www.luminis.eu

 KvK (CoC) 09 16 28 93
 BTW (VAT) NL8169.78.566.B.01
 -BEGIN PGP SIGNATURE-
 Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
 Comment: GPGTools - http://gpgtools.org
 Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

 iQIcBAEBAgAGBQJQd7mSAAoJEKF/mP2eHDc435YQALSxb3W9yvt9fUwH86EjlOmJ
 JNCYYPxZWd65ZL0vHdSUOzIofn0ODVvbVU3wBBq2oMBfq+q5wuE/G1AKlE838VSv
 k4JZIVfBO59jiyoJByCEYM+0KWq6G8hMdsSgcP00MTytom5REqx9g7PD24I88ZeE
 IbetwdpRO1Rrs5OCq/dR5OzhC8ge2ySSDTl4l5Ye1YlEwjb6O0HlNQBMD9r+Ge7K
 esUzT8V8f/NM1ai/jhTbr76O81EAgpz0fCMquH1b++Z7FDHmIAsEmbgI40rgU8pQ
 owKlm8LbhBwqtnAtlCoggaqhgbOGgFMohsglRVxstdbAkEc9T7v9k+koDfyTwRpJ
 Pp/7PfxPBZfI39/eJPZvZ9nHG7xA6VnmxJ9jk4wBrpIsozwdSrXB8ocWgSvsUDMp
 3XwzxkohndGRmMFQn+E922NjFxT2FkTYDeZ4SfTDx9fXx4wiqKPSVQeMtOlusD/M
 88aM3YiH/qrGdW6gILGiK0lfGb2PxQ/gFIXC2BNFpOKoMk2Uwzc58xZlAcfRRBwo
 75ymQDQo9wtni8nl79aCTtao/h6gOZoqtqh1pKq6JR2Eprchs8neer3xgv8rOj5t
 FeM6BDVyd3x9k+SAwnkKKu9zbYMVNedH8nJGMwxe02PI1b8oFFAIsKwkrflV+ETE
 CTh+DYbXi/rRyXjRtZip
 =FsRy
 -END PGP SIGNATURE-

Re: Review Request: File downloaded via Proxy always has name p.txt - Include file name on proxy URL because IE8 does not respect Content-Disposition

2012-10-10 Thread Henry Saputra


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/7309/#review12306
---



http://svn.apache.org/repos/asf/shindig/trunk/java/gadgets/src/main/java/org/apache/shindig/gadgets/servlet/ProxyHandler.java
https://reviews.apache.org/r/7309/#comment26072

Can we change this check with StringUtils.isBlank instead of == null just 
in case the response origin server return empty or blank Content-Disposition 
header?



http://svn.apache.org/repos/asf/shindig/trunk/java/gadgets/src/main/java/org/apache/shindig/gadgets/servlet/ProxyHandler.java
https://reviews.apache.org/r/7309/#comment26073

Do we need else if over here? I think the if checks will guarantee that the 
Content-Disposition header is valid?


- Henry Saputra


On Oct. 10, 2012, 2:28 a.m., Erik Bi wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/7309/
 ---
 
 (Updated Oct. 10, 2012, 2:28 a.m.)
 
 
 Review request for shindig, Ryan Baxter, Dan Dumont, Stanton Sievers, and 
 Rich Thompson.
 
 
 Description
 ---
 
 Problem 1: Shindig proxy doesn't respect the content-Disposition header 
 correctly, so when user click a button to download the file via shindig 
 proxy use, the file name in the pop-up dialog is always p.txt. Here code is 
 updated to copy the right Content-Disposition header. 
 
 Problem 2: Even with the right Content-Disposition header, IE8 handles 
 Content-Disposition header differently.
 
 IE8 doesn't handle the Content-Disposition header like Content-Disposition = 
 attachment; filename*= UTF-8''%e2%82%ac%20rates correctly (should be a 
 limitation of IE8). 
 
 Even with the right Content-Disposition header,  when you open click a button 
 to download the file via shindig proxy, you will get a message box asking 
 if you want to open or save this file. At that time file name displayed will 
 not be the one in the header, but the path name of the current urlstart, in 
 Shindig, it will probably be proxy.
 
 In order to fix, append a file name on proxy url and ignore that at the proxy 
 server side. 
 
 For example, when you call 
 gadgets.io.getProxyUrl(http://target.example.com/image.gif;);
 it will get result like 
 http://host/proxy/image.gif?url=http%3a%2f%2ftarget.example.com%2fimage.gif; +
   refresh=3600 +
   g=http%3a%2f%2fwww.gadget.com%2fgadget.xml +
   c=foo
 
 It will not effect any existing code
 
 
 This addresses bug shindig-1875.
 https://issues.apache.org/jira/browse/shindig-1875
 
 
 Diffs
 -
 
   http://svn.apache.org/repos/asf/shindig/trunk/config/container.js 1369611 
   
 http://svn.apache.org/repos/asf/shindig/trunk/features/src/main/javascript/features/core.io/feature.xml
  1383008 
   
 http://svn.apache.org/repos/asf/shindig/trunk/features/src/main/javascript/features/core.io/io.js
  1395276 
   
 http://svn.apache.org/repos/asf/shindig/trunk/features/src/test/javascript/features/core.io/iotest.js
  1366998 
   
 http://svn.apache.org/repos/asf/shindig/trunk/java/gadgets/src/main/java/org/apache/shindig/gadgets/servlet/ProxyHandler.java
  1366998 
 
 Diff: https://reviews.apache.org/r/7309/diff/
 
 
 Testing
 ---
 
 Add Test case in iotest.js
 
 
 Thanks,
 
 Erik Bi

Re: Review Request: File downloaded via Proxy always has name p.txt - Include file name on proxy URL because IE8 does not respect Content-Disposition

2012-10-10 Thread Henry Saputra


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/7309/#review12327
---

Ship it!


Ship It!

- Henry Saputra


On Oct. 10, 2012, 7:03 a.m., Erik Bi wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/7309/
 ---
 
 (Updated Oct. 10, 2012, 7:03 a.m.)
 
 
 Review request for shindig, Ryan Baxter, Dan Dumont, Stanton Sievers, and 
 Rich Thompson.
 
 
 Description
 ---
 
 Problem 1: Shindig proxy doesn't respect the content-Disposition header 
 correctly, so when user click a button to download the file via shindig 
 proxy use, the file name in the pop-up dialog is always p.txt. Here code is 
 updated to copy the right Content-Disposition header. 
 
 Problem 2: Even with the right Content-Disposition header, IE8 handles 
 Content-Disposition header differently.
 
 IE8 doesn't handle the Content-Disposition header like Content-Disposition = 
 attachment; filename*= UTF-8''%e2%82%ac%20rates correctly (should be a 
 limitation of IE8). 
 
 Even with the right Content-Disposition header,  when you open click a button 
 to download the file via shindig proxy, you will get a message box asking 
 if you want to open or save this file. At that time file name displayed will 
 not be the one in the header, but the path name of the current urlstart, in 
 Shindig, it will probably be proxy.
 
 In order to fix, append a file name on proxy url and ignore that at the proxy 
 server side. 
 
 For example, when you call 
 gadgets.io.getProxyUrl(http://target.example.com/image.gif;);
 it will get result like 
 http://host/proxy/image.gif?url=http%3a%2f%2ftarget.example.com%2fimage.gif; +
   refresh=3600 +
   g=http%3a%2f%2fwww.gadget.com%2fgadget.xml +
   c=foo
 
 It will not effect any existing code
 
 
 This addresses bug shindig-1875.
 https://issues.apache.org/jira/browse/shindig-1875
 
 
 Diffs
 -
 
   http://svn.apache.org/repos/asf/shindig/trunk/config/container.js 1369611 
   
 http://svn.apache.org/repos/asf/shindig/trunk/features/src/main/javascript/features/core.io/feature.xml
  1383008 
   
 http://svn.apache.org/repos/asf/shindig/trunk/features/src/main/javascript/features/core.io/io.js
  1395276 
   
 http://svn.apache.org/repos/asf/shindig/trunk/features/src/test/javascript/features/core.io/iotest.js
  1366998 
   
 http://svn.apache.org/repos/asf/shindig/trunk/java/gadgets/src/main/java/org/apache/shindig/gadgets/servlet/ProxyHandler.java
  1366998 
 
 Diff: https://reviews.apache.org/r/7309/diff/
 
 
 Testing
 ---
 
 Add Test case in iotest.js
 
 
 Thanks,
 
 Erik Bi

Re: Review Request: SHINDIG-1821 Add support for @following, @followers, et. according to OS 2.5 spec

2012-10-09 Thread Henry Saputra



 On Oct. 9, 2012, 1:37 a.m., Ryan Baxter wrote:
  Henry any plans on completing this fix?
 
 Henry Saputra wrote:
 Sorry guys, I'll have to pick up this effort next week after Jive World 
 conference.
 
 Ryan Baxter wrote:
 I assume this is something we want for a 2.5 release though correct?

yes that is correct. Would like to include this in 2.5 release.


- Henry


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/6140/#review12259
---


On July 25, 2012, 6:02 p.m., Henry Saputra wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/6140/
 ---
 
 (Updated July 25, 2012, 6:02 p.m.)
 
 
 Review request for shindig.
 
 
 Description
 ---
 
 See https://issues.apache.org/jira/browse/SHINDIG-1821 for details
 
 
 This addresses bug SHINDIG-1821.
 https://issues.apache.org/jira/browse/SHINDIG-1821
 
 
 Diffs
 -
 
   trunk/content/sampledata/canonicaldb.json 1364039 
   
 trunk/java/social-api/src/main/java/org/apache/shindig/social/opensocial/spi/GroupId.java
  1364039 
   
 trunk/java/social-api/src/main/java/org/apache/shindig/social/sample/spi/JsonDbOpensocialService.java
  1364039 
 
 Diff: https://reviews.apache.org/r/6140/diff/
 
 
 Testing
 ---
 
 
 Thanks,
 
 Henry Saputra

Re: Review Request: Improve servicability of the MakeRequest servlet handling classes

2012-10-09 Thread Henry Saputra



 On Sept. 24, 2012, 11:51 p.m., Henry Saputra wrote:
  Ship It!
 
 Erik Bi wrote:
 Could somebody help to submit this into Shindig since I don't have that 
 privilege?

Patch committed. Please close the review.


- Henry


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/7010/#review11869
---


On Sept. 24, 2012, 5:23 a.m., Erik Bi wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/7010/
 ---
 
 (Updated Sept. 24, 2012, 5:23 a.m.)
 
 
 Review request for shindig, Ryan Baxter, Dan Dumont, Stanton Sievers, and 
 Rich Thompson.
 
 
 Description
 ---
 
 The server-side classes need to support finer level of logging/debugging 
 information when an admin turns on that need. 
 
 
 This addresses bug SHINDIG-1866.
 https://issues.apache.org/jira/browse/SHINDIG-1866
 
 
 Diffs
 -
 
   
 http://svn.apache.org/repos/asf/shindig/trunk/java/gadgets/src/main/java/org/apache/shindig/gadgets/servlet/MakeRequestServlet.java
  1366998 
 
 Diff: https://reviews.apache.org/r/7010/diff/
 
 
 Testing
 ---
 
 
 Thanks,
 
 Erik Bi

Re: Review Request: Improve servicability of the MakeRequest servlet handling classes

2012-10-09 Thread Henry Saputra



 On Sept. 24, 2012, 11:51 p.m., Henry Saputra wrote:
  Ship It!
 
 Erik Bi wrote:
 Could somebody help to submit this into Shindig since I don't have that 
 privilege?
 
 Henry Saputra wrote:
 Patch committed. Please close the review.
 
 Erik Bi wrote:
 Thank you Henry.

Thanks for the patch Erik


- Henry


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/7010/#review11869
---


On Sept. 24, 2012, 5:23 a.m., Erik Bi wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/7010/
 ---
 
 (Updated Sept. 24, 2012, 5:23 a.m.)
 
 
 Review request for shindig, Ryan Baxter, Dan Dumont, Stanton Sievers, and 
 Rich Thompson.
 
 
 Description
 ---
 
 The server-side classes need to support finer level of logging/debugging 
 information when an admin turns on that need. 
 
 
 This addresses bug SHINDIG-1866.
 https://issues.apache.org/jira/browse/SHINDIG-1866
 
 
 Diffs
 -
 
   
 http://svn.apache.org/repos/asf/shindig/trunk/java/gadgets/src/main/java/org/apache/shindig/gadgets/servlet/MakeRequestServlet.java
  1366998 
 
 Diff: https://reviews.apache.org/r/7010/diff/
 
 
 Testing
 ---
 
 
 Thanks,
 
 Erik Bi

Re: Review Request: File downloaded via Proxy always has name p.txt - Include file name on proxy URL because IE8 does not respect Content-Disposition

2012-10-09 Thread Henry Saputra


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/7309/#review12302
---



http://svn.apache.org/repos/asf/shindig/trunk/java/gadgets/src/main/java/org/apache/shindig/gadgets/servlet/ProxyHandler.java
https://reviews.apache.org/r/7309/#comment26065

But isn't Content-Disposition is response header for the Shindig to suggest 
a default filename if the user agent requests for the content is saved to a 
file?


- Henry Saputra


On Oct. 10, 2012, 2:28 a.m., Erik Bi wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/7309/
 ---
 
 (Updated Oct. 10, 2012, 2:28 a.m.)
 
 
 Review request for shindig, Ryan Baxter, Dan Dumont, Stanton Sievers, and 
 Rich Thompson.
 
 
 Description
 ---
 
 Problem 1: Shindig proxy doesn't respect the content-Disposition header 
 correctly, so when user click a button to download the file via shindig 
 proxy use, the file name in the pop-up dialog is always p.txt. Here code is 
 updated to copy the right Content-Disposition header. 
 
 Problem 2: Even with the right Content-Disposition header, IE8 handles 
 Content-Disposition header differently.
 
 IE8 doesn't handle the Content-Disposition header like Content-Disposition = 
 attachment; filename*= UTF-8''%e2%82%ac%20rates correctly (should be a 
 limitation of IE8). 
 
 Even with the right Content-Disposition header,  when you open click a button 
 to download the file via shindig proxy, you will get a message box asking 
 if you want to open or save this file. At that time file name displayed will 
 not be the one in the header, but the path name of the current urlstart, in 
 Shindig, it will probably be proxy.
 
 In order to fix, append a file name on proxy url and ignore that at the proxy 
 server side. 
 
 For example, when you call 
 gadgets.io.getProxyUrl(http://target.example.com/image.gif;);
 it will get result like 
 http://host/proxy/image.gif?url=http%3a%2f%2ftarget.example.com%2fimage.gif; +
   refresh=3600 +
   g=http%3a%2f%2fwww.gadget.com%2fgadget.xml +
   c=foo
 
 It will not effect any existing code
 
 
 This addresses bug shindig-1875.
 https://issues.apache.org/jira/browse/shindig-1875
 
 
 Diffs
 -
 
   http://svn.apache.org/repos/asf/shindig/trunk/config/container.js 1369611 
   
 http://svn.apache.org/repos/asf/shindig/trunk/features/src/main/javascript/features/core.io/feature.xml
  1383008 
   
 http://svn.apache.org/repos/asf/shindig/trunk/features/src/main/javascript/features/core.io/io.js
  1395276 
   
 http://svn.apache.org/repos/asf/shindig/trunk/features/src/test/javascript/features/core.io/iotest.js
  1366998 
   
 http://svn.apache.org/repos/asf/shindig/trunk/java/gadgets/src/main/java/org/apache/shindig/gadgets/servlet/ProxyHandler.java
  1366998 
 
 Diff: https://reviews.apache.org/r/7309/diff/
 
 
 Testing
 ---
 
 Add Test case in iotest.js
 
 
 Thanks,
 
 Erik Bi

Re: SHINDIG-1702

2012-10-08 Thread Henry Saputra

I am ok with it

- Henry

On Mon, Oct 8, 2012 at 5:43 PM, Ryan Baxter rbaxte...@apache.org wrote:
 What do we think about this one?  Seems to make sense since we removed the
 opensocial-0.8 feature.

 https://issues.apache.org/jira/browse/SHINDIG-1702

 -Ryan

Re: Review Request: SHINDIG-1821 Add support for @following, @followers, et. according to OS 2.5 spec

2012-10-08 Thread Henry Saputra



 On Oct. 9, 2012, 1:37 a.m., Ryan Baxter wrote:
  Henry any plans on completing this fix?

Sorry guys, I'll have to pick up this effort next week after Jive World 
conference.


- Henry


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/6140/#review12259
---


On July 25, 2012, 6:02 p.m., Henry Saputra wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/6140/
 ---
 
 (Updated July 25, 2012, 6:02 p.m.)
 
 
 Review request for shindig.
 
 
 Description
 ---
 
 See https://issues.apache.org/jira/browse/SHINDIG-1821 for details
 
 
 This addresses bug SHINDIG-1821.
 https://issues.apache.org/jira/browse/SHINDIG-1821
 
 
 Diffs
 -
 
   trunk/content/sampledata/canonicaldb.json 1364039 
   
 trunk/java/social-api/src/main/java/org/apache/shindig/social/opensocial/spi/GroupId.java
  1364039 
   
 trunk/java/social-api/src/main/java/org/apache/shindig/social/sample/spi/JsonDbOpensocialService.java
  1364039 
 
 Diff: https://reviews.apache.org/r/6140/diff/
 
 
 Testing
 ---
 
 
 Thanks,
 
 Henry Saputra

Re: Releasing Shindig 2.5

2012-10-03 Thread Henry Saputra

Yes +1.

I could help sprint out fixes after next week.

So we are targeting end of month of October for code complete of
patches for 2.5?

- Henry

On Wed, Oct 3, 2012 at 9:48 AM, Ryan Baxter rbaxte...@apache.org wrote:
 Everyone, I feel we are close to shutting down Shindig 2.5 and doing an
 official release.  Does anyone disagree?  I am going to go through the list
 of open JIRAs and reviews we have opeb against 2.5 and see what we want to
 do with them.  I know there a few that we would like to get in before 2.5
 is released, like some OAuth 2.0 cleanup.  The purpose of this email is to
 see if there is anything that anyone wants to get in to 2.5 that they have
 not created a JIRA for at this point.  Please let me know by the end of the
 week so we can see where we are at.

 -Ryan

Re: Review Request: Leaky abstraction wrt BeanJsonConverter.

2012-09-25 Thread Henry Saputra


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/7266/#review11902
---

Ship it!


Well thats a good catch =)

+1

- Henry Saputra


On Sept. 25, 2012, 6:30 p.m., Jan Willem Janssen wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/7266/
 ---
 
 (Updated Sept. 25, 2012, 6:30 p.m.)
 
 
 Review request for shindig.
 
 
 Description
 ---
 
 See https://issues.apache.org/jira/browse/SHINDIG-1874 for details.
 
 
 This addresses bug SHINDIG-1874.
 https://issues.apache.org/jira/browse/SHINDIG-1874
 
 
 Diffs
 -
 
   trunk/java/common/src/main/java/org/apache/shindig/protocol/ApiServlet.java 
 1389865 
 
 Diff: https://reviews.apache.org/r/7266/diff/
 
 
 Testing
 ---
 
 
 Thanks,
 
 Jan Willem Janssen

Re: enabling default features for all gadgets

2012-09-25 Thread Henry Saputra

HI Christian,

You can either have custom DefaultGadgetSpecFactory.parse() and
decorate the ModulePrefs element with your features or have custom
Processor.process() to add default or additional feature there.

Or you can have custom rewriter early in the flow and add the required
features via call to Gadget.addFeature before other rewriters process
the gadget

Hope this helps.

- Henry

On Tue, Sep 25, 2012 at 11:37 AM, Christian Fischer flyinghu...@web.de wrote:
 Hi all,

 i'm using shindig (inside Apache RAVE) for my master-thesis and need to
 enable a default feature for all gadgets even the gadgets doesn't require
 this feature.
 In other words: i must inject a reference to a javascript file into each
 gadget.

 What is the best way to acquire this goal with shindig?
 It is possible to set a feature as required for all? Then i only must
 create a new feature.
 If not, which source files are responsible for the script ... inclusion?

 For now, the Code looks a bit confusing to me.

 Thanks,
 Christian

Re: Review Request: Improve servicability of the MakeRequest servlet handling classes

2012-09-24 Thread Henry Saputra


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/7010/#review11868
---



http://svn.apache.org/repos/asf/shindig/trunk/java/gadgets/src/main/java/org/apache/shindig/gadgets/servlet/MakeRequestServlet.java
https://reviews.apache.org/r/7010/#comment25404

Yeah, looks like the rest of  classname var name was not following 
convention.

Need to create separate ticket for it.


- Henry Saputra


On Sept. 24, 2012, 5:23 a.m., Erik Bi wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/7010/
 ---
 
 (Updated Sept. 24, 2012, 5:23 a.m.)
 
 
 Review request for shindig, Ryan Baxter, Dan Dumont, Stanton Sievers, and 
 Rich Thompson.
 
 
 Description
 ---
 
 The server-side classes need to support finer level of logging/debugging 
 information when an admin turns on that need. 
 
 
 This addresses bug SHINDIG-1866.
 https://issues.apache.org/jira/browse/SHINDIG-1866
 
 
 Diffs
 -
 
   
 http://svn.apache.org/repos/asf/shindig/trunk/java/gadgets/src/main/java/org/apache/shindig/gadgets/servlet/MakeRequestServlet.java
  1366998 
 
 Diff: https://reviews.apache.org/r/7010/diff/
 
 
 Testing
 ---
 
 
 Thanks,
 
 Erik Bi

Re: Review Request: Improve servicability of the MakeRequest servlet handling classes

2012-09-24 Thread Henry Saputra


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/7010/#review11869
---

Ship it!


Ship It!

- Henry Saputra


On Sept. 24, 2012, 5:23 a.m., Erik Bi wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/7010/
 ---
 
 (Updated Sept. 24, 2012, 5:23 a.m.)
 
 
 Review request for shindig, Ryan Baxter, Dan Dumont, Stanton Sievers, and 
 Rich Thompson.
 
 
 Description
 ---
 
 The server-side classes need to support finer level of logging/debugging 
 information when an admin turns on that need. 
 
 
 This addresses bug SHINDIG-1866.
 https://issues.apache.org/jira/browse/SHINDIG-1866
 
 
 Diffs
 -
 
   
 http://svn.apache.org/repos/asf/shindig/trunk/java/gadgets/src/main/java/org/apache/shindig/gadgets/servlet/MakeRequestServlet.java
  1366998 
 
 Diff: https://reviews.apache.org/r/7010/diff/
 
 
 Testing
 ---
 
 
 Thanks,
 
 Erik Bi

Re: Review Request: OAuth 1.0a broken with recent oauthpopup changes moving window open to container from gadget

2012-09-20 Thread Henry Saputra



 On Sept. 20, 2012, 4:47 a.m., Henry Saputra wrote:
  Dan, could you tell a bit more details what the issue looks like with 
  3-legged OAuth  1.0a dance? It will help review the change. 
  
  This needs to be fixed ASAP bc the oauthpopup change is part of beta4 
  release and if its broken we need to come up with beta5 quickly.
 
 Dan Dumont wrote:
 Hey, thanks for helping with the review :)
 
 Let me start by describing what I saw before any of these changes or the 
 oauthpopup changes with locked domains in a deployment.
 1. Oauth request made by a gadget on locked.gadget.com through the proxy, 
 no oauth creds... 
 2. The remote server sends back the appropriate response
 3. The proxy ads info to the response like the oauth authorize uri with 
 the authorize callback.  
 
 3's callback is generated by the shindig property 
 shindig.signing.global-callback-url which points to the unlocked server 
 domain.  In the (now deleted) GadgetOAuthCallbackGenerator.java we would take 
 the callback endpoint generated from container.js 
 gadgets.uri.oauth.callbackTemplate and %host% is replaced with the authority 
 of the gadget on the locked domain and add it to a token.
 (I will be updating this patch to delete the 
 gadgets.uri.oauth.callbackTemplate param in the container config, it's not 
 used anymore)
 
 4. Encrypt the locked domain callback endpoint in a token and add it to 
 the callback url in 3 as a query param.
 5. Gadget gets request failure and uses the oauthpopup class to open the 
 authorize url (with callback url?state={encrypted-callback-url-query-param})  
 window.open on locked domain.
 6. Log in on remote service, press authorize, yadda yadda
 7. Redirected back to UNLCOKED domain (the one from shindig.properties).  
 8. The (now deleted) code in the servlet would see you have a token, 
 decrypt it, move all current query params to the decrypted callback and send 
 a redirect.
 9. Back to the same servlet on the LOCKED domain.  Servlet serves up js 
 code that sets window.opener.someoauthproperty for some makerequest oauth 
 completion.
 
 Note here that window.opener is on the gadget's locked domain, so this 
 redirection madness was necessary to make sure that the window.opener would 
 be able to be written to.
 
 
 After my changes to oauthpopup, everything was the same except for
 5. The container page on an unlocked domain sends the window.open to the 
 authorize url (with callback url?state={encrypted-callback-url-query-param})
 So during 9, the js code had access violation accessing a property in 
 window.opener (from locked domain to container domain)
 
 After these changes, we change
 4. do nothing
 5. changed as above
 8. do nothing
 9. Now on the unlocked domain, window.opener would now match domains.
 
 Dan Dumont wrote:
 After talking with Stanton, we're kind of weary of how large this change 
 is getting because we found a slight wrinkle in the redirect in the case 
 where the container isn't on the same domain as the shindig server.
 
 Typically one would have a proxy set up so that rpc stuff would work... 
 so we were thinking we could take the container host in the security token 
 and use that to generate a url to the oauth endpoint via the container's 
 proxy (you would have to edit the shindig.properties value with any proxy you 
 are using on that url).
 
 I could add the comments describing this setup and create 
 warnings/errors/exceptions for values for the container in the security token 
 that cannot be handled so that admins can easily understand the failures and 
 correct them.  And also write all this up in UPGRADING... Or I can just 
 rip all this out now and revert my oauthpopup changes and save this for post 
 2.5.  I had hoped that this would be a simpler change and a stepping stone to 
 better, more fluid handling of the oauth experience... but the change has 
 become larger than I had planned   Though removing all of these classes 
 does cut down on complexity a bit and remove 1 redirect from the equation. 
 What do you think?

Dan, the flow seems need a lot of testing and configuration change =(
The problem is that now the total fixes for the oauthpopup changes are spread 
into 3 different change requests (the original change is already released in 
beta4)

Since we are trying to close all the missing implementations and critical bug 
for 2.5.0 release, I have to Vote for -1 for these changes and ask to revert 
all the oauthpopup changes back.
We need to ask Ryan to spin 2.5.0-beta5 immediately since its breaking existing 
release.

Lets proposed all the required changes for this enhancement in one CR with all 
the required changes, and have enough time to test the flow in actual 
implementations.
Otherwise it could become hard to understand code like the ones contributed by 
Googlers to just work

Re: Spin off Apache Shindig 2.5.0-beta5 release with critical fixes

2012-09-20 Thread Henry Saputra

Hmm so looks like the original bug
https://issues.apache.org/jira/browse/SHINDIG-1864 is close with wrong
fix version then?

It has fix version of 2.5.0-beta4

- Henry

On Thu, Sep 20, 2012 at 3:35 PM, Ryan Baxter rbaxte...@gmail.com wrote:
 I am fairly sure Dan's oAuth changes didn't make it in beta 4 but the Caja
 fix probably warrants a new build.

 -Ryan

 On Sep 20, 2012, at 5:34 PM, Paul Lindner lind...@inuus.com wrote:

 sure. happy to.


 On Thursday, September 20, 2012, Henry Saputra wrote:

 Hi Ryan or Paul,

 With Dan's reverting changes to improvement for oauthpopup (this will
 fix OAuth 1.0a flow for three legged dance) and Paul changes to fix
 Caja security vulnerability, could one of you help preparing
 2.5.0-beta5 release?


 Thanks,

 - Henry



 --
 Paul Lindner -- lind...@inuus.com -- profiles.google.com/pmlindner

Re: Spin off Apache Shindig 2.5.0-beta5 release with critical fixes

2012-09-20 Thread Henry Saputra

Ah you are right Ryan, looks like you had cutoff the beta4 before
Dan's commit the changes.

We have custom beta4 that include Dan's refactor that we now revert
to default beta4.

So looks like we only need beta5 for Caja fix then I suppose.

- Henry

On Thu, Sep 20, 2012 at 3:40 PM, Henry Saputra henry.sapu...@gmail.com wrote:
 Hmm so looks like the original bug
 https://issues.apache.org/jira/browse/SHINDIG-1864 is close with wrong
 fix version then?

 It has fix version of 2.5.0-beta4

 - Henry

 On Thu, Sep 20, 2012 at 3:35 PM, Ryan Baxter rbaxte...@gmail.com wrote:
 I am fairly sure Dan's oAuth changes didn't make it in beta 4 but the Caja
 fix probably warrants a new build.

 -Ryan

 On Sep 20, 2012, at 5:34 PM, Paul Lindner lind...@inuus.com wrote:

 sure. happy to.


 On Thursday, September 20, 2012, Henry Saputra wrote:

 Hi Ryan or Paul,

 With Dan's reverting changes to improvement for oauthpopup (this will
 fix OAuth 1.0a flow for three legged dance) and Paul changes to fix
 Caja security vulnerability, could one of you help preparing
 2.5.0-beta5 release?


 Thanks,

 - Henry



 --
 Paul Lindner -- lind...@inuus.com -- profiles.google.com/pmlindner

Re: Review Request: OAuth 1.0a broken with recent oauthpopup changes moving window open to container from gadget

2012-09-20 Thread Henry Saputra



 On Sept. 20, 2012, 4:47 a.m., Henry Saputra wrote:
  Dan, could you tell a bit more details what the issue looks like with 
  3-legged OAuth  1.0a dance? It will help review the change. 
  
  This needs to be fixed ASAP bc the oauthpopup change is part of beta4 
  release and if its broken we need to come up with beta5 quickly.
 
 Dan Dumont wrote:
 Hey, thanks for helping with the review :)
 
 Let me start by describing what I saw before any of these changes or the 
 oauthpopup changes with locked domains in a deployment.
 1. Oauth request made by a gadget on locked.gadget.com through the proxy, 
 no oauth creds... 
 2. The remote server sends back the appropriate response
 3. The proxy ads info to the response like the oauth authorize uri with 
 the authorize callback.  
 
 3's callback is generated by the shindig property 
 shindig.signing.global-callback-url which points to the unlocked server 
 domain.  In the (now deleted) GadgetOAuthCallbackGenerator.java we would take 
 the callback endpoint generated from container.js 
 gadgets.uri.oauth.callbackTemplate and %host% is replaced with the authority 
 of the gadget on the locked domain and add it to a token.
 (I will be updating this patch to delete the 
 gadgets.uri.oauth.callbackTemplate param in the container config, it's not 
 used anymore)
 
 4. Encrypt the locked domain callback endpoint in a token and add it to 
 the callback url in 3 as a query param.
 5. Gadget gets request failure and uses the oauthpopup class to open the 
 authorize url (with callback url?state={encrypted-callback-url-query-param})  
 window.open on locked domain.
 6. Log in on remote service, press authorize, yadda yadda
 7. Redirected back to UNLCOKED domain (the one from shindig.properties).  
 8. The (now deleted) code in the servlet would see you have a token, 
 decrypt it, move all current query params to the decrypted callback and send 
 a redirect.
 9. Back to the same servlet on the LOCKED domain.  Servlet serves up js 
 code that sets window.opener.someoauthproperty for some makerequest oauth 
 completion.
 
 Note here that window.opener is on the gadget's locked domain, so this 
 redirection madness was necessary to make sure that the window.opener would 
 be able to be written to.
 
 
 After my changes to oauthpopup, everything was the same except for
 5. The container page on an unlocked domain sends the window.open to the 
 authorize url (with callback url?state={encrypted-callback-url-query-param})
 So during 9, the js code had access violation accessing a property in 
 window.opener (from locked domain to container domain)
 
 After these changes, we change
 4. do nothing
 5. changed as above
 8. do nothing
 9. Now on the unlocked domain, window.opener would now match domains.
 
 Dan Dumont wrote:
 After talking with Stanton, we're kind of weary of how large this change 
 is getting because we found a slight wrinkle in the redirect in the case 
 where the container isn't on the same domain as the shindig server.
 
 Typically one would have a proxy set up so that rpc stuff would work... 
 so we were thinking we could take the container host in the security token 
 and use that to generate a url to the oauth endpoint via the container's 
 proxy (you would have to edit the shindig.properties value with any proxy you 
 are using on that url).
 
 I could add the comments describing this setup and create 
 warnings/errors/exceptions for values for the container in the security token 
 that cannot be handled so that admins can easily understand the failures and 
 correct them.  And also write all this up in UPGRADING... Or I can just 
 rip all this out now and revert my oauthpopup changes and save this for post 
 2.5.  I had hoped that this would be a simpler change and a stepping stone to 
 better, more fluid handling of the oauth experience... but the change has 
 become larger than I had planned   Though removing all of these classes 
 does cut down on complexity a bit and remove 1 redirect from the equation. 
 What do you think?
 
 Henry Saputra wrote:
 Dan, the flow seems need a lot of testing and configuration change =(
 The problem is that now the total fixes for the oauthpopup changes are 
 spread into 3 different change requests (the original change is already 
 released in beta4)
 
 Since we are trying to close all the missing implementations and critical 
 bug for 2.5.0 release, I have to Vote for -1 for these changes and ask to 
 revert all the oauthpopup changes back.
 We need to ask Ryan to spin 2.5.0-beta5 immediately since its breaking 
 existing release.
 
 Lets proposed all the required changes for this enhancement in one CR 
 with all the required changes, and have enough time to test the flow in 
 actual implementations.
 Otherwise it could become hard to understand

Re: Spin off Apache Shindig 2.5.0-beta5 release with critical fixes

2012-09-20 Thread Henry Saputra

Hi Stanton,

The Caja fix does warrant new release but I think it could wait till
next week if no one actively using Caja with Shindig.

I dont know if any implementors of Shindig that uses Caja needs this
ASAP. I know Yahoo! container does use it.

I am CCing user list for FYI.

Paul, any thoughts?

- Henry

On Thu, Sep 20, 2012 at 4:02 PM, Stanton Sievers ssiev...@apache.org wrote:
 Does that mean it can happen at the regularly scheduled time, i.e., the end
 of the month?  Or do you think we need beta5 ASAP because of the caja fix?

 Thanks,
 -Stanton

 On Thu, Sep 20, 2012 at 6:52 PM, Henry Saputra henry.sapu...@gmail.comwrote:

 Ah you are right Ryan, looks like you had cutoff the beta4 before
 Dan's commit the changes.

 We have custom beta4 that include Dan's refactor that we now revert
 to default beta4.

 So looks like we only need beta5 for Caja fix then I suppose.

 - Henry

 On Thu, Sep 20, 2012 at 3:40 PM, Henry Saputra henry.sapu...@gmail.com
 wrote:
  Hmm so looks like the original bug
  https://issues.apache.org/jira/browse/SHINDIG-1864 is close with wrong
  fix version then?
 
  It has fix version of 2.5.0-beta4
 
  - Henry
 
  On Thu, Sep 20, 2012 at 3:35 PM, Ryan Baxter rbaxte...@gmail.com
 wrote:
  I am fairly sure Dan's oAuth changes didn't make it in beta 4 but the
 Caja
  fix probably warrants a new build.
 
  -Ryan
 
  On Sep 20, 2012, at 5:34 PM, Paul Lindner lind...@inuus.com wrote:
 
  sure. happy to.
 
 
  On Thursday, September 20, 2012, Henry Saputra wrote:
 
  Hi Ryan or Paul,
 
  With Dan's reverting changes to improvement for oauthpopup (this will
  fix OAuth 1.0a flow for three legged dance) and Paul changes to fix
  Caja security vulnerability, could one of you help preparing
  2.5.0-beta5 release?
 
 
  Thanks,
 
  - Henry
 
 
 
  --
  Paul Lindner -- lind...@inuus.com -- profiles.google.com/pmlindner

Re: Spin off Apache Shindig 2.5.0-beta5 release with critical fixes - CANCELLED

2012-09-20 Thread Henry Saputra

Thanks Paul.

So based on Ryan and Paul inputs we will return the 2.5.0-beta5
release to its regular schedule.

I apologize for the trouble and false alarm guys.

- Henry

On Thu, Sep 20, 2012 at 5:14 PM, Paul Lindner lind...@inuus.com wrote:
 Release can wait.  The caja problem was a limited set of revisions.


 On Thursday, September 20, 2012, Henry Saputra wrote:

 Hi Stanton,

 The Caja fix does warrant new release but I think it could wait till
 next week if no one actively using Caja with Shindig.

 I dont know if any implementors of Shindig that uses Caja needs this
 ASAP. I know Yahoo! container does use it.

 I am CCing user list for FYI.

 Paul, any thoughts?

 - Henry

 On Thu, Sep 20, 2012 at 4:02 PM, Stanton Sievers ssiev...@apache.org
 wrote:
  Does that mean it can happen at the regularly scheduled time, i.e., the
  end
  of the month?  Or do you think we need beta5 ASAP because of the caja
  fix?
 
  Thanks,
  -Stanton
 
  On Thu, Sep 20, 2012 at 6:52 PM, Henry Saputra
  henry.sapu...@gmail.comwrote:
 
  Ah you are right Ryan, looks like you had cutoff the beta4 before
  Dan's commit the changes.
 
  We have custom beta4 that include Dan's refactor that we now revert
  to default beta4.
 
  So looks like we only need beta5 for Caja fix then I suppose.
 
  - Henry
 
  On Thu, Sep 20, 2012 at 3:40 PM, Henry Saputra
  henry.sapu...@gmail.com
  wrote:
   Hmm so looks like the original bug
   https://issues.apache.org/jira/browse/SHINDIG-1864 is close with
   wrong
   fix version then?
  
   It has fix version of 2.5.0-beta4
  
   - Henry
  
   On Thu, Sep 20, 2012 at 3:35 PM, Ryan Baxter rbaxte...@gmail.com
  wrote:
   I am fairly sure Dan's oAuth changes didn't make it in beta 4 but
   the
  Caja
   fix probably warrants a new build.
  
   -Ryan
  
   On Sep 20, 2012, at 5:34 PM, Paul Lindner lind...@inuus.com wrote:
  
   sure. happy to.
  
  
   On Thursday, September 20, 2012, Henry Saputra wrote:
  
   Hi Ryan or Paul,
  
   With Dan's reverting changes to improvement for oauthpopup (this
   will
   fix OAuth 1.0a flow for three legged dance) and Paul changes to fix
   Caja security vulnerability, could one of you help preparing
   2.5.0-beta5 release?
  
  
   Thanks,
  
   - Henry
  
  
  
   --
   Paul Lindner -- lind...@inuus.com -- profiles.google.com/pmlindner
 



 --
 Paul Lindner -- lind...@inuus.com -- profiles.google.com/pmlindner

Re: Review Request: Correct moduleId parsing in TokenRequestData

2012-09-19 Thread Henry Saputra



 On Sept. 19, 2012, 1:50 p.m., Dan Dumont wrote:
  Nice catch!
  
  What do others think would be best?   Change this to use the fragment as a 
  blob, or enhance the shindig.uri js class to encode multiple params in the 
  fragment like the java side does?

I would +1 to change it to encode multiple params to the URL fragment to be 
consistent with rendering flow.


- Henry


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/7166/#review11690
---


On Sept. 19, 2012, 1:36 p.m., Matt Jones wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/7166/
 ---
 
 (Updated Sept. 19, 2012, 1:36 p.m.)
 
 
 Review request for shindig.
 
 
 Description
 ---
 
 Change TokenRequestData to use the whole URL fragment rather than a fragment 
 parameter, as this is what is sent to the container.
 
 
 This addresses bug SHINDIG-1873.
 https://issues.apache.org/jira/browse/SHINDIG-1873
 
 
 Diffs
 -
 
   
 tags/shindig-project-2.5.0-beta4/java/gadgets/src/main/java/org/apache/shindig/gadgets/servlet/GadgetsHandler.java
  1387492 
 
 Diff: https://reviews.apache.org/r/7166/diff/
 
 
 Testing
 ---
 
 
 Thanks,
 
 Matt Jones

Re: Review Request: OAuth 1.0a broken with recent oauthpopup changes moving window open to container from gadget

2012-09-19 Thread Henry Saputra


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/7186/#review11730
---


Dan, could you tell a bit more details what the issue looks like with 3-legged 
OAuth  1.0a dance? It will help review the change. 

This needs to be fixed ASAP bc the oauthpopup change is part of beta4 release 
and if its broken we need to come up with beta5 quickly.

- Henry Saputra


On Sept. 20, 2012, 12:02 a.m., Dan Dumont wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/7186/
 ---
 
 (Updated Sept. 20, 2012, 12:02 a.m.)
 
 
 Review request for shindig, Paul Lindner, Henry Saputra, johnfargo, Matt 
 Franklin, and Simon Hewett.
 
 
 Description
 ---
 
 So I found this in our deployments for 1.0a where we have locked domains 
 turned on.  From what I can tell, we would set the callback url to the base 
 one defined in shindig.properties and then encode a security token with the 
 locked domain callback url.  When we got the callback on the unlocked domain, 
 we would redirect to the locked domain in the encoded token.
 
 This appears to have been done because of some window.opener completion code 
 for makerequest which used to be set by the gadget (the gadget used to open 
 the window).  Now the container opens the window and we don't need all this 
 redirection magic.   So I've removed all the classes that had anything to do 
 with that (there were a few, but mostly well contained).
 
 After digging through this code, I now fear for my sanity.  Please, please, 
 PLEASE! code review this carefully.  I am not an oauth expert.
 
 
 Diffs
 -
 
   
 http://svn.apache.org/repos/asf/shindig/trunk/java/gadgets/src/main/java/org/apache/shindig/gadgets/oauth/GadgetOAuthCallbackGenerator.java
  1387677 
   
 http://svn.apache.org/repos/asf/shindig/trunk/java/gadgets/src/main/java/org/apache/shindig/gadgets/oauth/OAuthCallbackGenerator.java
  1387677 
   
 http://svn.apache.org/repos/asf/shindig/trunk/java/gadgets/src/main/java/org/apache/shindig/gadgets/oauth/OAuthCallbackState.java
  1387677 
   
 http://svn.apache.org/repos/asf/shindig/trunk/java/gadgets/src/main/java/org/apache/shindig/gadgets/oauth/OAuthCallbackStateToken.java
  1387677 
   
 http://svn.apache.org/repos/asf/shindig/trunk/java/gadgets/src/main/java/org/apache/shindig/gadgets/oauth/OAuthFetcherConfig.java
  1387677 
   
 http://svn.apache.org/repos/asf/shindig/trunk/java/gadgets/src/main/java/org/apache/shindig/gadgets/oauth/OAuthRequest.java
  1387677 
   
 http://svn.apache.org/repos/asf/shindig/trunk/java/gadgets/src/main/java/org/apache/shindig/gadgets/servlet/OAuthCallbackServlet.java
  1387677 
   
 http://svn.apache.org/repos/asf/shindig/trunk/java/gadgets/src/main/java/org/apache/shindig/gadgets/uri/DefaultOAuthUriManager.java
  1387677 
   
 http://svn.apache.org/repos/asf/shindig/trunk/java/gadgets/src/main/java/org/apache/shindig/gadgets/uri/OAuthUriManager.java
  1387677 
   
 http://svn.apache.org/repos/asf/shindig/trunk/java/gadgets/src/main/java/org/apache/shindig/gadgets/uri/UriModule.java
  1387677 
   
 http://svn.apache.org/repos/asf/shindig/trunk/java/gadgets/src/test/java/org/apache/shindig/gadgets/oauth/GadgetOAuthCallbackGeneratorTest.java
  1387677 
   
 http://svn.apache.org/repos/asf/shindig/trunk/java/gadgets/src/test/java/org/apache/shindig/gadgets/oauth/GadgetTokenStoreTest.java
  1387677 
   
 http://svn.apache.org/repos/asf/shindig/trunk/java/gadgets/src/test/java/org/apache/shindig/gadgets/oauth/OAuthFetcherConfigTest.java
  1387677 
   
 http://svn.apache.org/repos/asf/shindig/trunk/java/gadgets/src/test/java/org/apache/shindig/gadgets/oauth/OAuthRequestTest.java
  1387677 
   
 http://svn.apache.org/repos/asf/shindig/trunk/java/gadgets/src/test/java/org/apache/shindig/gadgets/servlet/OAuthCallbackServletTest.java
  1387677 
   
 http://svn.apache.org/repos/asf/shindig/trunk/java/gadgets/src/test/java/org/apache/shindig/gadgets/uri/DefaultOAuthUriManagerTest.java
  1387677 
 
 Diff: https://reviews.apache.org/r/7186/diff/
 
 
 Testing
 ---
 
 Updated tests.
 Removed obsolete tests.
 
 
 Thanks,
 
 Dan Dumont

Re: Caja 0day vulnerability

2012-09-18 Thread Henry Saputra

Thanks Paul

- Henry

On Tue, Sep 18, 2012 at 9:52 AM, Paul Lindner lind...@inuus.com wrote:
 http://www.thespanner.co.uk/2012/09/18/hacking-caja-part-2/

 New caja jar is being prepared, I'll have a patch to integrate it shortly.




 --
 Paul Lindner -- lind...@inuus.com -- profiles.google.com/pmlindner

Re: Review Request: Update to latest caja to deal with vulnerability

2012-09-18 Thread Henry Saputra


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/7149/#review11679
---


Need to update the UPGRADING to track the Java Dependency Changes

- Henry Saputra


On Sept. 18, 2012, 11:02 p.m., Paul Lindner wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/7149/
 ---
 
 (Updated Sept. 18, 2012, 11:02 p.m.)
 
 
 Review request for shindig and Jasvir Nagra.
 
 
 Description
 ---
 
 Update to latest caja to deal with vulnerability
 
 
 Diffs
 -
 
   
 /trunk/java/gadgets/src/main/java/org/apache/shindig/gadgets/servlet/CajaContentRewriter.java
  1387331 
   
 /trunk/java/gadgets/src/test/java/org/apache/shindig/gadgets/parse/caja/VanillaCajaHtmlParserTest.java
  1387331 
   
 /trunk/java/gadgets/src/test/java/org/apache/shindig/gadgets/servlet/CajaContentRewriterTest.java
  1387331 
   /trunk/pom.xml 1387331 
 
 Diff: https://reviews.apache.org/r/7149/diff/
 
 
 Testing
 ---
 
 compiles, tests pass.
 
 
 Thanks,
 
 Paul Lindner

Re: Review Request: Disabled thread in the closure compiler code and add thread management in the Shindig ClosureJSCompiler class

2012-09-17 Thread Henry Saputra

On Sept. 15, 2012, 2:52 p.m., Stanton Sievers wrote:
trunk/java/gadgets/src/main/java16/org/apache/shindig/gadgets/rewrite/js/ClosureJsCompiler.java,
line 263
https://reviews.apache.org/r/7122/diff/1/?file=155595#file155595line263

The javadoc for this method states Disable threads. This is for
clients that run on AppEngine and don't have threads. That concerns me,
as this is certainly not the case we're in. Is the javadoc incomplete?

Henry Saputra wrote:
Its kinda misleading bc internally the closure JS compiler doe not use
thread pool. So when compiling large number of JS resources it could spawn a
lot of threads.

I am planning to contribute code to add thread pool support to the code
but for now we could just disable closure compiler thread and let it run in
the thread than Shindig code created to run the compilation from the thread
pool.

Dan Dumont wrote:
The closure threads would be blocked from growing beyond the size of the
shindig thread pool though, right? We only ever compile one file with any
given compiler instance.

In any case, I think this is a good change. No need to spawn more
threads.

Dan, that's correct. After Dan's fix before it would only grow up to the size
of Shindig thread pool but it creates additional child thread per thread worker
created by Shindig which is not efficient.

- Henry

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/7122/#review11577
---

On Sept. 15, 2012, 4:58 p.m., Henry Saputra wrote:

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/7122/
---

(Updated Sept. 15, 2012, 4:58 p.m.)

Review request for shindig, Ryan Baxter, Dan Dumont, and Stanton Sievers.

Description
---

Disable thread in the closure compiler code since Shindig manage the thread
in the ClosureJSCompiler class via ExecuterService framework.
Otherwise internally the closure compiler create another thread then execute
the compile in that new thread instead

But we need to create the thread big enough stack to handle the compilation.
Copy the max stack size from the closure compiler code.

Diffs
-

trunk/java/gadgets/src/main/java16/org/apache/shindig/gadgets/rewrite/js/ClosureJsCompiler.java
1384587

Diff: https://reviews.apache.org/r/7122/diff/

Testing
---

Run smoke test with common container with debug sets to false to run the
closure js compiler.

Thanks,

Henry Saputra

Re: Review Request: Disabled thread in the closure compiler code and add thread management in the Shindig ClosureJSCompiler class

2012-09-17 Thread Henry Saputra


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/7122/
---

(Updated Sept. 17, 2012, 5:32 p.m.)


Review request for shindig, Ryan Baxter, Dan Dumont, and Stanton Sievers.


Changes
---

Address Stanton review to make the stack size configurable


Description
---

Disable thread in the closure compiler code since Shindig manage the thread in 
the ClosureJSCompiler class via ExecuterService framework.
Otherwise internally the closure compiler create another thread then execute 
the compile in that new thread instead

But we need to create the thread big enough stack to handle the compilation. 
Copy the max stack size from the closure compiler code.


Diffs (updated)
-

  
trunk/java/gadgets/src/main/java16/org/apache/shindig/gadgets/rewrite/js/ClosureJsCompiler.java
 1384587 

Diff: https://reviews.apache.org/r/7122/diff/


Testing
---

Run smoke test with common container with debug sets to false to run the 
closure js compiler.


Thanks,

Henry Saputra

Re: Review Request: AllJsIFrameVersioner causes large memory allocation

2012-09-17 Thread Henry Saputra


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/7074/#review11618
---

Ship it!


+1

- Henry Saputra


On Sept. 15, 2012, 11:02 p.m., Marshall Shi wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/7074/
 ---
 
 (Updated Sept. 15, 2012, 11:02 p.m.)
 
 
 Review request for shindig, Ryan Baxter, Dan Dumont, Stanton Sievers, and 
 Rich Thompson.
 
 
 Description
 ---
 
 The AllJsIframeVersioner causes a massive memory allocation executing the 
 following:
 
 StringBuilder jsBuf = new StringBuilder();
 for (FeatureResource resource : registry.getAllFeatures().getResources()) {
  jsBuf.append(resource.getContent()).append(resource.getDebugContent());
  }
  this.allJsChecksum = HashUtil.checksum(jsBuf.toString().getBytes());
  
 The two problems with this are:
 (1) Creates a massive char[] for that string (we tested with a 4M resource)
 (2) Then allocates a new byte[] for that giant string
 
 Proposed solution is to just use a simple message digest object against each 
 resource content. And concat all the bytes for HashUtil.checksum.
 
 
 This addresses bug SHINDIG-1867.
 https://issues.apache.org/jira/browse/SHINDIG-1867
 
 
 Diffs
 -
 
   
 http://svn.apache.org/repos/asf/shindig/trunk/java/gadgets/src/main/java/org/apache/shindig/gadgets/uri/AllJsIframeVersioner.java
  1384320 
   
 http://svn.apache.org/repos/asf/shindig/trunk/java/gadgets/src/test/java/org/apache/shindig/gadgets/uri/AllJsIframeVersionerTest.java
  1384320 
 
 Diff: https://reviews.apache.org/r/7074/diff/
 
 
 Testing
 ---
 
 Done.
 
 
 Thanks,
 
 Marshall Shi

Re: Review Request: Disable thread in the closure compiler code and add thread management in the Shindig ClosureJSCompiler class

2012-09-17 Thread Henry Saputra


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/7122/
---

(Updated Sept. 17, 2012, 11:13 p.m.)


Review request for shindig, Ryan Baxter, Dan Dumont, and Stanton Sievers.


Summary (updated)
-

Disable thread in the closure compiler code and add thread management in the 
Shindig ClosureJSCompiler class


Description
---

Disable thread in the closure compiler code since Shindig manage the thread in 
the ClosureJSCompiler class via ExecuterService framework.
Otherwise internally the closure compiler create another thread then execute 
the compile in that new thread instead

But we need to create the thread big enough stack to handle the compilation. 
Copy the max stack size from the closure compiler code.


Diffs
-

  
trunk/java/gadgets/src/main/java16/org/apache/shindig/gadgets/rewrite/js/ClosureJsCompiler.java
 1384587 

Diff: https://reviews.apache.org/r/7122/diff/


Testing
---

Run smoke test with common container with debug sets to false to run the 
closure js compiler.


Thanks,

Henry Saputra

Re: Review Request: AllJsIFrameVersioner causes large memory allocation

2012-09-17 Thread Henry Saputra



 On Sept. 18, 2012, 12:37 a.m., Ryan Baxter wrote:
  Committed revision 1386936
 
 Ryan Baxter wrote:
 I had to revert this change because String.getBytes(Charset) is only in 
 Java 1.6 so the Java 1.5 build fails.  We need to support Java 1.5 for 
 Shindig 2.5.0.

Uff good catch =(

I think we need to remove 1.5 Java support after 2.5.0 release =(


- Henry


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/7074/#review11640
---


On Sept. 15, 2012, 11:02 p.m., Marshall Shi wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/7074/
 ---
 
 (Updated Sept. 15, 2012, 11:02 p.m.)
 
 
 Review request for shindig, Ryan Baxter, Dan Dumont, Stanton Sievers, and 
 Rich Thompson.
 
 
 Description
 ---
 
 The AllJsIframeVersioner causes a massive memory allocation executing the 
 following:
 
 StringBuilder jsBuf = new StringBuilder();
 for (FeatureResource resource : registry.getAllFeatures().getResources()) {
  jsBuf.append(resource.getContent()).append(resource.getDebugContent());
  }
  this.allJsChecksum = HashUtil.checksum(jsBuf.toString().getBytes());
  
 The two problems with this are:
 (1) Creates a massive char[] for that string (we tested with a 4M resource)
 (2) Then allocates a new byte[] for that giant string
 
 Proposed solution is to just use a simple message digest object against each 
 resource content. And concat all the bytes for HashUtil.checksum.
 
 
 This addresses bug SHINDIG-1867.
 https://issues.apache.org/jira/browse/SHINDIG-1867
 
 
 Diffs
 -
 
   
 http://svn.apache.org/repos/asf/shindig/trunk/java/gadgets/src/main/java/org/apache/shindig/gadgets/uri/AllJsIframeVersioner.java
  1384320 
   
 http://svn.apache.org/repos/asf/shindig/trunk/java/gadgets/src/test/java/org/apache/shindig/gadgets/uri/AllJsIframeVersionerTest.java
  1384320 
 
 Diff: https://reviews.apache.org/r/7074/diff/
 
 
 Testing
 ---
 
 Done.
 
 
 Thanks,
 
 Marshall Shi

Re: Review Request: Disabled thread in the closure compiler code and add thread management in the Shindig ClosureJSCompiler class

2012-09-15 Thread Henry Saputra

On Sept. 15, 2012, 2:52 p.m., Stanton Sievers wrote:
trunk/java/gadgets/src/main/java16/org/apache/shindig/gadgets/rewrite/js/ClosureJsCompiler.java,
line 66
https://reviews.apache.org/r/7122/diff/1/?file=155595#file155595line66

Is this what came from the closure code? Can you add some javadoc to
make that clear.

Maybe also make this protected or have a protected getter so people
implementing their own JsCompiler can control the stack size more easily.

This is what come from closure code. I am actually will just move this to
shindig.properties to make it easier to configure.

Its kinda misleading bc internally the closure JS compiler doe not use thread
pool. So when compiling large number of JS resources it could spawn a lot of
threads.

I am planning to contribute code to add thread pool support to the code but for
now we could just disable closure compiler thread and let it run in the thread
than Shindig code created to run the compilation from the thread pool.

- Henry

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/7122/#review11577
---

On Sept. 14, 2012, 11:33 p.m., Henry Saputra wrote:

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/7122/
---

(Updated Sept. 14, 2012, 11:33 p.m.)

Review request for shindig, Ryan Baxter and Dan Dumont.

Description
---

But we need to create the thread big enough stack to handle the compilation.
Copy the max stack size from the closure compiler code.

Diffs
-

trunk/java/gadgets/src/main/java16/org/apache/shindig/gadgets/rewrite/js/ClosureJsCompiler.java
1384587

Diff: https://reviews.apache.org/r/7122/diff/

Testing
---

Run smoke test with common container with debug sets to false to run the
closure js compiler.

Thanks,

Henry Saputra

Re: Review Request: Disabled thread in the closure compiler code and add thread management in the Shindig ClosureJSCompiler class

2012-09-15 Thread Henry Saputra


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/7122/
---

(Updated Sept. 15, 2012, 4:58 p.m.)


Review request for shindig, Ryan Baxter, Dan Dumont, and Stanton Sievers.


Changes
---

adding Stanton as reviewer


Description
---

Disable thread in the closure compiler code since Shindig manage the thread in 
the ClosureJSCompiler class via ExecuterService framework.
Otherwise internally the closure compiler create another thread then execute 
the compile in that new thread instead

But we need to create the thread big enough stack to handle the compilation. 
Copy the max stack size from the closure compiler code.


Diffs
-

  
trunk/java/gadgets/src/main/java16/org/apache/shindig/gadgets/rewrite/js/ClosureJsCompiler.java
 1384587 

Diff: https://reviews.apache.org/r/7122/diff/


Testing
---

Run smoke test with common container with debug sets to false to run the 
closure js compiler.


Thanks,

Henry Saputra

Review Request: Disabled thread in the closure compiler code and add thread management in the Shindig ClosureJSCompiler class

2012-09-14 Thread Henry Saputra


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/7122/
---

Review request for shindig and Dan Dumont.


Description
---

Disable thread in the closure compiler code since Shindig manage the thread in 
the ClosureJSCompiler class via ExecuterService framework.
Otherwise internally the closure compiler create another thread then execute 
the compile in that new thread instead

But we need to create the thread big enough stack to handle the compilation. 
Copy the max stack size from the closure compiler code.


Diffs
-

  
trunk/java/gadgets/src/main/java16/org/apache/shindig/gadgets/rewrite/js/ClosureJsCompiler.java
 1384587 

Diff: https://reviews.apache.org/r/7122/diff/


Testing
---

Run smoke test with common container with debug sets to false to run the 
closure js compiler.


Thanks,

Henry Saputra

Re: Review Request: Disabled thread in the closure compiler code and add thread management in the Shindig ClosureJSCompiler class

2012-09-14 Thread Henry Saputra


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/7122/
---

(Updated Sept. 14, 2012, 11:33 p.m.)


Review request for shindig, Ryan Baxter and Dan Dumont.


Description
---

Disable thread in the closure compiler code since Shindig manage the thread in 
the ClosureJSCompiler class via ExecuterService framework.
Otherwise internally the closure compiler create another thread then execute 
the compile in that new thread instead

But we need to create the thread big enough stack to handle the compilation. 
Copy the max stack size from the closure compiler code.


Diffs
-

  
trunk/java/gadgets/src/main/java16/org/apache/shindig/gadgets/rewrite/js/ClosureJsCompiler.java
 1384587 

Diff: https://reviews.apache.org/r/7122/diff/


Testing
---

Run smoke test with common container with debug sets to false to run the 
closure js compiler.


Thanks,

Henry Saputra

Re: Review Request: gadget iframe accessibility fixes

2012-09-11 Thread Henry Saputra


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/6561/#review11331
---


I thought these attributes only used for XHTML? I believe Shindig spits out 
HTML DOCTYPE right?

- Henry Saputra


On Sept. 11, 2012, 1:44 a.m., Marshall Shi wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/6561/
 ---
 
 (Updated Sept. 11, 2012, 1:44 a.m.)
 
 
 Review request for shindig, Ryan Baxter, Dan Dumont, Stanton Sievers, and 
 Rich Thompson.
 
 
 Description
 ---
 
 The gadget iframe should follow certain format to pass the accessibility 
 test, rough format is:
 iframe title=[gadget_title] 
 html lang=[lang] xml:lang=[lang]
 body/body
 /html
 /iframe 
 
 
 This addresses bug shindig-1835.
 https://issues.apache.org/jira/browse/shindig-1835
 
 
 Diffs
 -
 
   
 http://svn.apache.org/repos/asf/shindig/trunk/features/src/main/javascript/features/container.site.gadget/gadget_holder.js
  1374903 
   
 http://svn.apache.org/repos/asf/shindig/trunk/features/src/main/javascript/features/container.site.gadget/gadget_site.js
  1373213 
   
 http://svn.apache.org/repos/asf/shindig/trunk/features/src/main/javascript/features/container.site.url/url_holder.js
  1373213 
   
 http://svn.apache.org/repos/asf/shindig/trunk/features/src/main/javascript/features/container.site/site.js
  1373213 
   
 http://svn.apache.org/repos/asf/shindig/trunk/features/src/main/javascript/features/container.site/site_holder.js
  1373213 
   
 http://svn.apache.org/repos/asf/shindig/trunk/features/src/test/javascript/features/container.url/url_holder_test.js
  1373213 
   
 http://svn.apache.org/repos/asf/shindig/trunk/features/src/test/javascript/features/container.url/url_site_test.js
  1373213 
   
 http://svn.apache.org/repos/asf/shindig/trunk/java/gadgets/src/main/java/org/apache/shindig/gadgets/render/RenderingGadgetRewriter.java
  1382185 
   
 http://svn.apache.org/repos/asf/shindig/trunk/java/gadgets/src/test/java/org/apache/shindig/gadgets/render/RenderingGadgetRewriterTest.java
  1373213 
 
 Diff: https://reviews.apache.org/r/6561/diff/
 
 
 Testing
 ---
 
 Done.
 
 
 Thanks,
 
 Marshall Shi

Re: Build failed in Jenkins: Shindig Trunk (JDK 1.6) #43

2012-09-11 Thread Henry Saputra

Maven RAT plugin for header check for the win =)

- Henry

On Tue, Sep 11, 2012 at 5:29 AM, Ryan Baxter rbaxte...@gmail.com wrote:
 Dan could you fix the missing license header in
 features/src/test/javascript/features/container/mixin_test.js?
 Thanks.

 -- Forwarded message --
 From: Apache Jenkins Server jenk...@builds.apache.org
 Date: Mon, Sep 10, 2012 at 10:43 PM
 Subject: Build failed in Jenkins: Shindig Trunk (JDK 1.6) #43
 To: comm...@shindig.apache.org


 See https://builds.apache.org/job/Shindig%20Trunk%20(JDK%201.6)/43/changes

 Changes:

 [hsaputra] Make helper function in DefaultGadgetSpecFactory class to be
 public for easier override.

 --
 Started by an SCM change
 Building remotely on ubuntu4 in workspace 
 https://builds.apache.org/job/Shindig%20Trunk%20(JDK%201.6)/ws/
 Updating http://svn.apache.org/repos/asf/shindig/trunk
 U
 java/gadgets/src/main/java/org/apache/shindig/gadgets/DefaultGadgetSpecFactory.java
 Fetching 'https://svn.apache.org/repos/asf/shindig/site/trunk' at -1 into '
 https://builds.apache.org/job/Shindig%20Trunk%20(JDK%201.6)/ws/site'
 At revision 1383228
 At revision 1383228
 no change for https://svn.apache.org/repos/asf/shindig/site/trunk since the
 previous build
 Parsing POMs
 [Shindig Trunk (JDK 1.6)] $ /home/hudson/tools/java/latest1.6/bin/java -cp
 /home/jenkins/jenkins-slave/maven3-agent.jar:/home/hudson/tools/maven/latest/boot/plexus-classworlds-2.4.jar
 org.jvnet.hudson.maven3.agent.Maven3Main /home/hudson/tools/maven/latest
 /home/jenkins/jenkins-slave/slave.jar
 /home/jenkins/jenkins-slave/maven3-interceptor.jar 35797
 ===[JENKINS REMOTING CAPACITY]===channel started
log4j:WARN No appenders could be found for logger
 (org.apache.commons.beanutils.converters.BooleanConverter).
 log4j:WARN Please initialize the log4j system properly.
 Executing Maven:  -B -f 
 https://builds.apache.org/job/Shindig%20Trunk%20(JDK%201.6)/ws/pom.xml
 -Dmaven.repo.local=/home/jenkins/jenkins-slave/maven-repositories/0
 -Pall,samples,reporting clean install cobertura:cobertura
 [INFO] Scanning for projects...
 [INFO]
 
 [INFO] Reactor Build Order:
 [INFO]
 [INFO] Apache Shindig Project
 [INFO] Apache Shindig Features
 [INFO] Apache Shindig Common Code
 [INFO] Apache Shindig Gadget Renderer
 [INFO] Apache Shindig Social API
 [INFO] Apache Shindig Sample Container
 [INFO] Apache Shindig Web App Resources
 [INFO] Apache Shindig Extra Modules
 [INFO] Apache Shindig Web App Dependencies
 [INFO] Apache Shindig Web App
 [INFO] Apache Shindig Sample SPI and API Implementations
 Projects to build: [MavenProject:
 org.apache.shindig:shindig-project:2.5.0-SNAPSHOT @ 
 https://builds.apache.org/job/Shindig%20Trunk%20(JDK%201.6)/ws/pom.xml,
 MavenProject: org.apache.shindig:shindig-features:2.5.0-SNAPSHOT @ 
 https://builds.apache.org/job/Shindig%20Trunk%20(JDK%201.6)/ws/features/pom.xml,
 MavenProject: org.apache.shindig:shindig-common:2.5.0-SNAPSHOT @ 
 https://builds.apache.org/job/Shindig%20Trunk%20(JDK%201.6)/ws/java/common/pom.xml,
 MavenProject: org.apache.shindig:shindig-gadgets:2.5.0-SNAPSHOT @ 
 https://builds.apache.org/job/Shindig%20Trunk%20(JDK%201.6)/ws/java/gadgets/pom.xml,
 MavenProject: org.apache.shindig:shindig-social-api:2.5.0-SNAPSHOT @ 
 https://builds.apache.org/job/Shindig%20Trunk%20(JDK%201.6)/ws/java/social-api/pom.xml,
 MavenProject: org.apache.shindig:shindig-sample-container:2.5.0-SNAPSHOT @ 
 https://builds.apache.org/job/Shindig%20Trunk%20(JDK%201.6)/ws/java/sample-container/pom.xml,
 MavenProject: org.apache.shindig:shindig-server-resources:2.5.0-SNAPSHOT @ 
 https://builds.apache.org/job/Shindig%20Trunk%20(JDK%201.6)/ws/java/server-resources/pom.xml,
 MavenProject: org.apache.shindig:shindig-extras:2.5.0-SNAPSHOT @ 
 https://builds.apache.org/job/Shindig%20Trunk%20(JDK%201.6)/ws/extras/pom.xml,
 MavenProject: org.apache.shindig:shindig-server-dependencies:2.5.0-SNAPSHOT
 @ 
 https://builds.apache.org/job/Shindig%20Trunk%20(JDK%201.6)/ws/java/server-dependencies/pom.xml,
 MavenProject: org.apache.shindig:shindig-server:2.5.0-SNAPSHOT @ 
 https://builds.apache.org/job/Shindig%20Trunk%20(JDK%201.6)/ws/java/server/pom.xml,
 MavenProject: org.apache.shindig:shindig-samples:2.5.0-SNAPSHOT @ 
 https://builds.apache.org/job/Shindig%20Trunk%20(JDK%201.6)/ws/java/samples/pom.xml
 ]
 projectStarted org.apache.shindig:shindig-project:2.5.0-SNAPSHOT
 [INFO]
 [INFO]
 
 [INFO] Building Apache Shindig Project 2.5.0-SNAPSHOT
 [INFO]
 
 mojoStarted org.apache.maven.plugins:maven-clean-plugin:2.4.1(default-clean)
 [INFO]
 [INFO] --- maven-clean-plugin:2.4.1:clean (default-clean) @ shindig-project
 ---
 [INFO] Deleting 
 https://builds.apache.org/job/Shindig%20Trunk%20(JDK%201.6)/ws/target
 mojoSucceeded

Re: Review Request: IE8 file download failed when retrieving content through proxy

2012-09-11 Thread Henry Saputra

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/6201/#review11344
---

Ship it!

- Henry Saputra

On Sept. 11, 2012, 2:55 a.m., Marshall Shi wrote:

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/6201/
---

(Updated Sept. 11, 2012, 2:55 a.m.)

Review request for shindig, Ryan Baxter, Dan Dumont, Stanton Sievers, and
Rich Thompson.

Description
---

Http response header has been modified when the refresh is set to -1.
However, in IE8, it needs the original response header been passed through
proxy.
Shindig is using cache-control: no-cache and Progma: no-cache header if TTL
is less than or equals to zero. It is not working for IE. IE would expect the
Cache-Control: no-store and progama: which are returned from original
content server response. The current shindig code already rewrite the header
a bit in this case, so the proposed fix is to leverage the original header
for cache control and progma.

This addresses bug shindig-1831.
https://issues.apache.org/jira/browse/shindig-1831

Diffs
-

http://svn.apache.org/repos/asf/shindig/trunk/java/common/src/main/java/org/apache/shindig/common/servlet/HttpUtil.java
1373213

http://svn.apache.org/repos/asf/shindig/trunk/java/gadgets/src/main/java/org/apache/shindig/gadgets/servlet/ServletUtil.java
1373213

Diff: https://reviews.apache.org/r/6201/diff/

Testing
---

Thanks,

Marshall Shi

Re: Review Request: Features in shindig do not check to make sure that the container has called their RPC endpoint

2012-09-10 Thread Henry Saputra


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/6945/#review11257
---

Ship it!


+1

- Henry Saputra


On Sept. 10, 2012, 5:48 p.m., Robert O'Neill wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/6945/
 ---
 
 (Updated Sept. 10, 2012, 5:48 p.m.)
 
 
 Review request for shindig, Ryan Baxter, Dan Dumont, and Stanton Sievers.
 
 
 Description
 ---
 
 Every rpc register within a gadget should check the `from` and make sure that 
 it's correct to process the call.
 
 
 Diffs
 -
 
   trunk/features/src/main/javascript/features/actions/actions.js 1378988 
   trunk/features/src/main/javascript/features/auth-refresh/auth-refresh.js 
 1378988 
   
 trunk/features/src/main/javascript/features/embeddedexperiences/embedded_experiences_gadgets.js
  1378988 
   
 trunk/features/src/main/javascript/features/open-views.results/open-views-results-gadget.js
  1378988 
   
 trunk/features/src/main/javascript/features/opensocial-jsonrpc/jsonrpccontainer.js
  1378988 
   trunk/features/src/main/javascript/features/pubsub/pubsub.js 1378988 
   trunk/features/src/main/javascript/features/selection/selection.js 1378988 
 
 Diff: https://reviews.apache.org/r/6945/diff/
 
 
 Testing
 ---
 
 
 Thanks,
 
 Robert O'Neill

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

2012-09-09 Thread Henry Saputra

You might want to close the vote thread first :)

On Sunday, September 9, 2012, Ryan Baxter rbaxte...@gmail.com wrote:
 +1 from me as well I will start publishing the release.

 On Sun, Sep 9, 2012 at 4:42 PM, Ryan Baxter rbaxte...@gmail.com wrote:

 Thanks guys!

 This query should be better:


https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=truejqlQuery=project+%3D+SHINDIG+AND+resolution+%3D+Fixed+AND+status+in+%28Resolved%2C+Closed%29+AND+resolved+%3E%3D+2012-07-31+AND+resolved+%3C%3D+2012-08-30


 On Sat, Sep 8, 2012 at 9:53 AM, Stanton Sievers siever...@gmail.com
wrote:

 +1 from me.

 Ryan, it looks like your query is picking up 3 JIRAs that were fixed
 post-beta4.  1859, 1861, 1865.

 On Fri, Sep 7, 2012 at 6:32 PM, Henry Saputra henry.sapu...@gmail.com
 wrote:

  +1 for common, gadget, features, social-api artifacts
  +1 for signatures of the execution binaries (I didnt check the doc and
  sources)
 
  So +1 from me.
 
  - Henry
 
  On Thu, Aug 30, 2012 at 5:33 AM, Ryan Baxter rbaxte...@apache.org
 wrote:
   Hi, it is that time of the month again, time for a release.
  
   We solved 9 issues:
  
 

https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=truejqlQuery=project+%3D+SHINDIG+AND+resolution+%3D+Fixed+AND+status+in+%28Resolved%2C+Closed%29+AND+resolved+%3E%3D+2012-07-31
  
  
   Staging repo:
  
 https://repository.apache.org/content/repositories/orgapacheshindig-023/
  
  
   Vote open for 72 hours.
  
   [ ] +1
   [ ] +0
   [ ] -1

Re: [RESULT] [VOTE] Release Apache Shindig version 2.5.0-beta4

2012-09-09 Thread Henry Saputra

Cool, awesome work Ryan.

Thank you so much.


- Henry

On Sun, Sep 9, 2012 at 3:15 PM, Ryan Baxter rbaxte...@gmail.com wrote:
 The release has been published to the Maven Central repo [1] and to the
 Apache Distribution repo [2].  There is a new tag for 2.5.0-beta5 in JIRA.
  I will send out a release email tomorrow so everything have a chance to
 sync across all the mirrors.

 [1]
 https://repository.apache.org/content/repositories/releases/org/apache/shindig/
 [2] https://dist.apache.org/repos/dist/release/shindig/2.5.0-beta4/

 -Ryan

 On Sun, Sep 9, 2012 at 5:09 PM, Ryan Baxter rbaxte...@gmail.com wrote:

 +1 from me as well I will start publishing the release.


 On Sun, Sep 9, 2012 at 4:42 PM, Ryan Baxter rbaxte...@gmail.com wrote:

 Thanks guys!

 This query should be better:

 https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=truejqlQuery=project+%3D+SHINDIG+AND+resolution+%3D+Fixed+AND+status+in+%28Resolved%2C+Closed%29+AND+resolved+%3E%3D+2012-07-31+AND+resolved+%3C%3D+2012-08-30


 On Sat, Sep 8, 2012 at 9:53 AM, Stanton Sievers siever...@gmail.comwrote:

 +1 from me.

 Ryan, it looks like your query is picking up 3 JIRAs that were fixed
 post-beta4.  1859, 1861, 1865.

 On Fri, Sep 7, 2012 at 6:32 PM, Henry Saputra henry.sapu...@gmail.com
 wrote:

  +1 for common, gadget, features, social-api artifacts
  +1 for signatures of the execution binaries (I didnt check the doc and
  sources)
 
  So +1 from me.
 
  - Henry
 
  On Thu, Aug 30, 2012 at 5:33 AM, Ryan Baxter rbaxte...@apache.org
 wrote:
   Hi, it is that time of the month again, time for a release.
  
   We solved 9 issues:
  
 
 https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=truejqlQuery=project+%3D+SHINDIG+AND+resolution+%3D+Fixed+AND+status+in+%28Resolved%2C+Closed%29+AND+resolved+%3E%3D+2012-07-31
  
  
   Staging repo:
  
 https://repository.apache.org/content/repositories/orgapacheshindig-023/
  
  
   Vote open for 72 hours.
  
   [ ] +1
   [ ] +0
   [ ] -1

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

2012-09-07 Thread Henry Saputra

+1 for common, gadget, features, social-api artifacts
+1 for signatures of the execution binaries (I didnt check the doc and sources)

So +1 from me.

- Henry

On Thu, Aug 30, 2012 at 5:33 AM, Ryan Baxter rbaxte...@apache.org wrote:
 Hi, it is that time of the month again, time for a release.

 We solved 9 issues:
 https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=truejqlQuery=project+%3D+SHINDIG+AND+resolution+%3D+Fixed+AND+status+in+%28Resolved%2C+Closed%29+AND+resolved+%3E%3D+2012-07-31


 Staging repo:
 https://repository.apache.org/content/repositories/orgapacheshindig-023/


 Vote open for 72 hours.

 [ ] +1
 [ ] +0
 [ ] -1

1 2 3 4 5 6 >

1 - 100 of 569 matches

Mail list logo