From matzew at apache.org Tue Jul 1 02:42:09 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Tue, 1 Jul 2014 08:42:09 +0200 Subject: [aerogear-dev] UPS 0.11 In-Reply-To: <20140630161444.GA14602@abstractj.org> References: <20140630161444.GA14602@abstractj.org> Message-ID: On Mon, Jun 30, 2014 at 6:14 PM, Bruno Oliveira wrote: > Hi Matthias, I think we're in a good shape. We have 3 PR to be reviewed: > > - https://github.com/aerogear/aerogear-unifiedpush-server/pull/154 > I would vote to postpone it for further releases > I just added a label (1.0.1) on that PR. since an external contributor sent it, I'd like to keep it open > > - https://github.com/aerogear/aerogear-unifiedpush-server/pull/250 > It seems like ready to go > > - https://github.com/aerogear/aerogear-unifiedpush-server/pull/253 > Need some feedback > > Regarding the Keycloak integration, I reasssigned AGPUSH-568 to myself, > but let me know if you want to be in charge of it. > no, perfect that way ! > > On 2014-06-30, Matthias Wessendorf wrote: > > Hello, > > > > while waiting for my flight back home I was looking over the open PRs and > > added a few comments: > > * https://github.com/aerogear/aerogear-unifiedpush-server/pull/250 > > * https://github.com/aerogear/aerogear-unifiedpush-server/pull/249 > > * https://github.com/aerogear/aerogear-unifiedpush-server/pull/244 > > * https://github.com/aerogear/aerogear-unifiedpush-server/pull/243 > > > > > > Besides those, there are three open tickets, which I'd like to see fixed > > for the 0.11: > > > https://issues.jboss.org/browse/AGPUSH/fixforversion/12321883/?selectedTab=com.atlassian.jira.jira-projects-plugin:version-issues-panel > > > > Any thoughts? > > -Matthias > > > > > > > > > > -- > > Matthias Wessendorf > > > > blog: http://matthiaswessendorf.wordpress.com/ > > sessions: http://www.slideshare.net/mwessendorf > > twitter: http://twitter.com/mwessendorf > > > > > > -- > > Sent from Gmail Mobile > > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > -- > > abstractj > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140701/6122c07f/attachment.html From matzew at apache.org Tue Jul 1 02:42:46 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Tue, 1 Jul 2014 08:42:46 +0200 Subject: [aerogear-dev] UPS 0.11 In-Reply-To: References: <20140630161444.GA14602@abstractj.org> Message-ID: Sebi, On Tue, Jul 1, 2014 at 1:20 AM, Sebastien Blanc wrote: > > > > On Mon, Jun 30, 2014 at 6:14 PM, Bruno Oliveira > wrote: > >> Hi Matthias, I think we're in a good shape. We have 3 PR to be reviewed: >> >> - https://github.com/aerogear/aerogear-unifiedpush-server/pull/154 >> I would vote to postpone it for further releases >> > +1 > >> >> - https://github.com/aerogear/aerogear-unifiedpush-server/pull/250 >> It seems like ready to go >> > +1 (just a small ui thing that could be better but we can see that later) > can you send a PR for that change ? > >> - https://github.com/aerogear/aerogear-unifiedpush-server/pull/253 >> Need some feedback >> > feedback given > >> >> Regarding the Keycloak integration, I reasssigned AGPUSH-568 to myself, >> but let me know if you want to be in charge of it. >> >> On 2014-06-30, Matthias Wessendorf wrote: >> > Hello, >> > >> > while waiting for my flight back home I was looking over the open PRs >> and >> > added a few comments: >> > * https://github.com/aerogear/aerogear-unifiedpush-server/pull/250 >> > * https://github.com/aerogear/aerogear-unifiedpush-server/pull/249 >> > * https://github.com/aerogear/aerogear-unifiedpush-server/pull/244 >> > * https://github.com/aerogear/aerogear-unifiedpush-server/pull/243 >> > >> > >> > Besides those, there are three open tickets, which I'd like to see fixed >> > for the 0.11: >> > >> https://issues.jboss.org/browse/AGPUSH/fixforversion/12321883/?selectedTab=com.atlassian.jira.jira-projects-plugin:version-issues-panel >> > >> > Any thoughts? >> > -Matthias >> > >> > >> > >> > >> > -- >> > Matthias Wessendorf >> > >> > blog: http://matthiaswessendorf.wordpress.com/ >> > sessions: http://www.slideshare.net/mwessendorf >> > twitter: http://twitter.com/mwessendorf >> > >> > >> > -- >> > Sent from Gmail Mobile >> >> > _______________________________________________ >> > aerogear-dev mailing list >> > aerogear-dev at lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> -- >> >> abstractj >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140701/ed3ff421/attachment.html From matzew at apache.org Tue Jul 1 02:45:10 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Tue, 1 Jul 2014 08:45:10 +0200 Subject: [aerogear-dev] UPS 0.11 In-Reply-To: References: <20140630161444.GA14602@abstractj.org> Message-ID: Thanks for the feedback guys, I will do some more testings in the morning. I feel we are very close to start the release and its testings. If all goes well, we can have the release by the end of the week, early next week. Due to 4th of July, I'd prefer the announcement after that long weekend -M On Tue, Jul 1, 2014 at 8:42 AM, Matthias Wessendorf wrote: > Sebi, > > > On Tue, Jul 1, 2014 at 1:20 AM, Sebastien Blanc > wrote: > >> >> >> >> On Mon, Jun 30, 2014 at 6:14 PM, Bruno Oliveira >> wrote: >> >>> Hi Matthias, I think we're in a good shape. We have 3 PR to be reviewed: >>> >>> - https://github.com/aerogear/aerogear-unifiedpush-server/pull/154 >>> I would vote to postpone it for further releases >>> >> +1 >> >>> >>> - https://github.com/aerogear/aerogear-unifiedpush-server/pull/250 >>> It seems like ready to go >>> >> +1 (just a small ui thing that could be better but we can see that later) >> > > can you send a PR for that change ? > > > > >> >>> - https://github.com/aerogear/aerogear-unifiedpush-server/pull/253 >>> Need some feedback >>> >> feedback given >> >>> >>> Regarding the Keycloak integration, I reasssigned AGPUSH-568 to myself, >>> but let me know if you want to be in charge of it. >>> >>> On 2014-06-30, Matthias Wessendorf wrote: >>> > Hello, >>> > >>> > while waiting for my flight back home I was looking over the open PRs >>> and >>> > added a few comments: >>> > * https://github.com/aerogear/aerogear-unifiedpush-server/pull/250 >>> > * https://github.com/aerogear/aerogear-unifiedpush-server/pull/249 >>> > * https://github.com/aerogear/aerogear-unifiedpush-server/pull/244 >>> > * https://github.com/aerogear/aerogear-unifiedpush-server/pull/243 >>> > >>> > >>> > Besides those, there are three open tickets, which I'd like to see >>> fixed >>> > for the 0.11: >>> > >>> https://issues.jboss.org/browse/AGPUSH/fixforversion/12321883/?selectedTab=com.atlassian.jira.jira-projects-plugin:version-issues-panel >>> > >>> > Any thoughts? >>> > -Matthias >>> > >>> > >>> > >>> > >>> > -- >>> > Matthias Wessendorf >>> > >>> > blog: http://matthiaswessendorf.wordpress.com/ >>> > sessions: http://www.slideshare.net/mwessendorf >>> > twitter: http://twitter.com/mwessendorf >>> > >>> > >>> > -- >>> > Sent from Gmail Mobile >>> >>> > _______________________________________________ >>> > aerogear-dev mailing list >>> > aerogear-dev at lists.jboss.org >>> > https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >>> >>> -- >>> >>> abstractj >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140701/54b67f23/attachment-0001.html From scm.blanc at gmail.com Tue Jul 1 02:55:59 2014 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Tue, 1 Jul 2014 08:55:59 +0200 Subject: [aerogear-dev] UPS 0.11 In-Reply-To: References: <20140630161444.GA14602@abstractj.org> Message-ID: On Tue, Jul 1, 2014 at 8:42 AM, Matthias Wessendorf wrote: > Sebi, > > > On Tue, Jul 1, 2014 at 1:20 AM, Sebastien Blanc > wrote: > >> >> >> >> On Mon, Jun 30, 2014 at 6:14 PM, Bruno Oliveira >> wrote: >> >>> Hi Matthias, I think we're in a good shape. We have 3 PR to be reviewed: >>> >>> - https://github.com/aerogear/aerogear-unifiedpush-server/pull/154 >>> I would vote to postpone it for further releases >>> >> +1 >> >>> >>> - https://github.com/aerogear/aerogear-unifiedpush-server/pull/250 >>> It seems like ready to go >>> >> +1 (just a small ui thing that could be better but we can see that later) >> > > can you send a PR for that change ? > Apparently, Erik, aka Flash Gordon, as already a PR for that ;) > > > > >> >>> - https://github.com/aerogear/aerogear-unifiedpush-server/pull/253 >>> Need some feedback >>> >> feedback given >> >>> >>> Regarding the Keycloak integration, I reasssigned AGPUSH-568 to myself, >>> but let me know if you want to be in charge of it. >>> >>> On 2014-06-30, Matthias Wessendorf wrote: >>> > Hello, >>> > >>> > while waiting for my flight back home I was looking over the open PRs >>> and >>> > added a few comments: >>> > * https://github.com/aerogear/aerogear-unifiedpush-server/pull/250 >>> > * https://github.com/aerogear/aerogear-unifiedpush-server/pull/249 >>> > * https://github.com/aerogear/aerogear-unifiedpush-server/pull/244 >>> > * https://github.com/aerogear/aerogear-unifiedpush-server/pull/243 >>> > >>> > >>> > Besides those, there are three open tickets, which I'd like to see >>> fixed >>> > for the 0.11: >>> > >>> https://issues.jboss.org/browse/AGPUSH/fixforversion/12321883/?selectedTab=com.atlassian.jira.jira-projects-plugin:version-issues-panel >>> > >>> > Any thoughts? >>> > -Matthias >>> > >>> > >>> > >>> > >>> > -- >>> > Matthias Wessendorf >>> > >>> > blog: http://matthiaswessendorf.wordpress.com/ >>> > sessions: http://www.slideshare.net/mwessendorf >>> > twitter: http://twitter.com/mwessendorf >>> > >>> > >>> > -- >>> > Sent from Gmail Mobile >>> >>> > _______________________________________________ >>> > aerogear-dev mailing list >>> > aerogear-dev at lists.jboss.org >>> > https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >>> >>> -- >>> >>> abstractj >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140701/83474371/attachment.html From scm.blanc at gmail.com Tue Jul 1 03:28:08 2014 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Tue, 1 Jul 2014 09:28:08 +0200 Subject: [aerogear-dev] UPS 0.11 In-Reply-To: References: <20140630161444.GA14602@abstractj.org> Message-ID: Fix has been merged https://github.com/aerogear/aerogear-unifiedpush-server/commit/422ce476b2c95b63a47a43f6495a02ef7780049a On Tue, Jul 1, 2014 at 8:55 AM, Sebastien Blanc wrote: > > > > On Tue, Jul 1, 2014 at 8:42 AM, Matthias Wessendorf > wrote: > >> Sebi, >> >> >> On Tue, Jul 1, 2014 at 1:20 AM, Sebastien Blanc >> wrote: >> >>> >>> >>> >>> On Mon, Jun 30, 2014 at 6:14 PM, Bruno Oliveira >>> wrote: >>> >>>> Hi Matthias, I think we're in a good shape. We have 3 PR to be reviewed: >>>> >>>> - https://github.com/aerogear/aerogear-unifiedpush-server/pull/154 >>>> I would vote to postpone it for further releases >>>> >>> +1 >>> >>>> >>>> - https://github.com/aerogear/aerogear-unifiedpush-server/pull/250 >>>> It seems like ready to go >>>> >>> +1 (just a small ui thing that could be better but we can see that >>> later) >>> >> >> can you send a PR for that change ? >> > Apparently, Erik, aka Flash Gordon, as already a PR for that ;) > >> >> >> >> >>> >>>> - https://github.com/aerogear/aerogear-unifiedpush-server/pull/253 >>>> Need some feedback >>>> >>> feedback given >>> >>>> >>>> Regarding the Keycloak integration, I reasssigned AGPUSH-568 to myself, >>>> but let me know if you want to be in charge of it. >>>> >>>> On 2014-06-30, Matthias Wessendorf wrote: >>>> > Hello, >>>> > >>>> > while waiting for my flight back home I was looking over the open PRs >>>> and >>>> > added a few comments: >>>> > * https://github.com/aerogear/aerogear-unifiedpush-server/pull/250 >>>> > * https://github.com/aerogear/aerogear-unifiedpush-server/pull/249 >>>> > * https://github.com/aerogear/aerogear-unifiedpush-server/pull/244 >>>> > * https://github.com/aerogear/aerogear-unifiedpush-server/pull/243 >>>> > >>>> > >>>> > Besides those, there are three open tickets, which I'd like to see >>>> fixed >>>> > for the 0.11: >>>> > >>>> https://issues.jboss.org/browse/AGPUSH/fixforversion/12321883/?selectedTab=com.atlassian.jira.jira-projects-plugin:version-issues-panel >>>> > >>>> > Any thoughts? >>>> > -Matthias >>>> > >>>> > >>>> > >>>> > >>>> > -- >>>> > Matthias Wessendorf >>>> > >>>> > blog: http://matthiaswessendorf.wordpress.com/ >>>> > sessions: http://www.slideshare.net/mwessendorf >>>> > twitter: http://twitter.com/mwessendorf >>>> > >>>> > >>>> > -- >>>> > Sent from Gmail Mobile >>>> >>>> > _______________________________________________ >>>> > aerogear-dev mailing list >>>> > aerogear-dev at lists.jboss.org >>>> > https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> >>>> >>>> -- >>>> >>>> abstractj >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> >>> >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >> >> >> >> -- >> Matthias Wessendorf >> >> blog: http://matthiaswessendorf.wordpress.com/ >> sessions: http://www.slideshare.net/mwessendorf >> twitter: http://twitter.com/mwessendorf >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140701/c10c4f1d/attachment.html From matzew at apache.org Tue Jul 1 06:31:37 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Tue, 1 Jul 2014 12:31:37 +0200 Subject: [aerogear-dev] Release of UnifiedPush Server 0.11 Message-ID: Ahoy folks! we have been extremely busy over the last few weeks and we are getting closer to our 1.0.0 release. That was a lot of work and I am very happy with the results. THANKS A LOT!!!!!!!! However, before we are moving towards the 1.0.0 community release, I'd love to get the current work out as 0.11. Note this release contains a ton of work and new features. To name a few highlights: * New AdminUI ** a complete rewrite to go with Angular.js * Keycloak integration ** user-management and auth is no longer done by the UPS itself. We bundle a Keycloak auth server in a separate WAR file * Analytics and Metrics ** get some details about your applications, the devices and the status of the submitted push request job to the 3rd party provider Besides these big changes, a ton of more work was done by the team: https://issues.jboss.org/browse/AGPUSH/fixforversion/12321883/?selectedTab=com.atlassian.jira.jira-projects-plugin:version-issues-panel The staging repository is located here: http://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-3490/ NOTE! This release will not make it to OpenShift yet, as that involves a bit more of testing, as discussed a few weeks ago on IRC Let me know the results of your testing; If I hear nothing bad by Thursday evening, the release to maven central will happen on Friday; The offical announcement will go out AFTER the long weekend (4th of July) Greetings, Matthias -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140701/955d747d/attachment-0001.html From jbalunas at redhat.com Tue Jul 1 08:03:52 2014 From: jbalunas at redhat.com (Jay Balunas) Date: Tue, 1 Jul 2014 08:03:52 -0400 Subject: [aerogear-dev] Release of UnifiedPush Server 0.11 In-Reply-To: References: Message-ID: <1F65E576-2FD1-49BE-93E2-1128FA50AFCB@redhat.com> This is awesome!! Good work everyone! On Jul 1, 2014, at 6:31 AM, Matthias Wessendorf wrote: > Ahoy folks! > > we have been extremely busy over the last few weeks and we are getting closer to our 1.0.0 release. That was a lot of work and I am very happy with the results. > > THANKS A LOT!!!!!!!! > > > However, before we are moving towards the 1.0.0 community release, I'd love to get the current work out as 0.11. Note this release contains a ton of work and new features. To name a few highlights: > > * New AdminUI > ** a complete rewrite to go with Angular.js > * Keycloak integration > ** user-management and auth is no longer done by the UPS itself. We bundle a Keycloak auth server in a separate WAR file > * Analytics and Metrics > ** get some details about your applications, the devices and the status of the submitted push request job to the 3rd party provider > > Besides these big changes, a ton of more work was done by the team: > https://issues.jboss.org/browse/AGPUSH/fixforversion/12321883/?selectedTab=com.atlassian.jira.jira-projects-plugin:version-issues-panel > > The staging repository is located here: > http://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-3490/ > > NOTE! This release will not make it to OpenShift yet, as that involves a bit more of testing, as discussed a few weeks ago on IRC > > > Let me know the results of your testing; > If I hear nothing bad by Thursday evening, the release to maven central will happen on Friday; > > The offical announcement will go out AFTER the long weekend (4th of July) > > > Greetings, > Matthias > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140701/96ac4254/attachment.html From bruno at abstractj.org Tue Jul 1 08:37:56 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Tue, 1 Jul 2014 09:37:56 -0300 Subject: [aerogear-dev] Release of UnifiedPush Server 0.11 In-Reply-To: References: Message-ID: <20140701123756.GA1787@abstractj.org> Release the Kraken! On 2014-07-01, Matthias Wessendorf wrote: > Ahoy folks! > > we have been extremely busy over the last few weeks and we are getting > closer to our 1.0.0 release. That was a lot of work and I am very happy > with the results. > > THANKS A LOT!!!!!!!! > > > However, before we are moving towards the 1.0.0 community release, I'd love > to get the current work out as 0.11. Note this release contains a ton of > work and new features. To name a few highlights: > > * New AdminUI > ** a complete rewrite to go with Angular.js > * Keycloak integration > ** user-management and auth is no longer done by the UPS itself. We bundle > a Keycloak auth server in a separate WAR file > * Analytics and Metrics > ** get some details about your applications, the devices and the status of > the submitted push request job to the 3rd party provider > > Besides these big changes, a ton of more work was done by the team: > https://issues.jboss.org/browse/AGPUSH/fixforversion/12321883/?selectedTab=com.atlassian.jira.jira-projects-plugin:version-issues-panel > > The staging repository is located here: > http://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-3490/ > > NOTE! This release will not make it to OpenShift yet, as that involves a > bit more of testing, as discussed a few weeks ago on IRC > > > Let me know the results of your testing; > If I hear nothing bad by Thursday evening, the release to maven central > will happen on Friday; > > The offical announcement will go out AFTER the long weekend (4th of July) > > > Greetings, > Matthias > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -- abstractj From cvasilak at gmail.com Tue Jul 1 10:07:56 2014 From: cvasilak at gmail.com (Christos Vasilakis) Date: Tue, 1 Jul 2014 17:07:56 +0300 Subject: [aerogear-dev] Team meeting Message-ID: <72067BF1-232C-49CD-B498-A750124E03F9@gmail.com> fyi meeting minutes: Meeting ended Tue Jul 1 13:47:11 2014 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) Minutes: http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2014/aerogear.2014-07-01-13.42.html Minutes (text): http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2014/aerogear.2014-07-01-13.42.txt Log: http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2014/aerogear.2014-07-01-13.42.log.html -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140701/00d3971f/attachment.html From daniel at passos.me Tue Jul 1 10:36:51 2014 From: daniel at passos.me (Daniel Passos) Date: Tue, 1 Jul 2014 11:36:51 -0300 Subject: [aerogear-dev] AeroGear Android 1.4.0 Staged Message-ID: Hey Everyone, AeroGear Android 1.4.0 was staged on Nexus. \o/ This release introduced OAuth2 support, numerous doc, quickstarts and cookbook updates. Pipe and pipeline updates and modularizes our push APIs [1] We planned press the button and release it to maven central next thursday Feel free to test it[2]! [1] https://issues.jboss.org/issues/?filter=12320506 [2] http://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-3491/ -- Passos -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140701/09d36ae7/attachment.html From corinnekrych at gmail.com Tue Jul 1 11:38:48 2014 From: corinnekrych at gmail.com (Corinne Krych) Date: Tue, 1 Jul 2014 17:38:48 +0200 Subject: [aerogear-dev] AeroGear iOS meeting Message-ID: <563318AC-1A4B-4934-856C-E6BA9637D292@gmail.com> Hello iOS lovers, 1.6 is over let?s sit down together and discuss what?s next. We'll use our usual Tuesday slot. See you Tuesday 8th July at 2pm (CEST - UTC + 2hours). Here is a proposal agenda: http://oksoclap.com/p/aerogear_ios_meeting_01072014 Feel free to add topics you would like to discuss. See you all Tuesday! ++ Corinne From matzew at apache.org Wed Jul 2 00:55:16 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Wed, 2 Jul 2014 06:55:16 +0200 Subject: [aerogear-dev] Aerogear slide decks and videos In-Reply-To: <292531261.30693098.1403766373388.JavaMail.zimbra@redhat.com> References: <1271931635.30692564.1403766264788.JavaMail.zimbra@redhat.com> <292531261.30693098.1403766373388.JavaMail.zimbra@redhat.com> Message-ID: Hello Michelle, thanks for getting in touch. Sorry for the late reply but the team was busy at last weeks Face2Face. Here is a slide deck that I used last Saturday for the Mobile JUDCon Boston: http://people.apache.org/~matzew/UPS_2014/ Others, like Sebi, Erik or Corinne do have slide decks that cover some of the push bits as well -Matthias On Thu, Jun 26, 2014 at 9:06 AM, Michelle Murray wrote: > Hello, > > The Mobile Docs team is trying to gather resources from which to learn > about aerogear and the unified push server. > > We've already looked at the aerogear push 101 youtube video and the docs > on the aerogear website. > > Does anyone have any slide decks or more recent videos that we could learn > from? > > Thanks, > Michelle > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140702/16c15360/attachment.html From mmurray at redhat.com Wed Jul 2 01:07:43 2014 From: mmurray at redhat.com (Michelle Murray) Date: Wed, 2 Jul 2014 01:07:43 -0400 (EDT) Subject: [aerogear-dev] Aerogear slide decks and videos In-Reply-To: References: <1271931635.30692564.1403766264788.JavaMail.zimbra@redhat.com> <292531261.30693098.1403766373388.JavaMail.zimbra@redhat.com> Message-ID: <2103242850.1972681.1404277663005.JavaMail.zimbra@redhat.com> Hi Matthias, That's great - thanks. Do you have any of the demos from that slide deck recorded? It's always good to see things in action. Thanks, Michelle ----- Original Message ----- > From: "Matthias Wessendorf" > To: "AeroGear Developer Mailing List" > Cc: "Supriya Bharadwaj" > Sent: Wednesday, 2 July, 2014 2:55:16 PM > Subject: Re: [aerogear-dev] Aerogear slide decks and videos > Hello Michelle, > thanks for getting in touch. Sorry for the late reply but the team was busy > at last weeks Face2Face. > Here is a slide deck that I used last Saturday for the Mobile JUDCon Boston: > http://people.apache.org/~matzew/UPS_2014/ > Others, like Sebi, Erik or Corinne do have slide decks that cover some of the > push bits as well > -Matthias > On Thu, Jun 26, 2014 at 9:06 AM, Michelle Murray < mmurray at redhat.com > > wrote: > > Hello, > > > The Mobile Docs team is trying to gather resources from which to learn > > about > > aerogear and the unified push server. > > > We've already looked at the aerogear push 101 youtube video and the docs on > > the aerogear website. > > > Does anyone have any slide decks or more recent videos that we could learn > > from? > > > Thanks, > > > Michelle > > > _______________________________________________ > > > aerogear-dev mailing list > > > aerogear-dev at lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > -- > Matthias Wessendorf > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140702/0ec134c0/attachment-0001.html From matzew at apache.org Wed Jul 2 01:21:23 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Wed, 2 Jul 2014 07:21:23 +0200 Subject: [aerogear-dev] Aerogear slide decks and videos In-Reply-To: <2103242850.1972681.1404277663005.JavaMail.zimbra@redhat.com> References: <1271931635.30692564.1403766264788.JavaMail.zimbra@redhat.com> <292531261.30693098.1403766373388.JavaMail.zimbra@redhat.com> <2103242850.1972681.1404277663005.JavaMail.zimbra@redhat.com> Message-ID: Hello Michelle! Not really in terms of a deployed demo - but there is a video from my presentation (starts at 1:39:45): https://www.youtube.com/watch?v=yHU781JR2hk#t=5985 ends around 2:25:25 Oh, that above video contains also all the talks from Saturday, including Erik's and Sebi's talk around Cordova and Push. I think watching all of the presentations does make sense On Wed, Jul 2, 2014 at 7:07 AM, Michelle Murray wrote: > Hi Matthias, > > That's great - thanks. Do you have any of the demos from that slide deck > recorded? It's always good to see things in action. > > Thanks, > Michelle > > ------------------------------ > > *From: *"Matthias Wessendorf" > *To: *"AeroGear Developer Mailing List" > *Cc: *"Supriya Bharadwaj" > *Sent: *Wednesday, 2 July, 2014 2:55:16 PM > *Subject: *Re: [aerogear-dev] Aerogear slide decks and videos > > > Hello Michelle, > > thanks for getting in touch. Sorry for the late reply but the team was > busy at last weeks Face2Face. > > Here is a slide deck that I used last Saturday for the Mobile JUDCon > Boston: > http://people.apache.org/~matzew/UPS_2014/ > > Others, like Sebi, Erik or Corinne do have slide decks that cover some of > the push bits as well > > -Matthias > > > On Thu, Jun 26, 2014 at 9:06 AM, Michelle Murray > wrote: > >> Hello, >> >> The Mobile Docs team is trying to gather resources from which to learn >> about aerogear and the unified push server. >> >> We've already looked at the aerogear push 101 youtube video and the docs >> on the aerogear website. >> >> Does anyone have any slide decks or more recent videos that we could >> learn from? >> >> Thanks, >> Michelle >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140702/0869dff5/attachment.html From edewit at redhat.com Wed Jul 2 02:57:44 2014 From: edewit at redhat.com (Erik Jan de Wit) Date: Wed, 2 Jul 2014 08:57:44 +0200 Subject: [aerogear-dev] JUDcon Slides Message-ID: <5D6CB709-2E44-474A-ACA7-CEC9FBAAB333@redhat.com> Hi, Slides of our (S?bastien and I) presentation on the JUDcon 2014 in Boston are published here: http://www.slideshare.net/slideshow/embed_code/36539071 There is also a video to go with that: http://www.youtube.com/watch?feature=player_detailpage&v=yHU781JR2hk#t=2623 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140702/d0bd8cb5/attachment.html From corinnekrych at gmail.com Wed Jul 2 04:53:08 2014 From: corinnekrych at gmail.com (Corinne Krych) Date: Wed, 2 Jul 2014 10:53:08 +0200 Subject: [aerogear-dev] iOS8: what's new? Message-ID: Hello iOS lovers, With WWDC over, we?ve got plenty news stuff coming. We?re pretty existing about it so I would like to share with you the excitement. If you want to catch up quickly on what?s new, one blog post I really like and would recommend: http://nshipster.com/ios8/ and if you have more time, if you?re enrolled in iOS dev program and have Safari opened you can watch the great WWDC videos. In https://developer.apple.com/videos/wwdc/2014/ I would recommend the followings: - swift: session 403, 404, 406, 407, 408 - iOS notification: session 713 The stuff I found most existed about are: - Swift coming: to me, it?s a big win. iOS platform with Swift will be a killer. Xcode6 with its Playground features and it REPL will be much easier to play with. - LocalAuthentication Developers can use TouchID APIs. Bin win for secure offline. - iOS8 interactive notification, increased size - embedded widgets This is a thread to gather all the things you like (or don?t like) about iOS8. Feel free to add your own comments and feelings. Some interesting tickets to follow: AGIOS-210 - Epic iOS8 notification AGIOS-220 - Epic for Swift (a Swift version of aerogear-push-ios-registration) ++ Corinne From matzew at apache.org Wed Jul 2 05:20:53 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Wed, 2 Jul 2014 11:20:53 +0200 Subject: [aerogear-dev] iOS8: what's new? In-Reply-To: References: Message-ID: Thanks for sharing! I will get on the session731 this afternoon :-) On Wed, Jul 2, 2014 at 10:53 AM, Corinne Krych wrote: > Hello iOS lovers, > > With WWDC over, we?ve got plenty news stuff coming. We?re pretty existing > about it so I would like to share with you the excitement. > If you want to catch up quickly on what?s new, one blog post I really like > and would recommend: > http://nshipster.com/ios8/ > > and if you have more time, if you?re enrolled in iOS dev program and have > Safari opened you can watch the great WWDC videos. > In https://developer.apple.com/videos/wwdc/2014/ > I would recommend the followings: > - swift: session 403, 404, 406, 407, 408 > - iOS notification: session 713 > > The stuff I found most existed about are: > - Swift coming: to me, it?s a big win. iOS platform with Swift will be a > killer. Xcode6 with its Playground features and it REPL will be much easier > to play with. > - LocalAuthentication Developers can use TouchID APIs. Bin win for secure > offline. > - iOS8 interactive notification, increased size > - embedded widgets > > This is a thread to gather all the things you like (or don?t like) about > iOS8. Feel free to add your own comments and feelings. > > Some interesting tickets to follow: > AGIOS-210 - Epic iOS8 notification > AGIOS-220 - Epic for Swift (a Swift version of > aerogear-push-ios-registration) > > ++ > Corinne > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140702/eef63bcb/attachment.html From corinnekrych at gmail.com Wed Jul 2 05:22:16 2014 From: corinnekrych at gmail.com (Corinne Krych) Date: Wed, 2 Jul 2014 11:22:16 +0200 Subject: [aerogear-dev] Swift HelloWorld for MobilePush Message-ID: Hello all, Working toward our next 1.0 release for AeroGear Push, we?ve got our first Swift repo merged today! So we have a Swift HelloWorld app working with push registration obj-C framework. Next steps will be to offer a Swift version of aerogear-push-ios-registration to demo a entirely swift stack. Have a look to: https://github.com/aerogear/aerogear-push-helloworld/tree/master/ios-swift ++ Corinne From matzew at apache.org Wed Jul 2 05:24:00 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Wed, 2 Jul 2014 11:24:00 +0200 Subject: [aerogear-dev] Swift HelloWorld for MobilePush In-Reply-To: References: Message-ID: On Wed, Jul 2, 2014 at 11:22 AM, Corinne Krych wrote: > Hello all, > > Working toward our next 1.0 release for AeroGear Push, we?ve got our first > Swift repo merged today! > ZOMG !!!! that is so cool! > So we have a Swift HelloWorld app working with push registration obj-C > framework. Next steps will be to offer a Swift version of > aerogear-push-ios-registration to demo a entirely swift stack. > yay! sounds really great! Thanks Corinne and Christos for looking into it! > > Have a look to: > https://github.com/aerogear/aerogear-push-helloworld/tree/master/ios-swift > > ++ > Corinne > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140702/323b5409/attachment-0001.html From scm.blanc at gmail.com Wed Jul 2 05:43:59 2014 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Wed, 2 Jul 2014 11:43:59 +0200 Subject: [aerogear-dev] iOS8: what's new? In-Reply-To: References: Message-ID: Thanks for this overview ! I can't wait to play with the interactive notifications. On Wed, Jul 2, 2014 at 11:20 AM, Matthias Wessendorf wrote: > Thanks for sharing! > > I will get on the session731 this afternoon :-) > > > On Wed, Jul 2, 2014 at 10:53 AM, Corinne Krych > wrote: > >> Hello iOS lovers, >> >> With WWDC over, we?ve got plenty news stuff coming. We?re pretty existing >> about it so I would like to share with you the excitement. >> If you want to catch up quickly on what?s new, one blog post I really >> like and would recommend: >> http://nshipster.com/ios8/ >> >> and if you have more time, if you?re enrolled in iOS dev program and have >> Safari opened you can watch the great WWDC videos. >> In https://developer.apple.com/videos/wwdc/2014/ >> I would recommend the followings: >> - swift: session 403, 404, 406, 407, 408 >> - iOS notification: session 713 >> >> The stuff I found most existed about are: >> - Swift coming: to me, it?s a big win. iOS platform with Swift will be a >> killer. Xcode6 with its Playground features and it REPL will be much easier >> to play with. >> - LocalAuthentication Developers can use TouchID APIs. Bin win for secure >> offline. >> - iOS8 interactive notification, increased size >> - embedded widgets >> >> This is a thread to gather all the things you like (or don?t like) about >> iOS8. Feel free to add your own comments and feelings. >> >> Some interesting tickets to follow: >> AGIOS-210 - Epic iOS8 notification >> AGIOS-220 - Epic for Swift (a Swift version of >> aerogear-push-ios-registration) >> >> ++ >> Corinne >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140702/daa6efe1/attachment.html From matzew at apache.org Wed Jul 2 08:56:21 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Wed, 2 Jul 2014 14:56:21 +0200 Subject: [aerogear-dev] UPS Production worthiness In-Reply-To: References: <002b01cf7424$528dc0a0$f7a941e0$@pinelabs.com> <005d01cf74ed$3d977140$b8c653c0$@pinelabs.com> <003c01cf78cd$1095df40$31c19dc0$@pinelabs.com> <17C1B903-C13B-482F-93FA-1B9B55AEF707@redhat.com> Message-ID: Hello Vivek, On Mon, May 26, 2014 at 1:23 PM, Matthias Wessendorf wrote: > > > > On Mon, May 26, 2014 at 12:59 PM, Erik Jan de Wit > wrote: > >> Hi Vivek, >> >> We?ve fixed that >> https://github.com/aerogear/aerogear-unifiedpush-server/commit/1357c9e834286a9227a90e9ab618226aa54bbbf3 the >> collection is now lazy. But I?m sure other query optimisations can be made. >> > > +1 > > btw. Vivek, I added your mail to an existing ticket: > https://issues.jboss.org/browse/AGPUSH-661 > > coming back from vacation and going over the JIRAs, I was wondering if an 'importer' helps? That would be a RESTful endpoint that accepts a JSON file, containing all the devices you want to register (for a given variant). That way it would be also a bit nicer on your side, to perform the import: * generate a "large" JSON file (instead of a ton of requests) * only one HTTP request * server accepts and will process it in the background I think that would be a nice migration tool. Let me know what you think! -Matthias > -Matthias > > >> >> Cheers, >> Erik Jan >> >> On 26 May,2014, at 12:27 , Vivek Pandey >> wrote: >> >> Hi Matthias, >> >> It is good to know that activity in java-apns is picking up and also that >> you are looking at pushy. >> >> I did a few tests which added installations to UPS with a concurrency of >> 4-8 threads. I was using Postgres 9.3 and UPS 0.10.3 war >> >> I noticed that response slowed down considerably after some time with >> high CPU usage and continued to get worse. After doing some profiling, I >> found that bulk of CPU cycles are being taken by >> org.postgresql.core.VisibleBufferedInputStream.readMore. The entire thread >> stack is attached. Also postgres continuously flagged >> >> select installati0_.variantID as variant10_0_0_, installati0_.id as >> id1_3_0_, installati0_.id as id1_3_1_, installati0_.alias as alias2_3_1_, >> installati0_.deviceToken as deviceTo3_3_1_, installati0_.deviceType as >> deviceTy4_3_1_, installati0_.enabled as enabled5_3_1_, >> installati0_.operatingSystem as operatin6_3_1_, installati0_.osVersion as >> osVersio7_3_1_, installati0_.platform as platform8_3_1_, >> installati0_.simplePushEndpoint as simplePu9_3_1_ from InstallationImpl >> installati0_ where installati0_.variantID=$1 >> >> as the slow query. I am pretty sure that eager collection >> AbstractVariant.installations is the root cause of the problem. >> >> Please let me know if you need any more information. >> >> Thanks >> Vivek >> >> *From:* mwessendorf at gmail.com [mailto:mwessendorf at gmail.com >> ] *On Behalf Of *Matthias Wessendorf >> *Sent:* Wednesday, May 21, 2014 5:55 PM >> *To:* vivek.pandey at pinelabs.com; AeroGear Developer Mailing List >> *Subject:* Re: [aerogear-dev] UPS Production worthiness >> >> Hello Vivek! >> >> >> On Wed, May 21, 2014 at 2:07 PM, Vivek Pandey >> wrote: >> Hi Jay, >> >> Thanks for your reply. >> >> While we have not faced any issues in using UPS in our limited testing, I >> often see info stacktraces in ups logs >> >> 2014-05-16 10:19:20,032 INFO >> [com.notnoop.apns.internal.ApnsConnectionImpl] (Thread-118) Exception while >> waiting for error code: java.net.SocketException: Socket closed >> at java.net.SocketInputStream.socketRead0(Native Method) >> [rt.jar:1.7.0_51] >> at java.net.SocketInputStream.read(SocketInputStream.java:152) >> [rt.jar:1.7.0_51] >> at java.net.SocketInputStream.read(SocketInputStream.java:122) >> [rt.jar:1.7.0_51] >> ????? >> at >> com.notnoop.apns.internal.ApnsConnectionImpl$1MonitoringThread.run(ApnsConnectionImpl.java:114) >> [apns-0.2.3.jar:] >> >> >> These stacktraces coupled with low dev activity of noop/java-apns project >> are disconcerting to me. >> >> the stack-trace is no harm - it's only happening w/ doing a monitoring of >> the thread (that's what we currently do, when setting up ApnsService - I >> thought about explicitly disable that) >> >> The activity of the underlying java-apns is very low, yes! However >> @froh42 is getting back: >> https://github.com/notnoop/java-apns/commits/master >> >> There will be a new release in the near future; @froh42 asked me if I >> could help with pushing the bits to maven central >> >> >> That said, I recently started looking at pushy: >> https://github.com/relayrides/pushy >> >> I also sent a PR that would allow us to feed pushy w/ our certificate >> from the database: >> https://github.com/relayrides/pushy/pull/87 >> >> Hope that helps >> -Matthias >> >> >> >> I am currently using UPS 0.10.2 war. >> >> Thanks, >> Vivek >> *From:* Jay Balunas [mailto:jbalunas at redhat.com] >> *Sent:* Tuesday, May 20, 2014 11:36 PM >> *To:* vivek.pandey at pinelabs.com; AeroGear Developer Mailing List >> *Cc:* Jay Balunas >> *Subject:* Re: [aerogear-dev] UPS Production worthiness >> >> Hi Vivek, >> >> It's awesome to hear that you have integrated the UPS into your backend >> systems and some of your mobile apps! >> >> We have a lot of confidence around the UPS, its functionality, and >> performance. Our team has been working hard on improvements and stability >> including our QE team. Also, as you may have seen we're planning a 1.0 >> release of the UPS this summer. >> >> However at this time we don't have specific references or success stories >> outside of what you can see in the community mailing lists - other users >> using it ;-) We're also about to kick off some performance and scale >> testing in the next couple of months. >> >> Have you run into any issues that drove these questions about production >> worthiness? If so please let us know and we'll certainly take a look. >> >> Hope this helps! >> >> Thanks, >> Jay Balunas >> >> On May 20, 2014, at 8:09 AM, Vivek Pandey >> wrote: >> >> >> Hello Aerogear dev team, >> >> We integrated UPS into our backend server which is serving various mobile >> apps. While the development and testing phase went well, my manager is >> questioning me about production worthiness about Aerogear. It would be >> great help if you could point me to references/success stories where UPS is >> being used in production environments and scaling well in medium to high >> loads. >> >> Thanks, >> Vivek >> >> >> >> ------------------------------ >> This message may contain privileged and confidential information and is >> solely for the use of intended recipient. The views expressed in this email >> are those of the sender and not of Pine Labs. The recipient should check >> this email and attachments for the presence of viruses / malwares etc. Pine >> Labs accepts no liability for any damage caused by any virus transmitted by >> this email. Pine Labs may monitor and record all emails. >> ------------------------------ >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> ------------------------------ >> This message may contain privileged and confidential information and is >> solely for the use of intended recipient. The views expressed in this email >> are those of the sender and not of Pine Labs. The recipient should check >> this email and attachments for the presence of viruses / malwares etc. Pine >> Labs accepts no liability for any damage caused by any virus transmitted by >> this email. Pine Labs may monitor and record all emails. >> ------------------------------ >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> >> >> -- >> Matthias Wessendorf >> >> blog: http://matthiaswessendorf.wordpress.com/ >> sessions: http://www.slideshare.net/mwessendorf >> twitter: http://twitter.com/mwessendorf >> >> ------------------------------ >> This message may contain privileged and confidential information and is >> solely for the use of intended recipient. The views expressed in this email >> are those of the sender and not of Pine Labs. The recipient should check >> this email and attachments for the presence of viruses / malwares etc. Pine >> Labs accepts no liability for any damage caused by any virus transmitted by >> this email. Pine Labs may monitor and record all emails. >> ------------------------------ >> >> _______________________________________________ >> >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140702/7c141fcc/attachment-0001.html From corinnekrych at gmail.com Wed Jul 2 08:38:18 2014 From: corinnekrych at gmail.com (Corinne Krych) Date: Wed, 2 Jul 2014 14:38:18 +0200 Subject: [aerogear-dev] iOS8: what's new? In-Reply-To: References: Message-ID: <53F0878C-B864-4CC1-8D70-6768C07D6156@gmail.com> Good point Sebi, Let?s launch the discussion on interactive notifications. To support them (remotely), a new payload need to be added server side, just adding a category field: { "aps" : { "alert": "you're invited", "category": "HelloWorld" } } in category you should match client side code like in example below: https://github.com/corinnekrych/HelloWorld-Swift/blob/local.notification/HelloWorldSwift/AppDelegate.swift#L60 I?ve tried interactive notification in HelloWorld sample but tbh I think Helloworld should stay simple, it might be a better idea to demo them in a more elaboraten example like: Quickstarts or AeroDoc. Should we demo them for mobile Push 1.0. Waiting for your feedback and bright idea ;) ++ Corinne Here?s a good reading on interactive notification: http://www.imore.com/interactive-notifications-ios-8-explained On 02 Jul 2014, at 11:43, Sebastien Blanc wrote: > Thanks for this overview ! > I can't wait to play with the interactive notifications. > > > > On Wed, Jul 2, 2014 at 11:20 AM, Matthias Wessendorf wrote: > Thanks for sharing! > > I will get on the session731 this afternoon :-) > > > On Wed, Jul 2, 2014 at 10:53 AM, Corinne Krych wrote: > Hello iOS lovers, > > With WWDC over, we?ve got plenty news stuff coming. We?re pretty existing about it so I would like to share with you the excitement. > If you want to catch up quickly on what?s new, one blog post I really like and would recommend: > http://nshipster.com/ios8/ > > and if you have more time, if you?re enrolled in iOS dev program and have Safari opened you can watch the great WWDC videos. > In https://developer.apple.com/videos/wwdc/2014/ > I would recommend the followings: > - swift: session 403, 404, 406, 407, 408 > - iOS notification: session 713 > > The stuff I found most existed about are: > - Swift coming: to me, it?s a big win. iOS platform with Swift will be a killer. Xcode6 with its Playground features and it REPL will be much easier to play with. > - LocalAuthentication Developers can use TouchID APIs. Bin win for secure offline. > - iOS8 interactive notification, increased size > - embedded widgets > > This is a thread to gather all the things you like (or don?t like) about iOS8. Feel free to add your own comments and feelings. > > Some interesting tickets to follow: > AGIOS-210 - Epic iOS8 notification > AGIOS-220 - Epic for Swift (a Swift version of aerogear-push-ios-registration) > > ++ > Corinne > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140702/7c2d46c4/attachment.html From matzew at apache.org Wed Jul 2 09:10:42 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Wed, 2 Jul 2014 15:10:42 +0200 Subject: [aerogear-dev] iOS8: what's new? In-Reply-To: <53F0878C-B864-4CC1-8D70-6768C07D6156@gmail.com> References: <53F0878C-B864-4CC1-8D70-6768C07D6156@gmail.com> Message-ID: On Wed, Jul 2, 2014 at 2:38 PM, Corinne Krych wrote: > > Good point Sebi, > > Let?s launch the discussion on interactive notifications. To support them > (remotely), a new payload need to be added server side, just adding a > category field: > > { "aps" : { > "alert": "you're invited", > * "category": "HelloWorld"* > } > } > Do we have a JIRA for that already ? > > in category you should match client side code like in example below: > > https://github.com/corinnekrych/HelloWorld-Swift/blob/local.notification/HelloWorldSwift/AppDelegate.swift#L60 > > I?ve tried interactive notification in HelloWorld sample but tbh I think > Helloworld should stay simple, it might be a better idea to demo them in a > more elaboraten example like: Quickstarts or AeroDoc. > > Should we demo them for mobile Push 1.0. > Waiting for your feedback and bright idea ;) > > ++ > Corinne > > Here?s a good reading on interactive notification: > http://www.imore.com/interactive-notifications-ios-8-explained > > On 02 Jul 2014, at 11:43, Sebastien Blanc wrote: > > > Thanks for this overview ! > I can't wait to play with the interactive notifications. > > > > On Wed, Jul 2, 2014 at 11:20 AM, Matthias Wessendorf > wrote: > Thanks for sharing! > > I will get on the session731 this afternoon :-) > > > On Wed, Jul 2, 2014 at 10:53 AM, Corinne Krych > wrote: > Hello iOS lovers, > > With WWDC over, we?ve got plenty news stuff coming. We?re pretty existing > about it so I would like to share with you the excitement. > If you want to catch up quickly on what?s new, one blog post I really like > and would recommend: > http://nshipster.com/ios8/ > > and if you have more time, if you?re enrolled in iOS dev program and have > Safari opened you can watch the great WWDC videos. > In https://developer.apple.com/videos/wwdc/2014/ > I would recommend the followings: > - swift: session 403, 404, 406, 407, 408 > - iOS notification: session 713 > > The stuff I found most existed about are: > - Swift coming: to me, it?s a big win. iOS platform with Swift will be a > killer. Xcode6 with its Playground features and it REPL will be much easier > to play with. > - LocalAuthentication Developers can use TouchID APIs. Bin win for secure > offline. > - iOS8 interactive notification, increased size > - embedded widgets > > This is a thread to gather all the things you like (or don?t like) about > iOS8. Feel free to add your own comments and feelings. > > Some interesting tickets to follow: > AGIOS-210 - Epic iOS8 notification > AGIOS-220 - Epic for Swift (a Swift version of > aerogear-push-ios-registration) > > ++ > Corinne > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140702/755788cf/attachment.html From corinnekrych at gmail.com Wed Jul 2 09:13:54 2014 From: corinnekrych at gmail.com (Corinne Krych) Date: Wed, 2 Jul 2014 15:13:54 +0200 Subject: [aerogear-dev] iOS8: what's new? In-Reply-To: References: <53F0878C-B864-4CC1-8D70-6768C07D6156@gmail.com> Message-ID: <8EFC9551-FECD-4A46-A838-9D4AAF2828AD@gmail.com> On 02 Jul 2014, at 15:10, Matthias Wessendorf wrote: > > > > On Wed, Jul 2, 2014 at 2:38 PM, Corinne Krych wrote: > > Good point Sebi, > > Let?s launch the discussion on interactive notifications. To support them (remotely), a new payload need to be added server side, just adding a category field: > > { "aps" : { > "alert": "you're invited", > "category": "HelloWorld" > } > } > > > Do we have a JIRA for that already ? > Nope not sure where to add it AGPUSH I guess? If you create one could you link it to AGIOS-210 epic please > > in category you should match client side code like in example below: > https://github.com/corinnekrych/HelloWorld-Swift/blob/local.notification/HelloWorldSwift/AppDelegate.swift#L60 > > I?ve tried interactive notification in HelloWorld sample but tbh I think Helloworld should stay simple, it might be a better idea to demo them in a more elaboraten example like: Quickstarts or AeroDoc. > > Should we demo them for mobile Push 1.0. > Waiting for your feedback and bright idea ;) we also need a demo add. Quickstart? > > ++ > Corinne > > Here?s a good reading on interactive notification: > http://www.imore.com/interactive-notifications-ios-8-explained > > On 02 Jul 2014, at 11:43, Sebastien Blanc wrote: > > >> Thanks for this overview ! >> I can't wait to play with the interactive notifications. >> >> >> >> On Wed, Jul 2, 2014 at 11:20 AM, Matthias Wessendorf wrote: >> Thanks for sharing! >> >> I will get on the session731 this afternoon :-) >> >> >> On Wed, Jul 2, 2014 at 10:53 AM, Corinne Krych wrote: >> Hello iOS lovers, >> >> With WWDC over, we?ve got plenty news stuff coming. We?re pretty existing about it so I would like to share with you the excitement. >> If you want to catch up quickly on what?s new, one blog post I really like and would recommend: >> http://nshipster.com/ios8/ >> >> and if you have more time, if you?re enrolled in iOS dev program and have Safari opened you can watch the great WWDC videos. >> In https://developer.apple.com/videos/wwdc/2014/ >> I would recommend the followings: >> - swift: session 403, 404, 406, 407, 408 >> - iOS notification: session 713 >> >> The stuff I found most existed about are: >> - Swift coming: to me, it?s a big win. iOS platform with Swift will be a killer. Xcode6 with its Playground features and it REPL will be much easier to play with. >> - LocalAuthentication Developers can use TouchID APIs. Bin win for secure offline. >> - iOS8 interactive notification, increased size >> - embedded widgets >> >> This is a thread to gather all the things you like (or don?t like) about iOS8. Feel free to add your own comments and feelings. >> >> Some interesting tickets to follow: >> AGIOS-210 - Epic iOS8 notification >> AGIOS-220 - Epic for Swift (a Swift version of aerogear-push-ios-registration) >> >> ++ >> Corinne >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> >> -- >> Matthias Wessendorf >> >> blog: http://matthiaswessendorf.wordpress.com/ >> sessions: http://www.slideshare.net/mwessendorf >> twitter: http://twitter.com/mwessendorf >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev From matzew at apache.org Wed Jul 2 09:15:20 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Wed, 2 Jul 2014 15:15:20 +0200 Subject: [aerogear-dev] iOS8: what's new? In-Reply-To: <8EFC9551-FECD-4A46-A838-9D4AAF2828AD@gmail.com> References: <53F0878C-B864-4CC1-8D70-6768C07D6156@gmail.com> <8EFC9551-FECD-4A46-A838-9D4AAF2828AD@gmail.com> Message-ID: On Wed, Jul 2, 2014 at 3:13 PM, Corinne Krych wrote: > > On 02 Jul 2014, at 15:10, Matthias Wessendorf wrote: > > > > > > > > > On Wed, Jul 2, 2014 at 2:38 PM, Corinne Krych > wrote: > > > > Good point Sebi, > > > > Let?s launch the discussion on interactive notifications. To support > them (remotely), a new payload need to be added server side, just adding a > category field: > > > > { "aps" : { > > "alert": "you're invited", > > "category": "HelloWorld" > > } > > } > > > > > > Do we have a JIRA for that already ? > > > > Nope > not sure where to add it AGPUSH I guess? > yep, that's where the server tickets go into -M > If you create one could you link it to AGIOS-210 epic please > > > > > > in category you should match client side code like in example below: > > > https://github.com/corinnekrych/HelloWorld-Swift/blob/local.notification/HelloWorldSwift/AppDelegate.swift#L60 > > > > I?ve tried interactive notification in HelloWorld sample but tbh I think > Helloworld should stay simple, it might be a better idea to demo them in a > more elaboraten example like: Quickstarts or AeroDoc. > > > > Should we demo them for mobile Push 1.0. > > Waiting for your feedback and bright idea ;) > > > we also need a demo add. Quickstart? > > > > > ++ > > Corinne > > > > Here?s a good reading on interactive notification: > > http://www.imore.com/interactive-notifications-ios-8-explained > > > > On 02 Jul 2014, at 11:43, Sebastien Blanc wrote: > > > > > >> Thanks for this overview ! > >> I can't wait to play with the interactive notifications. > >> > >> > >> > >> On Wed, Jul 2, 2014 at 11:20 AM, Matthias Wessendorf > wrote: > >> Thanks for sharing! > >> > >> I will get on the session731 this afternoon :-) > >> > >> > >> On Wed, Jul 2, 2014 at 10:53 AM, Corinne Krych > wrote: > >> Hello iOS lovers, > >> > >> With WWDC over, we?ve got plenty news stuff coming. We?re pretty > existing about it so I would like to share with you the excitement. > >> If you want to catch up quickly on what?s new, one blog post I really > like and would recommend: > >> http://nshipster.com/ios8/ > >> > >> and if you have more time, if you?re enrolled in iOS dev program and > have Safari opened you can watch the great WWDC videos. > >> In https://developer.apple.com/videos/wwdc/2014/ > >> I would recommend the followings: > >> - swift: session 403, 404, 406, 407, 408 > >> - iOS notification: session 713 > >> > >> The stuff I found most existed about are: > >> - Swift coming: to me, it?s a big win. iOS platform with Swift will be > a killer. Xcode6 with its Playground features and it REPL will be much > easier to play with. > >> - LocalAuthentication Developers can use TouchID APIs. Bin win for > secure offline. > >> - iOS8 interactive notification, increased size > >> - embedded widgets > >> > >> This is a thread to gather all the things you like (or don?t like) > about iOS8. Feel free to add your own comments and feelings. > >> > >> Some interesting tickets to follow: > >> AGIOS-210 - Epic iOS8 notification > >> AGIOS-220 - Epic for Swift (a Swift version of > aerogear-push-ios-registration) > >> > >> ++ > >> Corinne > >> _______________________________________________ > >> aerogear-dev mailing list > >> aerogear-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > >> > >> > >> > >> -- > >> Matthias Wessendorf > >> > >> blog: http://matthiaswessendorf.wordpress.com/ > >> sessions: http://www.slideshare.net/mwessendorf > >> twitter: http://twitter.com/mwessendorf > >> > >> _______________________________________________ > >> aerogear-dev mailing list > >> aerogear-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > >> > >> _______________________________________________ > >> aerogear-dev mailing list > >> aerogear-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > > > > -- > > Matthias Wessendorf > > > > blog: http://matthiaswessendorf.wordpress.com/ > > sessions: http://www.slideshare.net/mwessendorf > > twitter: http://twitter.com/mwessendorf > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140702/85e1b478/attachment-0001.html From scm.blanc at gmail.com Wed Jul 2 09:24:52 2014 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Wed, 2 Jul 2014 15:24:52 +0200 Subject: [aerogear-dev] iOS8: what's new? In-Reply-To: <8EFC9551-FECD-4A46-A838-9D4AAF2828AD@gmail.com> References: <53F0878C-B864-4CC1-8D70-6768C07D6156@gmail.com> <8EFC9551-FECD-4A46-A838-9D4AAF2828AD@gmail.com> Message-ID: On Wed, Jul 2, 2014 at 3:13 PM, Corinne Krych wrote: > > On 02 Jul 2014, at 15:10, Matthias Wessendorf wrote: > > > > > > > > > On Wed, Jul 2, 2014 at 2:38 PM, Corinne Krych > wrote: > > > > Good point Sebi, > > > > Let?s launch the discussion on interactive notifications. To support > them (remotely), a new payload need to be added server side, just adding a > category field: > > > > { "aps" : { > > "alert": "you're invited", > > "category": "HelloWorld" > > } > > } > > > > > > Do we have a JIRA for that already ? > > > > Nope > not sure where to add it AGPUSH I guess? > If you create one could you link it to AGIOS-210 epic please > > > > > > in category you should match client side code like in example below: > > > https://github.com/corinnekrych/HelloWorld-Swift/blob/local.notification/HelloWorldSwift/AppDelegate.swift#L60 > > > > I?ve tried interactive notification in HelloWorld sample but tbh I think > Helloworld should stay simple, it might be a better idea to demo them in a > more elaboraten example like: Quickstarts or AeroDoc. > > > > Should we demo them for mobile Push 1.0. > > Waiting for your feedback and bright idea ;) > > > we also need a demo add. Quickstart? > For the Quickstart we need to see how we could introduce this but for Aerodoc it will make perfect sense : Have the feature to accept the Lead from the notification itself, that would be super cool ! > > > > > ++ > > Corinne > > > > Here?s a good reading on interactive notification: > > http://www.imore.com/interactive-notifications-ios-8-explained > > > > On 02 Jul 2014, at 11:43, Sebastien Blanc wrote: > > > > > >> Thanks for this overview ! > >> I can't wait to play with the interactive notifications. > >> > >> > >> > >> On Wed, Jul 2, 2014 at 11:20 AM, Matthias Wessendorf > wrote: > >> Thanks for sharing! > >> > >> I will get on the session731 this afternoon :-) > >> > >> > >> On Wed, Jul 2, 2014 at 10:53 AM, Corinne Krych > wrote: > >> Hello iOS lovers, > >> > >> With WWDC over, we?ve got plenty news stuff coming. We?re pretty > existing about it so I would like to share with you the excitement. > >> If you want to catch up quickly on what?s new, one blog post I really > like and would recommend: > >> http://nshipster.com/ios8/ > >> > >> and if you have more time, if you?re enrolled in iOS dev program and > have Safari opened you can watch the great WWDC videos. > >> In https://developer.apple.com/videos/wwdc/2014/ > >> I would recommend the followings: > >> - swift: session 403, 404, 406, 407, 408 > >> - iOS notification: session 713 > >> > >> The stuff I found most existed about are: > >> - Swift coming: to me, it?s a big win. iOS platform with Swift will be > a killer. Xcode6 with its Playground features and it REPL will be much > easier to play with. > >> - LocalAuthentication Developers can use TouchID APIs. Bin win for > secure offline. > >> - iOS8 interactive notification, increased size > >> - embedded widgets > >> > >> This is a thread to gather all the things you like (or don?t like) > about iOS8. Feel free to add your own comments and feelings. > >> > >> Some interesting tickets to follow: > >> AGIOS-210 - Epic iOS8 notification > >> AGIOS-220 - Epic for Swift (a Swift version of > aerogear-push-ios-registration) > >> > >> ++ > >> Corinne > >> _______________________________________________ > >> aerogear-dev mailing list > >> aerogear-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > >> > >> > >> > >> -- > >> Matthias Wessendorf > >> > >> blog: http://matthiaswessendorf.wordpress.com/ > >> sessions: http://www.slideshare.net/mwessendorf > >> twitter: http://twitter.com/mwessendorf > >> > >> _______________________________________________ > >> aerogear-dev mailing list > >> aerogear-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > >> > >> _______________________________________________ > >> aerogear-dev mailing list > >> aerogear-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > > > > -- > > Matthias Wessendorf > > > > blog: http://matthiaswessendorf.wordpress.com/ > > sessions: http://www.slideshare.net/mwessendorf > > twitter: http://twitter.com/mwessendorf > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140702/ebc69122/attachment.html From corinnekrych at gmail.com Wed Jul 2 09:29:46 2014 From: corinnekrych at gmail.com (Corinne Krych) Date: Wed, 2 Jul 2014 15:29:46 +0200 Subject: [aerogear-dev] iOS8: what's new? In-Reply-To: References: <53F0878C-B864-4CC1-8D70-6768C07D6156@gmail.com> <8EFC9551-FECD-4A46-A838-9D4AAF2828AD@gmail.com> Message-ID: <203E1E9C-FD09-4F61-A428-3A14697BDAD9@gmail.com> Good idea sebi, I?ve just created JIRA to keep track of it server side ticket: https://issues.jboss.org/browse/AGPUSH-764 and AeroDoc one: https://issues.jboss.org/browse/AGIOS-223 ++ Corinne On 02 Jul 2014, at 15:24, Sebastien Blanc wrote: > > > > On Wed, Jul 2, 2014 at 3:13 PM, Corinne Krych wrote: > > On 02 Jul 2014, at 15:10, Matthias Wessendorf wrote: > > > > > > > > > On Wed, Jul 2, 2014 at 2:38 PM, Corinne Krych wrote: > > > > Good point Sebi, > > > > Let?s launch the discussion on interactive notifications. To support them (remotely), a new payload need to be added server side, just adding a category field: > > > > { "aps" : { > > "alert": "you're invited", > > "category": "HelloWorld" > > } > > } > > > > > > Do we have a JIRA for that already ? > > > > Nope > not sure where to add it AGPUSH I guess? > If you create one could you link it to AGIOS-210 epic please > > > > > > in category you should match client side code like in example below: > > https://github.com/corinnekrych/HelloWorld-Swift/blob/local.notification/HelloWorldSwift/AppDelegate.swift#L60 > > > > I?ve tried interactive notification in HelloWorld sample but tbh I think Helloworld should stay simple, it might be a better idea to demo them in a more elaboraten example like: Quickstarts or AeroDoc. > > > > Should we demo them for mobile Push 1.0. > > Waiting for your feedback and bright idea ;) > > > we also need a demo add. Quickstart? > For the Quickstart we need to see how we could introduce this but for Aerodoc it will make perfect sense : > Have the feature to accept the Lead from the notification itself, that would be super cool ! > > > > > > ++ > > Corinne > > > > Here?s a good reading on interactive notification: > > http://www.imore.com/interactive-notifications-ios-8-explained > > > > On 02 Jul 2014, at 11:43, Sebastien Blanc wrote: > > > > > >> Thanks for this overview ! > >> I can't wait to play with the interactive notifications. > >> > >> > >> > >> On Wed, Jul 2, 2014 at 11:20 AM, Matthias Wessendorf wrote: > >> Thanks for sharing! > >> > >> I will get on the session731 this afternoon :-) > >> > >> > >> On Wed, Jul 2, 2014 at 10:53 AM, Corinne Krych wrote: > >> Hello iOS lovers, > >> > >> With WWDC over, we?ve got plenty news stuff coming. We?re pretty existing about it so I would like to share with you the excitement. > >> If you want to catch up quickly on what?s new, one blog post I really like and would recommend: > >> http://nshipster.com/ios8/ > >> > >> and if you have more time, if you?re enrolled in iOS dev program and have Safari opened you can watch the great WWDC videos. > >> In https://developer.apple.com/videos/wwdc/2014/ > >> I would recommend the followings: > >> - swift: session 403, 404, 406, 407, 408 > >> - iOS notification: session 713 > >> > >> The stuff I found most existed about are: > >> - Swift coming: to me, it?s a big win. iOS platform with Swift will be a killer. Xcode6 with its Playground features and it REPL will be much easier to play with. > >> - LocalAuthentication Developers can use TouchID APIs. Bin win for secure offline. > >> - iOS8 interactive notification, increased size > >> - embedded widgets > >> > >> This is a thread to gather all the things you like (or don?t like) about iOS8. Feel free to add your own comments and feelings. > >> > >> Some interesting tickets to follow: > >> AGIOS-210 - Epic iOS8 notification > >> AGIOS-220 - Epic for Swift (a Swift version of aerogear-push-ios-registration) > >> > >> ++ > >> Corinne > >> _______________________________________________ > >> aerogear-dev mailing list > >> aerogear-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > >> > >> > >> > >> -- > >> Matthias Wessendorf > >> > >> blog: http://matthiaswessendorf.wordpress.com/ > >> sessions: http://www.slideshare.net/mwessendorf > >> twitter: http://twitter.com/mwessendorf > >> > >> _______________________________________________ > >> aerogear-dev mailing list > >> aerogear-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > >> > >> _______________________________________________ > >> aerogear-dev mailing list > >> aerogear-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > > > > -- > > Matthias Wessendorf > > > > blog: http://matthiaswessendorf.wordpress.com/ > > sessions: http://www.slideshare.net/mwessendorf > > twitter: http://twitter.com/mwessendorf > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev From kpiwko at redhat.com Wed Jul 2 10:10:05 2014 From: kpiwko at redhat.com (Karel Piwko) Date: Wed, 02 Jul 2014 16:10:05 +0200 Subject: [aerogear-dev] iOS8: what's new? In-Reply-To: References: <53F0878C-B864-4CC1-8D70-6768C07D6156@gmail.com> Message-ID: <1404310205.16123.14.camel@kpiwko-x220> Should we also have Swift registration snippet in UPS Admin UI? On Wed, 2014-07-02 at 15:10 +0200, Matthias Wessendorf wrote: > > > > On Wed, Jul 2, 2014 at 2:38 PM, Corinne Krych > wrote: > > > Good point Sebi, > > Let?s launch the discussion on interactive notifications. To > support them (remotely), a new payload need to be added server > side, just adding a category field: > > > { "aps" : { > "alert": "you're invited", > "category": "HelloWorld" > } > } > > > > > > Do we have a JIRA for that already ? > > > > in category you should match client side code like in example > below: > https://github.com/corinnekrych/HelloWorld-Swift/blob/local.notification/HelloWorldSwift/AppDelegate.swift#L60 > > > I?ve tried interactive notification in HelloWorld sample but > tbh I think Helloworld should stay simple, it might be a > better idea to demo them in a more elaboraten example like: > Quickstarts or AeroDoc. > > > Should we demo them for mobile Push 1.0. > Waiting for your feedback and bright idea ;) > > > ++ > Corinne > > > Here?s a good reading on interactive notification: > http://www.imore.com/interactive-notifications-ios-8-explained > > > On 02 Jul 2014, at 11:43, Sebastien Blanc > wrote: > > > > Thanks for this overview ! > > I can't wait to play with the interactive notifications. > > > > > > > > On Wed, Jul 2, 2014 at 11:20 AM, Matthias > > Wessendorf wrote: > > Thanks for sharing! > > > > I will get on the session731 this afternoon :-) > > > > > > On Wed, Jul 2, 2014 at 10:53 AM, Corinne > > Krych wrote: > > Hello iOS lovers, > > > > With WWDC over, we?ve got plenty news stuff coming. We?re > > pretty existing about it so I would like to share with you > > the excitement. > > If you want to catch up quickly on what?s new, one blog post > > I really like and would recommend: > > http://nshipster.com/ios8/ > > > > and if you have more time, if you?re enrolled in iOS dev > > program and have Safari opened you can watch the great WWDC > > videos. > > In https://developer.apple.com/videos/wwdc/2014/ > > I would recommend the followings: > > - swift: session 403, 404, 406, 407, 408 > > - iOS notification: session 713 > > > > The stuff I found most existed about are: > > - Swift coming: to me, it?s a big win. iOS platform with > > Swift will be a killer. Xcode6 with its Playground features > > and it REPL will be much easier to play with. > > - LocalAuthentication Developers can use TouchID APIs. Bin > > win for secure offline. > > - iOS8 interactive notification, increased size > > - embedded widgets > > > > This is a thread to gather all the things you like (or don?t > > like) about iOS8. Feel free to add your own comments and > > feelings. > > > > Some interesting tickets to follow: > > AGIOS-210 - Epic iOS8 notification > > AGIOS-220 - Epic for Swift (a Swift version of > > aerogear-push-ios-registration) > > > > ++ > > Corinne > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > > > > -- > > Matthias Wessendorf > > > > blog: http://matthiaswessendorf.wordpress.com/ > > sessions: http://www.slideshare.net/mwessendorf > > twitter: http://twitter.com/mwessendorf > > > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev From corinnekrych at gmail.com Wed Jul 2 10:18:13 2014 From: corinnekrych at gmail.com (Corinne Krych) Date: Wed, 2 Jul 2014 16:18:13 +0200 Subject: [aerogear-dev] iOS8: what's new? In-Reply-To: <1404310205.16123.14.camel@kpiwko-x220> References: <53F0878C-B864-4CC1-8D70-6768C07D6156@gmail.com> <1404310205.16123.14.camel@kpiwko-x220> Message-ID: <4C72E298-3D10-471B-9E2D-E029EB0EF3CE@gmail.com> Good point Karel, I?ve added this one to the epic https://issues.jboss.org/browse/AGPUSH-767 ++ Corinne On 02 Jul 2014, at 16:10, Karel Piwko wrote: > Should we also have Swift registration snippet in UPS Admin UI? > > On Wed, 2014-07-02 at 15:10 +0200, Matthias Wessendorf wrote: >> >> >> >> On Wed, Jul 2, 2014 at 2:38 PM, Corinne Krych >> wrote: >> >> >> Good point Sebi, >> >> Let?s launch the discussion on interactive notifications. To >> support them (remotely), a new payload need to be added server >> side, just adding a category field: >> >> >> { "aps" : { >> "alert": "you're invited", >> "category": "HelloWorld" >> } >> } >> >> >> >> >> >> Do we have a JIRA for that already ? >> >> >> >> in category you should match client side code like in example >> below: >> https://github.com/corinnekrych/HelloWorld-Swift/blob/local.notification/HelloWorldSwift/AppDelegate.swift#L60 >> >> >> I?ve tried interactive notification in HelloWorld sample but >> tbh I think Helloworld should stay simple, it might be a >> better idea to demo them in a more elaboraten example like: >> Quickstarts or AeroDoc. >> >> >> Should we demo them for mobile Push 1.0. >> Waiting for your feedback and bright idea ;) >> >> >> ++ >> Corinne >> >> >> Here?s a good reading on interactive notification: >> http://www.imore.com/interactive-notifications-ios-8-explained >> >> >> On 02 Jul 2014, at 11:43, Sebastien Blanc >> wrote: >> >> >>> Thanks for this overview ! >>> I can't wait to play with the interactive notifications. >>> >>> >>> >>> On Wed, Jul 2, 2014 at 11:20 AM, Matthias >>> Wessendorf wrote: >>> Thanks for sharing! >>> >>> I will get on the session731 this afternoon :-) >>> >>> >>> On Wed, Jul 2, 2014 at 10:53 AM, Corinne >>> Krych wrote: >>> Hello iOS lovers, >>> >>> With WWDC over, we?ve got plenty news stuff coming. We?re >>> pretty existing about it so I would like to share with you >>> the excitement. >>> If you want to catch up quickly on what?s new, one blog post >>> I really like and would recommend: >>> http://nshipster.com/ios8/ >>> >>> and if you have more time, if you?re enrolled in iOS dev >>> program and have Safari opened you can watch the great WWDC >>> videos. >>> In https://developer.apple.com/videos/wwdc/2014/ >>> I would recommend the followings: >>> - swift: session 403, 404, 406, 407, 408 >>> - iOS notification: session 713 >>> >>> The stuff I found most existed about are: >>> - Swift coming: to me, it?s a big win. iOS platform with >>> Swift will be a killer. Xcode6 with its Playground features >>> and it REPL will be much easier to play with. >>> - LocalAuthentication Developers can use TouchID APIs. Bin >>> win for secure offline. >>> - iOS8 interactive notification, increased size >>> - embedded widgets >>> >>> This is a thread to gather all the things you like (or don?t >>> like) about iOS8. Feel free to add your own comments and >>> feelings. >>> >>> Some interesting tickets to follow: >>> AGIOS-210 - Epic iOS8 notification >>> AGIOS-220 - Epic for Swift (a Swift version of >>> aerogear-push-ios-registration) >>> >>> ++ >>> Corinne >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >>> >>> >>> -- >>> Matthias Wessendorf >>> >>> blog: http://matthiaswessendorf.wordpress.com/ >>> sessions: http://www.slideshare.net/mwessendorf >>> twitter: http://twitter.com/mwessendorf >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> >> >> -- >> Matthias Wessendorf >> >> blog: http://matthiaswessendorf.wordpress.com/ >> sessions: http://www.slideshare.net/mwessendorf >> twitter: http://twitter.com/mwessendorf >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev From vivek.pandey at pinelabs.com Wed Jul 2 10:40:39 2014 From: vivek.pandey at pinelabs.com (Vivek Pandey) Date: Wed, 2 Jul 2014 20:10:39 +0530 Subject: [aerogear-dev] UPS Production worthiness In-Reply-To: References: <002b01cf7424$528dc0a0$f7a941e0$@pinelabs.com> <005d01cf74ed$3d977140$b8c653c0$@pinelabs.com> <003c01cf78cd$1095df40$31c19dc0$@pinelabs.com> <17C1B903-C13B-482F-93FA-1B9B55AEF707@redhat.com> Message-ID: <008f01cf9603$9cf11fb0$d6d35f10$@pinelabs.com> Hello Matthias, An ?importer? might help, but smaller changes in existing domain/service might help more. I ran a stress test on the installation endpoint yesterday, after merging Eric?s changes on source code of 0.10.x branch. I saw that even after using the merged code, the response worsened continuously. Looking closing, I saw that GenericVariantServiceImpl. addInstallation causes initialization of the now ?lazy? collection AbstractVariant.installations. I changed the model a bit, by adding variantID to Installation, and made it the owner of the variant-installation relationship. That changed the code in InstallationRegistrationEndpoint. registerInstallation from // store the installation: entity = clientInstallationService.addInstallation(entity); // add installation to the matching variant genericVariantService.addInstallation(variant, entity); to // store the installation: entity.setVariantID(variant); entity = clientInstallationService.addInstallation(entity); This fixed the problem for me and now I am getting constant time installation registration with dramatically better performance Please let me know if you want me to add this to AGPUSH-661 Thanks Vivek From: mwessendorf at gmail.com [mailto:mwessendorf at gmail.com] On Behalf Of Matthias Wessendorf Sent: Wednesday, July 02, 2014 6:26 PM To: AeroGear Developer Mailing List; vivek.pandey at pinelabs.com Subject: Re: [aerogear-dev] UPS Production worthiness Hello Vivek, On Mon, May 26, 2014 at 1:23 PM, Matthias Wessendorf wrote: On Mon, May 26, 2014 at 12:59 PM, Erik Jan de Wit wrote: Hi Vivek, We?ve fixed that https://github.com/aerogear/aerogear-unifiedpush-server/commit/1357c9e834286a9227a90e9ab618226aa54bbbf3 the collection is now lazy. But I?m sure other query optimisations can be made. +1 btw. Vivek, I added your mail to an existing ticket: https://issues.jboss.org/browse/AGPUSH-661 coming back from vacation and going over the JIRAs, I was wondering if an 'importer' helps? That would be a RESTful endpoint that accepts a JSON file, containing all the devices you want to register (for a given variant). That way it would be also a bit nicer on your side, to perform the import: * generate a "large" JSON file (instead of a ton of requests) * only one HTTP request * server accepts and will process it in the background I think that would be a nice migration tool. Let me know what you think! -Matthias -Matthias Cheers, Erik Jan On 26 May,2014, at 12:27 , Vivek Pandey wrote: Hi Matthias, It is good to know that activity in java-apns is picking up and also that you are looking at pushy. I did a few tests which added installations to UPS with a concurrency of 4-8 threads. I was using Postgres 9.3 and UPS 0.10.3 war I noticed that response slowed down considerably after some time with high CPU usage and continued to get worse. After doing some profiling, I found that bulk of CPU cycles are being taken by org.postgresql.core.VisibleBufferedInputStream.readMore. The entire thread stack is attached. Also postgres continuously flagged select installati0_.variantID as variant10_0_0_, installati0_.id as id1_3_0_, installati0_.id as id1_3_1_, installati0_.alias as alias2_3_1_, installati0_.deviceToken as deviceTo3_3_1_, installati0_.deviceType as deviceTy4_3_1_, installati0_.enabled as enabled5_3_1_, installati0_.operatingSystem as operatin6_3_1_, installati0_.osVersion as osVersio7_3_1_, installati0_.platform as platform8_3_1_, installati0_.simplePushEndpoint as simplePu9_3_1_ from InstallationImpl installati0_ where installati0_.variantID=$1 as the slow query. I am pretty sure that eager collection AbstractVariant.installations is the root cause of the problem. Please let me know if you need any more information. Thanks Vivek From: mwessendorf at gmail.com [ mailto:mwessendorf at gmail.com] On Behalf Of Matthias Wessendorf Sent: Wednesday, May 21, 2014 5:55 PM To: vivek.pandey at pinelabs.com; AeroGear Developer Mailing List Subject: Re: [aerogear-dev] UPS Production worthiness Hello Vivek! On Wed, May 21, 2014 at 2:07 PM, Vivek Pandey < vivek.pandey at pinelabs.com> wrote: Hi Jay, Thanks for your reply. While we have not faced any issues in using UPS in our limited testing, I often see info stacktraces in ups logs 2014-05-16 10:19:20,032 INFO [com.notnoop.apns.internal.ApnsConnectionImpl] (Thread-118) Exception while waiting for error code: java.net.SocketException: Socket closed at java.net.SocketInputStream.socketRead0(Native Method) [rt.jar:1.7.0_51] at java.net.SocketInputStream.read(SocketInputStream.java:152) [rt.jar:1.7.0_51] at java.net.SocketInputStream.read(SocketInputStream.java:122) [rt.jar:1.7.0_51] ????? at com.notnoop.apns.internal.ApnsConnectionImpl$1MonitoringThread.run(ApnsConnectionImpl.java:114) [apns-0.2.3.jar:] These stacktraces coupled with low dev activity of noop/java-apns project are disconcerting to me. the stack-trace is no harm - it's only happening w/ doing a monitoring of the thread (that's what we currently do, when setting up ApnsService - I thought about explicitly disable that) The activity of the underlying java-apns is very low, yes! However @froh42 is getting back: https://github.com/notnoop/java-apns/commits/master There will be a new release in the near future; @froh42 asked me if I could help with pushing the bits to maven central That said, I recently started looking at pushy: https://github.com/relayrides/pushy I also sent a PR that would allow us to feed pushy w/ our certificate from the database: https://github.com/relayrides/pushy/pull/87 Hope that helps -Matthias I am currently using UPS 0.10.2 war. Thanks, Vivek From: Jay Balunas [mailto: jbalunas at redhat.com] Sent: Tuesday, May 20, 2014 11:36 PM To: vivek.pandey at pinelabs.com; AeroGear Developer Mailing List Cc: Jay Balunas Subject: Re: [aerogear-dev] UPS Production worthiness Hi Vivek, It's awesome to hear that you have integrated the UPS into your backend systems and some of your mobile apps! We have a lot of confidence around the UPS, its functionality, and performance. Our team has been working hard on improvements and stability including our QE team. Also, as you may have seen we're planning a 1.0 release of the UPS this summer. However at this time we don't have specific references or success stories outside of what you can see in the community mailing lists - other users using it ;-) We're also about to kick off some performance and scale testing in the next couple of months. Have you run into any issues that drove these questions about production worthiness? If so please let us know and we'll certainly take a look. Hope this helps! Thanks, Jay Balunas On May 20, 2014, at 8:09 AM, Vivek Pandey < vivek.pandey at pinelabs.com> wrote: Hello Aerogear dev team, We integrated UPS into our backend server which is serving various mobile apps. While the development and testing phase went well, my manager is questioning me about production worthiness about Aerogear. It would be great help if you could point me to references/success stories where UPS is being used in production environments and scaling well in medium to high loads. Thanks, Vivek _____ This message may contain privileged and confidential information and is solely for the use of intended recipient. The views expressed in this email are those of the sender and not of Pine Labs. The recipient should check this email and attachments for the presence of viruses / malwares etc. Pine Labs accepts no liability for any damage caused by any virus transmitted by this email. Pine Labs may monitor and record all emails. _____ _______________________________________________ aerogear-dev mailing list aerogear-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev _____ This message may contain privileged and confidential information and is solely for the use of intended recipient. The views expressed in this email are those of the sender and not of Pine Labs. The recipient should check this email and attachments for the presence of viruses / malwares etc. Pine Labs accepts no liability for any damage caused by any virus transmitted by this email. Pine Labs may monitor and record all emails. _____ _______________________________________________ aerogear-dev mailing list aerogear-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf _____ This message may contain privileged and confidential information and is solely for the use of intended recipient. The views expressed in this email are those of the sender and not of Pine Labs. The recipient should check this email and attachments for the presence of viruses / malwares etc. Pine Labs accepts no liability for any damage caused by any virus transmitted by this email. Pine Labs may monitor and record all emails. _____ _______________________________________________ aerogear-dev mailing list aerogear-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev _______________________________________________ aerogear-dev mailing list aerogear-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf This message may contain privileged and confidential information and is solely for the use of intended recipient. The views expressed in this email are those of the sender and not of Pine Labs. The recipient should check this email and attachments for the presence of viruses / malwares etc. Pine Labs accepts no liability for any damage caused by any virus transmitted by this email. Pine Labs may monitor and record all emails. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140702/c698370c/attachment-0001.html From matzew at apache.org Wed Jul 2 10:45:06 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Wed, 2 Jul 2014 16:45:06 +0200 Subject: [aerogear-dev] UPS Production worthiness In-Reply-To: <008f01cf9603$9cf11fb0$d6d35f10$@pinelabs.com> References: <002b01cf7424$528dc0a0$f7a941e0$@pinelabs.com> <005d01cf74ed$3d977140$b8c653c0$@pinelabs.com> <003c01cf78cd$1095df40$31c19dc0$@pinelabs.com> <17C1B903-C13B-482F-93FA-1B9B55AEF707@redhat.com> <008f01cf9603$9cf11fb0$d6d35f10$@pinelabs.com> Message-ID: Hello vivek! thanks for the reply! Absolutely a PR is more than welcome! If you have interest and the bandwidth, we would really appreciate that ! @importer: I still think it's a nice thing to have :-) -Matthias On Wed, Jul 2, 2014 at 4:40 PM, Vivek Pandey wrote: > Hello Matthias, > > > > An ?importer? might help, but smaller changes in existing domain/service > might help more. > > I ran a stress test on the installation endpoint yesterday, after merging > Eric?s changes on source code of 0.10.x branch. > > I saw that even after using the merged code, the response worsened > continuously. > > Looking closing, I saw that GenericVariantServiceImpl. addInstallation > causes initialization of the now ?lazy? collection > AbstractVariant.installations. > > > > I changed the model a bit, by adding variantID to Installation, and made > it the owner of the variant-installation relationship. > > That changed the code in InstallationRegistrationEndpoint. registerInstallation > from > > // store the installation: > > entity = clientInstallationService.addInstallation(entity); > > // add installation to the matching variant > > genericVariantService.addInstallation(variant, entity); > > > > to > > // store the installation: > > > entity.setVariantID(variant); > > entity = > clientInstallationService.addInstallation(entity); > > > > This fixed the problem for me and now I am getting constant time > installation registration with dramatically better performance > > > > Please let me know if you want me to add this to AGPUSH-661 > > > > Thanks > > Vivek > > > > *From:* mwessendorf at gmail.com [mailto:mwessendorf at gmail.com] *On Behalf > Of *Matthias Wessendorf > *Sent:* Wednesday, July 02, 2014 6:26 PM > *To:* AeroGear Developer Mailing List; vivek.pandey at pinelabs.com > > *Subject:* Re: [aerogear-dev] UPS Production worthiness > > > > Hello Vivek, > > > > On Mon, May 26, 2014 at 1:23 PM, Matthias Wessendorf > wrote: > > > > > > On Mon, May 26, 2014 at 12:59 PM, Erik Jan de Wit > wrote: > > Hi Vivek, > > > > We?ve fixed that > https://github.com/aerogear/aerogear-unifiedpush-server/commit/1357c9e834286a9227a90e9ab618226aa54bbbf3 the > collection is now lazy. But I?m sure other query optimisations can be made. > > > > +1 > > > > btw. Vivek, I added your mail to an existing ticket: > > https://issues.jboss.org/browse/AGPUSH-661 > > > > > > coming back from vacation and going over the JIRAs, I was wondering if an > 'importer' helps? > > > > That would be a RESTful endpoint that accepts a JSON file, containing all > the devices you want to register (for a given variant). > > > > That way it would be also a bit nicer on your side, to perform the import: > > * generate a "large" JSON file (instead of a ton of requests) > > * only one HTTP request > > * server accepts and will process it in the background > > > > I think that would be a nice migration tool. > > > > Let me know what you think! > > > > -Matthias > > > > > > -Matthias > > > > > > Cheers, > > Erik Jan > > > > On 26 May,2014, at 12:27 , Vivek Pandey wrote: > > > > Hi Matthias, > > > > It is good to know that activity in java-apns is picking up and also that > you are looking at pushy. > > > > I did a few tests which added installations to UPS with a concurrency of > 4-8 threads. I was using Postgres 9.3 and UPS 0.10.3 war > > > > I noticed that response slowed down considerably after some time with high > CPU usage and continued to get worse. After doing some profiling, I found > that bulk of CPU cycles are being taken by > org.postgresql.core.VisibleBufferedInputStream.readMore. The entire thread > stack is attached. Also postgres continuously flagged > > > > select installati0_.variantID as variant10_0_0_, installati0_.id as > id1_3_0_, installati0_.id as id1_3_1_, installati0_.alias as alias2_3_1_, > installati0_.deviceToken as deviceTo3_3_1_, installati0_.deviceType as > deviceTy4_3_1_, installati0_.enabled as enabled5_3_1_, > installati0_.operatingSystem as operatin6_3_1_, installati0_.osVersion as > osVersio7_3_1_, installati0_.platform as platform8_3_1_, > installati0_.simplePushEndpoint as simplePu9_3_1_ from InstallationImpl > installati0_ where installati0_.variantID=$1 > > > > as the slow query. I am pretty sure that eager collection > AbstractVariant.installations is the root cause of the problem. > > > > Please let me know if you need any more information. > > > > Thanks > > Vivek > > > > *From:* mwessendorf at gmail.com [mailto:mwessendorf at gmail.com > ] *On Behalf Of *Matthias Wessendorf > *Sent:* Wednesday, May 21, 2014 5:55 PM > *To:* vivek.pandey at pinelabs.com; AeroGear Developer Mailing List > *Subject:* Re: [aerogear-dev] UPS Production worthiness > > > > Hello Vivek! > > > > On Wed, May 21, 2014 at 2:07 PM, Vivek Pandey > wrote: > > Hi Jay, > > > > Thanks for your reply. > > > > While we have not faced any issues in using UPS in our limited testing, I > often see info stacktraces in ups logs > > > > 2014-05-16 10:19:20,032 INFO > [com.notnoop.apns.internal.ApnsConnectionImpl] (Thread-118) Exception while > waiting for error code: java.net.SocketException: Socket closed > > at java.net.SocketInputStream.socketRead0(Native Method) > [rt.jar:1.7.0_51] > > at java.net.SocketInputStream.read(SocketInputStream.java:152) > [rt.jar:1.7.0_51] > > at java.net.SocketInputStream.read(SocketInputStream.java:122) > [rt.jar:1.7.0_51] > > ????? > > at > com.notnoop.apns.internal.ApnsConnectionImpl$1MonitoringThread.run(ApnsConnectionImpl.java:114) > [apns-0.2.3.jar:] > > > > > > These stacktraces coupled with low dev activity of noop/java-apns project > are disconcerting to me. > > > > the stack-trace is no harm - it's only happening w/ doing a monitoring of > the thread (that's what we currently do, when setting up ApnsService - I > thought about explicitly disable that) > > > > The activity of the underlying java-apns is very low, yes! However @froh42 > is getting back: > > https://github.com/notnoop/java-apns/commits/master > > > > There will be a new release in the near future; @froh42 asked me if I > could help with pushing the bits to maven central > > > > > > That said, I recently started looking at pushy: > > https://github.com/relayrides/pushy > > > > I also sent a PR that would allow us to feed pushy w/ our certificate from > the database: > > https://github.com/relayrides/pushy/pull/87 > > > > Hope that helps > > -Matthias > > > > > > I am currently using UPS 0.10.2 war. > > > > Thanks, > > Vivek > > *From:* Jay Balunas [mailto:jbalunas at redhat.com] > *Sent:* Tuesday, May 20, 2014 11:36 PM > *To:* vivek.pandey at pinelabs.com; AeroGear Developer Mailing List > *Cc:* Jay Balunas > *Subject:* Re: [aerogear-dev] UPS Production worthiness > > > > Hi Vivek, > > > > It's awesome to hear that you have integrated the UPS into your backend > systems and some of your mobile apps! > > > > We have a lot of confidence around the UPS, its functionality, and > performance. Our team has been working hard on improvements and stability > including our QE team. Also, as you may have seen we're planning a 1.0 > release of the UPS this summer. > > > > However at this time we don't have specific references or success stories > outside of what you can see in the community mailing lists - other users > using it ;-) We're also about to kick off some performance and scale > testing in the next couple of months. > > > > Have you run into any issues that drove these questions about production > worthiness? If so please let us know and we'll certainly take a look. > > > > Hope this helps! > > > > Thanks, > > Jay Balunas > > > > On May 20, 2014, at 8:09 AM, Vivek Pandey > wrote: > > > > Hello Aerogear dev team, > > > > We integrated UPS into our backend server which is serving various mobile > apps. While the development and testing phase went well, my manager is > questioning me about production worthiness about Aerogear. It would be > great help if you could point me to references/success stories where UPS is > being used in production environments and scaling well in medium to high > loads. > > > > Thanks, > > Vivek > > > > > > > ------------------------------ > > This message may contain privileged and confidential information and is > solely for the use of intended recipient. The views expressed in this email > are those of the sender and not of Pine Labs. The recipient should check > this email and attachments for the presence of viruses / malwares etc. Pine > Labs accepts no liability for any damage caused by any virus transmitted by > this email. Pine Labs may monitor and record all emails. > ------------------------------ > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > ------------------------------ > > This message may contain privileged and confidential information and is > solely for the use of intended recipient. The views expressed in this email > are those of the sender and not of Pine Labs. The recipient should check > this email and attachments for the presence of viruses / malwares etc. Pine > Labs accepts no liability for any damage caused by any virus transmitted by > this email. Pine Labs may monitor and record all emails. > ------------------------------ > > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > > > ------------------------------ > > This message may contain privileged and confidential information and is > solely for the use of intended recipient. The views expressed in this email > are those of the sender and not of Pine Labs. The recipient should check > this email and attachments for the presence of viruses / malwares etc. Pine > Labs accepts no liability for any damage caused by any virus transmitted by > this email. Pine Labs may monitor and record all emails. > ------------------------------ > > > > _______________________________________________ > > > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > > > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > > ------------------------------ > This message may contain privileged and confidential information and is > solely for the use of intended recipient. The views expressed in this email > are those of the sender and not of Pine Labs. The recipient should check > this email and attachments for the presence of viruses / malwares etc. Pine > Labs accepts no liability for any damage caused by any virus transmitted by > this email. Pine Labs may monitor and record all emails. > ------------------------------ > > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140702/c201df7d/attachment-0001.html From matzew at apache.org Wed Jul 2 14:09:16 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Wed, 2 Jul 2014 20:09:16 +0200 Subject: [aerogear-dev] Aerogear - The UnifiedPush Server on Glassfish In-Reply-To: References: <64b09d313cac4d468b7da713918d3897@ServerMail2.ids-unitelm.it> Message-ID: Hello Giuseppe, I got a reply on that bug from the PicketLink team a few days ago. Based on their suggestion I am _trying_ to override the included PL dependecies on a branch: https://github.com/aerogear/aerogear-unifiedpush-server/tree/0.10.x_PLINK_override Do you mind to build this branch and see if you can deploy the build WAR file to your configured Glassfish container ? Thanks! Matthias On Thu, Jun 26, 2014 at 4:22 PM, Giuseppe Sciacca < giuseppe.sciacca at gmail.com> wrote: > thank's > > Giuseppe. > > 2014-06-26 13:55 GMT+02:00 Matthias Wessendorf : > > Hello Giuseppe, > > > > here is the PicketLink bug: > > https://issues.jboss.org/browse/PLINK-514 > > > > -Matthias > > > > > > > > On Thu, Jun 26, 2014 at 7:37 AM, Matthias Wessendorf > > wrote: > >> > >> Hello Giuseppe! > >> > >> thanks for reporting the issue. In the 0.10.x series we are using > >> Picketlink for security (mainly auth of the user), but it looks like the > >> version we are using has an issue w/ EclipseLink that is used as > Glassfish's > >> JPA Provider. I will report that issue to the Picketlink team. Perhaps > there > >> is a way to get a patched version of the 0.10x series. We will keep you > >> posted. > >> > >> > >> On the master branch (0.11.x) series we are no longer using Picketlink, > we > >> are using Keycloak, but I don't see a Glassfish adapter for Keycloak at > the > >> moment. > >> > >> > >> Besides these issues, there is still an option to use the UnifiedPush > >> Server: > >> * On the cloud, via OpenShift (it's free to get an OpenShift account) > >> * Via JBoss AS / EAP > >> > >> Hope that helps for now > >> > >> -Matthias > >> > >> > >> > >> > >> > >> On Thu, Jun 26, 2014 at 3:54 AM, Giuseppe Sciacca > >> wrote: > >>> > >>> Hi Matthias, > >>> > >>> > >>> > >>> > >>> > >>> thank's for all. > >>> > >>> > >>> > >>> this is a part of my log :( > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > [#|2014-06-26T09:39:19.315+0200|SEVERE|glassfish3.1.2|javax.enterprise.system.tools.admin.org.glassfish.deployment.admin|_ThreadID=45;_ThreadName=Thread-2;|Exception > >>> while visiting > org/jboss/aerogear/security/auth/AuthenticationManager.class > >>> of size 335 > >>> > >>> java.lang.NullPointerException > >>> > >>> at > >>> > org.glassfish.hk2.classmodel.reflect.impl.TypesImpl.getType(TypesImpl.java:78) > >>> > >>> at > >>> > org.glassfish.hk2.classmodel.reflect.impl.ModelClassVisitor.visit(ModelClassVisitor.java:119) > >>> > >>> at org.objectweb.asm.ClassReader.accept(Unknown Source) > >>> > >>> at org.objectweb.asm.ClassReader.accept(Unknown Source) > >>> > >>> at > >>> org.glassfish.hk2.classmodel.reflect.Parser$5.on(Parser.java:363) > >>> > >>> at > >>> > com.sun.enterprise.v3.server.ReadableArchiveScannerAdapter.handleEntry(ReadableArchiveScannerAdapter.java:171) > >>> > >>> at > >>> > com.sun.enterprise.v3.server.ReadableArchiveScannerAdapter.onSelectedEntries(ReadableArchiveScannerAdapter.java:133) > >>> > >>> at > >>> org.glassfish.hk2.classmodel.reflect.Parser.doJob(Parser.java:348) > >>> > >>> at > >>> org.glassfish.hk2.classmodel.reflect.Parser.access$300(Parser.java:70) > >>> > >>> at > >>> org.glassfish.hk2.classmodel.reflect.Parser$3.call(Parser.java:307) > >>> > >>> at > >>> org.glassfish.hk2.classmodel.reflect.Parser$3.call(Parser.java:296) > >>> > >>> at > >>> java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) > >>> > >>> at java.util.concurrent.FutureTask.run(FutureTask.java:166) > >>> > >>> at > >>> > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) > >>> > >>> at > >>> > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) > >>> > >>> at java.lang.Thread.run(Thread.java:722) > >>> > >>> > >>> > >>> ...... > >>> > >>> > >>> > >>> > >>> > >>> > >>> > [#|2014-06-26T09:39:22.564+0200|SEVERE|glassfish3.1.2|javax.enterprise.system.core.com.sun.enterprise.v3.server|_ThreadID=44;_ThreadName=Thread-2;|Exception > >>> [EclipseLink-28018] (Eclipse Persistence Services - > 2.3.2.v20111125-r10461): > >>> org.eclipse.persistence.exceptions.EntityManagerSetupException > >>> > >>> Exception Description: Predeployment of PersistenceUnit > >>> [picketlink-default] failed. > >>> > >>> Internal Exception: Exception [EclipseLink-7212] (Eclipse Persistence > >>> Services - 2.3.2.v20111125-r10461): > >>> org.eclipse.persistence.exceptions.ValidationException > >>> > >>> Exception Description: The attribute [expiryDate] from the entity class > >>> [class > >>> > org.picketlink.idm.jpa.model.sample.simple.AbstractCredentialTypeEntity] > >>> does not specify a temporal type. A temporal type must be specified for > >>> persistent fields or properties of type java.util.Date and > >>> java.util.Calendar. > >>> > >>> javax.persistence.PersistenceException: Exception [EclipseLink-28018] > >>> (Eclipse Persistence Services - 2.3.2.v20111125-r10461): > >>> org.eclipse.persistence.exceptions.EntityManagerSetupException > >>> > >>> Exception Description: Predeployment of PersistenceUnit > >>> [picketlink-default] failed. > >>> > >>> Internal Exception: Exception [EclipseLink-7212] (Eclipse Persistence > >>> Services - 2.3.2.v20111125-r10461): > >>> org.eclipse.persistence.exceptions.ValidationException > >>> > >>> Exception Description: The attribute [expiryDate] from the entity class > >>> [class > >>> > org.picketlink.idm.jpa.model.sample.simple.AbstractCredentialTypeEntity] > >>> does not specify a temporal type. A temporal type must be specified for > >>> persistent fields or properties of type java.util.Date and > >>> java.util.Calendar. > >>> > >>> at > >>> > org.eclipse.persistence.internal.jpa.EntityManagerSetupImpl.predeploy(EntityManagerSetupImpl.java:1402) > >>> > >>> at > >>> > org.eclipse.persistence.jpa.PersistenceProvider.createContainerEntityManagerFactory(PersistenceProvider.java:208) > >>> > >>> at > >>> > org.glassfish.persistence.jpa.PersistenceUnitLoader.loadPU(PersistenceUnitLoader.java:206) > >>> > >>> at > >>> > org.glassfish.persistence.jpa.PersistenceUnitLoader.(PersistenceUnitLoader.java:120) > >>> > >>> .... > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> Greetings, > >>> > >>> Giuseppe > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> hello Giuseppe! > >>> > >>> > >>> > >>> thanks for the interest in the UnifiedPush Server. Since it is standard > >>> JavaEE, it should be working in Glassfish. > >>> > >>> However you need to configure a datasource (e.g. MySQL) inside of > >>> Glassfish. Here is the details about our DS name: > >>> > >>> > >>> > https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/model/jpa/src/main/resources/META-INF/persistence.xml#L23 > >>> > >>> > >>> > >>> > >>> > >>> Did you give it a try? If there are any issues, please report them > here, > >>> so that we can help :) > >>> > >>> > >>> > >>> Greetings, > >>> > >>> Matthias > >>> > >>> > >>> > >>> > >>> > >>> On Wed, Jun 25, 2014 at 10:24 AM, Giuseppe Sciacca < > g.sciacca at glauco.it> > >>> wrote: > >>> > >>> Hi, > >>> > >>> sorry for my english :P > >>> > >>> > >>> > >>> "The UnifiedPush Server on Glassfish" > >>> > >>> > >>> > >>> it's possible ? > >>> > >>> is there some tutorial? > >>> > >>> > >>> > >>> > >>> > >>> thank's a lot > >>> > >>> > >>> > >>> GiuScia > >>> > >>> > >>> _______________________________________________ > >>> aerogear-dev mailing list > >>> aerogear-dev at lists.jboss.org > >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev > >>> > >>> > >>> > >>> > >>> > >>> -- > >>> Matthias Wessendorf > >>> > >>> blog: http://matthiaswessendorf.wordpress.com/ > >>> sessions: http://www.slideshare.net/mwessendorf > >>> twitter: http://twitter.com/mwessendorf > >>> > >>> > >>> _______________________________________________ > >>> aerogear-dev mailing list > >>> aerogear-dev at lists.jboss.org > >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev > >>> > >>> > >>> _______________________________________________ > >>> aerogear-dev mailing list > >>> aerogear-dev at lists.jboss.org > >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev > >> > >> > >> > >> > >> -- > >> Matthias Wessendorf > >> > >> blog: http://matthiaswessendorf.wordpress.com/ > >> sessions: http://www.slideshare.net/mwessendorf > >> twitter: http://twitter.com/mwessendorf > > > > > > > > > > -- > > Matthias Wessendorf > > > > blog: http://matthiaswessendorf.wordpress.com/ > > sessions: http://www.slideshare.net/mwessendorf > > twitter: http://twitter.com/mwessendorf > > > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > -- > Giuseppe Sciacca > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140702/5e2dedc5/attachment.html From scm.blanc at gmail.com Thu Jul 3 05:18:35 2014 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Thu, 3 Jul 2014 11:18:35 +0200 Subject: [aerogear-dev] [RELEASE] aerogear-simplepush-java-client 0.1.0 Message-ID: Folks ! I'm happy to announce that aerogear-simplepush-java-client 0.1.0 has been staged. The big change is that we are now relying on Matzew's Java Simple WebSocket Client[1] and that we have an extended test suite which test this library against : Tyrus, Netty, Vertx and Undertow ! Wondering what you can do with this library ? Basically any Device that can run the JVM can now receive Push Notifications through the SimplePush Protocol. For instance, receiving Push Notifications on your Raspberry PI : https://www.youtube.com/watch?v=PpPNSu2ENUA Or on a Lego EV3 Robot : https://www.youtube.com/watch?v=4uqfcqq42es A lot of other feature are possible, like an Eclipse Plugin to receive notification in your IDE. This library has also full support for the AeroGear UnifiedPush Server, meaning it can register to it ! Have fun and go crazy, the staging repository is located here : https://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-3507 Sebi [1]https://github.com/matzew/simple-websocket-client -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140703/d8accbb8/attachment-0001.html From bsutter at redhat.com Thu Jul 3 08:11:07 2014 From: bsutter at redhat.com (Burr Sutter) Date: Thu, 3 Jul 2014 08:11:07 -0400 Subject: [aerogear-dev] iOS8: what's new? In-Reply-To: References: Message-ID: <60CD36F8-B21C-4343-99E5-09C447226542@redhat.com> A couple that I noticed (only a few minutes of scanning the headlines) - WKWebView - a lot of native apps leverage the webview, not just Cordova - to show docs as an example - NSQualityOfService - might be the way to address backgrounded tasks like checking for some data to sync? On Jul 2, 2014, at 4:53 AM, Corinne Krych wrote: > Hello iOS lovers, > > With WWDC over, we?ve got plenty news stuff coming. We?re pretty existing about it so I would like to share with you the excitement. > If you want to catch up quickly on what?s new, one blog post I really like and would recommend: > http://nshipster.com/ios8/ > > and if you have more time, if you?re enrolled in iOS dev program and have Safari opened you can watch the great WWDC videos. > In https://developer.apple.com/videos/wwdc/2014/ > I would recommend the followings: > - swift: session 403, 404, 406, 407, 408 > - iOS notification: session 713 > > The stuff I found most existed about are: > - Swift coming: to me, it?s a big win. iOS platform with Swift will be a killer. Xcode6 with its Playground features and it REPL will be much easier to play with. > - LocalAuthentication Developers can use TouchID APIs. Bin win for secure offline. > - iOS8 interactive notification, increased size > - embedded widgets > > This is a thread to gather all the things you like (or don?t like) about iOS8. Feel free to add your own comments and feelings. > > Some interesting tickets to follow: > AGIOS-210 - Epic iOS8 notification > AGIOS-220 - Epic for Swift (a Swift version of aerogear-push-ios-registration) > > ++ > Corinne > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev From cvasilak at gmail.com Thu Jul 3 08:30:20 2014 From: cvasilak at gmail.com (Christos Vasilakis) Date: Thu, 3 Jul 2014 15:30:20 +0300 Subject: [aerogear-dev] iOS8: what's new? In-Reply-To: <60CD36F8-B21C-4343-99E5-09C447226542@redhat.com> References: <60CD36F8-B21C-4343-99E5-09C447226542@redhat.com> Message-ID: <8F010C6E-6233-4659-8293-C94F49CBE7C4@gmail.com> > On Jul 3, 2014, at 3:11 PM, Burr Sutter wrote: > > A couple that I noticed (only a few minutes of scanning the headlines) > - WKWebView - a lot of native apps leverage the webview, not just Cordova - to show docs as an example yeap a long-awaited feature finally settled..at last > - NSQualityOfService - might be the way to address backgrounded tasks like checking for some data to sync? it could be, basically replaces an old ?threadPriority' property attached to an operation which much be settled manually (0.0 to 1.0) with more fine grained and expressive values e.g NSOperationQualityOfServiceBackground, NSOperationQualityOfServiceUserInitiated.. etc - Christos > > > On Jul 2, 2014, at 4:53 AM, Corinne Krych wrote: > >> Hello iOS lovers, >> >> With WWDC over, we?ve got plenty news stuff coming. We?re pretty existing about it so I would like to share with you the excitement. >> If you want to catch up quickly on what?s new, one blog post I really like and would recommend: >> http://nshipster.com/ios8/ >> >> and if you have more time, if you?re enrolled in iOS dev program and have Safari opened you can watch the great WWDC videos. >> In https://developer.apple.com/videos/wwdc/2014/ >> I would recommend the followings: >> - swift: session 403, 404, 406, 407, 408 >> - iOS notification: session 713 >> >> The stuff I found most existed about are: >> - Swift coming: to me, it?s a big win. iOS platform with Swift will be a killer. Xcode6 with its Playground features and it REPL will be much easier to play with. >> - LocalAuthentication Developers can use TouchID APIs. Bin win for secure offline. >> - iOS8 interactive notification, increased size >> - embedded widgets >> >> This is a thread to gather all the things you like (or don?t like) about iOS8. Feel free to add your own comments and feelings. >> >> Some interesting tickets to follow: >> AGIOS-210 - Epic iOS8 notification >> AGIOS-220 - Epic for Swift (a Swift version of aerogear-push-ios-registration) >> >> ++ >> Corinne >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev From corinnekrych at gmail.com Thu Jul 3 08:56:59 2014 From: corinnekrych at gmail.com (Corinne Krych) Date: Thu, 3 Jul 2014 14:56:59 +0200 Subject: [aerogear-dev] iOS8: what's new? In-Reply-To: <8F010C6E-6233-4659-8293-C94F49CBE7C4@gmail.com> References: <60CD36F8-B21C-4343-99E5-09C447226542@redhat.com> <8F010C6E-6233-4659-8293-C94F49CBE7C4@gmail.com> Message-ID: Another long-awaited feature is widget. In iOS8 they come as Extensions. A cool article on 1Password and how they use extension in iOS8: http://www.cultofmac.com/285764/1password-touch-id-integration-ios-8-truly-amazing/ Session to watch ion in WWDC: https://developer.apple.com/videos/wwdc/2014/ session 205, 217 ?Creating extensions for iOS and OSX part1/2 A could blog post going in more details: http://www.glimsoft.com/06/28/ios-8-today-extension-tutorial/ We could actually do a Share extension for our cookbook app Shoot?nShare that allow uploading pictures (to a bunch of social network) in the background if already logged in otherwise bring shoot app settings in foreground. Let me track that on Oauth2 Epic... ++ Corinne On 03 Jul 2014, at 14:30, Christos Vasilakis wrote: >> >> On Jul 3, 2014, at 3:11 PM, Burr Sutter wrote: >> >> A couple that I noticed (only a few minutes of scanning the headlines) >> - WKWebView - a lot of native apps leverage the webview, not just Cordova - to show docs as an example > > yeap a long-awaited feature finally settled..at last > >> - NSQualityOfService - might be the way to address backgrounded tasks like checking for some data to sync? > > it could be, > basically replaces an old ?threadPriority' property attached to an operation which much be settled manually (0.0 to 1.0) with more fine grained and expressive values e.g NSOperationQualityOfServiceBackground, NSOperationQualityOfServiceUserInitiated.. etc > > - > Christos > > >> >> >> On Jul 2, 2014, at 4:53 AM, Corinne Krych wrote: >> >>> Hello iOS lovers, >>> >>> With WWDC over, we?ve got plenty news stuff coming. We?re pretty existing about it so I would like to share with you the excitement. >>> If you want to catch up quickly on what?s new, one blog post I really like and would recommend: >>> http://nshipster.com/ios8/ >>> >>> and if you have more time, if you?re enrolled in iOS dev program and have Safari opened you can watch the great WWDC videos. >>> In https://developer.apple.com/videos/wwdc/2014/ >>> I would recommend the followings: >>> - swift: session 403, 404, 406, 407, 408 >>> - iOS notification: session 713 >>> >>> The stuff I found most existed about are: >>> - Swift coming: to me, it?s a big win. iOS platform with Swift will be a killer. Xcode6 with its Playground features and it REPL will be much easier to play with. >>> - LocalAuthentication Developers can use TouchID APIs. Bin win for secure offline. >>> - iOS8 interactive notification, increased size >>> - embedded widgets >>> >>> This is a thread to gather all the things you like (or don?t like) about iOS8. Feel free to add your own comments and feelings. >>> >>> Some interesting tickets to follow: >>> AGIOS-210 - Epic iOS8 notification >>> AGIOS-220 - Epic for Swift (a Swift version of aerogear-push-ios-registration) >>> >>> ++ >>> Corinne >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev From matzew at apache.org Thu Jul 3 09:35:56 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Thu, 3 Jul 2014 15:35:56 +0200 Subject: [aerogear-dev] Release of UnifiedPush Server 0.11 In-Reply-To: References: Message-ID: Based on QE feedback provided via IRC, here is a new staging repository: http://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-3508/ Let me know by end of Friday, so we can celebrate the release next week! -Matthias On Tue, Jul 1, 2014 at 12:31 PM, Matthias Wessendorf wrote: > Ahoy folks! > > we have been extremely busy over the last few weeks and we are getting > closer to our 1.0.0 release. That was a lot of work and I am very happy > with the results. > > THANKS A LOT!!!!!!!! > > > However, before we are moving towards the 1.0.0 community release, I'd > love to get the current work out as 0.11. Note this release contains a ton > of work and new features. To name a few highlights: > > * New AdminUI > ** a complete rewrite to go with Angular.js > * Keycloak integration > ** user-management and auth is no longer done by the UPS itself. We bundle > a Keycloak auth server in a separate WAR file > * Analytics and Metrics > ** get some details about your applications, the devices and the status of > the submitted push request job to the 3rd party provider > > Besides these big changes, a ton of more work was done by the team: > > https://issues.jboss.org/browse/AGPUSH/fixforversion/12321883/?selectedTab=com.atlassian.jira.jira-projects-plugin:version-issues-panel > > The staging repository is located here: > > http://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-3490/ > > NOTE! This release will not make it to OpenShift yet, as that involves a > bit more of testing, as discussed a few weeks ago on IRC > > > Let me know the results of your testing; > If I hear nothing bad by Thursday evening, the release to maven central > will happen on Friday; > > The offical announcement will go out AFTER the long weekend (4th of July) > > > Greetings, > Matthias > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140703/6b6c5c84/attachment.html From yagyesh.agrawal at itpeoplecorp.com Thu Jul 3 09:58:38 2014 From: yagyesh.agrawal at itpeoplecorp.com (Yagyesh) Date: Thu, 3 Jul 2014 06:58:38 -0700 (PDT) Subject: [aerogear-dev] iOS8: what's new? In-Reply-To: References: <60CD36F8-B21C-4343-99E5-09C447226542@redhat.com> <8F010C6E-6233-4659-8293-C94F49CBE7C4@gmail.com> Message-ID: <1404395917814-8278.post@n5.nabble.com> Can't remember a feature more awaited than Custom Keyboards. Sigh...finally -- View this message in context: http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-iOS8-what-s-new-tp8256p8278.html Sent from the aerogear-dev mailing list archive at Nabble.com. From corinnekrych at gmail.com Thu Jul 3 10:17:51 2014 From: corinnekrych at gmail.com (Corinne Krych) Date: Thu, 3 Jul 2014 16:17:51 +0200 Subject: [aerogear-dev] iOS8: what's new? In-Reply-To: <1404395917814-8278.post@n5.nabble.com> References: <60CD36F8-B21C-4343-99E5-09C447226542@redhat.com> <8F010C6E-6233-4659-8293-C94F49CBE7C4@gmail.com> <1404395917814-8278.post@n5.nabble.com> Message-ID: <4C56421B-0D6B-4428-B49D-723599BEC63D@gmail.com> On 03 Jul 2014, at 15:58, Yagyesh wrote: > Can't remember a feature more awaited than Custom Keyboards. Sigh...finally > > Indeed :) > > -- > View this message in context: http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-iOS8-what-s-new-tp8256p8278.html > Sent from the aerogear-dev mailing list archive at Nabble.com. > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev From matzew at apache.org Fri Jul 4 02:30:19 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Fri, 4 Jul 2014 08:30:19 +0200 Subject: [aerogear-dev] [RELEASE] aerogear-simplepush-java-client 0.1.0 In-Reply-To: References: Message-ID: Hi Sebi, I was able to test this version against Mozilla's Push Service Network, using the following code: https://gist.github.com/matzew/fd3f85a01aa3e46157c7 I used a vanilla CURL to send messages/updates +1 on that release On Thu, Jul 3, 2014 at 11:18 AM, Sebastien Blanc wrote: > Folks ! > I'm happy to announce that aerogear-simplepush-java-client 0.1.0 has been > staged. > > The big change is that we are now relying on Matzew's Java Simple > WebSocket Client[1] and that we have an extended test suite which test this > library against : Tyrus, Netty, Vertx and Undertow ! > > Wondering what you can do with this library ? Basically any Device that > can run the JVM can now receive Push Notifications through the SimplePush > Protocol. > > For instance, receiving Push Notifications on your Raspberry PI : > https://www.youtube.com/watch?v=PpPNSu2ENUA > > Or on a Lego EV3 Robot : https://www.youtube.com/watch?v=4uqfcqq42es > > A lot of other feature are possible, like an Eclipse Plugin to receive > notification in your IDE. > > This library has also full support for the AeroGear UnifiedPush Server, > meaning it can register to it ! > > Have fun and go crazy, the staging repository is located here : > https://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-3507 > > Sebi > > > [1]https://github.com/matzew/simple-websocket-client > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140704/36a37783/attachment-0001.html From matzew at apache.org Fri Jul 4 03:28:18 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Fri, 4 Jul 2014 09:28:18 +0200 Subject: [aerogear-dev] Sync - Server items (JAX-RS and JPA) Message-ID: Hi, last week at our Face2Face we had a discussion about sync, moving forward on the client (will be a different thread) and on the server. For the server-side we had a few different approaches: 1) AeroGear Sync-Server: Dan and Luke worked on the sync-server ([1]) as a 'long term' solution The project contains two server implementations: - RestServer implementation that uses a simple approach of rejecting conflicts and delegating the responsibility to resolve conflicts to the client. - DiffServer Based on Google's Differential Synchonrization by Neil Fraser. This server is WebSocket based. 2) Initial quick and simple solution based on JAX-RS and JPA: - We have versioning in JPA (optimistic locking) - Use it (send 409 on server and send right data) -- Use JAX-RS ExceptionMapper for exceptions around the optimistic locking ? - Client library will have helper methods for managing data - Use push to send notifications that data changed? - JAX-RS Annotation to send notifications? I'd like to follow up on that, to see where things stand Greetings, Matthias [1] https://github.com/danbev/aerogear-sync-server/tree/differential-synchronization -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140704/68c3ff84/attachment.html From edewit at redhat.com Fri Jul 4 03:46:11 2014 From: edewit at redhat.com (Erik Jan de Wit) Date: Fri, 4 Jul 2014 09:46:11 +0200 Subject: [aerogear-dev] Sync - Server items (JAX-RS and JPA) In-Reply-To: References: Message-ID: <66BC3E5F-229C-4891-A5C3-ACCCE35FEF76@redhat.com> On 4 Jul,2014, at 9:28 , Matthias Wessendorf wrote: > > 2) Initial quick and simple solution based on JAX-RS and JPA: > - We have versioning in JPA (optimistic locking) - Use it (send 409 on server and send right data) > -- Use JAX-RS ExceptionMapper for exceptions around the optimistic locking ? Added handling of OptimisticLockException to forge https://github.com/forge/core/pull/481 this will give clients a 409 so that they could show to the user that their copy was out of date. Now the client still need to react to this. > - Client library will have helper methods for managing data POC of client handeling this https://github.com/edewit/aerogear-push-quickstarts/tree/conflict/client/cordova/angular/www this will just show the client version and the server version and the user can choose which version to take > - Use push to send notifications that data changed? > - JAX-RS Annotation to send notifications? > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140704/653c9441/attachment.html From tkriz at redhat.com Fri Jul 4 09:00:20 2014 From: tkriz at redhat.com (Tadeas Kriz) Date: Fri, 4 Jul 2014 15:00:20 +0200 Subject: [aerogear-dev] Release of UnifiedPush Server 0.11 In-Reply-To: References: Message-ID: <7C0257CF-553C-433F-8F04-D879E76CCE03@redhat.com> Integration tests are nicely green and there seems to be no issues on the UI console side as well! Great work guys! ? Tadeas Kriz On 03 Jul 2014, at 15:35, Matthias Wessendorf wrote: > Based on QE feedback provided via IRC, here is a new staging repository: > > http://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-3508/ > > Let me know by end of Friday, so we can celebrate the release next week! > > > -Matthias > > > On Tue, Jul 1, 2014 at 12:31 PM, Matthias Wessendorf wrote: > Ahoy folks! > > we have been extremely busy over the last few weeks and we are getting closer to our 1.0.0 release. That was a lot of work and I am very happy with the results. > > THANKS A LOT!!!!!!!! > > > However, before we are moving towards the 1.0.0 community release, I'd love to get the current work out as 0.11. Note this release contains a ton of work and new features. To name a few highlights: > > * New AdminUI > ** a complete rewrite to go with Angular.js > * Keycloak integration > ** user-management and auth is no longer done by the UPS itself. We bundle a Keycloak auth server in a separate WAR file > * Analytics and Metrics > ** get some details about your applications, the devices and the status of the submitted push request job to the 3rd party provider > > Besides these big changes, a ton of more work was done by the team: > https://issues.jboss.org/browse/AGPUSH/fixforversion/12321883/?selectedTab=com.atlassian.jira.jira-projects-plugin:version-issues-panel > > The staging repository is located here: > http://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-3490/ > > NOTE! This release will not make it to OpenShift yet, as that involves a bit more of testing, as discussed a few weeks ago on IRC > > > Let me know the results of your testing; > If I hear nothing bad by Thursday evening, the release to maven central will happen on Friday; > > The offical announcement will go out AFTER the long weekend (4th of July) > > > Greetings, > Matthias > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140704/74e25b62/attachment.html From matzew at apache.org Fri Jul 4 09:18:58 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Fri, 4 Jul 2014 15:18:58 +0200 Subject: [aerogear-dev] Release of UnifiedPush Server 0.11 In-Reply-To: <7C0257CF-553C-433F-8F04-D879E76CCE03@redhat.com> References: <7C0257CF-553C-433F-8F04-D879E76CCE03@redhat.com> Message-ID: Thanks a lot for testing! And thanks to the team for delivering such a great release, with a ton of new features and lot's of fixes/enhancements. This release will go out to Maven central over the weekend and the 'official' announcement will follow early next week On Fri, Jul 4, 2014 at 3:00 PM, Tadeas Kriz wrote: > Integration tests are nicely green and there seems to be no issues on the > UI console side as well! Great work guys! > > ? > Tadeas Kriz > > On 03 Jul 2014, at 15:35, Matthias Wessendorf wrote: > > Based on QE feedback provided via IRC, here is a new staging repository: > > > http://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-3508/ > > Let me know by end of Friday, so we can celebrate the release next week! > > > -Matthias > > > On Tue, Jul 1, 2014 at 12:31 PM, Matthias Wessendorf > wrote: > >> Ahoy folks! >> >> we have been extremely busy over the last few weeks and we are getting >> closer to our 1.0.0 release. That was a lot of work and I am very happy >> with the results. >> >> THANKS A LOT!!!!!!!! >> >> >> However, before we are moving towards the 1.0.0 community release, I'd >> love to get the current work out as 0.11. Note this release contains a ton >> of work and new features. To name a few highlights: >> >> * New AdminUI >> ** a complete rewrite to go with Angular.js >> * Keycloak integration >> ** user-management and auth is no longer done by the UPS itself. We >> bundle a Keycloak auth server in a separate WAR file >> * Analytics and Metrics >> ** get some details about your applications, the devices and the status >> of the submitted push request job to the 3rd party provider >> >> Besides these big changes, a ton of more work was done by the team: >> >> https://issues.jboss.org/browse/AGPUSH/fixforversion/12321883/?selectedTab=com.atlassian.jira.jira-projects-plugin:version-issues-panel >> >> The staging repository is located here: >> >> http://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-3490/ >> >> NOTE! This release will not make it to OpenShift yet, as that involves a >> bit more of testing, as discussed a few weeks ago on IRC >> >> >> Let me know the results of your testing; >> If I hear nothing bad by Thursday evening, the release to maven central >> will happen on Friday; >> >> The offical announcement will go out AFTER the long weekend (4th of July) >> >> >> Greetings, >> Matthias >> >> -- >> Matthias Wessendorf >> >> blog: http://matthiaswessendorf.wordpress.com/ >> sessions: http://www.slideshare.net/mwessendorf >> twitter: http://twitter.com/mwessendorf >> > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140704/0e6b7a3d/attachment-0001.html From daniel.bevenius at gmail.com Fri Jul 4 09:21:02 2014 From: daniel.bevenius at gmail.com (Daniel Bevenius) Date: Fri, 4 Jul 2014 15:21:02 +0200 Subject: [aerogear-dev] Release of UnifiedPush Server 0.11 In-Reply-To: References: <7C0257CF-553C-433F-8F04-D879E76CCE03@redhat.com> Message-ID: Nice work everyone! On 4 July 2014 15:18, Matthias Wessendorf wrote: > Thanks a lot for testing! > > And thanks to the team for delivering such a great release, with a ton of > new features and lot's of fixes/enhancements. > > This release will go out to Maven central over the weekend and the > 'official' announcement will follow early next week > > > On Fri, Jul 4, 2014 at 3:00 PM, Tadeas Kriz wrote: > >> Integration tests are nicely green and there seems to be no issues on the >> UI console side as well! Great work guys! >> >> ? >> Tadeas Kriz >> >> On 03 Jul 2014, at 15:35, Matthias Wessendorf wrote: >> >> Based on QE feedback provided via IRC, here is a new staging repository: >> >> >> http://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-3508/ >> >> Let me know by end of Friday, so we can celebrate the release next week! >> >> >> -Matthias >> >> >> On Tue, Jul 1, 2014 at 12:31 PM, Matthias Wessendorf >> wrote: >> >>> Ahoy folks! >>> >>> we have been extremely busy over the last few weeks and we are getting >>> closer to our 1.0.0 release. That was a lot of work and I am very happy >>> with the results. >>> >>> THANKS A LOT!!!!!!!! >>> >>> >>> However, before we are moving towards the 1.0.0 community release, I'd >>> love to get the current work out as 0.11. Note this release contains a ton >>> of work and new features. To name a few highlights: >>> >>> * New AdminUI >>> ** a complete rewrite to go with Angular.js >>> * Keycloak integration >>> ** user-management and auth is no longer done by the UPS itself. We >>> bundle a Keycloak auth server in a separate WAR file >>> * Analytics and Metrics >>> ** get some details about your applications, the devices and the status >>> of the submitted push request job to the 3rd party provider >>> >>> Besides these big changes, a ton of more work was done by the team: >>> >>> https://issues.jboss.org/browse/AGPUSH/fixforversion/12321883/?selectedTab=com.atlassian.jira.jira-projects-plugin:version-issues-panel >>> >>> The staging repository is located here: >>> >>> http://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-3490/ >>> >>> NOTE! This release will not make it to OpenShift yet, as that involves a >>> bit more of testing, as discussed a few weeks ago on IRC >>> >>> >>> Let me know the results of your testing; >>> If I hear nothing bad by Thursday evening, the release to maven central >>> will happen on Friday; >>> >>> The offical announcement will go out AFTER the long weekend (4th of July) >>> >>> >>> Greetings, >>> Matthias >>> >>> -- >>> Matthias Wessendorf >>> >>> blog: http://matthiaswessendorf.wordpress.com/ >>> sessions: http://www.slideshare.net/mwessendorf >>> twitter: http://twitter.com/mwessendorf >>> >> >> >> >> -- >> Matthias Wessendorf >> >> blog: http://matthiaswessendorf.wordpress.com/ >> sessions: http://www.slideshare.net/mwessendorf >> twitter: http://twitter.com/mwessendorf >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140704/72e4f96f/attachment.html From bsutter at redhat.com Fri Jul 4 09:30:40 2014 From: bsutter at redhat.com (Burr Sutter) Date: Fri, 4 Jul 2014 09:30:40 -0400 Subject: [aerogear-dev] Sync - Server items (JAX-RS and JPA) In-Reply-To: <66BC3E5F-229C-4891-A5C3-ACCCE35FEF76@redhat.com> References: <66BC3E5F-229C-4891-A5C3-ACCCE35FEF76@redhat.com> Message-ID: <83C3B5B3-D837-49E5-A717-1E2E9C022CE3@redhat.com> On Jul 4, 2014, at 3:46 AM, Erik Jan de Wit wrote: > > On 4 Jul,2014, at 9:28 , Matthias Wessendorf wrote: >> >> 2) Initial quick and simple solution based on JAX-RS and JPA: >> - We have versioning in JPA (optimistic locking) - Use it (send 409 on server and send right data) >> -- Use JAX-RS ExceptionMapper for exceptions around the optimistic locking ? > > Added handling of OptimisticLockException to forge https://github.com/forge/core/pull/481 this will give clients a 409 so that they could show to the user that their copy was out of date. Now the client still need to react to this. https://issues.jboss.org/browse/FORGE-1916 > >> - Client library will have helper methods for managing data > > POC of client handeling this https://github.com/edewit/aerogear-push-quickstarts/tree/conflict/client/cordova/angular/www this will just show the client version and the server version and the user can choose which version to take > >> - Use push to send notifications that data changed? >> - JAX-RS Annotation to send notifications? >> > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140704/117e65a4/attachment.html From bruno at abstractj.org Fri Jul 4 10:33:52 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Fri, 04 Jul 2014 07:33:52 -0700 (PDT) Subject: [aerogear-dev] Release of UnifiedPush Server 0.11 In-Reply-To: References: Message-ID: <1404484431700.3f764dfe@Nodemailer> You guys are Legen... wait for it, DARY! Legendary!? abstractj On Fri, Jul 4, 2014 at 10:21 AM, Daniel Bevenius wrote: > Nice work everyone! > On 4 July 2014 15:18, Matthias Wessendorf wrote: >> Thanks a lot for testing! >> >> And thanks to the team for delivering such a great release, with a ton of >> new features and lot's of fixes/enhancements. >> >> This release will go out to Maven central over the weekend and the >> 'official' announcement will follow early next week >> >> >> On Fri, Jul 4, 2014 at 3:00 PM, Tadeas Kriz wrote: >> >>> Integration tests are nicely green and there seems to be no issues on the >>> UI console side as well! Great work guys! >>> >>> ? >>> Tadeas Kriz >>> >>> On 03 Jul 2014, at 15:35, Matthias Wessendorf wrote: >>> >>> Based on QE feedback provided via IRC, here is a new staging repository: >>> >>> >>> http://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-3508/ >>> >>> Let me know by end of Friday, so we can celebrate the release next week! >>> >>> >>> -Matthias >>> >>> >>> On Tue, Jul 1, 2014 at 12:31 PM, Matthias Wessendorf >>> wrote: >>> >>>> Ahoy folks! >>>> >>>> we have been extremely busy over the last few weeks and we are getting >>>> closer to our 1.0.0 release. That was a lot of work and I am very happy >>>> with the results. >>>> >>>> THANKS A LOT!!!!!!!! >>>> >>>> >>>> However, before we are moving towards the 1.0.0 community release, I'd >>>> love to get the current work out as 0.11. Note this release contains a ton >>>> of work and new features. To name a few highlights: >>>> >>>> * New AdminUI >>>> ** a complete rewrite to go with Angular.js >>>> * Keycloak integration >>>> ** user-management and auth is no longer done by the UPS itself. We >>>> bundle a Keycloak auth server in a separate WAR file >>>> * Analytics and Metrics >>>> ** get some details about your applications, the devices and the status >>>> of the submitted push request job to the 3rd party provider >>>> >>>> Besides these big changes, a ton of more work was done by the team: >>>> >>>> https://issues.jboss.org/browse/AGPUSH/fixforversion/12321883/?selectedTab=com.atlassian.jira.jira-projects-plugin:version-issues-panel >>>> >>>> The staging repository is located here: >>>> >>>> http://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-3490/ >>>> >>>> NOTE! This release will not make it to OpenShift yet, as that involves a >>>> bit more of testing, as discussed a few weeks ago on IRC >>>> >>>> >>>> Let me know the results of your testing; >>>> If I hear nothing bad by Thursday evening, the release to maven central >>>> will happen on Friday; >>>> >>>> The offical announcement will go out AFTER the long weekend (4th of July) >>>> >>>> >>>> Greetings, >>>> Matthias >>>> >>>> -- >>>> Matthias Wessendorf >>>> >>>> blog: http://matthiaswessendorf.wordpress.com/ >>>> sessions: http://www.slideshare.net/mwessendorf >>>> twitter: http://twitter.com/mwessendorf >>>> >>> >>> >>> >>> -- >>> Matthias Wessendorf >>> >>> blog: http://matthiaswessendorf.wordpress.com/ >>> sessions: http://www.slideshare.net/mwessendorf >>> twitter: http://twitter.com/mwessendorf >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >>> >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >> >> >> >> -- >> Matthias Wessendorf >> >> blog: http://matthiaswessendorf.wordpress.com/ >> sessions: http://www.slideshare.net/mwessendorf >> twitter: http://twitter.com/mwessendorf >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140704/46d7d9f7/attachment-0001.html From daniel at passos.me Sun Jul 6 18:44:45 2014 From: daniel at passos.me (Daniel Passos) Date: Sun, 6 Jul 2014 19:44:45 -0300 Subject: [aerogear-dev] AeroGear Android 1.4.0 Staged In-Reply-To: References: Message-ID: AeroGear Android 1.4 is released on Maven Central. Take a look here[1] for more details. [1] https://blog.sagaoftherealms.net/?p=493 -- Passos On Tue, Jul 1, 2014 at 11:36 AM, Daniel Passos wrote: > Hey Everyone, > > AeroGear Android 1.4.0 was staged on Nexus. \o/ > > This release introduced OAuth2 support, numerous doc, quickstarts and > cookbook updates. Pipe and pipeline updates and modularizes our push APIs > [1] > > We planned press the button and release it to maven central next thursday > > Feel free to test it[2]! > > [1] https://issues.jboss.org/issues/?filter=12320506 > [2] > http://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-3491/ > > -- Passos > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140706/4de7bdaf/attachment.html From bruno at abstractj.org Sun Jul 6 18:48:37 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Sun, 06 Jul 2014 15:48:37 -0700 (PDT) Subject: [aerogear-dev] AeroGear Android 1.4.0 Staged In-Reply-To: References: Message-ID: <1404686917516.60a90ad4@Nodemailer> Yay and go back to the beach Passos!? abstractj On Sun, Jul 6, 2014 at 7:45 PM, Daniel Passos wrote: > AeroGear Android 1.4 is released on Maven Central. > Take a look here[1] for more details. > [1] https://blog.sagaoftherealms.net/?p=493 > -- Passos > On Tue, Jul 1, 2014 at 11:36 AM, Daniel Passos wrote: >> Hey Everyone, >> >> AeroGear Android 1.4.0 was staged on Nexus. \o/ >> >> This release introduced OAuth2 support, numerous doc, quickstarts and >> cookbook updates. Pipe and pipeline updates and modularizes our push APIs >> [1] >> >> We planned press the button and release it to maven central next thursday >> >> Feel free to test it[2]! >> >> [1] https://issues.jboss.org/issues/?filter=12320506 >> [2] >> http://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-3491/ >> >> -- Passos >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140706/ed7bfe37/attachment.html From daniel.bevenius at gmail.com Mon Jul 7 01:09:51 2014 From: daniel.bevenius at gmail.com (Daniel Bevenius) Date: Mon, 7 Jul 2014 07:09:51 +0200 Subject: [aerogear-dev] Team meeting Message-ID: Agenda: http://oksoclap.com/p/aerogear-team-mgt-20140707 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140707/5a6eb7e5/attachment.html From scm.blanc at gmail.com Mon Jul 7 03:36:58 2014 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Mon, 7 Jul 2014 09:36:58 +0200 Subject: [aerogear-dev] [RELEASE] aerogear-simplepush-java-client 0.1.0 In-Reply-To: References: Message-ID: FYI I have just released this version and now just waiting for Maven Central to sync ! On Fri, Jul 4, 2014 at 8:30 AM, Matthias Wessendorf wrote: > Hi Sebi, > > I was able to test this version against Mozilla's Push Service Network, > using the following code: > https://gist.github.com/matzew/fd3f85a01aa3e46157c7 > > I used a vanilla CURL to send messages/updates > > > > +1 on that release > > > > > On Thu, Jul 3, 2014 at 11:18 AM, Sebastien Blanc > wrote: > >> Folks ! >> I'm happy to announce that aerogear-simplepush-java-client 0.1.0 has been >> staged. >> >> The big change is that we are now relying on Matzew's Java Simple >> WebSocket Client[1] and that we have an extended test suite which test this >> library against : Tyrus, Netty, Vertx and Undertow ! >> >> Wondering what you can do with this library ? Basically any Device that >> can run the JVM can now receive Push Notifications through the SimplePush >> Protocol. >> >> For instance, receiving Push Notifications on your Raspberry PI : >> https://www.youtube.com/watch?v=PpPNSu2ENUA >> >> Or on a Lego EV3 Robot : https://www.youtube.com/watch?v=4uqfcqq42es >> >> A lot of other feature are possible, like an Eclipse Plugin to receive >> notification in your IDE. >> >> This library has also full support for the AeroGear UnifiedPush Server, >> meaning it can register to it ! >> >> Have fun and go crazy, the staging repository is located here : >> https://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-3507 >> >> Sebi >> >> >> [1]https://github.com/matzew/simple-websocket-client >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140707/fbbe6433/attachment.html From matzew at apache.org Mon Jul 7 05:11:45 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Mon, 7 Jul 2014 11:11:45 +0200 Subject: [aerogear-dev] It's out now (was Re: Release of UnifiedPush Server 0.11) Message-ID: Folks, the 0.11.0 got released: http://matthiaswessendorf.wordpress.com/2014/07/07/unifiedpush-0-11/ Feedback more than welcome! Thanks to the entire team for this great amount of work. Special thanks to the Keycloak team for their support and getting in features that were required to make the smooth integration happen. Thanks! <3 -Matthias On Thu, Jul 3, 2014 at 3:35 PM, Matthias Wessendorf wrote: > Based on QE feedback provided via IRC, here is a new staging repository: > > > http://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-3508/ > > Let me know by end of Friday, so we can celebrate the release next week! > > > -Matthias > > > On Tue, Jul 1, 2014 at 12:31 PM, Matthias Wessendorf > wrote: > >> Ahoy folks! >> >> we have been extremely busy over the last few weeks and we are getting >> closer to our 1.0.0 release. That was a lot of work and I am very happy >> with the results. >> >> THANKS A LOT!!!!!!!! >> >> >> However, before we are moving towards the 1.0.0 community release, I'd >> love to get the current work out as 0.11. Note this release contains a ton >> of work and new features. To name a few highlights: >> >> * New AdminUI >> ** a complete rewrite to go with Angular.js >> * Keycloak integration >> ** user-management and auth is no longer done by the UPS itself. We >> bundle a Keycloak auth server in a separate WAR file >> * Analytics and Metrics >> ** get some details about your applications, the devices and the status >> of the submitted push request job to the 3rd party provider >> >> Besides these big changes, a ton of more work was done by the team: >> >> https://issues.jboss.org/browse/AGPUSH/fixforversion/12321883/?selectedTab=com.atlassian.jira.jira-projects-plugin:version-issues-panel >> >> The staging repository is located here: >> >> http://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-3490/ >> >> NOTE! This release will not make it to OpenShift yet, as that involves a >> bit more of testing, as discussed a few weeks ago on IRC >> >> >> Let me know the results of your testing; >> If I hear nothing bad by Thursday evening, the release to maven central >> will happen on Friday; >> >> The offical announcement will go out AFTER the long weekend (4th of July) >> >> >> Greetings, >> Matthias >> >> -- >> Matthias Wessendorf >> >> blog: http://matthiaswessendorf.wordpress.com/ >> sessions: http://www.slideshare.net/mwessendorf >> twitter: http://twitter.com/mwessendorf >> > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140707/543c43ce/attachment-0001.html From matzew at apache.org Mon Jul 7 07:42:53 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Mon, 7 Jul 2014 13:42:53 +0200 Subject: [aerogear-dev] [RELEASE] aerogear-simplepush-java-client 0.1.0 In-Reply-To: References: Message-ID: nice! can you add that to 'push section' on the download.html page ? http://aerogear.org/download/ On Mon, Jul 7, 2014 at 9:36 AM, Sebastien Blanc wrote: > FYI I have just released this version and now just waiting for Maven > Central to sync ! > > > > > On Fri, Jul 4, 2014 at 8:30 AM, Matthias Wessendorf > wrote: > >> Hi Sebi, >> >> I was able to test this version against Mozilla's Push Service Network, >> using the following code: >> https://gist.github.com/matzew/fd3f85a01aa3e46157c7 >> >> I used a vanilla CURL to send messages/updates >> >> >> >> +1 on that release >> >> >> >> >> On Thu, Jul 3, 2014 at 11:18 AM, Sebastien Blanc >> wrote: >> >>> Folks ! >>> I'm happy to announce that aerogear-simplepush-java-client 0.1.0 has >>> been staged. >>> >>> The big change is that we are now relying on Matzew's Java Simple >>> WebSocket Client[1] and that we have an extended test suite which test this >>> library against : Tyrus, Netty, Vertx and Undertow ! >>> >>> Wondering what you can do with this library ? Basically any Device that >>> can run the JVM can now receive Push Notifications through the SimplePush >>> Protocol. >>> >>> For instance, receiving Push Notifications on your Raspberry PI : >>> https://www.youtube.com/watch?v=PpPNSu2ENUA >>> >>> Or on a Lego EV3 Robot : https://www.youtube.com/watch?v=4uqfcqq42es >>> >>> A lot of other feature are possible, like an Eclipse Plugin to receive >>> notification in your IDE. >>> >>> This library has also full support for the AeroGear UnifiedPush Server, >>> meaning it can register to it ! >>> >>> Have fun and go crazy, the staging repository is located here : >>> https://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-3507 >>> >>> Sebi >>> >>> >>> [1]https://github.com/matzew/simple-websocket-client >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >> >> >> >> -- >> Matthias Wessendorf >> >> blog: http://matthiaswessendorf.wordpress.com/ >> sessions: http://www.slideshare.net/mwessendorf >> twitter: http://twitter.com/mwessendorf >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140707/61e4c76f/attachment.html From bam at tretau.net Mon Jul 7 08:30:28 2014 From: bam at tretau.net (Torben) Date: Mon, 07 Jul 2014 14:30:28 +0200 Subject: [aerogear-dev] Unified Push Server 0.10.4 / Logging Message-ID: <20140707143028.Horde.IQ4rNWSsh35bC6OpBrQgew1@webmail.df.eu> Hello all, I am starting to use the UPS with Version 0.10.4 on Openshift. - As I got into trouble receiving Messages via GCM I want to debug with more logging statements. Can anybody give me a hint where I can change the Java Util logging to a finer level at the Openshift installation? - I use the cordova client and have another question to push register/unregister. In the documentation there is a statement that the unregister is not needed: "Note: The method is optional, since not all supported Push Networks recommend having a client application actively performing an _unregister." So should I just call the push.register method, without unregister, on each app start? Best regards, congratulations to the new 0.11 version! Torben From cvasilak at gmail.com Mon Jul 7 10:16:36 2014 From: cvasilak at gmail.com (Christos Vasilakis) Date: Mon, 7 Jul 2014 17:16:36 +0300 Subject: [aerogear-dev] Team meeting In-Reply-To: References: Message-ID: fyi, meeting minutes: Meeting ended Mon Jul 7 13:56:04 2014 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) Minutes: http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2014/aerogear.2014-07-07-13.46.html Minutes (text): http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2014/aerogear.2014-07-07-13.46.txt Log: http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2014/aerogear.2014-07-07-13.46.log.html > On Jul 7, 2014, at 8:09 AM, Daniel Bevenius wrote: > > Agenda: > http://oksoclap.com/p/aerogear-team-mgt-20140707 > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140707/838f1b36/attachment.html From edewit at redhat.com Mon Jul 7 10:27:23 2014 From: edewit at redhat.com (Erik Jan de Wit) Date: Mon, 7 Jul 2014 16:27:23 +0200 Subject: [aerogear-dev] Unified Push Server 0.10.4 / Logging In-Reply-To: <20140707143028.Horde.IQ4rNWSsh35bC6OpBrQgew1@webmail.df.eu> References: <20140707143028.Horde.IQ4rNWSsh35bC6OpBrQgew1@webmail.df.eu> Message-ID: On 7 Jul,2014, at 14:30 , Torben wrote: > Hello all, > > I am starting to use the UPS with Version 0.10.4 on Openshift. > > - As I got into trouble receiving Messages via GCM I want to debug > with more logging statements. Can anybody give me a hint where I can > change the Java Util logging to a finer level at the Openshift > installation? > > - I use the cordova client and have another question to push > register/unregister. In the documentation there is a statement that > the unregister is not needed: "Note: The method is optional, since not > all supported Push Networks recommend having a client application > actively performing an _unregister." > So should I just call the push.register method, without unregister, on > each app start? Short answer yes, unregister only exists on android and even there you?ll only need it in rare cases see: http://developer.android.com/google/gcm/adv.html#unreg-why > > Best regards, congratulations to the new 0.11 version! > > Torben > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140707/e9352600/attachment.html From avibelli at redhat.com Mon Jul 7 10:29:04 2014 From: avibelli at redhat.com (Andrea Vibelli) Date: Mon, 7 Jul 2014 07:29:04 -0700 (PDT) Subject: [aerogear-dev] Random Jenkins failures when building UPS Message-ID: <1404743344275-8297.post@n5.nabble.com> Hi all, while using the latest version of the UnifiedPush Server (0.11.0), that includes the new frontend-maven-plugin to build the admin-ui module, I was experiencing random failures when building with Jenkins. I have googled for a while, and found that the problem was in the concurrent modification of the bower cache and registry. I tried one solution suggested in (https://github.com/bower/bower/issues/933), so I changed the admin-ui/.bowerrc file and added the following: "storage": { "packages": ".bower-cache", "registry": ".bower-registry" }, "tmp": ".bower-tmp" , so admin-ui/.bowerrc ending with this content: { "directory": "app/bower_components" "storage": { "packages": ".bower-cache", "registry": ".bower-registry" }, "tmp": ".bower-tmp" } This made my Jenkins build stable, and I did not experience random failures anymore (ran 10 subsequent builds without errors, while I could not run 2 successful subsequent builds before). However, digging more into the thread, I found that the problem of the race condition against the bower cache was solved in bower version >= 1.3.2 (https://github.com/bower/bower/pull/1211). Actually in admin-ui/package.json we have "grunt-bower-task": "^0.3.4", that would download a bower version >= 1.2.0 (looking in my Jenkins build, it downloaded bower version 1.2.8), which is not enough for having the problem fixed. So I explicitly forced bower version to be at least 1.3.2, by adding: "bower": "~1.3.2" into admin-ui/package.json. The solution is working for me, and I also removed the additional content inside the file admin-ui/.bowerrc that I added before. I also found another project that solved the problem in this way: https://github.com/opf/openproject/commit/36d2e9079b23955d3a1198ec1a8698ce10361026 I have opened a PR for this (https://github.com/aerogear/aerogear-unifiedpush-server/pull/275), could you please review? Thanks! Andrea -- View this message in context: http://aerogear-dev.1069024.n5.nabble.com/Random-Jenkins-failures-when-building-UPS-tp8297.html Sent from the aerogear-dev mailing list archive at Nabble.com. From fjuma at redhat.com Mon Jul 7 10:35:11 2014 From: fjuma at redhat.com (Farah Juma) Date: Mon, 7 Jul 2014 10:35:11 -0400 (EDT) Subject: [aerogear-dev] Unified Push Server 0.10.4 / Logging In-Reply-To: <20140707143028.Horde.IQ4rNWSsh35bC6OpBrQgew1@webmail.df.eu> References: <20140707143028.Horde.IQ4rNWSsh35bC6OpBrQgew1@webmail.df.eu> Message-ID: <99981532.2963385.1404743711374.JavaMail.zimbra@redhat.com> > From: "Torben" > To: aerogear-dev at lists.jboss.org > Sent: Monday, July 7, 2014 8:30:28 AM > Subject: [aerogear-dev] Unified Push Server 0.10.4 / Logging > > Hello all, > > I am starting to use the UPS with Version 0.10.4 on Openshift. > > - As I got into trouble receiving Messages via GCM I want to debug > with more logging statements. Can anybody give me a hint where I can > change the Java Util logging to a finer level at the Openshift > installation? Logging can be configured in the JBoss AS standalone.xml file (once you ssh into your instance, you can edit the logging subsystem configuration in $OPENSHIFT_AEROGEAR_PUSH_DIR/standalone/configuration/standalone.xml). More information about logging can be found here: https://docs.jboss.org/author/display/AS71/Logging+Configuration > - I use the cordova client and have another question to push > register/unregister. In the documentation there is a statement that > the unregister is not needed: "Note: The method is optional, since not > all supported Push Networks recommend having a client application > actively performing an _unregister." > So should I just call the push.register method, without unregister, on > each app start? > > Best regards, congratulations to the new 0.11 version! > > Torben > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > From mwringe at redhat.com Mon Jul 7 12:14:17 2014 From: mwringe at redhat.com (Matt Wringe) Date: Mon, 07 Jul 2014 12:14:17 -0400 Subject: [aerogear-dev] LiveOak SDK Message-ID: <53BAC759.7030000@redhat.com> Initial email to get some discussion going around the LiveOak SDK and AeroGear collaboration. Essentially in LiveOak we are going to need a few different SDK types - Client Application SDK This is the code which will run on the users device. Initial targets here are javascript (+ cordova support), iOS, Android. This type of SDK will handle things like getting and sending resources to and from the server, handling login/logout/registration, etc. Probably some other things like device registration would be needed as well. Not sure if we want to provide support for some other things outside of communicating with the server or not (eg access to device components (eg camera, location, etc)) or if these would be best handled by using the native environment's SDK instead. - Server Side SDK This is code that runs on the server side, written in JavaScript by the application developer. This will need to be familiar to the client application's JavaScript SDK, but may not be exactly the same. This type of SDK will be able to access the same resources as the client side JavaScript, as well as other internal resources and libraries. I am not sure how to collaborate between the LiveOak and AeroGear teams here. AeroGear makes really awesome SDKs for various mobile platforms, but with LiveOak we are dealing with a specific type of application. The AeroGear SDKs tend to handle the more generic case, which I don't necessarily think makes sense for a LiveOak SDK. I do think it makes sense that the LiveOak SDK uses the AeroGear SDK internally, but I don't know if we want to expose these AeroGear components to a LiveOak developer or not. For me, I envision something like the admin setting up their application in the LiveOak console which then generates a json configuration file (url locations, resources available, KeyCloak settings, UPS settings, etc). The application developer then drops this json file in to their application, the LiveOak SDK reads the json file to set it self up and then its really easy for the developer to start using it. [there are also some really cool things we could be doing here as well if we can get awesome data sync support for AeroGear. It might be interesting to be able to fetch a resource from the server and automatically sync its state across between the client and server. This way the object appears as a local object: if the resource changes on the server, it changes locally as well, if it changes locally, that change is pushed to the server. This way you are just dealing with an object, and not having to fetch and then push object back and forth between the server manually] Anyone have any thoughts on this? From matzew at apache.org Tue Jul 8 01:05:53 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Tue, 8 Jul 2014 07:05:53 +0200 Subject: [aerogear-dev] [release] parent / bom new release ? Message-ID: Hi, please test this staged aerogear/bom repo: http://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-3538/ Changes: mainly version adjustments -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140708/245caf0d/attachment.html From matzew at apache.org Tue Jul 8 01:17:10 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Tue, 8 Jul 2014 07:17:10 +0200 Subject: [aerogear-dev] cordova plugin release In-Reply-To: References: Message-ID: I think we never actually released the version 0.6.0 :-) -Matthias On Wed, May 28, 2014 at 11:15 AM, Erik Jan de Wit wrote: > Hi, > > As discussed here ( > http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-New-Cordova-Push-release-was-Re-Mobile-Push-1-0-0-Client-SDKs-for-Android-Cordova-and-i-td7932.html) > we are going to release a new version of the cordova push plugin the new > version 0.5.1 most important feature is the updated android libraries. > There are also some community bug fixes: > > * fix a bug with the foreground/isInline flag > * > * fix bug with android not sending cached message > * > * Automate plugin testing using grunt-cordova-plugin-jasmine. > * > > Thank you TadeasKriz and keithdmoore for contributing > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140708/2505bb98/attachment.html From bam at tretau.net Tue Jul 8 02:39:06 2014 From: bam at tretau.net (Torben) Date: Tue, 08 Jul 2014 08:39:06 +0200 Subject: [aerogear-dev] Unified Push Server 0.10.4 / Logging In-Reply-To: <99981532.2963385.1404743711374.JavaMail.zimbra@redhat.com> References: <20140707143028.Horde.IQ4rNWSsh35bC6OpBrQgew1@webmail.df.eu> <99981532.2963385.1404743711374.JavaMail.zimbra@redhat.com> Message-ID: <20140708083906.Horde.8OOSQoyDc5SPqpx-ZFeoBw6@webmail.df.eu> Hello Farah, Hello Erik Jan, thank you for your prompt answers. Great news! Kind regards, Torben Quoting Farah Juma : >> From: "Torben" >> To: aerogear-dev at lists.jboss.org >> Sent: Monday, July 7, 2014 8:30:28 AM >> Subject: [aerogear-dev] Unified Push Server 0.10.4 / Logging >> >> Hello all, >> >> I am starting to use the UPS with Version 0.10.4 on Openshift. >> >> - As I got into trouble receiving Messages via GCM I want to debug >> with more logging statements. Can anybody give me a hint where I can >> change the Java Util logging to a finer level at the Openshift >> installation? > > Logging can be configured in the JBoss AS standalone.xml file (once > you ssh into your instance, you can edit the logging subsystem > configuration in > $OPENSHIFT_AEROGEAR_PUSH_DIR/standalone/configuration/standalone.xml). More > information about logging can be found here: > > https://docs.jboss.org/author/display/AS71/Logging+Configuration > >> - I use the cordova client and have another question to push >> register/unregister. In the documentation there is a statement that >> the unregister is not needed: "Note: The method is optional, since not >> all supported Push Networks recommend having a client application >> actively performing an _unregister." >> So should I just call the push.register method, without unregister, on >> each app start? >> >> Best regards, congratulations to the new 0.11 version! >> >> Torben >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev From edewit at redhat.com Tue Jul 8 02:47:24 2014 From: edewit at redhat.com (Erik Jan de Wit) Date: Tue, 8 Jul 2014 08:47:24 +0200 Subject: [aerogear-dev] cordova plugin release In-Reply-To: References: Message-ID: <1215EAF1-CA43-40E4-8165-72490EBA1F84@redhat.com> Because of all the changes needed to be made to the UnifiedPush Server console, this didn?t get the attention it deserves. There was a bug found by Karel in the quick starts that I just merged. Please retest and then we?ll release next week. Cheers, Erik Jan On 8 Jul,2014, at 7:17 , Matthias Wessendorf wrote: > I think we never actually released the version 0.6.0 :-) > > -Matthias > > > > On Wed, May 28, 2014 at 11:15 AM, Erik Jan de Wit wrote: > Hi, > > As discussed here (http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-New-Cordova-Push-release-was-Re-Mobile-Push-1-0-0-Client-SDKs-for-Android-Cordova-and-i-td7932.html) we are going to release a new version of the cordova push plugin the new version 0.5.1 most important feature is the updated android libraries. There are also some community bug fixes: > > fix a bug with the foreground/isInline flag > fix bug with android not sending cached message > Automate plugin testing using grunt-cordova-plugin-jasmine. > > Thank you TadeasKriz and keithdmoore for contributing > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140708/7bd836b8/attachment.html From matzew at apache.org Tue Jul 8 03:07:55 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Tue, 8 Jul 2014 09:07:55 +0200 Subject: [aerogear-dev] Non-Java release processes Message-ID: Hi, at the face2face we had a discussion about formalizing our release processes for non-java project. The Java guide is, IMO, still relevant and up-to-date: https://github.com/aerogear/collateral/wiki/Release-Process-(Java) For the non-java projects I started a few gists * for Cordova and JavaScript, I think this could be used: https://gist.github.com/matzew/14f93693c8362b753782 Note: I am not sure if some extra steps are missing for things like npm oe bower * for iOS, I think we can formalize on something like this: https://gist.github.com/matzew/941883df5bd0abcf1d61 Greetings, Matthias -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140708/40e8fe9a/attachment-0001.html From scm.blanc at gmail.com Tue Jul 8 03:16:23 2014 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Tue, 8 Jul 2014 09:16:23 +0200 Subject: [aerogear-dev] Non-Java release processes In-Reply-To: References: Message-ID: On Tue, Jul 8, 2014 at 9:07 AM, Matthias Wessendorf wrote: > Hi, > > at the face2face we had a discussion about formalizing our release > processes for non-java project. > The Java guide is, IMO, still relevant and up-to-date: > https://github.com/aerogear/collateral/wiki/Release-Process-(Java) > > > For the non-java projects I started a few gists > > * for Cordova and JavaScript, I think this could be used: > https://gist.github.com/matzew/14f93693c8362b753782 > +1 but we need also instructions on the release process on the cordova plugin repo > Note: I am not sure if some extra steps are missing for things like npm oe > bower > > * for iOS, I think we can formalize on something like this: > https://gist.github.com/matzew/941883df5bd0abcf1d61 > > > Greetings, > Matthias > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140708/97a5383f/attachment.html From avibelli at redhat.com Tue Jul 8 03:17:56 2014 From: avibelli at redhat.com (Andrea Vibelli) Date: Tue, 8 Jul 2014 00:17:56 -0700 (PDT) Subject: [aerogear-dev] [release] parent / bom new release ? In-Reply-To: References: Message-ID: <1404803876358-8306.post@n5.nabble.com> Hi Matt, +1 for the release of a new version, it will also help polishing the pom.xml of the UnifiedPush Server. Thanks! Andrea -- View this message in context: http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-release-parent-bom-new-release-tp8300p8306.html Sent from the aerogear-dev mailing list archive at Nabble.com. From matzew at apache.org Tue Jul 8 03:24:16 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Tue, 8 Jul 2014 09:24:16 +0200 Subject: [aerogear-dev] Non-Java release processes In-Reply-To: References: Message-ID: On Tue, Jul 8, 2014 at 9:16 AM, Sebastien Blanc wrote: > > > > On Tue, Jul 8, 2014 at 9:07 AM, Matthias Wessendorf > wrote: > >> Hi, >> >> at the face2face we had a discussion about formalizing our release >> processes for non-java project. >> The Java guide is, IMO, still relevant and up-to-date: >> https://github.com/aerogear/collateral/wiki/Release-Process-(Java) >> >> >> For the non-java projects I started a few gists >> >> * for Cordova and JavaScript, I think this could be used: >> https://gist.github.com/matzew/14f93693c8362b753782 >> > > +1 but we need also instructions on the release process on the cordova > plugin repo > isn't that just doing a TAG on our gh repo? If not, indeed, we would need this extra info in there > > >> Note: I am not sure if some extra steps are missing for things like npm >> oe bower >> >> * for iOS, I think we can formalize on something like this: >> https://gist.github.com/matzew/941883df5bd0abcf1d61 >> >> >> Greetings, >> Matthias >> >> >> -- >> Matthias Wessendorf >> >> blog: http://matthiaswessendorf.wordpress.com/ >> sessions: http://www.slideshare.net/mwessendorf >> twitter: http://twitter.com/mwessendorf >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140708/d71fa1ab/attachment.html From daniel.bevenius at gmail.com Tue Jul 8 03:26:03 2014 From: daniel.bevenius at gmail.com (Daniel Bevenius) Date: Tue, 8 Jul 2014 09:26:03 +0200 Subject: [aerogear-dev] DockerFiles Message-ID: Hi, just wanted to give a heads up that we now have a directory in: https://github.com/jboss/dockerfiles We have added a docker file for AeroGear SimplePush Server and we can add more just be following the conventions (like servers in the server dir etc). The naming convention used at the moment the following: jboss/aerogear-simplepush-server You can find the it in the docker.io repository under: https://registry.hub.docker.com/u/jboss/aerogear-simplepush-server/ /Dan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140708/f3f18b04/attachment.html From edewit at redhat.com Tue Jul 8 03:27:50 2014 From: edewit at redhat.com (Erik Jan de Wit) Date: Tue, 8 Jul 2014 09:27:50 +0200 Subject: [aerogear-dev] Non-Java release processes In-Reply-To: References: Message-ID: <910958D6-92D5-4250-9A01-64DB5D124298@redhat.com> On 8 Jul,2014, at 9:24 , Matthias Wessendorf wrote: > > > > On Tue, Jul 8, 2014 at 9:16 AM, Sebastien Blanc wrote: > > > > On Tue, Jul 8, 2014 at 9:07 AM, Matthias Wessendorf wrote: > Hi, > > at the face2face we had a discussion about formalizing our release processes for non-java project. > The Java guide is, IMO, still relevant and up-to-date: > https://github.com/aerogear/collateral/wiki/Release-Process-(Java) > > > For the non-java projects I started a few gists > > * for Cordova and JavaScript, I think this could be used: > https://gist.github.com/matzew/14f93693c8362b753782 > > +1 but we need also instructions on the release process on the cordova plugin repo > > isn't that just doing a TAG on our gh repo? If not, indeed, we would need this extra info in there So for Cordova there are 2 extra steps needed, change the version number in the plugin.xml file and push the plugin to plugins.cordova.io with plugman. And one more thing is update the site (aerogear.org) to change the download link > > > > Note: I am not sure if some extra steps are missing for things like npm oe bower > > * for iOS, I think we can formalize on something like this: > https://gist.github.com/matzew/941883df5bd0abcf1d61 > > > Greetings, > Matthias > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140708/6a7f2b3a/attachment.html From scm.blanc at gmail.com Tue Jul 8 03:28:19 2014 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Tue, 8 Jul 2014 09:28:19 +0200 Subject: [aerogear-dev] DockerFiles In-Reply-To: References: Message-ID: Awesome ! Can't wait to see UPS there ! On Tue, Jul 8, 2014 at 9:26 AM, Daniel Bevenius wrote: > Hi, > > just wanted to give a heads up that we now have a directory in: > https://github.com/jboss/dockerfiles > > We have added a docker file for AeroGear SimplePush Server and we can add > more just be following the conventions (like servers in the server dir > etc). > > The naming convention used at the moment the following: > jboss/aerogear-simplepush-server > > You can find the it in the docker.io repository under: > https://registry.hub.docker.com/u/jboss/aerogear-simplepush-server/ > > /Dan > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140708/9bb30f1c/attachment-0001.html From scm.blanc at gmail.com Tue Jul 8 03:30:12 2014 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Tue, 8 Jul 2014 09:30:12 +0200 Subject: [aerogear-dev] Non-Java release processes In-Reply-To: <910958D6-92D5-4250-9A01-64DB5D124298@redhat.com> References: <910958D6-92D5-4250-9A01-64DB5D124298@redhat.com> Message-ID: On Tue, Jul 8, 2014 at 9:27 AM, Erik Jan de Wit wrote: > > On 8 Jul,2014, at 9:24 , Matthias Wessendorf wrote: > > > > > On Tue, Jul 8, 2014 at 9:16 AM, Sebastien Blanc > wrote: > >> >> >> >> On Tue, Jul 8, 2014 at 9:07 AM, Matthias Wessendorf >> wrote: >> >>> Hi, >>> >>> at the face2face we had a discussion about formalizing our release >>> processes for non-java project. >>> The Java guide is, IMO, still relevant and up-to-date: >>> https://github.com/aerogear/collateral/wiki/Release-Process-(Java) >>> >>> >>> For the non-java projects I started a few gists >>> >>> * for Cordova and JavaScript, I think this could be used: >>> https://gist.github.com/matzew/14f93693c8362b753782 >>> >> >> +1 but we need also instructions on the release process on the cordova >> plugin repo >> > > isn't that just doing a TAG on our gh repo? If not, indeed, we would need > this extra info in there > > > So for Cordova there are 2 extra steps needed, change the version number > in the plugin.xml file and push the plugin to plugins.cordova.io with > plugman. > > And one more thing is update the site (aerogear.org) to change the > download link > Maybe you can fork Matzew's Gist and add these steps and post the link back here ? > > >> >> >>> Note: I am not sure if some extra steps are missing for things like npm >>> oe bower >>> >>> * for iOS, I think we can formalize on something like this: >>> https://gist.github.com/matzew/941883df5bd0abcf1d61 >>> >>> >>> Greetings, >>> Matthias >>> >>> >>> -- >>> Matthias Wessendorf >>> >>> blog: http://matthiaswessendorf.wordpress.com/ >>> sessions: http://www.slideshare.net/mwessendorf >>> twitter: http://twitter.com/mwessendorf >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140708/bdc7fb49/attachment.html From daniel.bevenius at gmail.com Tue Jul 8 03:34:53 2014 From: daniel.bevenius at gmail.com (Daniel Bevenius) Date: Tue, 8 Jul 2014 09:34:53 +0200 Subject: [aerogear-dev] DockerFiles In-Reply-To: References: Message-ID: I was a little quick posting there. This image is now online: https://registry.hub.docker.com/u/jboss/aerogear-simplepush-server/ On 8 July 2014 09:28, Sebastien Blanc wrote: > Awesome ! > Can't wait to see UPS there ! > > > On Tue, Jul 8, 2014 at 9:26 AM, Daniel Bevenius > wrote: > >> Hi, >> >> just wanted to give a heads up that we now have a directory in: >> https://github.com/jboss/dockerfiles >> >> We have added a docker file for AeroGear SimplePush Server and we can add >> more just be following the conventions (like servers in the server dir >> etc). >> >> The naming convention used at the moment the following: >> jboss/aerogear-simplepush-server >> >> You can find the it in the docker.io repository under: >> https://registry.hub.docker.com/u/jboss/aerogear-simplepush-server/ >> >> /Dan >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140708/01105efb/attachment.html From edewit at redhat.com Tue Jul 8 03:43:33 2014 From: edewit at redhat.com (Erik Jan de Wit) Date: Tue, 8 Jul 2014 09:43:33 +0200 Subject: [aerogear-dev] Non-Java release processes In-Reply-To: References: <910958D6-92D5-4250-9A01-64DB5D124298@redhat.com> Message-ID: > > So for Cordova there are 2 extra steps needed, change the version number in the plugin.xml file and push the plugin to plugins.cordova.io with plugman. > > And one more thing is update the site (aerogear.org) to change the download link > Maybe you can fork Matzew's Gist and add these steps and post the link back here ? https://gist.github.com/edewit/57ba08f2351297e1336c -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140708/44b14aa9/attachment.html From scm.blanc at gmail.com Tue Jul 8 03:48:47 2014 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Tue, 8 Jul 2014 09:48:47 +0200 Subject: [aerogear-dev] [RELEASE] aerogear-simplepush-java-client 0.1.0 In-Reply-To: References: Message-ID: FYI , It's now available on Maven Central \o/ http://search.maven.org/#artifactdetails%7Corg.jboss.aerogear%7Caerogear-simplepush-java-client%7C0.1.0%7Cjar On Mon, Jul 7, 2014 at 1:42 PM, Matthias Wessendorf wrote: > nice! > > can you add that to 'push section' on the download.html page ? > http://aerogear.org/download/ > > > On Mon, Jul 7, 2014 at 9:36 AM, Sebastien Blanc > wrote: > >> FYI I have just released this version and now just waiting for Maven >> Central to sync ! >> >> >> >> >> On Fri, Jul 4, 2014 at 8:30 AM, Matthias Wessendorf >> wrote: >> >>> Hi Sebi, >>> >>> I was able to test this version against Mozilla's Push Service Network, >>> using the following code: >>> https://gist.github.com/matzew/fd3f85a01aa3e46157c7 >>> >>> I used a vanilla CURL to send messages/updates >>> >>> >>> >>> +1 on that release >>> >>> >>> >>> >>> On Thu, Jul 3, 2014 at 11:18 AM, Sebastien Blanc >>> wrote: >>> >>>> Folks ! >>>> I'm happy to announce that aerogear-simplepush-java-client 0.1.0 has >>>> been staged. >>>> >>>> The big change is that we are now relying on Matzew's Java Simple >>>> WebSocket Client[1] and that we have an extended test suite which test this >>>> library against : Tyrus, Netty, Vertx and Undertow ! >>>> >>>> Wondering what you can do with this library ? Basically any Device that >>>> can run the JVM can now receive Push Notifications through the SimplePush >>>> Protocol. >>>> >>>> For instance, receiving Push Notifications on your Raspberry PI : >>>> https://www.youtube.com/watch?v=PpPNSu2ENUA >>>> >>>> Or on a Lego EV3 Robot : https://www.youtube.com/watch?v=4uqfcqq42es >>>> >>>> A lot of other feature are possible, like an Eclipse Plugin to receive >>>> notification in your IDE. >>>> >>>> This library has also full support for the AeroGear UnifiedPush Server, >>>> meaning it can register to it ! >>>> >>>> Have fun and go crazy, the staging repository is located here : >>>> https://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-3507 >>>> >>>> Sebi >>>> >>>> >>>> [1]https://github.com/matzew/simple-websocket-client >>>> >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> >>> >>> >>> >>> -- >>> Matthias Wessendorf >>> >>> blog: http://matthiaswessendorf.wordpress.com/ >>> sessions: http://www.slideshare.net/mwessendorf >>> twitter: http://twitter.com/mwessendorf >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140708/db89c683/attachment-0001.html From daniel.bevenius at gmail.com Tue Jul 8 03:50:28 2014 From: daniel.bevenius at gmail.com (Daniel Bevenius) Date: Tue, 8 Jul 2014 09:50:28 +0200 Subject: [aerogear-dev] [RELEASE] aerogear-simplepush-java-client 0.1.0 In-Reply-To: References: Message-ID: Nice! On 8 July 2014 09:48, Sebastien Blanc wrote: > FYI , > It's now available on Maven Central \o/ > > > http://search.maven.org/#artifactdetails%7Corg.jboss.aerogear%7Caerogear-simplepush-java-client%7C0.1.0%7Cjar > > > > > On Mon, Jul 7, 2014 at 1:42 PM, Matthias Wessendorf > wrote: > >> nice! >> >> can you add that to 'push section' on the download.html page ? >> http://aerogear.org/download/ >> >> >> On Mon, Jul 7, 2014 at 9:36 AM, Sebastien Blanc >> wrote: >> >>> FYI I have just released this version and now just waiting for Maven >>> Central to sync ! >>> >>> >>> >>> >>> On Fri, Jul 4, 2014 at 8:30 AM, Matthias Wessendorf >>> wrote: >>> >>>> Hi Sebi, >>>> >>>> I was able to test this version against Mozilla's Push Service Network, >>>> using the following code: >>>> https://gist.github.com/matzew/fd3f85a01aa3e46157c7 >>>> >>>> I used a vanilla CURL to send messages/updates >>>> >>>> >>>> >>>> +1 on that release >>>> >>>> >>>> >>>> >>>> On Thu, Jul 3, 2014 at 11:18 AM, Sebastien Blanc >>>> wrote: >>>> >>>>> Folks ! >>>>> I'm happy to announce that aerogear-simplepush-java-client 0.1.0 has >>>>> been staged. >>>>> >>>>> The big change is that we are now relying on Matzew's Java Simple >>>>> WebSocket Client[1] and that we have an extended test suite which test this >>>>> library against : Tyrus, Netty, Vertx and Undertow ! >>>>> >>>>> Wondering what you can do with this library ? Basically any Device >>>>> that can run the JVM can now receive Push Notifications through the >>>>> SimplePush Protocol. >>>>> >>>>> For instance, receiving Push Notifications on your Raspberry PI : >>>>> https://www.youtube.com/watch?v=PpPNSu2ENUA >>>>> >>>>> Or on a Lego EV3 Robot : https://www.youtube.com/watch?v=4uqfcqq42es >>>>> >>>>> A lot of other feature are possible, like an Eclipse Plugin to receive >>>>> notification in your IDE. >>>>> >>>>> This library has also full support for the AeroGear UnifiedPush >>>>> Server, meaning it can register to it ! >>>>> >>>>> Have fun and go crazy, the staging repository is located here : >>>>> https://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-3507 >>>>> >>>>> Sebi >>>>> >>>>> >>>>> [1]https://github.com/matzew/simple-websocket-client >>>>> >>>>> _______________________________________________ >>>>> aerogear-dev mailing list >>>>> aerogear-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>> >>>> >>>> >>>> >>>> -- >>>> Matthias Wessendorf >>>> >>>> blog: http://matthiaswessendorf.wordpress.com/ >>>> sessions: http://www.slideshare.net/mwessendorf >>>> twitter: http://twitter.com/mwessendorf >>>> >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> >>> >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >> >> >> >> -- >> Matthias Wessendorf >> >> blog: http://matthiaswessendorf.wordpress.com/ >> sessions: http://www.slideshare.net/mwessendorf >> twitter: http://twitter.com/mwessendorf >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140708/f738177f/attachment.html From cvasilak at gmail.com Tue Jul 8 04:12:04 2014 From: cvasilak at gmail.com (Christos Vasilakis) Date: Tue, 8 Jul 2014 11:12:04 +0300 Subject: [aerogear-dev] Non-Java release processes In-Reply-To: References: Message-ID: > On Jul 8, 2014, at 10:07 AM, Matthias Wessendorf wrote: > > Hi, > > at the face2face we had a discussion about formalizing our release processes for non-java project. > The Java guide is, IMO, still relevant and up-to-date: > https://github.com/aerogear/collateral/wiki/Release-Process-(Java) > > > For the non-java projects I started a few gists > > * for Cordova and JavaScript, I think this could be used: > https://gist.github.com/matzew/14f93693c8362b753782 > > Note: I am not sure if some extra steps are missing for things like npm oe bower > > * for iOS, I think we can formalize on something like this: > https://gist.github.com/matzew/941883df5bd0abcf1d61 looks good +1 did some changes here [1] and modified the ?Perform? section adding cocoapods new approach to spec publish and the step to update the spec itself. If we are fine with it, will go ahead and add it on our 'https://github.com/aerogear/collateral/wiki' Thanks Christos [1] https://gist.github.com/cvasilak/114c7280b627ae6bcd9f [ > > > Greetings, > Matthias > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140708/cf6efb0c/attachment.html From corinnekrych at gmail.com Tue Jul 8 04:17:03 2014 From: corinnekrych at gmail.com (Corinne Krych) Date: Tue, 8 Jul 2014 10:17:03 +0200 Subject: [aerogear-dev] Non-Java release processes In-Reply-To: References: Message-ID: <8FB4F8C8-208E-458E-9436-0F1D15CB9A8B@gmail.com> On 08 Jul 2014, at 10:12, Christos Vasilakis wrote: >> >> On Jul 8, 2014, at 10:07 AM, Matthias Wessendorf wrote: >> >> Hi, >> >> at the face2face we had a discussion about formalizing our release processes for non-java project. >> The Java guide is, IMO, still relevant and up-to-date: >> https://github.com/aerogear/collateral/wiki/Release-Process-(Java) >> >> >> For the non-java projects I started a few gists >> >> * for Cordova and JavaScript, I think this could be used: >> https://gist.github.com/matzew/14f93693c8362b753782 >> >> Note: I am not sure if some extra steps are missing for things like npm oe bower >> >> * for iOS, I think we can formalize on something like this: >> https://gist.github.com/matzew/941883df5bd0abcf1d61 > > looks good +1 > did some changes here [1] and modified the ?Perform? section adding cocoapods new approach to spec publish and the step to update the spec itself. > > If we are fine with it, will go ahead and add it on our 'https://github.com/aerogear/collateral/wiki' > don?t we miss: - step 0: ?send PR to cocoapod? - step 5: update all demo Podfile with relevant tag > Thanks > Christos > > [1] https://gist.github.com/cvasilak/114c7280b627ae6bcd9f > > [ >> >> >> Greetings, >> Matthias >> >> >> -- >> Matthias Wessendorf >> >> blog: http://matthiaswessendorf.wordpress.com/ >> sessions: http://www.slideshare.net/mwessendorf >> twitter: http://twitter.com/mwessendorf >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev From matzew at apache.org Tue Jul 8 04:20:35 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Tue, 8 Jul 2014 10:20:35 +0200 Subject: [aerogear-dev] Non-Java release processes In-Reply-To: <8FB4F8C8-208E-458E-9436-0F1D15CB9A8B@gmail.com> References: <8FB4F8C8-208E-458E-9436-0F1D15CB9A8B@gmail.com> Message-ID: On Tue, Jul 8, 2014 at 10:17 AM, Corinne Krych wrote: > > On 08 Jul 2014, at 10:12, Christos Vasilakis wrote: > > >> > >> On Jul 8, 2014, at 10:07 AM, Matthias Wessendorf > wrote: > >> > >> Hi, > >> > >> at the face2face we had a discussion about formalizing our release > processes for non-java project. > >> The Java guide is, IMO, still relevant and up-to-date: > >> https://github.com/aerogear/collateral/wiki/Release-Process-(Java) > >> > >> > >> For the non-java projects I started a few gists > >> > >> * for Cordova and JavaScript, I think this could be used: > >> https://gist.github.com/matzew/14f93693c8362b753782 > >> > >> Note: I am not sure if some extra steps are missing for things like npm > oe bower > >> > >> * for iOS, I think we can formalize on something like this: > >> https://gist.github.com/matzew/941883df5bd0abcf1d61 > > > > looks good +1 > > did some changes here [1] and modified the ?Perform? section adding > cocoapods new approach to spec publish and the step to update the spec > itself. > > > > If we are fine with it, will go ahead and add it on our ' > https://github.com/aerogear/collateral/wiki' > > > > > don?t we miss: > - step 0: ?send PR to cocoapod? > I have that in my gist > - step 5: update all demo Podfile with relevant tag > good call ! > > > Thanks > > Christos > > > > [1] https://gist.github.com/cvasilak/114c7280b627ae6bcd9f > > > > [ > >> > >> > >> Greetings, > >> Matthias > >> > >> > >> -- > >> Matthias Wessendorf > >> > >> blog: http://matthiaswessendorf.wordpress.com/ > >> sessions: http://www.slideshare.net/mwessendorf > >> twitter: http://twitter.com/mwessendorf > >> _______________________________________________ > >> aerogear-dev mailing list > >> aerogear-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140708/b53f7f88/attachment-0001.html From cvasilak at gmail.com Tue Jul 8 04:29:25 2014 From: cvasilak at gmail.com (Christos Vasilakis) Date: Tue, 8 Jul 2014 11:29:25 +0300 Subject: [aerogear-dev] Non-Java release processes In-Reply-To: <8FB4F8C8-208E-458E-9436-0F1D15CB9A8B@gmail.com> References: <8FB4F8C8-208E-458E-9436-0F1D15CB9A8B@gmail.com> Message-ID: <9E6655A3-CA1C-49DD-8761-BF50B41F82A6@gmail.com> > On Jul 8, 2014, at 11:17 AM, Corinne Krych wrote: > > > On 08 Jul 2014, at 10:12, Christos Vasilakis wrote: > >>> >>> On Jul 8, 2014, at 10:07 AM, Matthias Wessendorf wrote: >>> >>> Hi, >>> >>> at the face2face we had a discussion about formalizing our release processes for non-java project. >>> The Java guide is, IMO, still relevant and up-to-date: >>> https://github.com/aerogear/collateral/wiki/Release-Process-(Java) >>> >>> >>> For the non-java projects I started a few gists >>> >>> * for Cordova and JavaScript, I think this could be used: >>> https://gist.github.com/matzew/14f93693c8362b753782 >>> >>> Note: I am not sure if some extra steps are missing for things like npm oe bower >>> >>> * for iOS, I think we can formalize on something like this: >>> https://gist.github.com/matzew/941883df5bd0abcf1d61 >> >> looks good +1 >> did some changes here [1] and modified the ?Perform? section adding cocoapods new approach to spec publish and the step to update the spec itself. >> >> If we are fine with it, will go ahead and add it on our 'https://github.com/aerogear/collateral/wiki' >> > > > don?t we miss: > - step 0: ?send PR to cocoa pod? this step was replaced from cocoa pods with the 'pod trunk push? command, no need to send PR on their repo any more. That was my update on matzew gist :) > - step 5: update all demo Podfile with relevant tag +1, have updated my gist[1] with this step too Thanks, Christos > >> Thanks >> Christos >> >> [1] https://gist.github.com/cvasilak/114c7280b627ae6bcd9f >> >> [ >>> >>> >>> Greetings, >>> Matthias >>> >>> >>> -- >>> Matthias Wessendorf >>> >>> blog: http://matthiaswessendorf.wordpress.com/ >>> sessions: http://www.slideshare.net/mwessendorf >>> twitter: http://twitter.com/mwessendorf >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev From corinnekrych at gmail.com Tue Jul 8 04:31:16 2014 From: corinnekrych at gmail.com (Corinne Krych) Date: Tue, 8 Jul 2014 10:31:16 +0200 Subject: [aerogear-dev] Non-Java release processes In-Reply-To: <9E6655A3-CA1C-49DD-8761-BF50B41F82A6@gmail.com> References: <8FB4F8C8-208E-458E-9436-0F1D15CB9A8B@gmail.com> <9E6655A3-CA1C-49DD-8761-BF50B41F82A6@gmail.com> Message-ID: <5831F96D-8A89-465E-A5D3-1CD8063215B4@gmail.com> On 08 Jul 2014, at 10:29, Christos Vasilakis wrote: >> >> On Jul 8, 2014, at 11:17 AM, Corinne Krych wrote: >> >> >> On 08 Jul 2014, at 10:12, Christos Vasilakis wrote: >> >>>> >>>> On Jul 8, 2014, at 10:07 AM, Matthias Wessendorf wrote: >>>> >>>> Hi, >>>> >>>> at the face2face we had a discussion about formalizing our release processes for non-java project. >>>> The Java guide is, IMO, still relevant and up-to-date: >>>> https://github.com/aerogear/collateral/wiki/Release-Process-(Java) >>>> >>>> >>>> For the non-java projects I started a few gists >>>> >>>> * for Cordova and JavaScript, I think this could be used: >>>> https://gist.github.com/matzew/14f93693c8362b753782 >>>> >>>> Note: I am not sure if some extra steps are missing for things like npm oe bower >>>> >>>> * for iOS, I think we can formalize on something like this: >>>> https://gist.github.com/matzew/941883df5bd0abcf1d61 >>> >>> looks good +1 >>> did some changes here [1] and modified the ?Perform? section adding cocoapods new approach to spec publish and the step to update the spec itself. >>> >>> If we are fine with it, will go ahead and add it on our 'https://github.com/aerogear/collateral/wiki' >>> >> >> >> don?t we miss: >> - step 0: ?send PR to cocoa pod? > > this step was replaced from cocoa pods with the 'pod trunk push? command, no need to send PR on their repo any more. That was my update on matzew gist :) Ahhhh! Good to clarify with a doc actually :) > > >> - step 5: update all demo Podfile with relevant tag > > +1, have updated my gist[1] with this step too > > Thanks, > Christos > > > > >> >>> Thanks >>> Christos >>> >>> [1] https://gist.github.com/cvasilak/114c7280b627ae6bcd9f >>> >>> [ >>>> >>>> >>>> Greetings, >>>> Matthias >>>> >>>> >>>> -- >>>> Matthias Wessendorf >>>> >>>> blog: http://matthiaswessendorf.wordpress.com/ >>>> sessions: http://www.slideshare.net/mwessendorf >>>> twitter: http://twitter.com/mwessendorf >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev From matzew at apache.org Tue Jul 8 05:26:22 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Tue, 8 Jul 2014 11:26:22 +0200 Subject: [aerogear-dev] Openshift was updated as well (was: Re: It's out now (was Re: Release of UnifiedPush Server 0.11)) Message-ID: The Openshift offering of AeroGear Push was updated to use the latest of our UnifiedPush and SimplePush Servers (both version 0.11.0) Give it a try: https://openshift.redhat.com/app/console/application_type/quickstart!15549 -Matthias On Mon, Jul 7, 2014 at 11:11 AM, Matthias Wessendorf wrote: > Folks, > > the 0.11.0 got released: > http://matthiaswessendorf.wordpress.com/2014/07/07/unifiedpush-0-11/ > > Feedback more than welcome! > > Thanks to the entire team for this great amount of work. Special thanks to > the Keycloak team for their support and getting in features that were > required to make the smooth integration happen. > > Thanks! <3 > > -Matthias > > > On Thu, Jul 3, 2014 at 3:35 PM, Matthias Wessendorf > wrote: > >> Based on QE feedback provided via IRC, here is a new staging repository: >> >> >> http://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-3508/ >> >> Let me know by end of Friday, so we can celebrate the release next week! >> >> >> -Matthias >> >> >> On Tue, Jul 1, 2014 at 12:31 PM, Matthias Wessendorf >> wrote: >> >>> Ahoy folks! >>> >>> we have been extremely busy over the last few weeks and we are getting >>> closer to our 1.0.0 release. That was a lot of work and I am very happy >>> with the results. >>> >>> THANKS A LOT!!!!!!!! >>> >>> >>> However, before we are moving towards the 1.0.0 community release, I'd >>> love to get the current work out as 0.11. Note this release contains a ton >>> of work and new features. To name a few highlights: >>> >>> * New AdminUI >>> ** a complete rewrite to go with Angular.js >>> * Keycloak integration >>> ** user-management and auth is no longer done by the UPS itself. We >>> bundle a Keycloak auth server in a separate WAR file >>> * Analytics and Metrics >>> ** get some details about your applications, the devices and the status >>> of the submitted push request job to the 3rd party provider >>> >>> Besides these big changes, a ton of more work was done by the team: >>> >>> https://issues.jboss.org/browse/AGPUSH/fixforversion/12321883/?selectedTab=com.atlassian.jira.jira-projects-plugin:version-issues-panel >>> >>> The staging repository is located here: >>> >>> http://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-3490/ >>> >>> NOTE! This release will not make it to OpenShift yet, as that involves a >>> bit more of testing, as discussed a few weeks ago on IRC >>> >>> >>> Let me know the results of your testing; >>> If I hear nothing bad by Thursday evening, the release to maven central >>> will happen on Friday; >>> >>> The offical announcement will go out AFTER the long weekend (4th of July) >>> >>> >>> Greetings, >>> Matthias >>> >>> -- >>> Matthias Wessendorf >>> >>> blog: http://matthiaswessendorf.wordpress.com/ >>> sessions: http://www.slideshare.net/mwessendorf >>> twitter: http://twitter.com/mwessendorf >>> >> >> >> >> -- >> Matthias Wessendorf >> >> blog: http://matthiaswessendorf.wordpress.com/ >> sessions: http://www.slideshare.net/mwessendorf >> twitter: http://twitter.com/mwessendorf >> > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140708/1f93f56b/attachment.html From vivek.pandey at pinelabs.com Tue Jul 8 08:06:22 2014 From: vivek.pandey at pinelabs.com (Vivek Pandey) Date: Tue, 8 Jul 2014 17:36:22 +0530 Subject: [aerogear-dev] UPS Production worthiness In-Reply-To: References: <002b01cf7424$528dc0a0$f7a941e0$@pinelabs.com> <005d01cf74ed$3d977140$b8c653c0$@pinelabs.com> <003c01cf78cd$1095df40$31c19dc0$@pinelabs.com> <17C1B903-C13B-482F-93FA-1B9B55AEF707@redhat.com> <008f01cf9603$9cf11fb0$d6d35f10$@pinelabs.com> Message-ID: <008701cf9aa5$09290bc0$1b7b2340$@pinelabs.com> Hi Matthias/UPS Team, I have put together a patch which shows the changes I had to make to get the requisite performance from UPS. Please find the same attached. The patch has my changes along with Eric?s changes merged on 0.10.4 branch. I had to do some hacky changes to prevent all the installations from getting serialized to UI. That should ideally be handled by removing this requirement and making corresponding changes to UI code. I will learn GIT and put together a PR for these changes as soon as I can. Thanks, Vivek From: mwessendorf at gmail.com [mailto:mwessendorf at gmail.com] On Behalf Of Matthias Wessendorf Sent: Wednesday, July 02, 2014 8:15 PM To: vivek.pandey at pinelabs.com Cc: AeroGear Developer Mailing List Subject: Re: [aerogear-dev] UPS Production worthiness Hello vivek! thanks for the reply! Absolutely a PR is more than welcome! If you have interest and the bandwidth, we would really appreciate that ! @importer: I still think it's a nice thing to have :-) -Matthias On Wed, Jul 2, 2014 at 4:40 PM, Vivek Pandey wrote: Hello Matthias, An ?importer? might help, but smaller changes in existing domain/service might help more. I ran a stress test on the installation endpoint yesterday, after merging Eric?s changes on source code of 0.10.x branch. I saw that even after using the merged code, the response worsened continuously. Looking closing, I saw that GenericVariantServiceImpl. addInstallation causes initialization of the now ?lazy? collection AbstractVariant.installations. I changed the model a bit, by adding variantID to Installation, and made it the owner of the variant-installation relationship. That changed the code in InstallationRegistrationEndpoint. registerInstallation from // store the installation: entity = clientInstallationService.addInstallation(entity); // add installation to the matching variant genericVariantService.addInstallation(variant, entity); to // store the installation: entity.setVariantID(variant); entity = clientInstallationService.addInstallation(entity); This fixed the problem for me and now I am getting constant time installation registration with dramatically better performance Please let me know if you want me to add this to AGPUSH-661 Thanks Vivek From: mwessendorf at gmail.com [mailto:mwessendorf at gmail.com] On Behalf Of Matthias Wessendorf Sent: Wednesday, July 02, 2014 6:26 PM To: AeroGear Developer Mailing List; vivek.pandey at pinelabs.com Subject: Re: [aerogear-dev] UPS Production worthiness Hello Vivek, On Mon, May 26, 2014 at 1:23 PM, Matthias Wessendorf wrote: On Mon, May 26, 2014 at 12:59 PM, Erik Jan de Wit wrote: Hi Vivek, We?ve fixed that https://github.com/aerogear/aerogear-unifiedpush-server/commit/1357c9e834286a9227a90e9ab618226aa54bbbf3 the collection is now lazy. But I?m sure other query optimisations can be made. +1 btw. Vivek, I added your mail to an existing ticket: https://issues.jboss.org/browse/AGPUSH-661 coming back from vacation and going over the JIRAs, I was wondering if an 'importer' helps? That would be a RESTful endpoint that accepts a JSON file, containing all the devices you want to register (for a given variant). That way it would be also a bit nicer on your side, to perform the import: * generate a "large" JSON file (instead of a ton of requests) * only one HTTP request * server accepts and will process it in the background I think that would be a nice migration tool. Let me know what you think! -Matthias -Matthias Cheers, Erik Jan On 26 May,2014, at 12:27 , Vivek Pandey wrote: Hi Matthias, It is good to know that activity in java-apns is picking up and also that you are looking at pushy. I did a few tests which added installations to UPS with a concurrency of 4-8 threads. I was using Postgres 9.3 and UPS 0.10.3 war I noticed that response slowed down considerably after some time with high CPU usage and continued to get worse. After doing some profiling, I found that bulk of CPU cycles are being taken by org.postgresql.core.VisibleBufferedInputStream.readMore. The entire thread stack is attached. Also postgres continuously flagged select installati0_.variantID as variant10_0_0_, installati0_.id as id1_3_0_, installati0_.id as id1_3_1_, installati0_.alias as alias2_3_1_, installati0_.deviceToken as deviceTo3_3_1_, installati0_.deviceType as deviceTy4_3_1_, installati0_.enabled as enabled5_3_1_, installati0_.operatingSystem as operatin6_3_1_, installati0_.osVersion as osVersio7_3_1_, installati0_.platform as platform8_3_1_, installati0_.simplePushEndpoint as simplePu9_3_1_ from InstallationImpl installati0_ where installati0_.variantID=$1 as the slow query. I am pretty sure that eager collection AbstractVariant.installations is the root cause of the problem. Please let me know if you need any more information. Thanks Vivek From: mwessendorf at gmail.com [ mailto:mwessendorf at gmail.com] On Behalf Of Matthias Wessendorf Sent: Wednesday, May 21, 2014 5:55 PM To: vivek.pandey at pinelabs.com; AeroGear Developer Mailing List Subject: Re: [aerogear-dev] UPS Production worthiness Hello Vivek! On Wed, May 21, 2014 at 2:07 PM, Vivek Pandey < vivek.pandey at pinelabs.com> wrote: Hi Jay, Thanks for your reply. While we have not faced any issues in using UPS in our limited testing, I often see info stacktraces in ups logs 2014-05-16 10:19:20,032 INFO [com.notnoop.apns.internal.ApnsConnectionImpl] (Thread-118) Exception while waiting for error code: java.net.SocketException: Socket closed at java.net.SocketInputStream.socketRead0(Native Method) [rt.jar:1.7.0_51] at java.net.SocketInputStream.read(SocketInputStream.java:152) [rt.jar:1.7.0_51] at java.net.SocketInputStream.read(SocketInputStream.java:122) [rt.jar:1.7.0_51] ????? at com.notnoop.apns.internal.ApnsConnectionImpl$1MonitoringThread.run(ApnsConnectionImpl.java:114) [apns-0.2.3.jar:] These stacktraces coupled with low dev activity of noop/java-apns project are disconcerting to me. the stack-trace is no harm - it's only happening w/ doing a monitoring of the thread (that's what we currently do, when setting up ApnsService - I thought about explicitly disable that) The activity of the underlying java-apns is very low, yes! However @froh42 is getting back: https://github.com/notnoop/java-apns/commits/master There will be a new release in the near future; @froh42 asked me if I could help with pushing the bits to maven central That said, I recently started looking at pushy: https://github.com/relayrides/pushy I also sent a PR that would allow us to feed pushy w/ our certificate from the database: https://github.com/relayrides/pushy/pull/87 Hope that helps -Matthias I am currently using UPS 0.10.2 war. Thanks, Vivek From: Jay Balunas [mailto: jbalunas at redhat.com] Sent: Tuesday, May 20, 2014 11:36 PM To: vivek.pandey at pinelabs.com; AeroGear Developer Mailing List Cc: Jay Balunas Subject: Re: [aerogear-dev] UPS Production worthiness Hi Vivek, It's awesome to hear that you have integrated the UPS into your backend systems and some of your mobile apps! We have a lot of confidence around the UPS, its functionality, and performance. Our team has been working hard on improvements and stability including our QE team. Also, as you may have seen we're planning a 1.0 release of the UPS this summer. However at this time we don't have specific references or success stories outside of what you can see in the community mailing lists - other users using it ;-) We're also about to kick off some performance and scale testing in the next couple of months. Have you run into any issues that drove these questions about production worthiness? If so please let us know and we'll certainly take a look. Hope this helps! Thanks, Jay Balunas On May 20, 2014, at 8:09 AM, Vivek Pandey < vivek.pandey at pinelabs.com> wrote: Hello Aerogear dev team, We integrated UPS into our backend server which is serving various mobile apps. While the development and testing phase went well, my manager is questioning me about production worthiness about Aerogear. It would be great help if you could point me to references/success stories where UPS is being used in production environments and scaling well in medium to high loads. Thanks, Vivek _____ This message may contain privileged and confidential information and is solely for the use of intended recipient. The views expressed in this email are those of the sender and not of Pine Labs. The recipient should check this email and attachments for the presence of viruses / malwares etc. Pine Labs accepts no liability for any damage caused by any virus transmitted by this email. Pine Labs may monitor and record all emails. _____ _______________________________________________ aerogear-dev mailing list aerogear-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev _____ This message may contain privileged and confidential information and is solely for the use of intended recipient. The views expressed in this email are those of the sender and not of Pine Labs. The recipient should check this email and attachments for the presence of viruses / malwares etc. Pine Labs accepts no liability for any damage caused by any virus transmitted by this email. Pine Labs may monitor and record all emails. _____ _______________________________________________ aerogear-dev mailing list aerogear-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf _____ This message may contain privileged and confidential information and is solely for the use of intended recipient. The views expressed in this email are those of the sender and not of Pine Labs. The recipient should check this email and attachments for the presence of viruses / malwares etc. Pine Labs accepts no liability for any damage caused by any virus transmitted by this email. Pine Labs may monitor and record all emails. _____ _______________________________________________ aerogear-dev mailing list aerogear-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev _______________________________________________ aerogear-dev mailing list aerogear-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf _____ This message may contain privileged and confidential information and is solely for the use of intended recipient. The views expressed in this email are those of the sender and not of Pine Labs. The recipient should check this email and attachments for the presence of viruses / malwares etc. Pine Labs accepts no liability for any damage caused by any virus transmitted by this email. Pine Labs may monitor and record all emails. _____ -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf This message may contain privileged and confidential information and is solely for the use of intended recipient. The views expressed in this email are those of the sender and not of Pine Labs. The recipient should check this email and attachments for the presence of viruses / malwares etc. Pine Labs accepts no liability for any damage caused by any virus transmitted by this email. Pine Labs may monitor and record all emails. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140708/7eb325b5/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: ups_changes_patch.patch Type: application/octet-stream Size: 13439 bytes Desc: not available Url : http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140708/7eb325b5/attachment-0001.obj From cvasilak at gmail.com Tue Jul 8 08:59:10 2014 From: cvasilak at gmail.com (cvasilak) Date: Tue, 8 Jul 2014 05:59:10 -0700 (PDT) Subject: [aerogear-dev] AeroGear iOS meeting In-Reply-To: <563318AC-1A4B-4934-856C-E6BA9637D292@gmail.com> References: <563318AC-1A4B-4934-856C-E6BA9637D292@gmail.com> Message-ID: <1404824350848-8323.post@n5.nabble.com> fyi, meeting minutes: Meeting ended Tue Jul 8 12:28:32 2014 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) Minutes: http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2014/aerogear.2014-07-08-11.42.html Minutes (text): http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2014/aerogear.2014-07-08-11.42.txt Log: http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2014/aerogear.2014-07-08-11.42.log.html -- View this message in context: http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-AeroGear-iOS-meeting-tp8251p8323.html Sent from the aerogear-dev mailing list archive at Nabble.com. From supittma at redhat.com Tue Jul 8 09:02:20 2014 From: supittma at redhat.com (Summers Pittman) Date: Tue, 08 Jul 2014 09:02:20 -0400 Subject: [aerogear-dev] LiveOak SDK In-Reply-To: <53BAC759.7030000@redhat.com> References: <53BAC759.7030000@redhat.com> Message-ID: <53BBEBDC.9000300@redhat.com> On Mon 07 Jul 2014 12:14:17 PM EDT, Matt Wringe wrote: > > Initial email to get some discussion going around the LiveOak SDK and > AeroGear collaboration. > > Essentially in LiveOak we are going to need a few different SDK types > > - Client Application SDK > This is the code which will run on the users device. Initial targets > here are javascript (+ cordova support), iOS, Android. This type of SDK > will handle things like getting and sending resources to and from the > server, handling login/logout/registration, etc. Probably some other > things like device registration would be needed as well. > > Not sure if we want to provide support for some other things outside of > communicating with the server or not (eg access to device components (eg > camera, location, etc)) or if these would be best handled by using the > native environment's SDK instead. > > - Server Side SDK > This is code that runs on the server side, written in JavaScript by the > application developer. This will need to be familiar to the client > application's JavaScript SDK, but may not be exactly the same. This type > of SDK will be able to access the same resources as the client side > JavaScript, as well as other internal resources and libraries. > > > I am not sure how to collaborate between the LiveOak and AeroGear teams > here. AeroGear makes really awesome SDKs for various mobile platforms, > but with LiveOak we are dealing with a specific type of application. The > AeroGear SDKs tend to handle the more generic case, which I don't > necessarily think makes sense for a LiveOak SDK. > > I do think it makes sense that the LiveOak SDK uses the AeroGear SDK > internally, but I don't know if we want to expose these AeroGear > components to a LiveOak developer or not. > > > For me, I envision something like the admin setting up their application > in the LiveOak console which then generates a json configuration file > (url locations, resources available, KeyCloak settings, UPS settings, > etc). The application developer then drops this json file in to their > application, the LiveOak SDK reads the json file to set it self up and > then its really easy for the developer to start using it. > > [there are also some really cool things we could be doing here as well > if we can get awesome data sync support for AeroGear. It might be > interesting to be able to fetch a resource from the server and > automatically sync its state across between the client and server. This > way the object appears as a local object: if the resource changes on the > server, it changes locally as well, if it changes locally, that change > is pushed to the server. This way you are just dealing with an object, > and not having to fetch and then push object back and forth between the > server manually] > > Anyone have any thoughts on this? One of the things which may be useful is aerogear-ios and aerogear-android are both modularizing their libraries. IN theory this means that the liveOAK SDK's could be extensions of those modules instead of a single monolothic thing. Sync is still an ongoing discussion in AeroGear, but I think right now the current group thought is that we will focus on 409 Conflict events (JPA versioning on server side and utilities on the client side) and not worrying about realtime sync. Some notes from out last meeting on the topic : Client API Strawman : https://github.com/secondsun/aerogear-android-sync/tree/master/android Client/Server workflow : https://docs.google.com/drawings/d/1E4NDEh3NQCdoEHNNHba4TR2akNrppvV5zDlk5nfzz08/edit Also we are looking at doing something with diff merge patch as well as adding in push based data changed notifications later. > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -- Summers Pittman >>Phone:404 941 4698 >>Java is my crack. From bsutter at redhat.com Tue Jul 8 09:11:04 2014 From: bsutter at redhat.com (Burr Sutter) Date: Tue, 8 Jul 2014 09:11:04 -0400 Subject: [aerogear-dev] LiveOak SDK In-Reply-To: <53BBEBDC.9000300@redhat.com> References: <53BAC759.7030000@redhat.com> <53BBEBDC.9000300@redhat.com> Message-ID: <1FDBF7E3-69D5-4C65-88F4-18A8416FEBC2@redhat.com> At a minimum, the same HTTP error codes used to indicate "sync errors" via JAX-RS + JPA should be the same for LiveOak's REST APIs - therefore the client-code can be reusable across the two endpoints. We should come up with sync strategies - levels 1, 2 and 3 - where 1 is simply the clever use of HTTP error codes and level 3 is real-time/off-line/auto-conflict resolution. Perhaps there are 4 levels :-) Anyone care to articulate the possible strategies? On Jul 8, 2014, at 9:02 AM, Summers Pittman wrote: > On Mon 07 Jul 2014 12:14:17 PM EDT, Matt Wringe wrote: >> >> Initial email to get some discussion going around the LiveOak SDK and >> AeroGear collaboration. >> >> Essentially in LiveOak we are going to need a few different SDK types >> >> - Client Application SDK >> This is the code which will run on the users device. Initial targets >> here are javascript (+ cordova support), iOS, Android. This type of SDK >> will handle things like getting and sending resources to and from the >> server, handling login/logout/registration, etc. Probably some other >> things like device registration would be needed as well. >> >> Not sure if we want to provide support for some other things outside of >> communicating with the server or not (eg access to device components (eg >> camera, location, etc)) or if these would be best handled by using the >> native environment's SDK instead. >> >> - Server Side SDK >> This is code that runs on the server side, written in JavaScript by the >> application developer. This will need to be familiar to the client >> application's JavaScript SDK, but may not be exactly the same. This type >> of SDK will be able to access the same resources as the client side >> JavaScript, as well as other internal resources and libraries. >> >> >> I am not sure how to collaborate between the LiveOak and AeroGear teams >> here. AeroGear makes really awesome SDKs for various mobile platforms, >> but with LiveOak we are dealing with a specific type of application. The >> AeroGear SDKs tend to handle the more generic case, which I don't >> necessarily think makes sense for a LiveOak SDK. >> >> I do think it makes sense that the LiveOak SDK uses the AeroGear SDK >> internally, but I don't know if we want to expose these AeroGear >> components to a LiveOak developer or not. >> >> >> For me, I envision something like the admin setting up their application >> in the LiveOak console which then generates a json configuration file >> (url locations, resources available, KeyCloak settings, UPS settings, >> etc). The application developer then drops this json file in to their >> application, the LiveOak SDK reads the json file to set it self up and >> then its really easy for the developer to start using it. >> >> [there are also some really cool things we could be doing here as well >> if we can get awesome data sync support for AeroGear. It might be >> interesting to be able to fetch a resource from the server and >> automatically sync its state across between the client and server. This >> way the object appears as a local object: if the resource changes on the >> server, it changes locally as well, if it changes locally, that change >> is pushed to the server. This way you are just dealing with an object, >> and not having to fetch and then push object back and forth between the >> server manually] >> >> Anyone have any thoughts on this? > > One of the things which may be useful is aerogear-ios and > aerogear-android are both modularizing their libraries. IN theory this > means that the liveOAK SDK's could be extensions of those modules > instead of a single monolothic thing. > > Sync is still an ongoing discussion in AeroGear, but I think right now > the current group thought is that we will focus on 409 Conflict events > (JPA versioning on server side and utilities on the client side) and not > worrying about realtime sync. > > > Some notes from out last meeting on the topic : > Client API Strawman : > https://github.com/secondsun/aerogear-android-sync/tree/master/android > Client/Server workflow : > https://docs.google.com/drawings/d/1E4NDEh3NQCdoEHNNHba4TR2akNrppvV5zDlk5nfzz08/edit > > > Also we are looking at doing something with diff merge patch as well as > adding in push based data changed notifications later. > > >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > -- > Summers Pittman >>> Phone:404 941 4698 >>> Java is my crack. > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140708/c839ceae/attachment.html From matzew at apache.org Tue Jul 8 09:13:10 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Tue, 8 Jul 2014 15:13:10 +0200 Subject: [aerogear-dev] UPS Production worthiness In-Reply-To: <008701cf9aa5$09290bc0$1b7b2340$@pinelabs.com> References: <002b01cf7424$528dc0a0$f7a941e0$@pinelabs.com> <005d01cf74ed$3d977140$b8c653c0$@pinelabs.com> <003c01cf78cd$1095df40$31c19dc0$@pinelabs.com> <17C1B903-C13B-482F-93FA-1B9B55AEF707@redhat.com> <008f01cf9603$9cf11fb0$d6d35f10$@pinelabs.com> <008701cf9aa5$09290bc0$1b7b2340$@pinelabs.com> Message-ID: Hello Vivek! thanks a lot for the patch! We will take a look at that for sure! The benefit of getting a PR out is that you are actually captured inside of the GH as an official contributor :-) But thanks again, very happy to see your patch ! -Matthias On Tue, Jul 8, 2014 at 2:06 PM, Vivek Pandey wrote: > Hi Matthias/UPS Team, > > I have put together a patch which shows the changes I had to make to get > the requisite performance from UPS. Please find the same attached. The > patch has my changes along with Eric?s changes merged on 0.10.4 branch. I > had to do some hacky changes to prevent all the installations from getting > serialized to UI. That should ideally be handled by removing this > requirement and making corresponding changes to UI code. > > I will learn GIT and put together a PR for these changes as soon as I can. > > > > Thanks, > > Vivek > > > > *From:* mwessendorf at gmail.com [mailto:mwessendorf at gmail.com] *On Behalf > Of *Matthias Wessendorf > *Sent:* Wednesday, July 02, 2014 8:15 PM > *To:* vivek.pandey at pinelabs.com > *Cc:* AeroGear Developer Mailing List > > *Subject:* Re: [aerogear-dev] UPS Production worthiness > > > > Hello vivek! > > > > thanks for the reply! Absolutely a PR is more than welcome! If you have > interest and the bandwidth, we would really appreciate that ! > > > > @importer: I still think it's a nice thing to have :-) > > > > -Matthias > > > > On Wed, Jul 2, 2014 at 4:40 PM, Vivek Pandey > wrote: > > Hello Matthias, > > > > An ?importer? might help, but smaller changes in existing domain/service > might help more. > > I ran a stress test on the installation endpoint yesterday, after merging > Eric?s changes on source code of 0.10.x branch. > > I saw that even after using the merged code, the response worsened > continuously. > > Looking closing, I saw that GenericVariantServiceImpl. addInstallation > causes initialization of the now ?lazy? collection > AbstractVariant.installations. > > > > I changed the model a bit, by adding variantID to Installation, and made > it the owner of the variant-installation relationship. > > That changed the code in InstallationRegistrationEndpoint. registerInstallation > from > > // store the installation: > > entity = clientInstallationService.addInstallation(entity); > > // add installation to the matching variant > > genericVariantService.addInstallation(variant, entity); > > > > to > > // store the installation: > > > entity.setVariantID(variant); > > entity = > clientInstallationService.addInstallation(entity); > > > > This fixed the problem for me and now I am getting constant time > installation registration with dramatically better performance > > > > Please let me know if you want me to add this to AGPUSH-661 > > > > Thanks > > Vivek > > > > *From:* mwessendorf at gmail.com [mailto:mwessendorf at gmail.com] *On Behalf > Of *Matthias Wessendorf > *Sent:* Wednesday, July 02, 2014 6:26 PM > *To:* AeroGear Developer Mailing List; vivek.pandey at pinelabs.com > > > *Subject:* Re: [aerogear-dev] UPS Production worthiness > > > > Hello Vivek, > > > > On Mon, May 26, 2014 at 1:23 PM, Matthias Wessendorf > wrote: > > > > > > On Mon, May 26, 2014 at 12:59 PM, Erik Jan de Wit > wrote: > > Hi Vivek, > > > > We?ve fixed that > https://github.com/aerogear/aerogear-unifiedpush-server/commit/1357c9e834286a9227a90e9ab618226aa54bbbf3 the > collection is now lazy. But I?m sure other query optimisations can be made. > > > > +1 > > > > btw. Vivek, I added your mail to an existing ticket: > > https://issues.jboss.org/browse/AGPUSH-661 > > > > > > coming back from vacation and going over the JIRAs, I was wondering if an > 'importer' helps? > > > > That would be a RESTful endpoint that accepts a JSON file, containing all > the devices you want to register (for a given variant). > > > > That way it would be also a bit nicer on your side, to perform the import: > > * generate a "large" JSON file (instead of a ton of requests) > > * only one HTTP request > > * server accepts and will process it in the background > > > > I think that would be a nice migration tool. > > > > Let me know what you think! > > > > -Matthias > > > > > > -Matthias > > > > > > Cheers, > > Erik Jan > > > > On 26 May,2014, at 12:27 , Vivek Pandey wrote: > > > > Hi Matthias, > > > > It is good to know that activity in java-apns is picking up and also that > you are looking at pushy. > > > > I did a few tests which added installations to UPS with a concurrency of > 4-8 threads. I was using Postgres 9.3 and UPS 0.10.3 war > > > > I noticed that response slowed down considerably after some time with high > CPU usage and continued to get worse. After doing some profiling, I found > that bulk of CPU cycles are being taken by > org.postgresql.core.VisibleBufferedInputStream.readMore. The entire thread > stack is attached. Also postgres continuously flagged > > > > select installati0_.variantID as variant10_0_0_, installati0_.id as > id1_3_0_, installati0_.id as id1_3_1_, installati0_.alias as alias2_3_1_, > installati0_.deviceToken as deviceTo3_3_1_, installati0_.deviceType as > deviceTy4_3_1_, installati0_.enabled as enabled5_3_1_, > installati0_.operatingSystem as operatin6_3_1_, installati0_.osVersion as > osVersio7_3_1_, installati0_.platform as platform8_3_1_, > installati0_.simplePushEndpoint as simplePu9_3_1_ from InstallationImpl > installati0_ where installati0_.variantID=$1 > > > > as the slow query. I am pretty sure that eager collection > AbstractVariant.installations is the root cause of the problem. > > > > Please let me know if you need any more information. > > > > Thanks > > Vivek > > > > *From:* mwessendorf at gmail.com [mailto:mwessendorf at gmail.com > ] *On Behalf Of *Matthias Wessendorf > *Sent:* Wednesday, May 21, 2014 5:55 PM > *To:* vivek.pandey at pinelabs.com; AeroGear Developer Mailing List > *Subject:* Re: [aerogear-dev] UPS Production worthiness > > > > Hello Vivek! > > > > On Wed, May 21, 2014 at 2:07 PM, Vivek Pandey > wrote: > > Hi Jay, > > > > Thanks for your reply. > > > > While we have not faced any issues in using UPS in our limited testing, I > often see info stacktraces in ups logs > > > > 2014-05-16 10:19:20,032 INFO > [com.notnoop.apns.internal.ApnsConnectionImpl] (Thread-118) Exception while > waiting for error code: java.net.SocketException: Socket closed > > at java.net.SocketInputStream.socketRead0(Native Method) > [rt.jar:1.7.0_51] > > at java.net.SocketInputStream.read(SocketInputStream.java:152) > [rt.jar:1.7.0_51] > > at java.net.SocketInputStream.read(SocketInputStream.java:122) > [rt.jar:1.7.0_51] > > ????? > > at > com.notnoop.apns.internal.ApnsConnectionImpl$1MonitoringThread.run(ApnsConnectionImpl.java:114) > [apns-0.2.3.jar:] > > > > > > These stacktraces coupled with low dev activity of noop/java-apns project > are disconcerting to me. > > > > the stack-trace is no harm - it's only happening w/ doing a monitoring of > the thread (that's what we currently do, when setting up ApnsService - I > thought about explicitly disable that) > > > > The activity of the underlying java-apns is very low, yes! However @froh42 > is getting back: > > https://github.com/notnoop/java-apns/commits/master > > > > There will be a new release in the near future; @froh42 asked me if I > could help with pushing the bits to maven central > > > > > > That said, I recently started looking at pushy: > > https://github.com/relayrides/pushy > > > > I also sent a PR that would allow us to feed pushy w/ our certificate from > the database: > > https://github.com/relayrides/pushy/pull/87 > > > > Hope that helps > > -Matthias > > > > > > I am currently using UPS 0.10.2 war. > > > > Thanks, > > Vivek > > *From:* Jay Balunas [mailto:jbalunas at redhat.com] > *Sent:* Tuesday, May 20, 2014 11:36 PM > *To:* vivek.pandey at pinelabs.com; AeroGear Developer Mailing List > *Cc:* Jay Balunas > *Subject:* Re: [aerogear-dev] UPS Production worthiness > > > > Hi Vivek, > > > > It's awesome to hear that you have integrated the UPS into your backend > systems and some of your mobile apps! > > > > We have a lot of confidence around the UPS, its functionality, and > performance. Our team has been working hard on improvements and stability > including our QE team. Also, as you may have seen we're planning a 1.0 > release of the UPS this summer. > > > > However at this time we don't have specific references or success stories > outside of what you can see in the community mailing lists - other users > using it ;-) We're also about to kick off some performance and scale > testing in the next couple of months. > > > > Have you run into any issues that drove these questions about production > worthiness? If so please let us know and we'll certainly take a look. > > > > Hope this helps! > > > > Thanks, > > Jay Balunas > > > > On May 20, 2014, at 8:09 AM, Vivek Pandey > wrote: > > > > Hello Aerogear dev team, > > > > We integrated UPS into our backend server which is serving various mobile > apps. While the development and testing phase went well, my manager is > questioning me about production worthiness about Aerogear. It would be > great help if you could point me to references/success stories where UPS is > being used in production environments and scaling well in medium to high > loads. > > > > Thanks, > > Vivek > > > > > > > ------------------------------ > > This message may contain privileged and confidential information and is > solely for the use of intended recipient. The views expressed in this email > are those of the sender and not of Pine Labs. The recipient should check > this email and attachments for the presence of viruses / malwares etc. Pine > Labs accepts no liability for any damage caused by any virus transmitted by > this email. Pine Labs may monitor and record all emails. > ------------------------------ > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > ------------------------------ > > This message may contain privileged and confidential information and is > solely for the use of intended recipient. The views expressed in this email > are those of the sender and not of Pine Labs. The recipient should check > this email and attachments for the presence of viruses / malwares etc. Pine > Labs accepts no liability for any damage caused by any virus transmitted by > this email. Pine Labs may monitor and record all emails. > ------------------------------ > > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > > > ------------------------------ > > This message may contain privileged and confidential information and is > solely for the use of intended recipient. The views expressed in this email > are those of the sender and not of Pine Labs. The recipient should check > this email and attachments for the presence of viruses / malwares etc. Pine > Labs accepts no liability for any damage caused by any virus transmitted by > this email. Pine Labs may monitor and record all emails. > ------------------------------ > > > > _______________________________________________ > > > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > > > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > > > ------------------------------ > > This message may contain privileged and confidential information and is > solely for the use of intended recipient. The views expressed in this email > are those of the sender and not of Pine Labs. The recipient should check > this email and attachments for the presence of viruses / malwares etc. Pine > Labs accepts no liability for any damage caused by any virus transmitted by > this email. Pine Labs may monitor and record all emails. > ------------------------------ > > > > > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > > ------------------------------ > This message may contain privileged and confidential information and is > solely for the use of intended recipient. The views expressed in this email > are those of the sender and not of Pine Labs. The recipient should check > this email and attachments for the presence of viruses / malwares etc. Pine > Labs accepts no liability for any damage caused by any virus transmitted by > this email. Pine Labs may monitor and record all emails. > ------------------------------ > > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140708/6e32118e/attachment-0001.html From matzew at apache.org Tue Jul 8 10:12:06 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Tue, 8 Jul 2014 16:12:06 +0200 Subject: [aerogear-dev] UnifiedPush Server domain model In-Reply-To: <5CF8ACC8-1614-4FAC-A11D-0572FFC6F27A@redhat.com> References: <5CF8ACC8-1614-4FAC-A11D-0572FFC6F27A@redhat.com> Message-ID: Hi Erik! this JIRA: https://issues.jboss.org/browse/AGPUSH-629 and its PR (https://github.com/aerogear/aerogear-unifiedpush-server/pull/271) are related here, right ? On Wed, Jun 11, 2014 at 3:14 PM, Erik Jan de Wit wrote: > Hi, > > Right now the domain model of the UnifiedPush Server has the variants > split into separate collections. > > > https://github.com/edewit/aerogear-unifiedpush-server/blob/master/model/api/src/main/java/org/jboss/aerogear/unifiedpush/api/PushApplication.java#L44-L50 > > This could be improved to only use one collection, we?ll get more > extendibility (adding another variant type for instance) and remove code > like this: > > > https://github.com/edewit/aerogear-unifiedpush-server/blob/master/model/jpa/src/main/java/org/jboss/aerogear/unifiedpush/jpa/dao/impl/JPAPushApplicationDao.java#L93-L96 > > In places where you only want the iOS variants for instance you could > either query them, or have a getter that collects them by type. > > What do you think? > > Cheers, > Erik Jan > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140708/50eae630/attachment.html From edewit at redhat.com Tue Jul 8 10:15:42 2014 From: edewit at redhat.com (Erik Jan de Wit) Date: Tue, 8 Jul 2014 16:15:42 +0200 Subject: [aerogear-dev] UnifiedPush Server domain model In-Reply-To: References: <5CF8ACC8-1614-4FAC-A11D-0572FFC6F27A@redhat.com> Message-ID: <2BDE5702-B41B-4928-9CD7-6D16B0958F9F@redhat.com> > this JIRA: > https://issues.jboss.org/browse/AGPUSH-629 > > and its PR (https://github.com/aerogear/aerogear-unifiedpush-server/pull/271) are related here, right ? Yeah, that is why the issue has a link to the PR and the ML-thread -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140708/7e2151b9/attachment.html From mwringe at redhat.com Tue Jul 8 10:23:21 2014 From: mwringe at redhat.com (Matt Wringe) Date: Tue, 08 Jul 2014 10:23:21 -0400 Subject: [aerogear-dev] [liveoak-dev] Re: LiveOak SDK In-Reply-To: <1FDBF7E3-69D5-4C65-88F4-18A8416FEBC2@redhat.com> References: <53BAC759.7030000@redhat.com> <53BBEBDC.9000300@redhat.com> <1FDBF7E3-69D5-4C65-88F4-18A8416FEBC2@redhat.com> Message-ID: <53BBFED9.4020502@redhat.com> On 08/07/14 09:11 AM, Burr Sutter wrote: > At a minimum, the same HTTP error codes used to indicate "sync errors" > via JAX-RS + JPA should be the same for LiveOak's REST APIs - > therefore the client-code can be reusable across the two endpoints. > We should come up with sync strategies - levels 1, 2 and 3 - where 1 > is simply the clever use of HTTP error codes and level 3 is > real-time/off-line/auto-conflict resolution. Perhaps there are 4 > levels :-) > > Anyone care to articulate the possible strategies? Some thoughts: 1) No conflict resolution. The way it handled in LiveOak right now, whoever is the last person to push to the server overwrites any other changes. Obviously not ideal, but may be acceptable in some cases. (or enabled via a 'force' option)b 2) Only allowed to update from the latest version: only allow updates if the resource being updated has not already been modified by someone else. If it has been updated, return HTTP error code 3) Non-conflicting field updates allowed: allow partial, non-conflicting updates to fields; otherwise return HTTP error code (Eg userA & userB both fetch resourceA from the server, userA makes a change to the 'foo' field and pushes it to the server. UserB makes a change to the 'bar' field and tries to push to the server. Since its a change to a different field, it is allowed). 4) Non-conflicting updates allowed: expands on the non-conflicting field updates. A smarter diff type system where its can handle more than just modifications to different fields. Eg say there is an 'article' field, UserA and UserB checkout the resource. UserA fixes a typo and pushes it to the server. UserB fixes the same typo and fixes 2 other typos. UserB can commit his change since his changes don't conflict with the previous update. [I am sure there are probably some nice diff and merge libraries around that we could use on the server side to take care of handling the conflict logic] The above is all stuff which needs to be done on the server side. And there are a few interesting things here where, except for the first option, we could require the data on the server to include special fields for conflict resolution (or something like a md5sum of the resources state). Having special fields like this breaks some data features we currently have in LiveOak, but its probably something we can make configurable and have a compromise. Client side stuff: 1) offline support: I am assuming this is about having some sort of local data cache so that when offline we can get the cached objects. All without having to resort to the whole fetch from a URL then save to local storage manually. Eg liveoak.get("/foo/bar") would fetch and cache locally if online, if offline liveoak.get("/foo/bar") would just get it from the cache. Some interesting stuff would need to be done here on the client side. [any plan for encryption and security in this local storage? Any ability to wipe the cache from the console if the device is lost or stolen?] 2) real-time: this is where I think things get more interesting. If we had conflict resolution (and partial updates) we could almost do this already in LiveOak (eg register to receive changes to a particular resource when modified on the server, push partial updates when the resource is modified locally. These steps of course would be handled by the SDK and not expected to be manually handled by the developer). This would also tie into the offline support, so when the device goes offline and then comes back, it would need to be able to handle the conflicts and push results back to the server. Other considerations - exposing conflicts to the developer so they can manually handle the issue and/or notify the user. - allowing the developer to specify what kind of conflict resolution they want for what resources - how to configure local storage (eg only cache objects already accessed, prefetch a list of resources, never cache certain resources, etc....) Anything else? > > > On Jul 8, 2014, at 9:02 AM, Summers Pittman > wrote: > >> On Mon 07 Jul 2014 12:14:17 PM EDT, Matt Wringe wrote: >>> >>> Initial email to get some discussion going around the LiveOak SDK and >>> AeroGear collaboration. >>> >>> Essentially in LiveOak we are going to need a few different SDK types >>> >>> - Client Application SDK >>> This is the code which will run on the users device. Initial targets >>> here are javascript (+ cordova support), iOS, Android. This type of SDK >>> will handle things like getting and sending resources to and from the >>> server, handling login/logout/registration, etc. Probably some other >>> things like device registration would be needed as well. >>> >>> Not sure if we want to provide support for some other things outside of >>> communicating with the server or not (eg access to device components (eg >>> camera, location, etc)) or if these would be best handled by using the >>> native environment's SDK instead. >>> >>> - Server Side SDK >>> This is code that runs on the server side, written in JavaScript by the >>> application developer. This will need to be familiar to the client >>> application's JavaScript SDK, but may not be exactly the same. This type >>> of SDK will be able to access the same resources as the client side >>> JavaScript, as well as other internal resources and libraries. >>> >>> >>> I am not sure how to collaborate between the LiveOak and AeroGear teams >>> here. AeroGear makes really awesome SDKs for various mobile platforms, >>> but with LiveOak we are dealing with a specific type of application. The >>> AeroGear SDKs tend to handle the more generic case, which I don't >>> necessarily think makes sense for a LiveOak SDK. >>> >>> I do think it makes sense that the LiveOak SDK uses the AeroGear SDK >>> internally, but I don't know if we want to expose these AeroGear >>> components to a LiveOak developer or not. >>> >>> >>> For me, I envision something like the admin setting up their application >>> in the LiveOak console which then generates a json configuration file >>> (url locations, resources available, KeyCloak settings, UPS settings, >>> etc). The application developer then drops this json file in to their >>> application, the LiveOak SDK reads the json file to set it self up and >>> then its really easy for the developer to start using it. >>> >>> [there are also some really cool things we could be doing here as well >>> if we can get awesome data sync support for AeroGear. It might be >>> interesting to be able to fetch a resource from the server and >>> automatically sync its state across between the client and server. This >>> way the object appears as a local object: if the resource changes on the >>> server, it changes locally as well, if it changes locally, that change >>> is pushed to the server. This way you are just dealing with an object, >>> and not having to fetch and then push object back and forth between the >>> server manually] >>> >>> Anyone have any thoughts on this? >> >> One of the things which may be useful is aerogear-ios and >> aerogear-android are both modularizing their libraries. IN theory this >> means that the liveOAK SDK's could be extensions of those modules >> instead of a single monolothic thing. >> >> Sync is still an ongoing discussion in AeroGear, but I think right now >> the current group thought is that we will focus on 409 Conflict events >> (JPA versioning on server side and utilities on the client side) and not >> worrying about realtime sync. >> >> >> Some notes from out last meeting on the topic : >> Client API Strawman : >> https://github.com/secondsun/aerogear-android-sync/tree/master/android >> Client/Server workflow : >> https://docs.google.com/drawings/d/1E4NDEh3NQCdoEHNNHba4TR2akNrppvV5zDlk5nfzz08/edit >> >> >> Also we are looking at doing something with diff merge patch as well as >> adding in push based data changed notifications later. >> >> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> >> -- >> Summers Pittman >>>> Phone:404 941 4698 >>>> Java is my crack. >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140708/7ee3df71/attachment-0001.html From corinnekrych at gmail.com Tue Jul 8 10:29:39 2014 From: corinnekrych at gmail.com (Corinne Krych) Date: Tue, 8 Jul 2014 16:29:39 +0200 Subject: [aerogear-dev] [liveoak-dev] Re: LiveOak SDK In-Reply-To: <53BBFED9.4020502@redhat.com> References: <53BAC759.7030000@redhat.com> <53BBEBDC.9000300@redhat.com> <1FDBF7E3-69D5-4C65-88F4-18A8416FEBC2@redhat.com> <53BBFED9.4020502@redhat.com> Message-ID: <42329C11-1092-4C54-85E3-AF18B0F60D15@gmail.com> On 08 Jul 2014, at 16:23, Matt Wringe wrote: > On 08/07/14 09:11 AM, Burr Sutter wrote: >> At a minimum, the same HTTP error codes used to indicate "sync errors" via JAX-RS + JPA should be the same for LiveOak's REST APIs - therefore the client-code can be reusable across the two endpoints. We should come up with sync strategies - levels 1, 2 and 3 - where 1 is simply the clever use of HTTP error codes and level 3 is real-time/off-line/auto-conflict resolution. Perhaps there are 4 levels :-) >> >> Anyone care to articulate the possible strategies? > > Some thoughts: > > 1) No conflict resolution. The way it handled in LiveOak right now, whoever is the last person to push to the server overwrites any other changes. Obviously not ideal, but may be acceptable in some cases. (or enabled via a 'force' option)b > > 2) Only allowed to update from the latest version: only allow updates if the resource being updated has not already been modified by someone else. If it has been updated, return HTTP error code > > 3) Non-conflicting field updates allowed: allow partial, non-conflicting updates to fields; otherwise return HTTP error code (Eg userA & userB both fetch resourceA from the server, userA makes a change to the 'foo' field and pushes it to the server. UserB makes a change to the 'bar' field and tries to push to the server. Since its a change to a different field, it is allowed). > > 4) Non-conflicting updates allowed: expands on the non-conflicting field updates. A smarter diff type system where its can handle more than just modifications to different fields. Eg say there is an 'article' field, UserA and UserB checkout the resource. UserA fixes a typo and pushes it to the server. UserB fixes the same typo and fixes 2 other typos. UserB can commit his change since his changes don't conflict with the previous update. > > [I am sure there are probably some nice diff and merge libraries around that we could use on the server side to take care of handling the conflict logic] > > The above is all stuff which needs to be done on the server side. And there are a few interesting things here where, except for the first option, we could require the data on the server to include special fields for conflict resolution (or something like a md5sum of the resources state). Having special fields like this breaks some data features we currently have in LiveOak, but its probably something we can make configurable and have a compromise. > > Client side stuff: > > 1) offline support: I am assuming this is about having some sort of local data cache so that when offline we can get the cached objects. All without having to resort to the whole fetch from a URL then save to local storage manually. Eg liveoak.get("/foo/bar") would fetch and cache locally if online, if offline liveoak.get("/foo/bar") would just get it from the cache. Some interesting stuff would need to be done here on the client side. > > [any plan for encryption and security in this local storage? Any ability to wipe the cache from the console if the device is lost or stolen?] > WIP started bu abstractj http://aerogear.org/docs/specs/aerogear-security-offline/ > 2) real-time: this is where I think things get more interesting. If we had conflict resolution (and partial updates) we could almost do this already in LiveOak (eg register to receive changes to a particular resource when modified on the server, push partial updates when the resource is modified locally. These steps of course would be handled by the SDK and not expected to be manually handled by the developer). This would also tie into the offline support, so when the device goes offline and then comes back, it would need to be able to handle the conflicts and push results back to the server. > > Other considerations > - exposing conflicts to the developer so they can manually handle the issue and/or notify the user. > - allowing the developer to specify what kind of conflict resolution they want for what resources > - how to configure local storage (eg only cache objects already accessed, prefetch a list of resources, never cache certain resources, etc....) > > Anything else? > > >> >> >> On Jul 8, 2014, at 9:02 AM, Summers Pittman wrote: >> >>> On Mon 07 Jul 2014 12:14:17 PM EDT, Matt Wringe wrote: >>>> >>>> Initial email to get some discussion going around the LiveOak SDK and >>>> AeroGear collaboration. >>>> >>>> Essentially in LiveOak we are going to need a few different SDK types >>>> >>>> - Client Application SDK >>>> This is the code which will run on the users device. Initial targets >>>> here are javascript (+ cordova support), iOS, Android. This type of SDK >>>> will handle things like getting and sending resources to and from the >>>> server, handling login/logout/registration, etc. Probably some other >>>> things like device registration would be needed as well. >>>> >>>> Not sure if we want to provide support for some other things outside of >>>> communicating with the server or not (eg access to device components (eg >>>> camera, location, etc)) or if these would be best handled by using the >>>> native environment's SDK instead. >>>> >>>> - Server Side SDK >>>> This is code that runs on the server side, written in JavaScript by the >>>> application developer. This will need to be familiar to the client >>>> application's JavaScript SDK, but may not be exactly the same. This type >>>> of SDK will be able to access the same resources as the client side >>>> JavaScript, as well as other internal resources and libraries. >>>> >>>> >>>> I am not sure how to collaborate between the LiveOak and AeroGear teams >>>> here. AeroGear makes really awesome SDKs for various mobile platforms, >>>> but with LiveOak we are dealing with a specific type of application. The >>>> AeroGear SDKs tend to handle the more generic case, which I don't >>>> necessarily think makes sense for a LiveOak SDK. >>>> >>>> I do think it makes sense that the LiveOak SDK uses the AeroGear SDK >>>> internally, but I don't know if we want to expose these AeroGear >>>> components to a LiveOak developer or not. >>>> >>>> >>>> For me, I envision something like the admin setting up their application >>>> in the LiveOak console which then generates a json configuration file >>>> (url locations, resources available, KeyCloak settings, UPS settings, >>>> etc). The application developer then drops this json file in to their >>>> application, the LiveOak SDK reads the json file to set it self up and >>>> then its really easy for the developer to start using it. >>>> >>>> [there are also some really cool things we could be doing here as well >>>> if we can get awesome data sync support for AeroGear. It might be >>>> interesting to be able to fetch a resource from the server and >>>> automatically sync its state across between the client and server. This >>>> way the object appears as a local object: if the resource changes on the >>>> server, it changes locally as well, if it changes locally, that change >>>> is pushed to the server. This way you are just dealing with an object, >>>> and not having to fetch and then push object back and forth between the >>>> server manually] >>>> >>>> Anyone have any thoughts on this? >>> >>> One of the things which may be useful is aerogear-ios and >>> aerogear-android are both modularizing their libraries. IN theory this >>> means that the liveOAK SDK's could be extensions of those modules >>> instead of a single monolothic thing. >>> >>> Sync is still an ongoing discussion in AeroGear, but I think right now >>> the current group thought is that we will focus on 409 Conflict events >>> (JPA versioning on server side and utilities on the client side) and not >>> worrying about realtime sync. >>> >>> >>> Some notes from out last meeting on the topic : >>> Client API Strawman : >>> https://github.com/secondsun/aerogear-android-sync/tree/master/android >>> Client/Server workflow : >>> https://docs.google.com/drawings/d/1E4NDEh3NQCdoEHNNHba4TR2akNrppvV5zDlk5nfzz08/edit >>> >>> >>> Also we are looking at doing something with diff merge patch as well as >>> adding in push based data changed notifications later. >>> >>> >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >>> >>> >>> -- >>> Summers Pittman >>>>> Phone:404 941 4698 >>>>> Java is my crack. >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > From matzew at apache.org Tue Jul 8 10:32:43 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Tue, 8 Jul 2014 16:32:43 +0200 Subject: [aerogear-dev] UnifiedPush Server domain model In-Reply-To: <2BDE5702-B41B-4928-9CD7-6D16B0958F9F@redhat.com> References: <5CF8ACC8-1614-4FAC-A11D-0572FFC6F27A@redhat.com> <2BDE5702-B41B-4928-9CD7-6D16B0958F9F@redhat.com> Message-ID: On Tue, Jul 8, 2014 at 4:15 PM, Erik Jan de Wit wrote: > > this JIRA: > https://issues.jboss.org/browse/AGPUSH-629 > > and its PR ( > https://github.com/aerogear/aerogear-unifiedpush-server/pull/271) are > related here, right ? > > > Yeah, that is why the issue has a link to the PR and the ML-thread > yeah, but said to postpone that JIRA :-) Anyways, I will merge that PR soon > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140708/b0e0f87f/attachment.html From edewit at redhat.com Tue Jul 8 10:40:28 2014 From: edewit at redhat.com (Erik Jan de Wit) Date: Tue, 8 Jul 2014 16:40:28 +0200 Subject: [aerogear-dev] UnifiedPush Server domain model In-Reply-To: References: <5CF8ACC8-1614-4FAC-A11D-0572FFC6F27A@redhat.com> <2BDE5702-B41B-4928-9CD7-6D16B0958F9F@redhat.com> Message-ID: <94D4CF84-93F3-4681-8B85-53D72F3D66E7@redhat.com> > > yeah, but said to postpone that JIRA :-) Right till after 0.11.0 which has been released, so no time like the present > > Anyways, I will merge that PR soon > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140708/86a7707d/attachment.html From matzew at apache.org Tue Jul 8 11:15:01 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Tue, 8 Jul 2014 17:15:01 +0200 Subject: [aerogear-dev] UnifiedPush Server domain model In-Reply-To: <94D4CF84-93F3-4681-8B85-53D72F3D66E7@redhat.com> References: <5CF8ACC8-1614-4FAC-A11D-0572FFC6F27A@redhat.com> <2BDE5702-B41B-4928-9CD7-6D16B0958F9F@redhat.com> <94D4CF84-93F3-4681-8B85-53D72F3D66E7@redhat.com> Message-ID: On Tue, Jul 8, 2014 at 4:40 PM, Erik Jan de Wit wrote: > > yeah, but said to postpone that JIRA :-) > > > Right till after 0.11.0 which has been released, so no time like the > present > gotcha > > > Anyways, I will merge that PR soon > > >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140708/7830d6ba/attachment.html From matzew at apache.org Tue Jul 8 13:55:21 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Tue, 8 Jul 2014 19:55:21 +0200 Subject: [aerogear-dev] grunt error Message-ID: someone seen this before? [ERROR] Failed to execute goal com.github.eirslett:frontend-maven-plugin:0.0.14:grunt (grunt build) on project unifiedpush-server: 'grunt dist --no-color' failed. (error code 8) -> [Help 1] Looks like yet another issue w/ the JS tools for the UI -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140708/4a81dd36/attachment-0001.html From matzew at apache.org Tue Jul 8 13:57:24 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Tue, 8 Jul 2014 19:57:24 +0200 Subject: [aerogear-dev] grunt error In-Reply-To: References: Message-ID: and a bit above that: [INFO] --- frontend-maven-plugin:0.0.14:grunt (grunt build) @ unifiedpush-server --- [INFO] Running 'grunt dist --no-color' in /home/travis/build/aerogear/aerogear-unifiedpush-server/admin-ui [INFO] [INFO] module.js:340 [INFO] throw err; [INFO] ^ [INFO] Error: Cannot find module 'findup-sync' [INFO] at Function.Module._resolveFilename (module.js:338:15) [INFO] at Function.Module._load (module.js:280:25) [INFO] at Module.require (module.js:364:17) [INFO] at require (module.js:380:17) [INFO] at Object. (/home/travis/build/aerogear/aerogear-unifiedpush-server/admin-ui/node_modules/grunt-cli/bin/grunt:8:14) [INFO] at Module._compile (module.js:456:26) [INFO] at Object.Module._extensions..js (module.js:474:10) [INFO] at Module.load (module.js:356:32) [INFO] at Function.Module._load (module.js:312:12) [INFO] at Function.Module.runMain (module.js:497:10) [INFO] ------------------------------------------------------------------------ so, not sure what that really means :-/ On Tue, Jul 8, 2014 at 7:55 PM, Matthias Wessendorf wrote: > someone seen this before? > > [ERROR] Failed to execute goal > com.github.eirslett:frontend-maven-plugin:0.0.14:grunt (grunt build) on > project unifiedpush-server: 'grunt dist --no-color' failed. (error code 8) > -> [Help 1] > > > Looks like yet another issue w/ the JS tools for the UI > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140708/98e4c550/attachment.html From lholmqui at redhat.com Tue Jul 8 14:03:10 2014 From: lholmqui at redhat.com (Luke Holmquist) Date: Tue, 8 Jul 2014 14:03:10 -0400 (EDT) Subject: [aerogear-dev] grunt error In-Reply-To: References: Message-ID: 'Npm install' first. Not sure Sent from my iPhone > On Jul 8, 2014, at 1:57 PM, Matthias Wessendorf wrote: > > and a bit above that: > > [INFO] --- frontend-maven-plugin:0.0.14:grunt (grunt build) @ unifiedpush-server --- > > [INFO] Running 'grunt dist --no-color' in /home/travis/build/aerogear/aerogear-unifiedpush-server/admin-ui > > [INFO] > > [INFO] module.js:340 > [INFO] throw err; > > [INFO] ^ > > [INFO] Error: Cannot find module 'findup-sync' > > [INFO] at Function.Module._resolveFilename (module.js:338:15) > > [INFO] at Function.Module._load (module.js:280:25) > > [INFO] at Module.require (module.js:364:17) > > [INFO] at require (module.js:380:17) > > [INFO] at Object. (/home/travis/build/aerogear/aerogear-unifiedpush-server/admin-ui/node_modules/grunt-cli/bin/grunt:8:14) > > [INFO] at Module._compile (module.js:456:26) > > [INFO] at Object.Module._extensions..js (module.js:474:10) > > [INFO] at Module.load (module.js:356:32) > > [INFO] at Function.Module._load (module.js:312:12) > > [INFO] at Function.Module.runMain (module.js:497:10) > > [INFO] ------------------------------------------------------------------------ > > > > so, not sure what that really means :-/ > > >> On Tue, Jul 8, 2014 at 7:55 PM, Matthias Wessendorf wrote: >> someone seen this before? >> >> [ERROR] Failed to execute goal com.github.eirslett:frontend-maven-plugin:0.0.14:grunt (grunt build) on project unifiedpush-server: 'grunt dist --no-color' failed. (error code 8) -> [Help 1] >> >> >> Looks like yet another issue w/ the JS tools for the UI >> >> >> -- >> Matthias Wessendorf >> >> blog: http://matthiaswessendorf.wordpress.com/ >> sessions: http://www.slideshare.net/mwessendorf >> twitter: http://twitter.com/mwessendorf > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140708/62947d6b/attachment.html From matzew at apache.org Tue Jul 8 14:24:47 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Tue, 8 Jul 2014 20:24:47 +0200 Subject: [aerogear-dev] grunt error In-Reply-To: References: Message-ID: I did assume the frontend plugin does that :-/ On Tuesday, July 8, 2014, Luke Holmquist wrote: > 'Npm install' first. Not sure > > Sent from my iPhone > > On Jul 8, 2014, at 1:57 PM, Matthias Wessendorf > wrote: > > and a bit above that: > > [INFO] --- frontend-maven-plugin:0.0.14:grunt (grunt build) @ unifiedpush-server --- > > [INFO] Running 'grunt dist --no-color' in /home/travis/build/aerogear/aerogear-unifiedpush-server/admin-ui > > [INFO] > > [INFO] module.js:340 > > [INFO] throw err; > > [INFO] ^ > > [INFO] Error: Cannot find module 'findup-sync' > > [INFO] at Function.Module._resolveFilename (module.js:338:15) > > [INFO] at Function.Module._load (module.js:280:25) > > [INFO] at Module.require (module.js:364:17) > > [INFO] at require (module.js:380:17) > > [INFO] at Object. (/home/travis/build/aerogear/aerogear-unifiedpush-server/admin-ui/node_modules/grunt-cli/bin/grunt:8:14) > > [INFO] at Module._compile (module.js:456:26) > > [INFO] at Object.Module._extensions..js (module.js:474:10) > > [INFO] at Module.load (module.js:356:32) > > [INFO] at Function.Module._load (module.js:312:12) > > [INFO] at Function.Module.runMain (module.js:497:10) > > [INFO] ------------------------------------------------------------------------ > > > > so, not sure what that really means :-/ > > > On Tue, Jul 8, 2014 at 7:55 PM, Matthias Wessendorf > wrote: > >> someone seen this before? >> >> [ERROR] Failed to execute goal >> com.github.eirslett:frontend-maven-plugin:0.0.14:grunt (grunt build) on >> project unifiedpush-server: 'grunt dist --no-color' failed. (error code 8) >> -> [Help 1] >> >> >> Looks like yet another issue w/ the JS tools for the UI >> >> >> -- >> Matthias Wessendorf >> >> blog: http://matthiaswessendorf.wordpress.com/ >> sessions: http://www.slideshare.net/mwessendorf >> twitter: http://twitter.com/mwessendorf >> > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > -- Sent from Gmail Mobile -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140708/50790ae2/attachment-0001.html From bruno at abstractj.org Tue Jul 8 14:44:30 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Tue, 08 Jul 2014 11:44:30 -0700 (PDT) Subject: [aerogear-dev] grunt error In-Reply-To: References: Message-ID: <1404845070006.3e1333dd@Nodemailer> I had this issue due to network problems. Does it happen on Travis or just locally? ? abstractj On Tue, Jul 8, 2014 at 3:24 PM, Matthias Wessendorf wrote: > I did assume the frontend plugin does that :-/ > On Tuesday, July 8, 2014, Luke Holmquist wrote: >> 'Npm install' first. Not sure >> >> Sent from my iPhone >> >> On Jul 8, 2014, at 1:57 PM, Matthias Wessendorf > > wrote: >> >> and a bit above that: >> >> [INFO] --- frontend-maven-plugin:0.0.14:grunt (grunt build) @ unifiedpush-server --- >> >> [INFO] Running 'grunt dist --no-color' in /home/travis/build/aerogear/aerogear-unifiedpush-server/admin-ui >> >> [INFO] >> >> [INFO] module.js:340 >> >> [INFO] throw err; >> >> [INFO] ^ >> >> [INFO] Error: Cannot find module 'findup-sync' >> >> [INFO] at Function.Module._resolveFilename (module.js:338:15) >> >> [INFO] at Function.Module._load (module.js:280:25) >> >> [INFO] at Module.require (module.js:364:17) >> >> [INFO] at require (module.js:380:17) >> >> [INFO] at Object. (/home/travis/build/aerogear/aerogear-unifiedpush-server/admin-ui/node_modules/grunt-cli/bin/grunt:8:14) >> >> [INFO] at Module._compile (module.js:456:26) >> >> [INFO] at Object.Module._extensions..js (module.js:474:10) >> >> [INFO] at Module.load (module.js:356:32) >> >> [INFO] at Function.Module._load (module.js:312:12) >> >> [INFO] at Function.Module.runMain (module.js:497:10) >> >> [INFO] ------------------------------------------------------------------------ >> >> >> >> so, not sure what that really means :-/ >> >> >> On Tue, Jul 8, 2014 at 7:55 PM, Matthias Wessendorf > > wrote: >> >>> someone seen this before? >>> >>> [ERROR] Failed to execute goal >>> com.github.eirslett:frontend-maven-plugin:0.0.14:grunt (grunt build) on >>> project unifiedpush-server: 'grunt dist --no-color' failed. (error code 8) >>> -> [Help 1] >>> >>> >>> Looks like yet another issue w/ the JS tools for the UI >>> >>> >>> -- >>> Matthias Wessendorf >>> >>> blog: http://matthiaswessendorf.wordpress.com/ >>> sessions: http://www.slideshare.net/mwessendorf >>> twitter: http://twitter.com/mwessendorf >>> >> >> >> >> -- >> Matthias Wessendorf >> >> blog: http://matthiaswessendorf.wordpress.com/ >> sessions: http://www.slideshare.net/mwessendorf >> twitter: http://twitter.com/mwessendorf >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> > -- > Sent from Gmail Mobile -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140708/6e14353a/attachment.html From matzew at apache.org Tue Jul 8 14:45:21 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Tue, 8 Jul 2014 20:45:21 +0200 Subject: [aerogear-dev] grunt error In-Reply-To: <1404845070006.3e1333dd@Nodemailer> References: <1404845070006.3e1333dd@Nodemailer> Message-ID: travis On Tue, Jul 8, 2014 at 8:44 PM, Bruno Oliveira wrote: > I had this issue due to network problems. Does it happen on Travis or just > locally? > > > ? > abstractj > > > On Tue, Jul 8, 2014 at 3:24 PM, Matthias Wessendorf > wrote: > >> I did assume the frontend plugin does that :-/ >> >> On Tuesday, July 8, 2014, Luke Holmquist wrote: >> >>> 'Npm install' first. Not sure >>> >>> Sent from my iPhone >>> >>> On Jul 8, 2014, at 1:57 PM, Matthias Wessendorf >>> wrote: >>> >>> and a bit above that: >>> >>> [INFO] --- frontend-maven-plugin:0.0.14:grunt (grunt build) @ unifiedpush-server --- >>> >>> [INFO] Running 'grunt dist --no-color' in /home/travis/build/aerogear/aerogear-unifiedpush-server/admin-ui >>> >>> [INFO] >>> >>> >>> [INFO] module.js:340 >>> >>> [INFO] throw err; >>> >>> [INFO] ^ >>> >>> >>> [INFO] Error: Cannot find module 'findup-sync' >>> >>> >>> [INFO] at Function.Module._resolveFilename (module.js:338:15) >>> >>> >>> [INFO] at Function.Module._load (module.js:280:25) >>> >>> >>> [INFO] at Module.require (module.js:364:17) >>> >>> [INFO] at require (module.js:380:17) >>> >>> >>> [INFO] at Object. (/home/travis/build/aerogear/aerogear-unifiedpush-server/admin-ui/node_modules/grunt-cli/bin/grunt:8:14) >>> >>> [INFO] at Module._compile (module.js:456:26) >>> >>> [INFO] at Object.Module._extensions..js (module.js:474:10) >>> >>> [INFO] at Module.load (module.js:356:32) >>> >>> [INFO] at Function.Module._load (module.js:312:12) >>> >>> [INFO] at Function.Module.runMain (module.js:497:10) >>> >>> [INFO] ------------------------------------------------------------------------ >>> >>> >>> >>> so, not sure what that really means :-/ >>> >>> >>> On Tue, Jul 8, 2014 at 7:55 PM, Matthias Wessendorf >>> wrote: >>> >>>> someone seen this before? >>>> >>>> [ERROR] Failed to execute goal >>>> com.github.eirslett:frontend-maven-plugin:0.0.14:grunt (grunt build) on >>>> project unifiedpush-server: 'grunt dist --no-color' failed. (error code 8) >>>> -> [Help 1] >>>> >>>> >>>> Looks like yet another issue w/ the JS tools for the UI >>>> >>>> >>>> -- >>>> Matthias Wessendorf >>>> >>>> blog: http://matthiaswessendorf.wordpress.com/ >>>> sessions: http://www.slideshare.net/mwessendorf >>>> twitter: http://twitter.com/mwessendorf >>>> >>> >>> >>> >>> -- >>> Matthias Wessendorf >>> >>> blog: http://matthiaswessendorf.wordpress.com/ >>> sessions: http://www.slideshare.net/mwessendorf >>> twitter: http://twitter.com/mwessendorf >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >>> >> >> -- >> Sent from Gmail Mobile >> > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140708/baf208a1/attachment.html From lholmqui at redhat.com Tue Jul 8 14:45:53 2014 From: lholmqui at redhat.com (Luke Holmquist) Date: Tue, 8 Jul 2014 14:45:53 -0400 (EDT) Subject: [aerogear-dev] grunt error In-Reply-To: References: Message-ID: <28F026E0-BE40-4B71-BD3A-8953E6D613E2@redhat.com> It might. But I'm not sure. Not really familiar with the plugin. When in doubt 'npm install' :) Sent from my iPhone > On Jul 8, 2014, at 2:25 PM, Matthias Wessendorf wrote: > > I did assume the frontend plugin does that :-/ > >> On Tuesday, July 8, 2014, Luke Holmquist wrote: >> 'Npm install' first. Not sure >> >> Sent from my iPhone >> >>> On Jul 8, 2014, at 1:57 PM, Matthias Wessendorf wrote: >>> >>> and a bit above that: >>> >>> [INFO] --- frontend-maven-plugin:0.0.14:grunt (grunt build) @ unifiedpush-server --- >>> >>> >>> [INFO] Running 'grunt dist --no-color' in /home/travis/build/aerogear/aerogear-unifiedpush-server/admin-ui >>> >>> >>> [INFO] >>> >>> >>> [INFO] module.js:340 >>> [INFO] throw err; >>> >>> >>> [INFO] ^ >>> >>> >>> [INFO] Error: Cannot find module 'findup-sync' >>> >>> >>> [INFO] at Function.Module._resolveFilename (module.js:338:15) >>> >>> >>> [INFO] at Function.Module._load (module.js:280:25) >>> >>> >>> [INFO] at Module.require (module.js:364:17) >>> >>> [INFO] at require (module.js:380:17) >>> >>> >>> [INFO] at Object. (/home/travis/build/aerogear/aerogear-unifiedpush-server/admin-ui/node_modules/grunt-cli/bin/grunt:8:14) >>> >>> >>> [INFO] at Module._compile (module.js:456:26) >>> >>> >>> [INFO] at Object.Module._extensions..js (module.js:474:10) >>> >>> >>> [INFO] at Module.load (module.js:356:32) >>> >>> [INFO] at Function.Module._load (module.js:312:12) >>> >>> >>> [INFO] at Function.Module.runMain (module.js:497:10) >>> >>> >>> [INFO] ------------------------------------------------------------------------ >>> >>> >>> >>> >>> so, not sure what that really means :-/ >>> >>> >>>> On Tue, Jul 8, 2014 at 7:55 PM, Matthias Wessendorf wrote: >>>> someone seen this before? >>>> >>>> [ERROR] Failed to execute goal com.github.eirslett:frontend-maven-plugin:0.0.14:grunt (grunt build) on project unifiedpush-server: 'grunt dist --no-color' failed. (error code 8) -> [Help 1] >>>> >>>> >>>> Looks like yet another issue w/ the JS tools for the UI >>>> >>>> >>>> -- >>>> Matthias Wessendorf >>>> >>>> blog: http://matthiaswessendorf.wordpress.com/ >>>> sessions: http://www.slideshare.net/mwessendorf >>>> twitter: http://twitter.com/mwessendorf >>> >>> >>> >>> -- >>> Matthias Wessendorf >>> >>> blog: http://matthiaswessendorf.wordpress.com/ >>> sessions: http://www.slideshare.net/mwessendorf >>> twitter: http://twitter.com/mwessendorf >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > -- > Sent from Gmail Mobile > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140708/5dea1f16/attachment-0001.html From bruno at abstractj.org Tue Jul 8 14:49:18 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Tue, 08 Jul 2014 11:49:18 -0700 (PDT) Subject: [aerogear-dev] grunt error In-Reply-To: References: Message-ID: <1404845358380.722b4c3a@Nodemailer> Network problems, push the button to execute the build again? abstractj On Tue, Jul 8, 2014 at 3:45 PM, Matthias Wessendorf wrote: > travis > On Tue, Jul 8, 2014 at 8:44 PM, Bruno Oliveira wrote: >> I had this issue due to network problems. Does it happen on Travis or just >> locally? >> >> >> ? >> abstractj >> >> >> On Tue, Jul 8, 2014 at 3:24 PM, Matthias Wessendorf >> wrote: >> >>> I did assume the frontend plugin does that :-/ >>> >>> On Tuesday, July 8, 2014, Luke Holmquist wrote: >>> >>>> 'Npm install' first. Not sure >>>> >>>> Sent from my iPhone >>>> >>>> On Jul 8, 2014, at 1:57 PM, Matthias Wessendorf >>>> wrote: >>>> >>>> and a bit above that: >>>> >>>> [INFO] --- frontend-maven-plugin:0.0.14:grunt (grunt build) @ unifiedpush-server --- >>>> >>>> [INFO] Running 'grunt dist --no-color' in /home/travis/build/aerogear/aerogear-unifiedpush-server/admin-ui >>>> >>>> [INFO] >>>> >>>> >>>> [INFO] module.js:340 >>>> >>>> [INFO] throw err; >>>> >>>> [INFO] ^ >>>> >>>> >>>> [INFO] Error: Cannot find module 'findup-sync' >>>> >>>> >>>> [INFO] at Function.Module._resolveFilename (module.js:338:15) >>>> >>>> >>>> [INFO] at Function.Module._load (module.js:280:25) >>>> >>>> >>>> [INFO] at Module.require (module.js:364:17) >>>> >>>> [INFO] at require (module.js:380:17) >>>> >>>> >>>> [INFO] at Object. (/home/travis/build/aerogear/aerogear-unifiedpush-server/admin-ui/node_modules/grunt-cli/bin/grunt:8:14) >>>> >>>> [INFO] at Module._compile (module.js:456:26) >>>> >>>> [INFO] at Object.Module._extensions..js (module.js:474:10) >>>> >>>> [INFO] at Module.load (module.js:356:32) >>>> >>>> [INFO] at Function.Module._load (module.js:312:12) >>>> >>>> [INFO] at Function.Module.runMain (module.js:497:10) >>>> >>>> [INFO] ------------------------------------------------------------------------ >>>> >>>> >>>> >>>> so, not sure what that really means :-/ >>>> >>>> >>>> On Tue, Jul 8, 2014 at 7:55 PM, Matthias Wessendorf >>>> wrote: >>>> >>>>> someone seen this before? >>>>> >>>>> [ERROR] Failed to execute goal >>>>> com.github.eirslett:frontend-maven-plugin:0.0.14:grunt (grunt build) on >>>>> project unifiedpush-server: 'grunt dist --no-color' failed. (error code 8) >>>>> -> [Help 1] >>>>> >>>>> >>>>> Looks like yet another issue w/ the JS tools for the UI >>>>> >>>>> >>>>> -- >>>>> Matthias Wessendorf >>>>> >>>>> blog: http://matthiaswessendorf.wordpress.com/ >>>>> sessions: http://www.slideshare.net/mwessendorf >>>>> twitter: http://twitter.com/mwessendorf >>>>> >>>> >>>> >>>> >>>> -- >>>> Matthias Wessendorf >>>> >>>> blog: http://matthiaswessendorf.wordpress.com/ >>>> sessions: http://www.slideshare.net/mwessendorf >>>> twitter: http://twitter.com/mwessendorf >>>> >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> >>>> >>> >>> -- >>> Sent from Gmail Mobile >>> >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > -- > Matthias Wessendorf > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140708/9d499e1d/attachment.html From bsutter at redhat.com Tue Jul 8 19:39:14 2014 From: bsutter at redhat.com (Burr Sutter) Date: Tue, 8 Jul 2014 19:39:14 -0400 Subject: [aerogear-dev] [liveoak-dev] Re: LiveOak SDK In-Reply-To: <53BBFED9.4020502@redhat.com> References: <53BAC759.7030000@redhat.com> <53BBEBDC.9000300@redhat.com> <1FDBF7E3-69D5-4C65-88F4-18A8416FEBC2@redhat.com> <53BBFED9.4020502@redhat.com> Message-ID: <2D414735-8CCA-43E3-924B-AF91BE037F59@redhat.com> On Jul 8, 2014, at 10:23 AM, Matt Wringe wrote: > On 08/07/14 09:11 AM, Burr Sutter wrote: >> At a minimum, the same HTTP error codes used to indicate "sync errors" via JAX-RS + JPA should be the same for LiveOak's REST APIs - therefore the client-code can be reusable across the two endpoints. We should come up with sync strategies - levels 1, 2 and 3 - where 1 is simply the clever use of HTTP error codes and level 3 is real-time/off-line/auto-conflict resolution. Perhaps there are 4 levels :-) >> >> Anyone care to articulate the possible strategies? > > Some thoughts: > > 1) No conflict resolution. The way it handled in LiveOak right now, whoever is the last person to push to the server overwrites any other changes. Obviously not ideal, but may be acceptable in some cases. (or enabled via a 'force' option)b > > 2) Only allowed to update from the latest version: only allow updates if the resource being updated has not already been modified by someone else. If it has been updated, return HTTP error code The prototype that Erik worked up includes the ability to return the "latest" data - so the end-user can make a decision to overwrite the server copy with the client version OR to overwrite the client copy with the server version. Based on a single HTTP 409 I believe. > > 3) Non-conflicting field updates allowed: allow partial, non-conflicting updates to fields; otherwise return HTTP error code (Eg userA & userB both fetch resourceA from the server, userA makes a change to the 'foo' field and pushes it to the server. UserB makes a change to the 'bar' field and tries to push to the server. Since its a change to a different field, it is allowed). I like that basic merge strategy. > > 4) Non-conflicting updates allowed: expands on the non-conflicting field updates. A smarter diff type system where its can handle more than just modifications to different fields. Eg say there is an 'article' field, UserA and UserB checkout the resource. UserA fixes a typo and pushes it to the server. UserB fixes the same typo and fixes 2 other typos. UserB can commit his change since his changes don't conflict with the previous update. > > [I am sure there are probably some nice diff and merge libraries around that we could use on the server side to take care of handling the conflict logic] > > The above is all stuff which needs to be done on the server side. And there are a few interesting things here where, except for the first option, we could require the data on the server to include special fields for conflict resolution (or something like a md5sum of the resources state). I like it - in a previous life I had a "checksum" like solution to know if something changed during an optimistic-locking scenario - this was much faster than comparing each individual field bit by bit. Once you found out something had changed, you could then iterate through the list of fields/values but the default operation was to first verify the checksum. > Having special fields like this breaks some data features we currently have in LiveOak, but its probably something we can make configurable and have a compromise. > > Client side stuff: > > 1) offline support: I am assuming this is about having some sort of local data cache so that when offline we can get the cached objects. All without having to resort to the whole fetch from a URL then save to local storage manually. Eg liveoak.get("/foo/bar") would fetch and cache locally if online, if offline liveoak.get("/foo/bar") would just get it from the cache. Some interesting stuff would need to be done here on the client side. > > [any plan for encryption and security in this local storage? Any ability to wipe the cache from the console if the device is lost or stolen?] > > 2) real-time: this is where I think things get more interesting. If we had conflict resolution (and partial updates) we could almost do this already in LiveOak (eg register to receive changes to a particular resource when modified on the server, push partial updates when the resource is modified locally. These steps of course would be handled by the SDK and not expected to be manually handled by the developer). This would also tie into the offline support, so when the device goes offline and then comes back, it would need to be able to handle the conflicts and push results back to the server. > > Other considerations > - exposing conflicts to the developer so they can manually handle the issue and/or notify the user. > - allowing the developer to specify what kind of conflict resolution they want for what resources > - how to configure local storage (eg only cache objects already accessed, prefetch a list of resources, never cache certain resources, etc....) > > Anything else? Anybody have comments? We should try to capture this in a wiki/gist :-) > > >> >> >> On Jul 8, 2014, at 9:02 AM, Summers Pittman wrote: >> >>> On Mon 07 Jul 2014 12:14:17 PM EDT, Matt Wringe wrote: >>>> >>>> Initial email to get some discussion going around the LiveOak SDK and >>>> AeroGear collaboration. >>>> >>>> Essentially in LiveOak we are going to need a few different SDK types >>>> >>>> - Client Application SDK >>>> This is the code which will run on the users device. Initial targets >>>> here are javascript (+ cordova support), iOS, Android. This type of SDK >>>> will handle things like getting and sending resources to and from the >>>> server, handling login/logout/registration, etc. Probably some other >>>> things like device registration would be needed as well. >>>> >>>> Not sure if we want to provide support for some other things outside of >>>> communicating with the server or not (eg access to device components (eg >>>> camera, location, etc)) or if these would be best handled by using the >>>> native environment's SDK instead. >>>> >>>> - Server Side SDK >>>> This is code that runs on the server side, written in JavaScript by the >>>> application developer. This will need to be familiar to the client >>>> application's JavaScript SDK, but may not be exactly the same. This type >>>> of SDK will be able to access the same resources as the client side >>>> JavaScript, as well as other internal resources and libraries. >>>> >>>> >>>> I am not sure how to collaborate between the LiveOak and AeroGear teams >>>> here. AeroGear makes really awesome SDKs for various mobile platforms, >>>> but with LiveOak we are dealing with a specific type of application. The >>>> AeroGear SDKs tend to handle the more generic case, which I don't >>>> necessarily think makes sense for a LiveOak SDK. >>>> >>>> I do think it makes sense that the LiveOak SDK uses the AeroGear SDK >>>> internally, but I don't know if we want to expose these AeroGear >>>> components to a LiveOak developer or not. >>>> >>>> >>>> For me, I envision something like the admin setting up their application >>>> in the LiveOak console which then generates a json configuration file >>>> (url locations, resources available, KeyCloak settings, UPS settings, >>>> etc). The application developer then drops this json file in to their >>>> application, the LiveOak SDK reads the json file to set it self up and >>>> then its really easy for the developer to start using it. >>>> >>>> [there are also some really cool things we could be doing here as well >>>> if we can get awesome data sync support for AeroGear. It might be >>>> interesting to be able to fetch a resource from the server and >>>> automatically sync its state across between the client and server. This >>>> way the object appears as a local object: if the resource changes on the >>>> server, it changes locally as well, if it changes locally, that change >>>> is pushed to the server. This way you are just dealing with an object, >>>> and not having to fetch and then push object back and forth between the >>>> server manually] >>>> >>>> Anyone have any thoughts on this? >>> >>> One of the things which may be useful is aerogear-ios and >>> aerogear-android are both modularizing their libraries. IN theory this >>> means that the liveOAK SDK's could be extensions of those modules >>> instead of a single monolothic thing. >>> >>> Sync is still an ongoing discussion in AeroGear, but I think right now >>> the current group thought is that we will focus on 409 Conflict events >>> (JPA versioning on server side and utilities on the client side) and not >>> worrying about realtime sync. >>> >>> >>> Some notes from out last meeting on the topic : >>> Client API Strawman : >>> https://github.com/secondsun/aerogear-android-sync/tree/master/android >>> Client/Server workflow : >>> https://docs.google.com/drawings/d/1E4NDEh3NQCdoEHNNHba4TR2akNrppvV5zDlk5nfzz08/edit >>> >>> >>> Also we are looking at doing something with diff merge patch as well as >>> adding in push based data changed notifications later. >>> >>> >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >>> >>> >>> -- >>> Summers Pittman >>>>> Phone:404 941 4698 >>>>> Java is my crack. >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140708/018e90cc/attachment-0001.html From tech4j at gmail.com Tue Jul 8 20:55:06 2014 From: tech4j at gmail.com (Jay Balunas) Date: Tue, 8 Jul 2014 20:55:06 -0400 Subject: [aerogear-dev] [liveoak-dev] Re: LiveOak SDK In-Reply-To: <2D414735-8CCA-43E3-924B-AF91BE037F59@redhat.com> References: <53BAC759.7030000@redhat.com> <53BBEBDC.9000300@redhat.com> <1FDBF7E3-69D5-4C65-88F4-18A8416FEBC2@redhat.com> <53BBFED9.4020502@redhat.com> <2D414735-8CCA-43E3-924B-AF91BE037F59@redhat.com> Message-ID: <5C0BAA8A-B452-4771-9B53-A0F14B079C03@gmail.com> On Jul 8, 2014, at 7:39 PM, Burr Sutter wrote: > > On Jul 8, 2014, at 10:23 AM, Matt Wringe wrote: > >> On 08/07/14 09:11 AM, Burr Sutter wrote: >>> At a minimum, the same HTTP error codes used to indicate "sync errors" via JAX-RS + JPA should be the same for LiveOak's REST APIs - therefore the client-code can be reusable across the two endpoints. We should come up with sync strategies - levels 1, 2 and 3 - where 1 is simply the clever use of HTTP error codes and level 3 is real-time/off-line/auto-conflict resolution. Perhaps there are 4 levels :-) >>> >>> Anyone care to articulate the possible strategies? >> >> Some thoughts: >> >> 1) No conflict resolution. The way it handled in LiveOak right now, whoever is the last person to push to the server overwrites any other changes. Obviously not ideal, but may be acceptable in some cases. (or enabled via a 'force' option)b >> >> 2) Only allowed to update from the latest version: only allow updates if the resource being updated has not already been modified by someone else. If it has been updated, return HTTP error code > The prototype that Erik worked up includes the ability to return the "latest" data - so the end-user can make a decision to overwrite the server copy with the client version OR to overwrite the client copy with the server version. Based on a single HTTP 409 I believe. >> >> 3) Non-conflicting field updates allowed: allow partial, non-conflicting updates to fields; otherwise return HTTP error code (Eg userA & userB both fetch resourceA from the server, userA makes a change to the 'foo' field and pushes it to the server. UserB makes a change to the 'bar' field and tries to push to the server. Since its a change to a different field, it is allowed). > I like that basic merge strategy. >> >> 4) Non-conflicting updates allowed: expands on the non-conflicting field updates. A smarter diff type system where its can handle more than just modifications to different fields. Eg say there is an 'article' field, UserA and UserB checkout the resource. UserA fixes a typo and pushes it to the server. UserB fixes the same typo and fixes 2 other typos. UserB can commit his change since his changes don't conflict with the previous update. >> >> [I am sure there are probably some nice diff and merge libraries around that we could use on the server side to take care of handling the conflict logic] >> >> The above is all stuff which needs to be done on the server side. And there are a few interesting things here where, except for the first option, we could require the data on the server to include special fields for conflict resolution (or something like a md5sum of the resources state). > I like it - in a previous life I had a "checksum" like solution to know if something changed during an optimistic-locking scenario - this was much faster than comparing each individual field bit by bit. Once you found out something had changed, you could then iterate through the list of fields/values but the default operation was to first verify the checksum. > >> Having special fields like this breaks some data features we currently have in LiveOak, but its probably something we can make configurable and have a compromise. >> >> Client side stuff: >> >> 1) offline support: I am assuming this is about having some sort of local data cache so that when offline we can get the cached objects. All without having to resort to the whole fetch from a URL then save to local storage manually. Eg liveoak.get("/foo/bar") would fetch and cache locally if online, if offline liveoak.get("/foo/bar") would just get it from the cache. Some interesting stuff would need to be done here on the client side. >> >> [any plan for encryption and security in this local storage? Any ability to wipe the cache from the console if the device is lost or stolen?] >> >> 2) real-time: this is where I think things get more interesting. If we had conflict resolution (and partial updates) we could almost do this already in LiveOak (eg register to receive changes to a particular resource when modified on the server, push partial updates when the resource is modified locally. These steps of course would be handled by the SDK and not expected to be manually handled by the developer). This would also tie into the offline support, so when the device goes offline and then comes back, it would need to be able to handle the conflicts and push results back to the server. >> >> Other considerations >> - exposing conflicts to the developer so they can manually handle the issue and/or notify the user. >> - allowing the developer to specify what kind of conflict resolution they want for what resources >> - how to configure local storage (eg only cache objects already accessed, prefetch a list of resources, never cache certain resources, etc....) >> >> Anything else? > Anybody have comments? > > We should try to capture this in a wiki/gist :-) +1 I know some of the AeroGear thoughts/plans are linked below and on our site/wiki, but we should capture this all somewhere. I know Randall also had some good thoughts around this in another email thread we should join and discuss. Randall and Bolek are both on vacation until next week I think (maybe longer). >> >> >>> >>> >>> On Jul 8, 2014, at 9:02 AM, Summers Pittman wrote: >>> >>>> On Mon 07 Jul 2014 12:14:17 PM EDT, Matt Wringe wrote: >>>>> >>>>> Initial email to get some discussion going around the LiveOak SDK and >>>>> AeroGear collaboration. >>>>> >>>>> Essentially in LiveOak we are going to need a few different SDK types >>>>> >>>>> - Client Application SDK >>>>> This is the code which will run on the users device. Initial targets >>>>> here are javascript (+ cordova support), iOS, Android. This type of SDK >>>>> will handle things like getting and sending resources to and from the >>>>> server, handling login/logout/registration, etc. Probably some other >>>>> things like device registration would be needed as well. >>>>> >>>>> Not sure if we want to provide support for some other things outside of >>>>> communicating with the server or not (eg access to device components (eg >>>>> camera, location, etc)) or if these would be best handled by using the >>>>> native environment's SDK instead. >>>>> >>>>> - Server Side SDK >>>>> This is code that runs on the server side, written in JavaScript by the >>>>> application developer. This will need to be familiar to the client >>>>> application's JavaScript SDK, but may not be exactly the same. This type >>>>> of SDK will be able to access the same resources as the client side >>>>> JavaScript, as well as other internal resources and libraries. >>>>> >>>>> >>>>> I am not sure how to collaborate between the LiveOak and AeroGear teams >>>>> here. AeroGear makes really awesome SDKs for various mobile platforms, >>>>> but with LiveOak we are dealing with a specific type of application. The >>>>> AeroGear SDKs tend to handle the more generic case, which I don't >>>>> necessarily think makes sense for a LiveOak SDK. >>>>> >>>>> I do think it makes sense that the LiveOak SDK uses the AeroGear SDK >>>>> internally, but I don't know if we want to expose these AeroGear >>>>> components to a LiveOak developer or not. >>>>> >>>>> >>>>> For me, I envision something like the admin setting up their application >>>>> in the LiveOak console which then generates a json configuration file >>>>> (url locations, resources available, KeyCloak settings, UPS settings, >>>>> etc). The application developer then drops this json file in to their >>>>> application, the LiveOak SDK reads the json file to set it self up and >>>>> then its really easy for the developer to start using it. >>>>> >>>>> [there are also some really cool things we could be doing here as well >>>>> if we can get awesome data sync support for AeroGear. It might be >>>>> interesting to be able to fetch a resource from the server and >>>>> automatically sync its state across between the client and server. This >>>>> way the object appears as a local object: if the resource changes on the >>>>> server, it changes locally as well, if it changes locally, that change >>>>> is pushed to the server. This way you are just dealing with an object, >>>>> and not having to fetch and then push object back and forth between the >>>>> server manually] >>>>> >>>>> Anyone have any thoughts on this? >>>> >>>> One of the things which may be useful is aerogear-ios and >>>> aerogear-android are both modularizing their libraries. IN theory this >>>> means that the liveOAK SDK's could be extensions of those modules >>>> instead of a single monolothic thing. >>>> >>>> Sync is still an ongoing discussion in AeroGear, but I think right now >>>> the current group thought is that we will focus on 409 Conflict events >>>> (JPA versioning on server side and utilities on the client side) and not >>>> worrying about realtime sync. >>>> >>>> >>>> Some notes from out last meeting on the topic : >>>> Client API Strawman : >>>> https://github.com/secondsun/aerogear-android-sync/tree/master/android >>>> Client/Server workflow : >>>> https://docs.google.com/drawings/d/1E4NDEh3NQCdoEHNNHba4TR2akNrppvV5zDlk5nfzz08/edit >>>> >>>> >>>> Also we are looking at doing something with diff merge patch as well as >>>> adding in push based data changed notifications later. >>>> >>>> >>>>> _______________________________________________ >>>>> aerogear-dev mailing list >>>>> aerogear-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> >>>> >>>> >>>> -- >>>> Summers Pittman >>>>>> Phone:404 941 4698 >>>>>> Java is my crack. >>>> >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >> > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140708/afa1dbe1/attachment-0001.html From tkriz at redhat.com Wed Jul 9 05:07:12 2014 From: tkriz at redhat.com (Tadeas Kriz) Date: Wed, 9 Jul 2014 11:07:12 +0200 Subject: [aerogear-dev] cordova plugin release In-Reply-To: <1215EAF1-CA43-40E4-8165-72490EBA1F84@redhat.com> References: <1215EAF1-CA43-40E4-8165-72490EBA1F84@redhat.com> Message-ID: Hey, I?ll test it today evening, so you?ll probably get the test results tomorrow. ? Tadeas Kriz On 08 Jul 2014, at 08:47, Erik Jan de Wit wrote: > Because of all the changes needed to be made to the UnifiedPush Server console, this didn?t get the attention it deserves. There was a bug found by Karel in the quick starts that I just merged. Please retest and then we?ll release next week. > > Cheers, > Erik Jan > > On 8 Jul,2014, at 7:17 , Matthias Wessendorf wrote: > >> I think we never actually released the version 0.6.0 :-) >> >> -Matthias >> >> >> >> On Wed, May 28, 2014 at 11:15 AM, Erik Jan de Wit wrote: >> Hi, >> >> As discussed here (http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-New-Cordova-Push-release-was-Re-Mobile-Push-1-0-0-Client-SDKs-for-Android-Cordova-and-i-td7932.html) we are going to release a new version of the cordova push plugin the new version 0.5.1 most important feature is the updated android libraries. There are also some community bug fixes: >> >> fix a bug with the foreground/isInline flag >> fix bug with android not sending cached message >> Automate plugin testing using grunt-cordova-plugin-jasmine. >> >> Thank you TadeasKriz and keithdmoore for contributing >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> >> -- >> Matthias Wessendorf >> >> blog: http://matthiaswessendorf.wordpress.com/ >> sessions: http://www.slideshare.net/mwessendorf >> twitter: http://twitter.com/mwessendorf >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140709/7f8b82de/attachment.html From matzew at apache.org Wed Jul 9 06:02:25 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Wed, 9 Jul 2014 12:02:25 +0200 Subject: [aerogear-dev] [release] parent / bom new release ? In-Reply-To: <1404803876358-8306.post@n5.nabble.com> References: <1404803876358-8306.post@n5.nabble.com> Message-ID: it hit maven central On Tue, Jul 8, 2014 at 9:17 AM, Andrea Vibelli wrote: > Hi Matt, > +1 for the release of a new version, it will also help polishing the > pom.xml > of the UnifiedPush Server. > > Thanks! > Andrea > > > > -- > View this message in context: > http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-release-parent-bom-new-release-tp8300p8306.html > Sent from the aerogear-dev mailing list archive at Nabble.com. > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140709/3b0d1c41/attachment.html From cvasilak at gmail.com Wed Jul 9 08:08:17 2014 From: cvasilak at gmail.com (Christos Vasilakis) Date: Wed, 9 Jul 2014 15:08:17 +0300 Subject: [aerogear-dev] iOS 6 and Cordova push-sdk Message-ID: Hi all, in order to support users that are currently want to use our Cordova push-sdk, in versions less than iOS 7 we have been discussing two options: a) either modify the native push-sdk that currently uses iOS 7 API for its foundation networking(as of 0.9.0), to use older API that is supported both in iOS 6 and iOS 7 (but not recommended from Apple in favor of the new networking API). b) create a branch in Cordova push-sdk plugin (e.g. ?branch_iOS 6')that uses an older version of the native push-sdk (0.8.1) which was the last version of the native plugin that used the old networking API supporting both iOS 6 and 7. After discussing with Eric And Matthias [1], from cordova push-plugin perspective the native API that Cordova uses hasn?t changed and option b) can be used for users that want to still support iOS 6. Note: This branch will be there just for community's convenience of the users that for some reason want to support iOS 6 and won?t be shipped. Thoughts? Thanks, Christos [1] http://transcripts.jboss.org/channel/irc.freenode.org/%23aerogear/2014/latest.log.html#t2014-07-09T09:42:55 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140709/6ece51a2/attachment.html From corinnekrych at gmail.com Wed Jul 9 08:30:56 2014 From: corinnekrych at gmail.com (Corinne Krych) Date: Wed, 9 Jul 2014 14:30:56 +0200 Subject: [aerogear-dev] iOS 6 and Cordova push-sdk In-Reply-To: References: Message-ID: On 09 Jul 2014, at 14:08, Christos Vasilakis wrote: > Hi all, > > in order to support users that are currently want to use our Cordova push-sdk, in versions less than iOS 7 we have been discussing two options: > > a) either modify the native push-sdk that currently uses iOS 7 API for its foundation networking(as of 0.9.0), to use older API that is supported both in iOS 6 and iOS 7 (but not recommended from Apple in favor of the new networking API). > b) create a branch in Cordova push-sdk plugin (e.g. ?branch_iOS 6')that uses an older version of the native push-sdk (0.8.1) which was the last version of the native plugin that used the old networking API supporting both iOS 6 and 7. > > After discussing with Eric And Matthias [1], from cordova push-plugin perspective the native API that Cordova uses hasn?t changed and option b) can be used for users that want to still support iOS 6. > I?ll go for the simplest. b sounds good to me. > Note: This branch will be there just for community's convenience of the users that for some reason want to support iOS 6 and won?t be shipped. > > Thoughts? > > Thanks, > Christos > > > [1] http://transcripts.jboss.org/channel/irc.freenode.org/%23aerogear/2014/latest.log.html#t2014-07-09T09:42:55 > > > > > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev From matzew at apache.org Wed Jul 9 08:32:36 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Wed, 9 Jul 2014 14:32:36 +0200 Subject: [aerogear-dev] iOS 6 and Cordova push-sdk In-Reply-To: References: Message-ID: On Wed, Jul 9, 2014 at 2:30 PM, Corinne Krych wrote: > > On 09 Jul 2014, at 14:08, Christos Vasilakis wrote: > > > Hi all, > > > > in order to support users that are currently want to use our Cordova > push-sdk, in versions less than iOS 7 we have been discussing two options: > > > > a) either modify the native push-sdk that currently uses iOS 7 API for > its foundation networking(as of 0.9.0), to use older API that is supported > both in iOS 6 and iOS 7 (but not recommended from Apple in favor of the new > networking API). > > b) create a branch in Cordova push-sdk plugin (e.g. ?branch_iOS 6')that > uses an older version of the native push-sdk (0.8.1) which was the last > version of the native plugin that used the old networking API supporting > both iOS 6 and 7. > > > > After discussing with Eric And Matthias [1], from cordova push-plugin > perspective the native API that Cordova uses hasn?t changed and option b) > can be used for users that want to still support iOS 6. > > > > I?ll go for the simplest. b sounds good to me. > I agree that having a temporary 'iOS6 branch' is a good enough solution (with the advent of iOS8 that might be even no more relevant) Thanks, Matthias > > > Note: This branch will be there just for community's convenience of the > users that for some reason want to support iOS 6 and won?t be shipped. > > > > Thoughts? > > > > Thanks, > > Christos > > > > > > [1] > http://transcripts.jboss.org/channel/irc.freenode.org/%23aerogear/2014/latest.log.html#t2014-07-09T09:42:55 > > > > > > > > > > > > > > > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140709/6c94afdf/attachment-0001.html From yagyesh.agrawal at itpeoplecorp.com Wed Jul 9 08:57:25 2014 From: yagyesh.agrawal at itpeoplecorp.com (Yagyesh) Date: Wed, 9 Jul 2014 05:57:25 -0700 (PDT) Subject: [aerogear-dev] iOS 6 and Cordova push-sdk In-Reply-To: References: Message-ID: <1404910645749-8349.post@n5.nabble.com> If i'm developing an application with push support and wants to reach out to all/majority of iOS users, do i need to create two different builds now? Is it possible to modify existing native push library to use older apis for iOS6 & below and newer ones for other OS versions? I'm assuming this has already been thought through & has been eliminated due to maintenance issues of the approach. Thus far i have been using AeroGear libraries only with iOS7, so not sure if same version works on older OS too. -- View this message in context: http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-iOS-6-and-Cordova-push-sdk-tp8346p8349.html Sent from the aerogear-dev mailing list archive at Nabble.com. From matzew at apache.org Wed Jul 9 08:59:19 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Wed, 9 Jul 2014 14:59:19 +0200 Subject: [aerogear-dev] iOS 6 and Cordova push-sdk In-Reply-To: <1404910645749-8349.post@n5.nabble.com> References: <1404910645749-8349.post@n5.nabble.com> Message-ID: On Wed, Jul 9, 2014 at 2:57 PM, Yagyesh wrote: > If i'm developing an application with push support and wants to reach out > to > all/majority of iOS users, do i need to create two different builds now? > the Cordova-SDK branch we are talking about should be running on iOS7 as well - should be ;-) > > Is it possible to modify existing native push library to use older apis for > iOS6 & below and newer ones for other OS versions? I'm assuming this has > already been thought through & has been eliminated due to maintenance > issues > of the approach. > > Thus far i have been using AeroGear libraries only with iOS7, so not sure > if > same version works on older OS too. > > > > -- > View this message in context: > http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-iOS-6-and-Cordova-push-sdk-tp8346p8349.html > Sent from the aerogear-dev mailing list archive at Nabble.com. > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140709/ccb4f57f/attachment.html From matzew at apache.org Wed Jul 9 11:03:49 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Wed, 9 Jul 2014 17:03:49 +0200 Subject: [aerogear-dev] Sync - Server items (JAX-RS and JPA) In-Reply-To: <66BC3E5F-229C-4891-A5C3-ACCCE35FEF76@redhat.com> References: <66BC3E5F-229C-4891-A5C3-ACCCE35FEF76@redhat.com> Message-ID: Hi, we had a meeting on this 'server side' sync topic. In terms of delivering a 'quick solution' around JavaEE (JAX-RS/JPA): Erik's sent a PR to forge (see [1]) and Erik started a branch on adding the minimal/quick solution to our Quickstarts (atm: Cordova and Server): https://github.com/edewit/aerogear-push-quickstarts/tree/conflict ==> It basically is "optimistic locking" and returning 409 to the client, telling there is a conflict; NOTE: there is NO merge. What we could do.... * Provide an annotation for all of that work (outside of the quickstart, as a "library"); * we could also integrate the push notification delivery on conflicts (not sure it really makes sense, for now...). Note that this is just an initial and very simple solution, not really something considered being called a 'sync server'. I liked Summers comment: "I think the EE stuff is a stop gap until the sync server is done IE the cheap 50% solution". I agree with that; Eventually it will go away in fav. of the 'sync-server' that Dan/Luke are working on. OK, in terms of timing,... we could include Erik's work (see [2]) into our 1.0.0 release (of the quickstarts). That means we would need to bring the Cordova behavior to iOS and Android (Summers has a POC that does similar bits around @Version Entities and Optimistic Locking (and returning 409), see [3]). Or we do that after we released the AeroGear Mobile Push 1.0.0 to the community; So it could be bundled with an 1.0.1 in... let's say September. About the long-term solution: Dan and Luke will continue their research --> Server side POC https://github.com/danbev/aerogear-sync-server/tree/differential-synchronization --> Client side POC https://github.com/lholmquist/ag-js-ds-poc We will be also reaching out to other groups, as we are not the only ones interested in 'sync' Any thoughts or questions ? -Matthias [1] https://github.com/forge/core/pull/481 [2] https://github.com/edewit/aerogear-push-quickstarts/tree/conflict [3] Summers POC: * https://github.com/secondsun/SmogRideAndroid (client) * https://github.com/secondsun/SmogRide (Server) On Fri, Jul 4, 2014 at 9:46 AM, Erik Jan de Wit wrote: > > On 4 Jul,2014, at 9:28 , Matthias Wessendorf wrote: > > > 2) Initial quick and simple solution based on JAX-RS and JPA: > - We have versioning in JPA (optimistic locking) - Use it (send 409 on > server and send right data) > > -- Use JAX-RS ExceptionMapper for exceptions around the optimistic locking > ? > > > Added handling of OptimisticLockException to forge > https://github.com/forge/core/pull/481 this will give clients a 409 so > that they could show to the user that their copy was out of date. Now the > client still need to react to this. > > - Client library will have helper methods for managing data > > > POC of client handeling this > https://github.com/edewit/aerogear-push-quickstarts/tree/conflict/client/cordova/angular/www this > will just show the client version and the server version and the user can > choose which version to take > > - Use push to send notifications that data changed? > - JAX-RS Annotation to send notifications? > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140709/04a0edae/attachment.html From bsutter at redhat.com Wed Jul 9 11:11:26 2014 From: bsutter at redhat.com (Burr Sutter) Date: Wed, 9 Jul 2014 11:11:26 -0400 Subject: [aerogear-dev] Sync - Server items (JAX-RS and JPA) In-Reply-To: References: <66BC3E5F-229C-4891-A5C3-ACCCE35FEF76@redhat.com> Message-ID: <639953A4-3B55-4109-AB2F-F92D5EE10347@redhat.com> On Jul 9, 2014, at 11:03 AM, Matthias Wessendorf wrote: > Hi, > > we had a meeting on this 'server side' sync topic. In terms of delivering a 'quick solution' around JavaEE (JAX-RS/JPA): > > Erik's sent a PR to forge (see [1]) and Erik started a branch on adding the minimal/quick solution to our Quickstarts (atm: Cordova and Server): > https://github.com/edewit/aerogear-push-quickstarts/tree/conflict > > ==> It basically is "optimistic locking" and returning 409 to the client, telling there is a conflict; NOTE: there is NO merge. > > What we could do.... in what timeframe? :-) > * Provide an annotation for all of that work (outside of the quickstart, as a "library"); that could be interesting, but how much boilderplate code is it eliminating? 10 lines? > * we could also integrate the push notification delivery on conflicts (not sure it really makes sense, for now...). Seems like overkill to me > > Note that this is just an initial and very simple solution, not really something considered being called a 'sync server'. I liked Summers comment: "I think the EE stuff is a stop gap until the sync server is done IE the cheap 50% solution". I agree with that; Eventually it will go away in fav. of the 'sync-server' that Dan/Luke are working on. > > > OK, in terms of timing,... we could include Erik's work (see [2]) into our 1.0.0 release (of the quickstarts). And try to get the Forge JAX-RS generation updated https://issues.jboss.org/browse/FORGE-1916 Just provide the template code - the Forge team will do the rest. > That means we would need to bring the Cordova behavior to iOS and Android (Summers has a POC that does similar bits around @Version Entities and Optimistic Locking (and returning 409), see [3]). Is this an update to just the quickstarts or to some framework/library code? > Or we do that after we released the AeroGear Mobile Push 1.0.0 to the community; So it could be bundled with an 1.0.1 in... let's say September. > > > About the long-term solution: > > Dan and Luke will continue their research > --> Server side POC https://github.com/danbev/aerogear-sync-server/tree/differential-synchronization > --> Client side POC https://github.com/lholmquist/ag-js-ds-poc > > We will be also reaching out to other groups, as we are not the only ones interested in 'sync' > > Any thoughts or questions ? > -Matthias > > > [1] https://github.com/forge/core/pull/481 > [2] https://github.com/edewit/aerogear-push-quickstarts/tree/conflict > [3] Summers POC: > * https://github.com/secondsun/SmogRideAndroid (client) > * https://github.com/secondsun/SmogRide (Server) > > > > On Fri, Jul 4, 2014 at 9:46 AM, Erik Jan de Wit wrote: > > On 4 Jul,2014, at 9:28 , Matthias Wessendorf wrote: >> >> 2) Initial quick and simple solution based on JAX-RS and JPA: >> - We have versioning in JPA (optimistic locking) - Use it (send 409 on server and send right data) >> -- Use JAX-RS ExceptionMapper for exceptions around the optimistic locking ? > > Added handling of OptimisticLockException to forge https://github.com/forge/core/pull/481 this will give clients a 409 so that they could show to the user that their copy was out of date. Now the client still need to react to this. > >> - Client library will have helper methods for managing data > > POC of client handeling this https://github.com/edewit/aerogear-push-quickstarts/tree/conflict/client/cordova/angular/www this will just show the client version and the server version and the user can choose which version to take > >> - Use push to send notifications that data changed? >> - JAX-RS Annotation to send notifications? >> > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140709/2e7ad44b/attachment-0001.html From matzew at apache.org Wed Jul 9 11:18:05 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Wed, 9 Jul 2014 17:18:05 +0200 Subject: [aerogear-dev] Sync - Server items (JAX-RS and JPA) In-Reply-To: <639953A4-3B55-4109-AB2F-F92D5EE10347@redhat.com> References: <66BC3E5F-229C-4891-A5C3-ACCCE35FEF76@redhat.com> <639953A4-3B55-4109-AB2F-F92D5EE10347@redhat.com> Message-ID: On Wed, Jul 9, 2014 at 5:11 PM, Burr Sutter wrote: > > On Jul 9, 2014, at 11:03 AM, Matthias Wessendorf > wrote: > > Hi, > > we had a meeting on this 'server side' sync topic. In terms of delivering > a 'quick solution' around JavaEE (JAX-RS/JPA): > > Erik's sent a PR to forge (see [1]) and Erik started a branch on adding > the minimal/quick solution to our Quickstarts (atm: Cordova and Server): > https://github.com/edewit/aerogear-push-quickstarts/tree/conflict > > ==> It basically is "optimistic locking" and returning 409 to the client, > telling there is a conflict; NOTE: there is NO merge. > > What we could do.... > > in what timeframe? :-) > I think I mentioned that a bit later in my email, at the bottom > > * Provide an annotation for all of that work (outside of the quickstart, > as a "library"); > > that could be interesting, but how much boilderplate code is it > eliminating? 10 lines? > Possible - just an idea we had at the Face2Face meeting. To make it darn simple > > * we could also integrate the push notification delivery on conflicts (not > sure it really makes sense, for now...). > > Seems like overkill to me > yeah, same feeing; No Push on Conflict it is, for now > > > Note that this is just an initial and very simple solution, not really > something considered being called a 'sync server'. I liked Summers comment: > "I think the EE stuff is a stop gap until the sync server is done IE the > cheap 50% solution". I agree with that; Eventually it will go away in fav. > of the 'sync-server' that Dan/Luke are working on. > > > > OK, in terms of timing,... we could include Erik's work (see [2]) into our > 1.0.0 release (of the quickstarts). > > And try to get the Forge JAX-RS generation updated > https://issues.jboss.org/browse/FORGE-1916 > > Just provide the template code - the Forge team will do the rest. > > That means we would need to bring the Cordova behavior to iOS and Android > (Summers has a POC that does similar bits around @Version Entities and > Optimistic Locking (and returning 409), see [3]). > > Is this an update to just the quickstarts or to some framework/library > code? > to the quickstarts; see https://github.com/edewit/aerogear-push-quickstarts/tree/conflict > > Or we do that after we released the AeroGear Mobile Push 1.0.0 to the > community; So it could be bundled with an 1.0.1 in... let's say September. > > > About the long-term solution: > > Dan and Luke will continue their research > --> Server side POC > https://github.com/danbev/aerogear-sync-server/tree/differential-synchronization > --> Client side POC https://github.com/lholmquist/ag-js-ds-poc > > We will be also reaching out to other groups, as we are not the only ones > interested in 'sync' > > Any thoughts or questions ? > -Matthias > > > [1] https://github.com/forge/core/pull/481 > [2] https://github.com/edewit/aerogear-push-quickstarts/tree/conflict > [3] Summers POC: > * https://github.com/secondsun/SmogRideAndroid (client) > * https://github.com/secondsun/SmogRide (Server) > > > > On Fri, Jul 4, 2014 at 9:46 AM, Erik Jan de Wit wrote: > >> >> On 4 Jul,2014, at 9:28 , Matthias Wessendorf wrote: >> >> >> 2) Initial quick and simple solution based on JAX-RS and JPA: >> - We have versioning in JPA (optimistic locking) - Use it (send 409 on >> server and send right data) >> >> -- Use JAX-RS ExceptionMapper for exceptions around the optimistic >> locking ? >> >> >> Added handling of OptimisticLockException to forge >> https://github.com/forge/core/pull/481 this will give clients a 409 so >> that they could show to the user that their copy was out of date. Now the >> client still need to react to this. >> >> - Client library will have helper methods for managing data >> >> >> POC of client handeling this >> https://github.com/edewit/aerogear-push-quickstarts/tree/conflict/client/cordova/angular/www this >> will just show the client version and the server version and the user can >> choose which version to take >> >> - Use push to send notifications that data changed? >> - JAX-RS Annotation to send notifications? >> >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140709/3412d228/attachment.html From scm.blanc at gmail.com Wed Jul 9 11:21:47 2014 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Wed, 9 Jul 2014 17:21:47 +0200 Subject: [aerogear-dev] Sync - Server items (JAX-RS and JPA) In-Reply-To: References: <66BC3E5F-229C-4891-A5C3-ACCCE35FEF76@redhat.com> <639953A4-3B55-4109-AB2F-F92D5EE10347@redhat.com> Message-ID: On Wed, Jul 9, 2014 at 5:18 PM, Matthias Wessendorf wrote: > > > > On Wed, Jul 9, 2014 at 5:11 PM, Burr Sutter wrote: > >> >> On Jul 9, 2014, at 11:03 AM, Matthias Wessendorf >> wrote: >> >> Hi, >> >> we had a meeting on this 'server side' sync topic. In terms of delivering >> a 'quick solution' around JavaEE (JAX-RS/JPA): >> >> Erik's sent a PR to forge (see [1]) and Erik started a branch on adding >> the minimal/quick solution to our Quickstarts (atm: Cordova and Server): >> https://github.com/edewit/aerogear-push-quickstarts/tree/conflict >> >> ==> It basically is "optimistic locking" and returning 409 to the client, >> telling there is a conflict; NOTE: there is NO merge. >> >> What we could do.... >> >> in what timeframe? :-) >> > > I think I mentioned that a bit later in my email, at the bottom > > > >> >> * Provide an annotation for all of that work (outside of the quickstart, >> as a "library"); >> >> that could be interesting, but how much boilderplate code is it >> eliminating? 10 lines? >> > > Possible - just an idea we had at the Face2Face meeting. To make it darn > simple > > >> >> * we could also integrate the push notification delivery on conflicts >> (not sure it really makes sense, for now...). >> >> Seems like overkill to me >> > > yeah, same feeing; No Push on Conflict it is, for now > If we go for the annotation that could be (in the future) an option to be passed to the annotation (serverUrl:"",masterId:"",masterSecret:"") > > >> >> >> Note that this is just an initial and very simple solution, not really >> something considered being called a 'sync server'. I liked Summers comment: >> "I think the EE stuff is a stop gap until the sync server is done IE the >> cheap 50% solution". I agree with that; Eventually it will go away in fav. >> of the 'sync-server' that Dan/Luke are working on. >> >> >> >> OK, in terms of timing,... we could include Erik's work (see [2]) into >> our 1.0.0 release (of the quickstarts). >> >> And try to get the Forge JAX-RS generation updated >> https://issues.jboss.org/browse/FORGE-1916 >> >> Just provide the template code - the Forge team will do the rest. >> >> That means we would need to bring the Cordova behavior to iOS and Android >> (Summers has a POC that does similar bits around @Version Entities and >> Optimistic Locking (and returning 409), see [3]). >> >> Is this an update to just the quickstarts or to some framework/library >> code? >> > > to the quickstarts; see > https://github.com/edewit/aerogear-push-quickstarts/tree/conflict > > > > > >> >> Or we do that after we released the AeroGear Mobile Push 1.0.0 to the >> community; So it could be bundled with an 1.0.1 in... let's say September. >> >> >> About the long-term solution: >> >> Dan and Luke will continue their research >> --> Server side POC >> https://github.com/danbev/aerogear-sync-server/tree/differential-synchronization >> --> Client side POC https://github.com/lholmquist/ag-js-ds-poc >> >> We will be also reaching out to other groups, as we are not the only ones >> interested in 'sync' >> >> Any thoughts or questions ? >> -Matthias >> >> >> [1] https://github.com/forge/core/pull/481 >> [2] https://github.com/edewit/aerogear-push-quickstarts/tree/conflict >> [3] Summers POC: >> * https://github.com/secondsun/SmogRideAndroid (client) >> * https://github.com/secondsun/SmogRide (Server) >> >> >> >> On Fri, Jul 4, 2014 at 9:46 AM, Erik Jan de Wit >> wrote: >> >>> >>> On 4 Jul,2014, at 9:28 , Matthias Wessendorf wrote: >>> >>> >>> 2) Initial quick and simple solution based on JAX-RS and JPA: >>> - We have versioning in JPA (optimistic locking) - Use it (send 409 on >>> server and send right data) >>> >>> -- Use JAX-RS ExceptionMapper for exceptions around the optimistic >>> locking ? >>> >>> >>> Added handling of OptimisticLockException to forge >>> https://github.com/forge/core/pull/481 this will give clients a 409 so >>> that they could show to the user that their copy was out of date. Now the >>> client still need to react to this. >>> >>> - Client library will have helper methods for managing data >>> >>> >>> POC of client handeling this >>> https://github.com/edewit/aerogear-push-quickstarts/tree/conflict/client/cordova/angular/www this >>> will just show the client version and the server version and the user can >>> choose which version to take >>> >>> - Use push to send notifications that data changed? >>> - JAX-RS Annotation to send notifications? >>> >>> >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >> >> >> >> -- >> Matthias Wessendorf >> >> blog: http://matthiaswessendorf.wordpress.com/ >> sessions: http://www.slideshare.net/mwessendorf >> twitter: http://twitter.com/mwessendorf >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140709/b79068a4/attachment-0001.html From matzew at apache.org Wed Jul 9 11:23:05 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Wed, 9 Jul 2014 17:23:05 +0200 Subject: [aerogear-dev] iOS 6 and Cordova push-sdk In-Reply-To: References: <1404910645749-8349.post@n5.nabble.com> Message-ID: Erik created the branch: https://github.com/aerogear/aerogear-pushplugin-cordova/tree/iOS6 he also tested it on iOS7 -> works guys, let us now if that works for you! -Matthias On Wed, Jul 9, 2014 at 2:59 PM, Matthias Wessendorf wrote: > > > > On Wed, Jul 9, 2014 at 2:57 PM, Yagyesh > wrote: > >> If i'm developing an application with push support and wants to reach out >> to >> all/majority of iOS users, do i need to create two different builds now? >> > > the Cordova-SDK branch we are talking about should be running on iOS7 as > well - should be ;-) > > > >> >> Is it possible to modify existing native push library to use older apis >> for >> iOS6 & below and newer ones for other OS versions? I'm assuming this has >> already been thought through & has been eliminated due to maintenance >> issues >> of the approach. >> >> Thus far i have been using AeroGear libraries only with iOS7, so not sure >> if >> same version works on older OS too. >> >> >> >> -- >> View this message in context: >> http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-iOS-6-and-Cordova-push-sdk-tp8346p8349.html >> Sent from the aerogear-dev mailing list archive at Nabble.com. >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140709/356dd3e7/attachment.html From edewit at redhat.com Wed Jul 9 11:33:55 2014 From: edewit at redhat.com (Erik Jan de Wit) Date: Wed, 9 Jul 2014 17:33:55 +0200 Subject: [aerogear-dev] Sync - Server items (JAX-RS and JPA) In-Reply-To: <639953A4-3B55-4109-AB2F-F92D5EE10347@redhat.com> References: <66BC3E5F-229C-4891-A5C3-ACCCE35FEF76@redhat.com> <639953A4-3B55-4109-AB2F-F92D5EE10347@redhat.com> Message-ID: <4EAA575E-D760-4D0A-8BC7-BFC75CA3FF29@redhat.com> >> OK, in terms of timing,... we could include Erik's work (see [2]) into our 1.0.0 release (of the quickstarts). > And try to get the Forge JAX-RS generation updated > https://issues.jboss.org/browse/FORGE-1916 > > Just provide the template code - the Forge team will do the rest. That is done, changes got merged -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140709/489fa220/attachment.html From matzew at apache.org Wed Jul 9 13:16:51 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Wed, 9 Jul 2014 19:16:51 +0200 Subject: [aerogear-dev] Another BOM release Message-ID: 0.2.2 has been staged here: http://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-3544/ main/only 'fix' -> using java-apns 1.0.0.Beta3 Any concerns? -Matt -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140709/d8625dca/attachment.html From avibelli at redhat.com Wed Jul 9 17:01:39 2014 From: avibelli at redhat.com (Andrea Vibelli) Date: Wed, 9 Jul 2014 14:01:39 -0700 (PDT) Subject: [aerogear-dev] Another BOM release In-Reply-To: References: Message-ID: <1404939699807-8358.post@n5.nabble.com> Nope, go for it! Thanks Andrea Matthias Wessendorf wrote > 0.2.2 has been staged here: > http://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-3544/ > > main/only 'fix' -> using java-apns 1.0.0.Beta3 > > > Any concerns? > > -Matt > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at .jboss > https://lists.jboss.org/mailman/listinfo/aerogear-dev -- View this message in context: http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-Another-BOM-release-tp8357p8358.html Sent from the aerogear-dev mailing list archive at Nabble.com. From matzew at apache.org Thu Jul 10 02:45:08 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Thu, 10 Jul 2014 08:45:08 +0200 Subject: [aerogear-dev] Another BOM release In-Reply-To: <1404939699807-8358.post@n5.nabble.com> References: <1404939699807-8358.post@n5.nabble.com> Message-ID: shipped to maven central ! On Wed, Jul 9, 2014 at 11:01 PM, Andrea Vibelli wrote: > Nope, > go for it! > > Thanks > Andrea > > > Matthias Wessendorf wrote > > 0.2.2 has been staged here: > > > http://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-3544/ > > > > main/only 'fix' -> using java-apns 1.0.0.Beta3 > > > > > > Any concerns? > > > > -Matt > > > > -- > > Matthias Wessendorf > > > > blog: http://matthiaswessendorf.wordpress.com/ > > sessions: http://www.slideshare.net/mwessendorf > > twitter: http://twitter.com/mwessendorf > > > > _______________________________________________ > > aerogear-dev mailing list > > > aerogear-dev at .jboss > > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > > -- > View this message in context: > http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-Another-BOM-release-tp8357p8358.html > Sent from the aerogear-dev mailing list archive at Nabble.com. > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140710/58786a39/attachment.html From matzew at apache.org Thu Jul 10 08:28:01 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Thu, 10 Jul 2014 14:28:01 +0200 Subject: [aerogear-dev] [Push] Notification Actions (iOS8) Message-ID: Hi, as Corinne mentioned on a different thread, w/ iOS8 Apple introduces new UIUserNotificationActions, that can be grouped into a category (UIUserNotificationCategory). For remote notifications (aka push) those actions can be trigger by sending this JSON payload to APNs: aps { alert: {...}, category: "SOMETHING" } I'd like to add that feature to the UnifiedPush Server and the Java/Node Senders. Our own message format (see [2]) has already a categoies element, but that is used for filtering/tagging; That element is NOT related to the actual payload of the message (which the apple action/category is all about). Now, I'd like to introduce an "action-category" element inside of the "message" object, like: message: { ....... "alert":"HELLO!", ....... "action-category":"SOMETHING" } This value will be send down to the actual device (by Apple) as part of the message. The name is perhaps a bit Apple-oriented, but I think it may fit other platforms as well... Looks like Summers/Passos want to do similar for Android (see [3]). What do you think ? -Matthias [1] What's New in iOS Notifications on: https://developer.apple.com/videos/wwdc/2014/ (caution, for lame reasons only works on Safari O_o) [2] http://aerogear.org/docs/specs/aerogear-push-messages/ [3] https://issues.jboss.org/browse/AGDROID-258 -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140710/7df88758/attachment-0001.html From scm.blanc at gmail.com Thu Jul 10 08:36:07 2014 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Thu, 10 Jul 2014 14:36:07 +0200 Subject: [aerogear-dev] [Push] Notification Actions (iOS8) In-Reply-To: References: Message-ID: Sounds good ! Just to confirm does the value of the "action-category" relates to the category.identifier like in https://github.com/corinnekrych/HelloWorld-Swift/blob/local.notification/HelloWorldSwift/AppDelegate.swift#L60 ? On Thu, Jul 10, 2014 at 2:28 PM, Matthias Wessendorf wrote: > Hi, > > as Corinne mentioned on a different thread, w/ iOS8 Apple introduces new > UIUserNotificationActions, that can be grouped into a category > (UIUserNotificationCategory). > > For remote notifications (aka push) those actions can be trigger by > sending this JSON payload to APNs: > > aps { > alert: {...}, > category: "SOMETHING" > } > > > I'd like to add that feature to the UnifiedPush Server and the Java/Node > Senders. > > Our own message format (see [2]) has already a categoies element, but that > is used for filtering/tagging; That element is NOT related to the actual > payload of the message (which the apple action/category is all about). > > Now, I'd like to introduce an "action-category" element inside of the > "message" object, like: > > message: { > ....... > "alert":"HELLO!", > ....... > "action-category":"SOMETHING" > } > > This value will be send down to the actual device (by Apple) as part of > the message. The name is perhaps a bit Apple-oriented, but I think it may > fit other platforms as well... > > Looks like Summers/Passos want to do similar for Android (see [3]). > > What do you think ? > > > -Matthias > > > > [1] What's New in iOS Notifications on: > https://developer.apple.com/videos/wwdc/2014/ (caution, for lame reasons > only works on Safari O_o) > > [2] http://aerogear.org/docs/specs/aerogear-push-messages/ > [3] https://issues.jboss.org/browse/AGDROID-258 > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140710/4c85d46f/attachment.html From corinnekrych at gmail.com Thu Jul 10 08:39:05 2014 From: corinnekrych at gmail.com (Corinne Krych) Date: Thu, 10 Jul 2014 14:39:05 +0200 Subject: [aerogear-dev] [Push] Notification Actions (iOS8) In-Reply-To: References: Message-ID: <5B361BA1-B1FA-418C-9AB6-616EB4AA0C9E@gmail.com> On 10 Jul 2014, at 14:36, Sebastien Blanc wrote: > Sounds good ! > > Just to confirm does the value of the "action-category" relates to the category.identifier like in https://github.com/corinnekrych/HelloWorld-Swift/blob/local.notification/HelloWorldSwift/AppDelegate.swift#L60 ? > > Yes like commented here: https://github.com/corinnekrych/HelloWorld-Swift/blob/local.notification/HelloWorldSwift/AppDelegate.swift#L21 > > On Thu, Jul 10, 2014 at 2:28 PM, Matthias Wessendorf wrote: > Hi, > > as Corinne mentioned on a different thread, w/ iOS8 Apple introduces new UIUserNotificationActions, that can be grouped into a category (UIUserNotificationCategory). > > For remote notifications (aka push) those actions can be trigger by sending this JSON payload to APNs: > > aps { > alert: {...}, > category: "SOMETHING" > } > > > I'd like to add that feature to the UnifiedPush Server and the Java/Node Senders. > > Our own message format (see [2]) has already a categoies element, but that is used for filtering/tagging; That element is NOT related to the actual payload of the message (which the apple action/category is all about). > > Now, I'd like to introduce an "action-category" element inside of the "message" object, like: > > message: { > ....... > "alert":"HELLO!", > ....... > "action-category":"SOMETHING" > } > > This value will be send down to the actual device (by Apple) as part of the message. The name is perhaps a bit Apple-oriented, but I think it may fit other platforms as well... > > Looks like Summers/Passos want to do similar for Android (see [3]). > > What do you think ? > > > -Matthias > > > > [1] What's New in iOS Notifications on: > https://developer.apple.com/videos/wwdc/2014/ (caution, for lame reasons only works on Safari O_o) > > [2] http://aerogear.org/docs/specs/aerogear-push-messages/ > [3] https://issues.jboss.org/browse/AGDROID-258 > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev From matzew at apache.org Thu Jul 10 08:41:34 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Thu, 10 Jul 2014 14:41:34 +0200 Subject: [aerogear-dev] [Push] Notification Actions (iOS8) In-Reply-To: References: Message-ID: On Thu, Jul 10, 2014 at 2:36 PM, Sebastien Blanc wrote: > Sounds good ! > > Just to confirm does the value of the "action-category" relates to the > category.identifier like in > https://github.com/corinnekrych/HelloWorld-Swift/blob/local.notification/HelloWorldSwift/AppDelegate.swift#L60 > ? > yes, that's how you group the action, on the client; the action-category is than used when sending bits to APNs, to trigger that categorized action, on the client. Makes sense? -Matthias > > > > On Thu, Jul 10, 2014 at 2:28 PM, Matthias Wessendorf > wrote: > >> Hi, >> >> as Corinne mentioned on a different thread, w/ iOS8 Apple introduces new >> UIUserNotificationActions, that can be grouped into a category >> (UIUserNotificationCategory). >> >> For remote notifications (aka push) those actions can be trigger by >> sending this JSON payload to APNs: >> >> aps { >> alert: {...}, >> category: "SOMETHING" >> } >> >> >> I'd like to add that feature to the UnifiedPush Server and the Java/Node >> Senders. >> >> Our own message format (see [2]) has already a categoies element, but >> that is used for filtering/tagging; That element is NOT related to the >> actual payload of the message (which the apple action/category is all >> about). >> >> Now, I'd like to introduce an "action-category" element inside of the >> "message" object, like: >> >> message: { >> ....... >> "alert":"HELLO!", >> ....... >> "action-category":"SOMETHING" >> } >> >> This value will be send down to the actual device (by Apple) as part of >> the message. The name is perhaps a bit Apple-oriented, but I think it may >> fit other platforms as well... >> >> Looks like Summers/Passos want to do similar for Android (see [3]). >> >> What do you think ? >> >> >> -Matthias >> >> >> >> [1] What's New in iOS Notifications on: >> https://developer.apple.com/videos/wwdc/2014/ (caution, for lame reasons >> only works on Safari O_o) >> >> [2] http://aerogear.org/docs/specs/aerogear-push-messages/ >> [3] https://issues.jboss.org/browse/AGDROID-258 >> >> >> -- >> Matthias Wessendorf >> >> blog: http://matthiaswessendorf.wordpress.com/ >> sessions: http://www.slideshare.net/mwessendorf >> twitter: http://twitter.com/mwessendorf >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140710/214c8ccf/attachment.html From matzew at apache.org Thu Jul 10 08:42:50 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Thu, 10 Jul 2014 14:42:50 +0200 Subject: [aerogear-dev] [Push] Notification Actions (iOS8) In-Reply-To: <5B361BA1-B1FA-418C-9AB6-616EB4AA0C9E@gmail.com> References: <5B361BA1-B1FA-418C-9AB6-616EB4AA0C9E@gmail.com> Message-ID: On Thu, Jul 10, 2014 at 2:39 PM, Corinne Krych wrote: > > On 10 Jul 2014, at 14:36, Sebastien Blanc wrote: > > > Sounds good ! > > > > Just to confirm does the value of the "action-category" relates to the > category.identifier like in > https://github.com/corinnekrych/HelloWorld-Swift/blob/local.notification/HelloWorldSwift/AppDelegate.swift#L60 > ? > what's the difference between your repo and this folder: https://github.com/aerogear/aerogear-push-helloworld/tree/master/ios-swift > > > > > > > Yes like commented here: > > https://github.com/corinnekrych/HelloWorld-Swift/blob/local.notification/HelloWorldSwift/AppDelegate.swift#L21 > > > > > > On Thu, Jul 10, 2014 at 2:28 PM, Matthias Wessendorf > wrote: > > Hi, > > > > as Corinne mentioned on a different thread, w/ iOS8 Apple introduces new > UIUserNotificationActions, that can be grouped into a category > (UIUserNotificationCategory). > > > > For remote notifications (aka push) those actions can be trigger by > sending this JSON payload to APNs: > > > > aps { > > alert: {...}, > > category: "SOMETHING" > > } > > > > > > I'd like to add that feature to the UnifiedPush Server and the Java/Node > Senders. > > > > Our own message format (see [2]) has already a categoies element, but > that is used for filtering/tagging; That element is NOT related to the > actual payload of the message (which the apple action/category is all > about). > > > > Now, I'd like to introduce an "action-category" element inside of the > "message" object, like: > > > > message: { > > ....... > > "alert":"HELLO!", > > ....... > > "action-category":"SOMETHING" > > } > > > > This value will be send down to the actual device (by Apple) as part of > the message. The name is perhaps a bit Apple-oriented, but I think it may > fit other platforms as well... > > > > Looks like Summers/Passos want to do similar for Android (see [3]). > > > > What do you think ? > > > > > > -Matthias > > > > > > > > [1] What's New in iOS Notifications on: > > https://developer.apple.com/videos/wwdc/2014/ (caution, for lame > reasons only works on Safari O_o) > > > > [2] http://aerogear.org/docs/specs/aerogear-push-messages/ > > [3] https://issues.jboss.org/browse/AGDROID-258 > > > > > > -- > > Matthias Wessendorf > > > > blog: http://matthiaswessendorf.wordpress.com/ > > sessions: http://www.slideshare.net/mwessendorf > > twitter: http://twitter.com/mwessendorf > > > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140710/4f8d7a63/attachment-0001.html From corinnekrych at gmail.com Thu Jul 10 09:31:56 2014 From: corinnekrych at gmail.com (Corinne Krych) Date: Thu, 10 Jul 2014 15:31:56 +0200 Subject: [aerogear-dev] [Push] Notification Actions (iOS8) In-Reply-To: References: <5B361BA1-B1FA-418C-9AB6-616EB4AA0C9E@gmail.com> Message-ID: I did those sample with interactive notification on local.notification on my initial repo. This is just POC/sample code. Then I merged my repo into aerogear-push-helloworld master I haven't merged interactive notification in central repo and actually I don't planned to. We have a ticket to demo interactive notification with AeroDoc. Let's keep Helloworld simple. ++ Corinne On 10 July 2014 14:42, Matthias Wessendorf wrote: > > > > On Thu, Jul 10, 2014 at 2:39 PM, Corinne Krych > wrote: > >> >> On 10 Jul 2014, at 14:36, Sebastien Blanc wrote: >> >> > Sounds good ! >> > >> > Just to confirm does the value of the "action-category" relates to the >> category.identifier like in >> https://github.com/corinnekrych/HelloWorld-Swift/blob/local.notification/HelloWorldSwift/AppDelegate.swift#L60 >> ? >> > > what's the difference between your repo and this folder: > https://github.com/aerogear/aerogear-push-helloworld/tree/master/ios-swift > > > > > > >> > >> > >> >> >> Yes like commented here: >> >> https://github.com/corinnekrych/HelloWorld-Swift/blob/local.notification/HelloWorldSwift/AppDelegate.swift#L21 >> >> >> > >> > On Thu, Jul 10, 2014 at 2:28 PM, Matthias Wessendorf >> wrote: >> > Hi, >> > >> > as Corinne mentioned on a different thread, w/ iOS8 Apple introduces >> new UIUserNotificationActions, that can be grouped into a category >> (UIUserNotificationCategory). >> > >> > For remote notifications (aka push) those actions can be trigger by >> sending this JSON payload to APNs: >> > >> > aps { >> > alert: {...}, >> > category: "SOMETHING" >> > } >> > >> > >> > I'd like to add that feature to the UnifiedPush Server and the >> Java/Node Senders. >> > >> > Our own message format (see [2]) has already a categoies element, but >> that is used for filtering/tagging; That element is NOT related to the >> actual payload of the message (which the apple action/category is all >> about). >> > >> > Now, I'd like to introduce an "action-category" element inside of the >> "message" object, like: >> > >> > message: { >> > ....... >> > "alert":"HELLO!", >> > ....... >> > "action-category":"SOMETHING" >> > } >> > >> > This value will be send down to the actual device (by Apple) as part of >> the message. The name is perhaps a bit Apple-oriented, but I think it may >> fit other platforms as well... >> > >> > Looks like Summers/Passos want to do similar for Android (see [3]). >> > >> > What do you think ? >> > >> > >> > -Matthias >> > >> > >> > >> > [1] What's New in iOS Notifications on: >> > https://developer.apple.com/videos/wwdc/2014/ (caution, for lame >> reasons only works on Safari O_o) >> > >> > [2] http://aerogear.org/docs/specs/aerogear-push-messages/ >> > [3] https://issues.jboss.org/browse/AGDROID-258 >> > >> > >> > -- >> > Matthias Wessendorf >> > >> > blog: http://matthiaswessendorf.wordpress.com/ >> > sessions: http://www.slideshare.net/mwessendorf >> > twitter: http://twitter.com/mwessendorf >> > >> > _______________________________________________ >> > aerogear-dev mailing list >> > aerogear-dev at lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > >> > _______________________________________________ >> > aerogear-dev mailing list >> > aerogear-dev at lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140710/e5defffa/attachment.html From matzew at apache.org Thu Jul 10 09:37:24 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Thu, 10 Jul 2014 15:37:24 +0200 Subject: [aerogear-dev] [Push] Notification Actions (iOS8) In-Reply-To: References: <5B361BA1-B1FA-418C-9AB6-616EB4AA0C9E@gmail.com> Message-ID: On Thu, Jul 10, 2014 at 3:31 PM, Corinne Krych wrote: > I did those sample with interactive notification on local.notification on > my initial repo. This is just POC/sample code. > Then I merged my repo into aerogear-push-helloworld master > I haven't merged interactive notification in central repo and actually I > don't planned to. We have a ticket to demo interactive notification with > AeroDoc. > Let's keep Helloworld simple. > I agree on keeping HelloWorld simple - but on the MobileContacts, that can be a nice thing ? IMO we should to that first and than bring it to AeroDoc > > ++ > Corinne > > > On 10 July 2014 14:42, Matthias Wessendorf wrote: > >> >> >> >> On Thu, Jul 10, 2014 at 2:39 PM, Corinne Krych >> wrote: >> >>> >>> On 10 Jul 2014, at 14:36, Sebastien Blanc wrote: >>> >>> > Sounds good ! >>> > >>> > Just to confirm does the value of the "action-category" relates to the >>> category.identifier like in >>> https://github.com/corinnekrych/HelloWorld-Swift/blob/local.notification/HelloWorldSwift/AppDelegate.swift#L60 >>> ? >>> >> >> what's the difference between your repo and this folder: >> https://github.com/aerogear/aerogear-push-helloworld/tree/master/ios-swift >> >> >> >> >> >> >>> > >>> > >>> >>> >>> Yes like commented here: >>> >>> https://github.com/corinnekrych/HelloWorld-Swift/blob/local.notification/HelloWorldSwift/AppDelegate.swift#L21 >>> >>> >>> > >>> > On Thu, Jul 10, 2014 at 2:28 PM, Matthias Wessendorf < >>> matzew at apache.org> wrote: >>> > Hi, >>> > >>> > as Corinne mentioned on a different thread, w/ iOS8 Apple introduces >>> new UIUserNotificationActions, that can be grouped into a category >>> (UIUserNotificationCategory). >>> > >>> > For remote notifications (aka push) those actions can be trigger by >>> sending this JSON payload to APNs: >>> > >>> > aps { >>> > alert: {...}, >>> > category: "SOMETHING" >>> > } >>> > >>> > >>> > I'd like to add that feature to the UnifiedPush Server and the >>> Java/Node Senders. >>> > >>> > Our own message format (see [2]) has already a categoies element, but >>> that is used for filtering/tagging; That element is NOT related to the >>> actual payload of the message (which the apple action/category is all >>> about). >>> > >>> > Now, I'd like to introduce an "action-category" element inside of the >>> "message" object, like: >>> > >>> > message: { >>> > ....... >>> > "alert":"HELLO!", >>> > ....... >>> > "action-category":"SOMETHING" >>> > } >>> > >>> > This value will be send down to the actual device (by Apple) as part >>> of the message. The name is perhaps a bit Apple-oriented, but I think it >>> may fit other platforms as well... >>> > >>> > Looks like Summers/Passos want to do similar for Android (see [3]). >>> > >>> > What do you think ? >>> > >>> > >>> > -Matthias >>> > >>> > >>> > >>> > [1] What's New in iOS Notifications on: >>> > https://developer.apple.com/videos/wwdc/2014/ (caution, for lame >>> reasons only works on Safari O_o) >>> > >>> > [2] http://aerogear.org/docs/specs/aerogear-push-messages/ >>> > [3] https://issues.jboss.org/browse/AGDROID-258 >>> > >>> > >>> > -- >>> > Matthias Wessendorf >>> > >>> > blog: http://matthiaswessendorf.wordpress.com/ >>> > sessions: http://www.slideshare.net/mwessendorf >>> > twitter: http://twitter.com/mwessendorf >>> > >>> > _______________________________________________ >>> > aerogear-dev mailing list >>> > aerogear-dev at lists.jboss.org >>> > https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> > >>> > _______________________________________________ >>> > aerogear-dev mailing list >>> > aerogear-dev at lists.jboss.org >>> > https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >> >> >> >> -- >> Matthias Wessendorf >> >> blog: http://matthiaswessendorf.wordpress.com/ >> sessions: http://www.slideshare.net/mwessendorf >> twitter: http://twitter.com/mwessendorf >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140710/e453a07e/attachment.html From scm.blanc at gmail.com Thu Jul 10 09:43:18 2014 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Thu, 10 Jul 2014 15:43:18 +0200 Subject: [aerogear-dev] [Push] Notification Actions (iOS8) In-Reply-To: References: <5B361BA1-B1FA-418C-9AB6-616EB4AA0C9E@gmail.com> Message-ID: On Thu, Jul 10, 2014 at 3:37 PM, Matthias Wessendorf wrote: > > > > On Thu, Jul 10, 2014 at 3:31 PM, Corinne Krych > wrote: > >> I did those sample with interactive notification on local.notification on >> my initial repo. This is just POC/sample code. >> Then I merged my repo into aerogear-push-helloworld master >> I haven't merged interactive notification in central repo and actually I >> don't planned to. We have a ticket to demo interactive notification with >> AeroDoc. >> Let's keep Helloworld simple. >> > > I agree on keeping HelloWorld simple - but on the MobileContacts, that can > be a nice thing ? IMO we should to that first and than bring it to AeroDoc > Not sure how we could introduce the interactive Notification in the Contact App , maybe " Show Contact | Ignore" ? > > >> >> ++ >> Corinne >> >> >> On 10 July 2014 14:42, Matthias Wessendorf wrote: >> >>> >>> >>> >>> On Thu, Jul 10, 2014 at 2:39 PM, Corinne Krych >>> wrote: >>> >>>> >>>> On 10 Jul 2014, at 14:36, Sebastien Blanc wrote: >>>> >>>> > Sounds good ! >>>> > >>>> > Just to confirm does the value of the "action-category" relates to >>>> the category.identifier like in >>>> https://github.com/corinnekrych/HelloWorld-Swift/blob/local.notification/HelloWorldSwift/AppDelegate.swift#L60 >>>> ? >>>> >>> >>> what's the difference between your repo and this folder: >>> >>> https://github.com/aerogear/aerogear-push-helloworld/tree/master/ios-swift >>> >>> >>> >>> >>> >>> >>>> > >>>> > >>>> >>>> >>>> Yes like commented here: >>>> >>>> https://github.com/corinnekrych/HelloWorld-Swift/blob/local.notification/HelloWorldSwift/AppDelegate.swift#L21 >>>> >>>> >>>> > >>>> > On Thu, Jul 10, 2014 at 2:28 PM, Matthias Wessendorf < >>>> matzew at apache.org> wrote: >>>> > Hi, >>>> > >>>> > as Corinne mentioned on a different thread, w/ iOS8 Apple introduces >>>> new UIUserNotificationActions, that can be grouped into a category >>>> (UIUserNotificationCategory). >>>> > >>>> > For remote notifications (aka push) those actions can be trigger by >>>> sending this JSON payload to APNs: >>>> > >>>> > aps { >>>> > alert: {...}, >>>> > category: "SOMETHING" >>>> > } >>>> > >>>> > >>>> > I'd like to add that feature to the UnifiedPush Server and the >>>> Java/Node Senders. >>>> > >>>> > Our own message format (see [2]) has already a categoies element, but >>>> that is used for filtering/tagging; That element is NOT related to the >>>> actual payload of the message (which the apple action/category is all >>>> about). >>>> > >>>> > Now, I'd like to introduce an "action-category" element inside of the >>>> "message" object, like: >>>> > >>>> > message: { >>>> > ....... >>>> > "alert":"HELLO!", >>>> > ....... >>>> > "action-category":"SOMETHING" >>>> > } >>>> > >>>> > This value will be send down to the actual device (by Apple) as part >>>> of the message. The name is perhaps a bit Apple-oriented, but I think it >>>> may fit other platforms as well... >>>> > >>>> > Looks like Summers/Passos want to do similar for Android (see [3]). >>>> > >>>> > What do you think ? >>>> > >>>> > >>>> > -Matthias >>>> > >>>> > >>>> > >>>> > [1] What's New in iOS Notifications on: >>>> > https://developer.apple.com/videos/wwdc/2014/ (caution, for lame >>>> reasons only works on Safari O_o) >>>> > >>>> > [2] http://aerogear.org/docs/specs/aerogear-push-messages/ >>>> > [3] https://issues.jboss.org/browse/AGDROID-258 >>>> > >>>> > >>>> > -- >>>> > Matthias Wessendorf >>>> > >>>> > blog: http://matthiaswessendorf.wordpress.com/ >>>> > sessions: http://www.slideshare.net/mwessendorf >>>> > twitter: http://twitter.com/mwessendorf >>>> > >>>> > _______________________________________________ >>>> > aerogear-dev mailing list >>>> > aerogear-dev at lists.jboss.org >>>> > https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> > >>>> > _______________________________________________ >>>> > aerogear-dev mailing list >>>> > aerogear-dev at lists.jboss.org >>>> > https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> >>>> >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> >>> >>> >>> >>> -- >>> Matthias Wessendorf >>> >>> blog: http://matthiaswessendorf.wordpress.com/ >>> sessions: http://www.slideshare.net/mwessendorf >>> twitter: http://twitter.com/mwessendorf >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140710/57e9272e/attachment-0001.html From scm.blanc at gmail.com Thu Jul 10 09:43:46 2014 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Thu, 10 Jul 2014 15:43:46 +0200 Subject: [aerogear-dev] [Push] Notification Actions (iOS8) In-Reply-To: References: <5B361BA1-B1FA-418C-9AB6-616EB4AA0C9E@gmail.com> Message-ID: but tbh I don't really see a use case for the contact app and interactive notifications. On Thu, Jul 10, 2014 at 3:43 PM, Sebastien Blanc wrote: > > > > On Thu, Jul 10, 2014 at 3:37 PM, Matthias Wessendorf > wrote: > >> >> >> >> On Thu, Jul 10, 2014 at 3:31 PM, Corinne Krych >> wrote: >> >>> I did those sample with interactive notification on local.notification >>> on my initial repo. This is just POC/sample code. >>> Then I merged my repo into aerogear-push-helloworld master >>> I haven't merged interactive notification in central repo and actually I >>> don't planned to. We have a ticket to demo interactive notification with >>> AeroDoc. >>> Let's keep Helloworld simple. >>> >> >> I agree on keeping HelloWorld simple - but on the MobileContacts, that >> can be a nice thing ? IMO we should to that first and than bring it to >> AeroDoc >> > Not sure how we could introduce the interactive Notification in the > Contact App , maybe " Show Contact | Ignore" ? > >> >> >>> >>> ++ >>> Corinne >>> >>> >>> On 10 July 2014 14:42, Matthias Wessendorf wrote: >>> >>>> >>>> >>>> >>>> On Thu, Jul 10, 2014 at 2:39 PM, Corinne Krych >>>> wrote: >>>> >>>>> >>>>> On 10 Jul 2014, at 14:36, Sebastien Blanc wrote: >>>>> >>>>> > Sounds good ! >>>>> > >>>>> > Just to confirm does the value of the "action-category" relates to >>>>> the category.identifier like in >>>>> https://github.com/corinnekrych/HelloWorld-Swift/blob/local.notification/HelloWorldSwift/AppDelegate.swift#L60 >>>>> ? >>>>> >>>> >>>> what's the difference between your repo and this folder: >>>> >>>> https://github.com/aerogear/aerogear-push-helloworld/tree/master/ios-swift >>>> >>>> >>>> >>>> >>>> >>>> >>>>> > >>>>> > >>>>> >>>>> >>>>> Yes like commented here: >>>>> >>>>> https://github.com/corinnekrych/HelloWorld-Swift/blob/local.notification/HelloWorldSwift/AppDelegate.swift#L21 >>>>> >>>>> >>>>> > >>>>> > On Thu, Jul 10, 2014 at 2:28 PM, Matthias Wessendorf < >>>>> matzew at apache.org> wrote: >>>>> > Hi, >>>>> > >>>>> > as Corinne mentioned on a different thread, w/ iOS8 Apple introduces >>>>> new UIUserNotificationActions, that can be grouped into a category >>>>> (UIUserNotificationCategory). >>>>> > >>>>> > For remote notifications (aka push) those actions can be trigger by >>>>> sending this JSON payload to APNs: >>>>> > >>>>> > aps { >>>>> > alert: {...}, >>>>> > category: "SOMETHING" >>>>> > } >>>>> > >>>>> > >>>>> > I'd like to add that feature to the UnifiedPush Server and the >>>>> Java/Node Senders. >>>>> > >>>>> > Our own message format (see [2]) has already a categoies element, >>>>> but that is used for filtering/tagging; That element is NOT related to the >>>>> actual payload of the message (which the apple action/category is all >>>>> about). >>>>> > >>>>> > Now, I'd like to introduce an "action-category" element inside of >>>>> the "message" object, like: >>>>> > >>>>> > message: { >>>>> > ....... >>>>> > "alert":"HELLO!", >>>>> > ....... >>>>> > "action-category":"SOMETHING" >>>>> > } >>>>> > >>>>> > This value will be send down to the actual device (by Apple) as part >>>>> of the message. The name is perhaps a bit Apple-oriented, but I think it >>>>> may fit other platforms as well... >>>>> > >>>>> > Looks like Summers/Passos want to do similar for Android (see [3]). >>>>> > >>>>> > What do you think ? >>>>> > >>>>> > >>>>> > -Matthias >>>>> > >>>>> > >>>>> > >>>>> > [1] What's New in iOS Notifications on: >>>>> > https://developer.apple.com/videos/wwdc/2014/ (caution, for lame >>>>> reasons only works on Safari O_o) >>>>> > >>>>> > [2] http://aerogear.org/docs/specs/aerogear-push-messages/ >>>>> > [3] https://issues.jboss.org/browse/AGDROID-258 >>>>> > >>>>> > >>>>> > -- >>>>> > Matthias Wessendorf >>>>> > >>>>> > blog: http://matthiaswessendorf.wordpress.com/ >>>>> > sessions: http://www.slideshare.net/mwessendorf >>>>> > twitter: http://twitter.com/mwessendorf >>>>> > >>>>> > _______________________________________________ >>>>> > aerogear-dev mailing list >>>>> > aerogear-dev at lists.jboss.org >>>>> > https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>> > >>>>> > _______________________________________________ >>>>> > aerogear-dev mailing list >>>>> > aerogear-dev at lists.jboss.org >>>>> > https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>> >>>>> >>>>> _______________________________________________ >>>>> aerogear-dev mailing list >>>>> aerogear-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>> >>>> >>>> >>>> >>>> -- >>>> Matthias Wessendorf >>>> >>>> blog: http://matthiaswessendorf.wordpress.com/ >>>> sessions: http://www.slideshare.net/mwessendorf >>>> twitter: http://twitter.com/mwessendorf >>>> >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> >>> >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >> >> >> >> -- >> Matthias Wessendorf >> >> blog: http://matthiaswessendorf.wordpress.com/ >> sessions: http://www.slideshare.net/mwessendorf >> twitter: http://twitter.com/mwessendorf >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140710/5086da78/attachment.html From matzew at apache.org Thu Jul 10 09:45:25 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Thu, 10 Jul 2014 15:45:25 +0200 Subject: [aerogear-dev] [Push] Notification Actions (iOS8) In-Reply-To: References: <5B361BA1-B1FA-418C-9AB6-616EB4AA0C9E@gmail.com> Message-ID: On Thu, Jul 10, 2014 at 3:43 PM, Sebastien Blanc wrote: > but tbh I don't really see a use case for the contact app and interactive > notifications. > yes, the 'Accept lead' makes much more sense -M > > > On Thu, Jul 10, 2014 at 3:43 PM, Sebastien Blanc > wrote: > >> >> >> >> On Thu, Jul 10, 2014 at 3:37 PM, Matthias Wessendorf >> wrote: >> >>> >>> >>> >>> On Thu, Jul 10, 2014 at 3:31 PM, Corinne Krych >>> wrote: >>> >>>> I did those sample with interactive notification on local.notification >>>> on my initial repo. This is just POC/sample code. >>>> Then I merged my repo into aerogear-push-helloworld master >>>> I haven't merged interactive notification in central repo and actually >>>> I don't planned to. We have a ticket to demo interactive notification with >>>> AeroDoc. >>>> Let's keep Helloworld simple. >>>> >>> >>> I agree on keeping HelloWorld simple - but on the MobileContacts, that >>> can be a nice thing ? IMO we should to that first and than bring it to >>> AeroDoc >>> >> Not sure how we could introduce the interactive Notification in the >> Contact App , maybe " Show Contact | Ignore" ? >> >>> >>> >>>> >>>> ++ >>>> Corinne >>>> >>>> >>>> On 10 July 2014 14:42, Matthias Wessendorf wrote: >>>> >>>>> >>>>> >>>>> >>>>> On Thu, Jul 10, 2014 at 2:39 PM, Corinne Krych >>>> > wrote: >>>>> >>>>>> >>>>>> On 10 Jul 2014, at 14:36, Sebastien Blanc >>>>>> wrote: >>>>>> >>>>>> > Sounds good ! >>>>>> > >>>>>> > Just to confirm does the value of the "action-category" relates to >>>>>> the category.identifier like in >>>>>> https://github.com/corinnekrych/HelloWorld-Swift/blob/local.notification/HelloWorldSwift/AppDelegate.swift#L60 >>>>>> ? >>>>>> >>>>> >>>>> what's the difference between your repo and this folder: >>>>> >>>>> https://github.com/aerogear/aerogear-push-helloworld/tree/master/ios-swift >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>> > >>>>>> > >>>>>> >>>>>> >>>>>> Yes like commented here: >>>>>> >>>>>> https://github.com/corinnekrych/HelloWorld-Swift/blob/local.notification/HelloWorldSwift/AppDelegate.swift#L21 >>>>>> >>>>>> >>>>>> > >>>>>> > On Thu, Jul 10, 2014 at 2:28 PM, Matthias Wessendorf < >>>>>> matzew at apache.org> wrote: >>>>>> > Hi, >>>>>> > >>>>>> > as Corinne mentioned on a different thread, w/ iOS8 Apple >>>>>> introduces new UIUserNotificationActions, that can be grouped into a >>>>>> category (UIUserNotificationCategory). >>>>>> > >>>>>> > For remote notifications (aka push) those actions can be trigger by >>>>>> sending this JSON payload to APNs: >>>>>> > >>>>>> > aps { >>>>>> > alert: {...}, >>>>>> > category: "SOMETHING" >>>>>> > } >>>>>> > >>>>>> > >>>>>> > I'd like to add that feature to the UnifiedPush Server and the >>>>>> Java/Node Senders. >>>>>> > >>>>>> > Our own message format (see [2]) has already a categoies element, >>>>>> but that is used for filtering/tagging; That element is NOT related to the >>>>>> actual payload of the message (which the apple action/category is all >>>>>> about). >>>>>> > >>>>>> > Now, I'd like to introduce an "action-category" element inside of >>>>>> the "message" object, like: >>>>>> > >>>>>> > message: { >>>>>> > ....... >>>>>> > "alert":"HELLO!", >>>>>> > ....... >>>>>> > "action-category":"SOMETHING" >>>>>> > } >>>>>> > >>>>>> > This value will be send down to the actual device (by Apple) as >>>>>> part of the message. The name is perhaps a bit Apple-oriented, but I think >>>>>> it may fit other platforms as well... >>>>>> > >>>>>> > Looks like Summers/Passos want to do similar for Android (see [3]). >>>>>> > >>>>>> > What do you think ? >>>>>> > >>>>>> > >>>>>> > -Matthias >>>>>> > >>>>>> > >>>>>> > >>>>>> > [1] What's New in iOS Notifications on: >>>>>> > https://developer.apple.com/videos/wwdc/2014/ (caution, for lame >>>>>> reasons only works on Safari O_o) >>>>>> > >>>>>> > [2] http://aerogear.org/docs/specs/aerogear-push-messages/ >>>>>> > [3] https://issues.jboss.org/browse/AGDROID-258 >>>>>> > >>>>>> > >>>>>> > -- >>>>>> > Matthias Wessendorf >>>>>> > >>>>>> > blog: http://matthiaswessendorf.wordpress.com/ >>>>>> > sessions: http://www.slideshare.net/mwessendorf >>>>>> > twitter: http://twitter.com/mwessendorf >>>>>> > >>>>>> > _______________________________________________ >>>>>> > aerogear-dev mailing list >>>>>> > aerogear-dev at lists.jboss.org >>>>>> > https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>> > >>>>>> > _______________________________________________ >>>>>> > aerogear-dev mailing list >>>>>> > aerogear-dev at lists.jboss.org >>>>>> > https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> aerogear-dev mailing list >>>>>> aerogear-dev at lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Matthias Wessendorf >>>>> >>>>> blog: http://matthiaswessendorf.wordpress.com/ >>>>> sessions: http://www.slideshare.net/mwessendorf >>>>> twitter: http://twitter.com/mwessendorf >>>>> >>>>> _______________________________________________ >>>>> aerogear-dev mailing list >>>>> aerogear-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>> >>>> >>>> >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> >>> >>> >>> >>> -- >>> Matthias Wessendorf >>> >>> blog: http://matthiaswessendorf.wordpress.com/ >>> sessions: http://www.slideshare.net/mwessendorf >>> twitter: http://twitter.com/mwessendorf >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >> >> > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140710/8428cdc9/attachment-0001.html From corinnekrych at gmail.com Thu Jul 10 09:45:51 2014 From: corinnekrych at gmail.com (Corinne Krych) Date: Thu, 10 Jul 2014 15:45:51 +0200 Subject: [aerogear-dev] [Push] Notification Actions (iOS8) In-Reply-To: References: <5B361BA1-B1FA-418C-9AB6-616EB4AA0C9E@gmail.com> Message-ID: <53C02436-F01D-494C-9C82-F86BF59FCF24@gmail.com> On 10 Jul 2014, at 15:43, Sebastien Blanc wrote: > but tbh I don't really see a use case for the contact app and interactive notifications. > > Same here. Initial idea from Sebi to have it on aeroDoc illustrates better interactive notification > On Thu, Jul 10, 2014 at 3:43 PM, Sebastien Blanc wrote: > > > > On Thu, Jul 10, 2014 at 3:37 PM, Matthias Wessendorf wrote: > > > > On Thu, Jul 10, 2014 at 3:31 PM, Corinne Krych wrote: > I did those sample with interactive notification on local.notification on my initial repo. This is just POC/sample code. > Then I merged my repo into aerogear-push-helloworld master > I haven't merged interactive notification in central repo and actually I don't planned to. We have a ticket to demo interactive notification with AeroDoc. > Let's keep Helloworld simple. > > I agree on keeping HelloWorld simple - but on the MobileContacts, that can be a nice thing ? IMO we should to that first and than bring it to AeroDoc > Not sure how we could introduce the interactive Notification in the Contact App , maybe " Show Contact | Ignore" ? > > > ++ > Corinne > > > On 10 July 2014 14:42, Matthias Wessendorf wrote: > > > > On Thu, Jul 10, 2014 at 2:39 PM, Corinne Krych wrote: > > On 10 Jul 2014, at 14:36, Sebastien Blanc wrote: > > > Sounds good ! > > > > Just to confirm does the value of the "action-category" relates to the category.identifier like in https://github.com/corinnekrych/HelloWorld-Swift/blob/local.notification/HelloWorldSwift/AppDelegate.swift#L60 ? > > what's the difference between your repo and this folder: > https://github.com/aerogear/aerogear-push-helloworld/tree/master/ios-swift > > > > > > > > > > > > Yes like commented here: > https://github.com/corinnekrych/HelloWorld-Swift/blob/local.notification/HelloWorldSwift/AppDelegate.swift#L21 > > > > > > On Thu, Jul 10, 2014 at 2:28 PM, Matthias Wessendorf wrote: > > Hi, > > > > as Corinne mentioned on a different thread, w/ iOS8 Apple introduces new UIUserNotificationActions, that can be grouped into a category (UIUserNotificationCategory). > > > > For remote notifications (aka push) those actions can be trigger by sending this JSON payload to APNs: > > > > aps { > > alert: {...}, > > category: "SOMETHING" > > } > > > > > > I'd like to add that feature to the UnifiedPush Server and the Java/Node Senders. > > > > Our own message format (see [2]) has already a categoies element, but that is used for filtering/tagging; That element is NOT related to the actual payload of the message (which the apple action/category is all about). > > > > Now, I'd like to introduce an "action-category" element inside of the "message" object, like: > > > > message: { > > ....... > > "alert":"HELLO!", > > ....... > > "action-category":"SOMETHING" > > } > > > > This value will be send down to the actual device (by Apple) as part of the message. The name is perhaps a bit Apple-oriented, but I think it may fit other platforms as well... > > > > Looks like Summers/Passos want to do similar for Android (see [3]). > > > > What do you think ? > > > > > > -Matthias > > > > > > > > [1] What's New in iOS Notifications on: > > https://developer.apple.com/videos/wwdc/2014/ (caution, for lame reasons only works on Safari O_o) > > > > [2] http://aerogear.org/docs/specs/aerogear-push-messages/ > > [3] https://issues.jboss.org/browse/AGDROID-258 > > > > > > -- > > Matthias Wessendorf > > > > blog: http://matthiaswessendorf.wordpress.com/ > > sessions: http://www.slideshare.net/mwessendorf > > twitter: http://twitter.com/mwessendorf > > > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev From cvasilak at gmail.com Thu Jul 10 09:49:18 2014 From: cvasilak at gmail.com (Christos Vasilakis) Date: Thu, 10 Jul 2014 16:49:18 +0300 Subject: [aerogear-dev] [Push] Notification Actions (iOS8) In-Reply-To: References: <5B361BA1-B1FA-418C-9AB6-616EB4AA0C9E@gmail.com> Message-ID: On Jul 10, 2014, at 4:45 PM, Matthias Wessendorf wrote: > > > > On Thu, Jul 10, 2014 at 3:43 PM, Sebastien Blanc wrote: > but tbh I don't really see a use case for the contact app and interactive notifications. > > yes, the 'Accept lead' makes much more sense +1 > > -M > > > > On Thu, Jul 10, 2014 at 3:43 PM, Sebastien Blanc wrote: > > > > On Thu, Jul 10, 2014 at 3:37 PM, Matthias Wessendorf wrote: > > > > On Thu, Jul 10, 2014 at 3:31 PM, Corinne Krych wrote: > I did those sample with interactive notification on local.notification on my initial repo. This is just POC/sample code. > Then I merged my repo into aerogear-push-helloworld master > I haven't merged interactive notification in central repo and actually I don't planned to. We have a ticket to demo interactive notification with AeroDoc. > Let's keep Helloworld simple. > > I agree on keeping HelloWorld simple - but on the MobileContacts, that can be a nice thing ? IMO we should to that first and than bring it to AeroDoc > Not sure how we could introduce the interactive Notification in the Contact App , maybe " Show Contact | Ignore" ? > > > ++ > Corinne > > > On 10 July 2014 14:42, Matthias Wessendorf wrote: > > > > On Thu, Jul 10, 2014 at 2:39 PM, Corinne Krych wrote: > > On 10 Jul 2014, at 14:36, Sebastien Blanc wrote: > > > Sounds good ! > > > > Just to confirm does the value of the "action-category" relates to the category.identifier like in https://github.com/corinnekrych/HelloWorld-Swift/blob/local.notification/HelloWorldSwift/AppDelegate.swift#L60 ? > > what's the difference between your repo and this folder: > https://github.com/aerogear/aerogear-push-helloworld/tree/master/ios-swift > > > > > > > > > > > > Yes like commented here: > https://github.com/corinnekrych/HelloWorld-Swift/blob/local.notification/HelloWorldSwift/AppDelegate.swift#L21 > > > > > > On Thu, Jul 10, 2014 at 2:28 PM, Matthias Wessendorf wrote: > > Hi, > > > > as Corinne mentioned on a different thread, w/ iOS8 Apple introduces new UIUserNotificationActions, that can be grouped into a category (UIUserNotificationCategory). > > > > For remote notifications (aka push) those actions can be trigger by sending this JSON payload to APNs: > > > > aps { > > alert: {...}, > > category: "SOMETHING" > > } > > > > > > I'd like to add that feature to the UnifiedPush Server and the Java/Node Senders. > > > > Our own message format (see [2]) has already a categoies element, but that is used for filtering/tagging; That element is NOT related to the actual payload of the message (which the apple action/category is all about). > > > > Now, I'd like to introduce an "action-category" element inside of the "message" object, like: > > > > message: { > > ....... > > "alert":"HELLO!", > > ....... > > "action-category":"SOMETHING" > > } > > > > This value will be send down to the actual device (by Apple) as part of the message. The name is perhaps a bit Apple-oriented, but I think it may fit other platforms as well... > > > > Looks like Summers/Passos want to do similar for Android (see [3]). > > > > What do you think ? > > > > > > -Matthias > > > > > > > > [1] What's New in iOS Notifications on: > > https://developer.apple.com/videos/wwdc/2014/ (caution, for lame reasons only works on Safari O_o) > > > > [2] http://aerogear.org/docs/specs/aerogear-push-messages/ > > [3] https://issues.jboss.org/browse/AGDROID-258 > > > > > > -- > > Matthias Wessendorf > > > > blog: http://matthiaswessendorf.wordpress.com/ > > sessions: http://www.slideshare.net/mwessendorf > > twitter: http://twitter.com/mwessendorf > > > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140710/4660c120/attachment.html From cvasilak at gmail.com Thu Jul 10 09:54:19 2014 From: cvasilak at gmail.com (Christos Vasilakis) Date: Thu, 10 Jul 2014 16:54:19 +0300 Subject: [aerogear-dev] [Push] Notification Actions (iOS8) In-Reply-To: References: Message-ID: <3EC1BC83-5746-4FB1-99AA-CF40ACE6244D@gmail.com> On Jul 10, 2014, at 3:28 PM, Matthias Wessendorf wrote: > Hi, > > as Corinne mentioned on a different thread, w/ iOS8 Apple introduces new UIUserNotificationActions, that can be grouped into a category (UIUserNotificationCategory). > > For remote notifications (aka push) those actions can be trigger by sending this JSON payload to APNs: > > aps { > alert: {...}, > category: "SOMETHING" > } > > > I'd like to add that feature to the UnifiedPush Server and the Java/Node Senders. > > Our own message format (see [2]) has already a categoies element, but that is used for filtering/tagging; That element is NOT related to the actual payload of the message (which the apple action/category is all about). > > Now, I'd like to introduce an "action-category" element inside of the "message" object, like: > > message: { > ....... > "alert":"HELLO!", > ....... > "action-category":"SOMETHING" > } > > This value will be send down to the actual device (by Apple) as part of the message. The name is perhaps a bit Apple-oriented, but I think it may fit other platforms as well... > > Looks like Summers/Passos want to do similar for Android (see [3]). > > What do you think ? sounds good +1 > > > -Matthias > > > > [1] What's New in iOS Notifications on: > https://developer.apple.com/videos/wwdc/2014/ (caution, for lame reasons only works on Safari O_o) > > [2] http://aerogear.org/docs/specs/aerogear-push-messages/ > [3] https://issues.jboss.org/browse/AGDROID-258 > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140710/31c91c1e/attachment-0001.html From tkriz at redhat.com Thu Jul 10 10:59:11 2014 From: tkriz at redhat.com (Tadeas Kriz) Date: Thu, 10 Jul 2014 16:59:11 +0200 Subject: [aerogear-dev] cordova plugin release In-Reply-To: References: <1215EAF1-CA43-40E4-8165-72490EBA1F84@redhat.com> Message-ID: Tested it and it works nicely. Ready to release, nice work! ? Tadeas Kriz On 09 Jul 2014, at 11:07, Tadeas Kriz wrote: > Hey, > > I?ll test it today evening, so you?ll probably get the test results tomorrow. > > ? > Tadeas Kriz > > On 08 Jul 2014, at 08:47, Erik Jan de Wit wrote: > >> Because of all the changes needed to be made to the UnifiedPush Server console, this didn?t get the attention it deserves. There was a bug found by Karel in the quick starts that I just merged. Please retest and then we?ll release next week. >> >> Cheers, >> Erik Jan >> >> On 8 Jul,2014, at 7:17 , Matthias Wessendorf wrote: >> >>> I think we never actually released the version 0.6.0 :-) >>> >>> -Matthias >>> >>> >>> >>> On Wed, May 28, 2014 at 11:15 AM, Erik Jan de Wit wrote: >>> Hi, >>> >>> As discussed here (http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-New-Cordova-Push-release-was-Re-Mobile-Push-1-0-0-Client-SDKs-for-Android-Cordova-and-i-td7932.html) we are going to release a new version of the cordova push plugin the new version 0.5.1 most important feature is the updated android libraries. There are also some community bug fixes: >>> >>> fix a bug with the foreground/isInline flag >>> fix bug with android not sending cached message >>> Automate plugin testing using grunt-cordova-plugin-jasmine. >>> >>> Thank you TadeasKriz and keithdmoore for contributing >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >>> >>> >>> -- >>> Matthias Wessendorf >>> >>> blog: http://matthiaswessendorf.wordpress.com/ >>> sessions: http://www.slideshare.net/mwessendorf >>> twitter: http://twitter.com/mwessendorf >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140710/7da66b2e/attachment.html From matzew at apache.org Thu Jul 10 11:25:10 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Thu, 10 Jul 2014 17:25:10 +0200 Subject: [aerogear-dev] [Push] Notification Actions (iOS8) In-Reply-To: <3EC1BC83-5746-4FB1-99AA-CF40ACE6244D@gmail.com> References: <3EC1BC83-5746-4FB1-99AA-CF40ACE6244D@gmail.com> Message-ID: based on this thread, here is a PR to be reviewed: https://github.com/aerogear/aerogear-unifiedpush-server/pull/288 On Thu, Jul 10, 2014 at 3:54 PM, Christos Vasilakis wrote: > > On Jul 10, 2014, at 3:28 PM, Matthias Wessendorf > wrote: > > Hi, > > as Corinne mentioned on a different thread, w/ iOS8 Apple introduces new > UIUserNotificationActions, that can be grouped into a category > (UIUserNotificationCategory). > > For remote notifications (aka push) those actions can be trigger by > sending this JSON payload to APNs: > > aps { > alert: {...}, > category: "SOMETHING" > } > > > I'd like to add that feature to the UnifiedPush Server and the Java/Node > Senders. > > Our own message format (see [2]) has already a categoies element, but that > is used for filtering/tagging; That element is NOT related to the actual > payload of the message (which the apple action/category is all about). > > Now, I'd like to introduce an "action-category" element inside of the > "message" object, like: > > message: { > ....... > "alert":"HELLO!", > ....... > "action-category":"SOMETHING" > } > > This value will be send down to the actual device (by Apple) as part of > the message. The name is perhaps a bit Apple-oriented, but I think it may > fit other platforms as well... > > Looks like Summers/Passos want to do similar for Android (see [3]). > > What do you think ? > > > sounds good +1 > > > > > -Matthias > > > > [1] What's New in iOS Notifications on: > https://developer.apple.com/videos/wwdc/2014/ (caution, for lame reasons > only works on Safari O_o) > > [2] http://aerogear.org/docs/specs/aerogear-push-messages/ > [3] https://issues.jboss.org/browse/AGDROID-258 > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140710/13edfb03/attachment.html From edewit at redhat.com Fri Jul 11 05:58:25 2014 From: edewit at redhat.com (Erik Jan de Wit) Date: Fri, 11 Jul 2014 11:58:25 +0200 Subject: [aerogear-dev] pushplugin release Message-ID: <33754C7D-D0D4-4149-B0B7-6009DC4F15AA@redhat.com> Hi, After succeful testing I?m happy to announce that the 0.6.0 version of the aerogear-pushplugin has been released. Thanks to everyone involved in making this release happen. Bug [AGCORDOVA-16] - Should fail gracefully if not configured fix a bug with the foreground/isInline flag fix bug with android not sending cached message Feature Request [AGCORDOVA-4] - Use latest aerogear-android-push library (0.2) [AGCORDOVA-5] - Use latest google-play-services [AGCORDOVA-8] - Use Plugin android.support.v4 as dependency rather than adding the jar directly [AGCORDOVA-9] - The example shipped with the plugin should use the latest API (simplification) [AGCORDOVA-11] - Update the underlying iOS Push SDK Automate plugin testing using grunt-cordova-plugin-jasmine. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140711/8824c44a/attachment.html From matzew at apache.org Fri Jul 11 06:09:07 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Fri, 11 Jul 2014 12:09:07 +0200 Subject: [aerogear-dev] pushplugin release In-Reply-To: <33754C7D-D0D4-4149-B0B7-6009DC4F15AA@redhat.com> References: <33754C7D-D0D4-4149-B0B7-6009DC4F15AA@redhat.com> Message-ID: yay! congratulations on this release ! On Fri, Jul 11, 2014 at 11:58 AM, Erik Jan de Wit wrote: > Hi, > > After succeful testing I?m happy to announce that the 0.6.0 version of the > aerogear-pushplugin has been released. Thanks to everyone involved in > making this release happen. > > Bug > > - [AGCORDOVA-16 ] - > Should fail gracefully if not configured > - *fix a bug with the foreground/isInline flag > * > - * fix bug with android not sending cached message > * > > Feature Request > > - [AGCORDOVA-4 ] - Use > latest aerogear-android-push library (0.2) > - [AGCORDOVA-5 ] - Use > latest google-play-services > - [AGCORDOVA-8 ] - Use > Plugin android.support.v4 as dependency rather than adding the jar directly > - [AGCORDOVA-9 ] - The > example shipped with the plugin should use the latest API (simplification) > - [AGCORDOVA-11 ] - > Update the underlying iOS Push SDK > - * Automate plugin testing using grunt-cordova-plugin-jasmine. > * > > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140711/f0662713/attachment-0001.html From matzew at apache.org Fri Jul 11 06:31:34 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Fri, 11 Jul 2014 12:31:34 +0200 Subject: [aerogear-dev] [SPS-JS] navigator.setMessageHandler Vs navigator.mozSetMessageHandler In-Reply-To: References: Message-ID: On Thu, Feb 6, 2014 at 10:31 AM, Sebastien Blanc wrote: > > > > On Thu, Feb 6, 2014 at 10:24 AM, Matthias Wessendorf > wrote: > >> >> >> >> On Thu, Feb 6, 2014 at 10:21 AM, Sebastien Blanc >> wrote: >> >>> >>> >>> >>> On Thu, Feb 6, 2014 at 10:11 AM, Matthias Wessendorf >>> wrote: >>> >>>> >>>> >>>> >>>> On Thu, Feb 6, 2014 at 10:07 AM, Sebastien Blanc >>>> wrote: >>>> >>>>> >>>>> >>>>> >>>>> On Thu, Feb 6, 2014 at 9:57 AM, Matthias Wessendorf >>>> > wrote: >>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Thu, Feb 6, 2014 at 9:52 AM, Sebastien Blanc >>>>>> wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Thu, Feb 6, 2014 at 9:45 AM, Matthias Wessendorf < >>>>>>> matzew at apache.org> wrote: >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Thu, Feb 6, 2014 at 9:42 AM, Sebastien Blanc < >>>>>>>> scm.blanc at gmail.com> wrote: >>>>>>>> >>>>>>>>> Hi, >>>>>>>>> Mozilla specifies[1] a function called "mozSetMessageHandler" >>>>>>>>> while we named this function "setMessageHandler" in our polyfill [2] . This >>>>>>>>> is the handler for incoming push notifications. >>>>>>>>> >>>>>>>>> I'm not really a big fan of specific prefixes but again if we want >>>>>>>>> to be really polyfill here, we should align. >>>>>>>>> >>>>>>>> >>>>>>>> hrm, not sure - I think, eventually theirs will be >>>>>>>> ``setMessageHandler`` as well; >>>>>>>> >>>>>>> >>>>>>> Yes, I should ping them on their list to have more details. >>>>>>> >>>>>>>> >>>>>>>> Why not just setting a reference from ``mozSetMessageHandler `` to >>>>>>>> ``setMessageHandler`` ? That way both would work, right ? >>>>>>>> >>>>>>> You mean defining both functions and calling setMessageHandler from >>>>>>> mozSetMessageHandler ? >>>>>>> >>>>>> >>>>>> >>>>>> No, just like: >>>>>> >>>>>> navigator.setMessageHandler = function(..) {........}; /// what we >>>>>> have ATM >>>>>> navigator.mozSetMessageHandler = navigator.setMessageHandler; // a >>>>>> reference >>>>>> >>>>> >>>>> Ok right , got it :) >>>>> That makes me think that we should have a page on our site describing >>>>> these kinds of things when develloping for ffos. >>>>> >>>> >>>> "these kind of things" ? >>>> >>> Things to take care of when implementing simple push in your app and >>> want to make sure it works on ffo, like adding permissions to the >>> manifest, >>> >> >> yep, I agree >> >> >>> the ref to mozSetMessageHandler , etc ... >>> >> >> well, IMO that should be done in our software, for em >> > > Ah ok, directly in our lib, yeah of course that makes even more sense :) > Let's see what Luke think about this. > I filed a ticket to not forget about this issue: https://issues.jboss.org/browse/AGJS-194 > >> >> >>> Just a simple guide. >>> >> >> Do we have a JIRA for a FFOS guide already ? >> > We have now ;) https://issues.jboss.org/browse/AEROGEAR-1429 > > >> >> >> >>> >>>> >>>>> >>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>> >>>>>>>>> wdyt ? >>>>>>>>> >>>>>>>>> Seb >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> [1] >>>>>>>>> https://developer.mozilla.org/en-US/docs/Web/API/Navigator.mozSetMessageHandler >>>>>>>>> [2] >>>>>>>>> https://github.com/aerogear/aerogear-js/blob/master/src/simplepush/aerogear.simplepush.js#L152 >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> aerogear-dev mailing list >>>>>>>>> aerogear-dev at lists.jboss.org >>>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Matthias Wessendorf >>>>>>>> >>>>>>>> blog: http://matthiaswessendorf.wordpress.com/ >>>>>>>> sessions: http://www.slideshare.net/mwessendorf >>>>>>>> twitter: http://twitter.com/mwessendorf >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> aerogear-dev mailing list >>>>>>>> aerogear-dev at lists.jboss.org >>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> aerogear-dev mailing list >>>>>>> aerogear-dev at lists.jboss.org >>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Matthias Wessendorf >>>>>> >>>>>> blog: http://matthiaswessendorf.wordpress.com/ >>>>>> sessions: http://www.slideshare.net/mwessendorf >>>>>> twitter: http://twitter.com/mwessendorf >>>>>> >>>>>> _______________________________________________ >>>>>> aerogear-dev mailing list >>>>>> aerogear-dev at lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> aerogear-dev mailing list >>>>> aerogear-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>> >>>> >>>> >>>> >>>> -- >>>> Matthias Wessendorf >>>> >>>> blog: http://matthiaswessendorf.wordpress.com/ >>>> sessions: http://www.slideshare.net/mwessendorf >>>> twitter: http://twitter.com/mwessendorf >>>> >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> >>> >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >> >> >> >> -- >> Matthias Wessendorf >> >> blog: http://matthiaswessendorf.wordpress.com/ >> sessions: http://www.slideshare.net/mwessendorf >> twitter: http://twitter.com/mwessendorf >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140711/804128b6/attachment.html From matzew at apache.org Fri Jul 11 06:33:22 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Fri, 11 Jul 2014 12:33:22 +0200 Subject: [aerogear-dev] Differences between Firefox OS "native" Push lib and AeroGear's Push adapter In-Reply-To: <3B256910-96B3-4F55-8456-D890F4B37B2B@redhat.com> References: <9B70BDB9-4774-4BF0-9FF7-5213185E4F52@redhat.com> <51C9D854-0730-4B2A-9A92-9DC92649947D@redhat.com> <8AEB32A5-0F61-495B-8EA5-767F48312B9C@redhat.com> <3B256910-96B3-4F55-8456-D890F4B37B2B@redhat.com> Message-ID: Hey Luke, I created this JIRA: https://issues.jboss.org/browse/AGPUSH-802 As I plan working on AGPUSH-532 next week, to make sure we have the 'right' model in place for 1.0.0. I think once the server bits are merged, we should address AGPUSH-802 -Matthias On Thu, Apr 10, 2014 at 5:22 PM, Lucas Holmquist wrote: > so after testing this thing out with encodeURIComponent, the delete does > work, however, we need to "double up" the encode. > > this works: > > https://gist.github.com/lholmquist/10393357 > > > this doesn't: > > https://gist.github.com/lholmquist/10393450 > > > > On Apr 7, 2014, at 2:09 PM, Lucas Holmquist wrote: > > > On Apr 7, 2014, at 12:52 PM, Matthias Wessendorf > wrote: > > Ok, > > So as token, we use the endpointURL, and on client we perform the encodeURIComponent() > function ? > > > i think so( as suggested 2 months ago :) ) i just need to see how this > will affect how we store stuff in LS. > > > > > -Matthias > > On Monday, April 7, 2014, Lucas Holmquist wrote: > >> so i went back to look at what i had, >> >> >> i don't think we need to get to complicated here, >> >> reading the spec stuff, and this example >> >> https://wiki.mozilla.org/WebAPI/SimplePush#Client_.28WebApp.29_code >> >> they show sending the pushEndpoint to the "App server", so i think we >> could just use and keep it simple >> >> it is also recommended that the channelID is never exposed to the >> application. >> >> >> On Apr 1, 2014, at 3:34 PM, Lucas Holmquist wrote: >> >> i had something, now i forgot what it was, need to go back and check >> On Apr 1, 2014, at 3:05 PM, Matthias Wessendorf >> wrote: >> >> >> On Fri, Feb 14, 2014 at 2:06 PM, Lucas Holmquist >> wrote: >> >> still exploring >> >> >> :-) any recent thoughts on 'encodeURIComponent()' ? >> >> >> >> On Feb 13, 2014, at 3:39 PM, Sebastien Blanc wrote: >> >> >> >> >> On Wed, Feb 12, 2014 at 2:30 PM, Lucas Holmquist >> wrote: >> >> i might have a couple thoughts, but i need to try some things out first >> >> >> Any update on that or does the solution proposed by Matzew (using encodeURIComponent() >> ) could be enough ? >> >> >> On Feb 12, 2014, at 3:53 AM, Sebastien Blanc wrote: >> >> >> >> >> On Tue, Feb 11, 2014 at 7:15 PM, Sebastien Blanc >> wrote: >> >> Ok, >> I've been doing some tests by using the PushEndpoint as device token. For >> registration it works but I just faced an issue by trying to unregister >> because the URL for the DELETE looks like : >> >> >> https://judconpush-sblanc.rhcloud.com/rest/registry/device/https://updates.push.services.mozilla.com/update/my_personnal_psuhendpoint_id >> [ >> >> And the REST endpoint get a bit crazy by the extra "/" present in the >> endpoint URL. Therefore, I think we must just use the last URL fragment as >> deviceToken. >> >> >> Ok answering to myself ;) That won't work neither since if we do that UPS >> won't have the compllete push endpoint URL. >> So how do we deal with that ? >> >> >> >> On Thu, Feb 6, 2014 at 3:27 PM, Matthias Wessendorf >> wrote: >> >> >> >> >> On Thu, Feb 6, 2014 at 3:11 PM, Sebastien Blanc >> >> > > -- > Sent from Gmail Mobile > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140711/4ee48897/attachment-0001.html From matzew at apache.org Fri Jul 11 07:05:44 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Fri, 11 Jul 2014 13:05:44 +0200 Subject: [aerogear-dev] Differences between Firefox OS "native" Push lib and AeroGear's Push adapter In-Reply-To: References: <9B70BDB9-4774-4BF0-9FF7-5213185E4F52@redhat.com> <51C9D854-0730-4B2A-9A92-9DC92649947D@redhat.com> <8AEB32A5-0F61-495B-8EA5-767F48312B9C@redhat.com> <3B256910-96B3-4F55-8456-D890F4B37B2B@redhat.com> Message-ID: PR for the SERVER part is here: https://issues.jboss.org/browse/AGPUSH-532 On Fri, Jul 11, 2014 at 12:33 PM, Matthias Wessendorf wrote: > Hey Luke, > > I created this JIRA: > https://issues.jboss.org/browse/AGPUSH-802 > > As I plan working on AGPUSH-532 next week, to make sure we have the > 'right' model in place for 1.0.0. I think once the server bits are merged, > we should address AGPUSH-802 > > -Matthias > > > On Thu, Apr 10, 2014 at 5:22 PM, Lucas Holmquist > wrote: > >> so after testing this thing out with encodeURIComponent, the delete does >> work, however, we need to "double up" the encode. >> >> this works: >> >> https://gist.github.com/lholmquist/10393357 >> >> >> this doesn't: >> >> https://gist.github.com/lholmquist/10393450 >> >> >> >> On Apr 7, 2014, at 2:09 PM, Lucas Holmquist wrote: >> >> >> On Apr 7, 2014, at 12:52 PM, Matthias Wessendorf >> wrote: >> >> Ok, >> >> So as token, we use the endpointURL, and on client we perform the encodeURIComponent() >> function ? >> >> >> i think so( as suggested 2 months ago :) ) i just need to see how this >> will affect how we store stuff in LS. >> >> >> >> >> -Matthias >> >> On Monday, April 7, 2014, Lucas Holmquist wrote: >> >>> so i went back to look at what i had, >>> >>> >>> i don't think we need to get to complicated here, >>> >>> reading the spec stuff, and this example >>> >>> https://wiki.mozilla.org/WebAPI/SimplePush#Client_.28WebApp.29_code >>> >>> they show sending the pushEndpoint to the "App server", so i think we >>> could just use and keep it simple >>> >>> it is also recommended that the channelID is never exposed to the >>> application. >>> >>> >>> On Apr 1, 2014, at 3:34 PM, Lucas Holmquist wrote: >>> >>> i had something, now i forgot what it was, need to go back and check >>> On Apr 1, 2014, at 3:05 PM, Matthias Wessendorf >>> wrote: >>> >>> >>> On Fri, Feb 14, 2014 at 2:06 PM, Lucas Holmquist >>> wrote: >>> >>> still exploring >>> >>> >>> :-) any recent thoughts on 'encodeURIComponent()' ? >>> >>> >>> >>> On Feb 13, 2014, at 3:39 PM, Sebastien Blanc >>> wrote: >>> >>> >>> >>> >>> On Wed, Feb 12, 2014 at 2:30 PM, Lucas Holmquist >>> wrote: >>> >>> i might have a couple thoughts, but i need to try some things out first >>> >>> >>> Any update on that or does the solution proposed by Matzew (using encodeURIComponent() >>> ) could be enough ? >>> >>> >>> On Feb 12, 2014, at 3:53 AM, Sebastien Blanc >>> wrote: >>> >>> >>> >>> >>> On Tue, Feb 11, 2014 at 7:15 PM, Sebastien Blanc >>> wrote: >>> >>> Ok, >>> I've been doing some tests by using the PushEndpoint as device token. >>> For registration it works but I just faced an issue by trying to unregister >>> because the URL for the DELETE looks like : >>> >>> >>> https://judconpush-sblanc.rhcloud.com/rest/registry/device/https://updates.push.services.mozilla.com/update/my_personnal_psuhendpoint_id >>> [ >>> >>> And the REST endpoint get a bit crazy by the extra "/" present in the >>> endpoint URL. Therefore, I think we must just use the last URL fragment as >>> deviceToken. >>> >>> >>> Ok answering to myself ;) That won't work neither since if we do that >>> UPS won't have the compllete push endpoint URL. >>> So how do we deal with that ? >>> >>> >>> >>> On Thu, Feb 6, 2014 at 3:27 PM, Matthias Wessendorf >>> wrote: >>> >>> >>> >>> >>> On Thu, Feb 6, 2014 at 3:11 PM, Sebastien Blanc >>> >>> >> >> -- >> Sent from Gmail Mobile >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140711/5057a5eb/attachment.html From matzew at apache.org Fri Jul 11 10:34:22 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Fri, 11 Jul 2014 16:34:22 +0200 Subject: [aerogear-dev] UPS Production worthiness In-Reply-To: References: <002b01cf7424$528dc0a0$f7a941e0$@pinelabs.com> <005d01cf74ed$3d977140$b8c653c0$@pinelabs.com> <003c01cf78cd$1095df40$31c19dc0$@pinelabs.com> <17C1B903-C13B-482F-93FA-1B9B55AEF707@redhat.com> <008f01cf9603$9cf11fb0$d6d35f10$@pinelabs.com> <008701cf9aa5$09290bc0$1b7b2340$@pinelabs.com> Message-ID: Hello Vivek, I pasted the patch to this gist: https://gist.github.com/matzew/95471393bc2a485fce10 since not all team members were able to open the attachment. Thanks again for sharing -Matthias On Tue, Jul 8, 2014 at 3:13 PM, Matthias Wessendorf wrote: > Hello Vivek! > > thanks a lot for the patch! We will take a look at that for sure! The > benefit of getting a PR out is that you are actually captured inside of the > GH as an official contributor :-) > > But thanks again, very happy to see your patch ! > > -Matthias > > > On Tue, Jul 8, 2014 at 2:06 PM, Vivek Pandey > wrote: > >> Hi Matthias/UPS Team, >> >> I have put together a patch which shows the changes I had to make to get >> the requisite performance from UPS. Please find the same attached. The >> patch has my changes along with Eric?s changes merged on 0.10.4 branch. I >> had to do some hacky changes to prevent all the installations from getting >> serialized to UI. That should ideally be handled by removing this >> requirement and making corresponding changes to UI code. >> >> I will learn GIT and put together a PR for these changes as soon as I >> can. >> >> >> >> Thanks, >> >> Vivek >> >> >> >> *From:* mwessendorf at gmail.com [mailto:mwessendorf at gmail.com] *On Behalf >> Of *Matthias Wessendorf >> *Sent:* Wednesday, July 02, 2014 8:15 PM >> *To:* vivek.pandey at pinelabs.com >> *Cc:* AeroGear Developer Mailing List >> >> *Subject:* Re: [aerogear-dev] UPS Production worthiness >> >> >> >> Hello vivek! >> >> >> >> thanks for the reply! Absolutely a PR is more than welcome! If you have >> interest and the bandwidth, we would really appreciate that ! >> >> >> >> @importer: I still think it's a nice thing to have :-) >> >> >> >> -Matthias >> >> >> >> On Wed, Jul 2, 2014 at 4:40 PM, Vivek Pandey >> wrote: >> >> Hello Matthias, >> >> >> >> An ?importer? might help, but smaller changes in existing domain/service >> might help more. >> >> I ran a stress test on the installation endpoint yesterday, after merging >> Eric?s changes on source code of 0.10.x branch. >> >> I saw that even after using the merged code, the response worsened >> continuously. >> >> Looking closing, I saw that GenericVariantServiceImpl. addInstallation >> causes initialization of the now ?lazy? collection >> AbstractVariant.installations. >> >> >> >> I changed the model a bit, by adding variantID to Installation, and made >> it the owner of the variant-installation relationship. >> >> That changed the code in InstallationRegistrationEndpoint. registerInstallation >> from >> >> // store the installation: >> >> entity = clientInstallationService.addInstallation(entity); >> >> // add installation to the matching variant >> >> genericVariantService.addInstallation(variant, entity); >> >> >> >> to >> >> // store the installation: >> >> >> entity.setVariantID(variant); >> >> entity = >> clientInstallationService.addInstallation(entity); >> >> >> >> This fixed the problem for me and now I am getting constant time >> installation registration with dramatically better performance >> >> >> >> Please let me know if you want me to add this to AGPUSH-661 >> >> >> >> Thanks >> >> Vivek >> >> >> >> *From:* mwessendorf at gmail.com [mailto:mwessendorf at gmail.com] *On Behalf >> Of *Matthias Wessendorf >> *Sent:* Wednesday, July 02, 2014 6:26 PM >> *To:* AeroGear Developer Mailing List; vivek.pandey at pinelabs.com >> >> >> *Subject:* Re: [aerogear-dev] UPS Production worthiness >> >> >> >> Hello Vivek, >> >> >> >> On Mon, May 26, 2014 at 1:23 PM, Matthias Wessendorf >> wrote: >> >> >> >> >> >> On Mon, May 26, 2014 at 12:59 PM, Erik Jan de Wit >> wrote: >> >> Hi Vivek, >> >> >> >> We?ve fixed that >> https://github.com/aerogear/aerogear-unifiedpush-server/commit/1357c9e834286a9227a90e9ab618226aa54bbbf3 the >> collection is now lazy. But I?m sure other query optimisations can be made. >> >> >> >> +1 >> >> >> >> btw. Vivek, I added your mail to an existing ticket: >> >> https://issues.jboss.org/browse/AGPUSH-661 >> >> >> >> >> >> coming back from vacation and going over the JIRAs, I was wondering if an >> 'importer' helps? >> >> >> >> That would be a RESTful endpoint that accepts a JSON file, containing all >> the devices you want to register (for a given variant). >> >> >> >> That way it would be also a bit nicer on your side, to perform the import: >> >> * generate a "large" JSON file (instead of a ton of requests) >> >> * only one HTTP request >> >> * server accepts and will process it in the background >> >> >> >> I think that would be a nice migration tool. >> >> >> >> Let me know what you think! >> >> >> >> -Matthias >> >> >> >> >> >> -Matthias >> >> >> >> >> >> Cheers, >> >> Erik Jan >> >> >> >> On 26 May,2014, at 12:27 , Vivek Pandey >> wrote: >> >> >> >> Hi Matthias, >> >> >> >> It is good to know that activity in java-apns is picking up and also that >> you are looking at pushy. >> >> >> >> I did a few tests which added installations to UPS with a concurrency of >> 4-8 threads. I was using Postgres 9.3 and UPS 0.10.3 war >> >> >> >> I noticed that response slowed down considerably after some time with >> high CPU usage and continued to get worse. After doing some profiling, I >> found that bulk of CPU cycles are being taken by >> org.postgresql.core.VisibleBufferedInputStream.readMore. The entire thread >> stack is attached. Also postgres continuously flagged >> >> >> >> select installati0_.variantID as variant10_0_0_, installati0_.id as >> id1_3_0_, installati0_.id as id1_3_1_, installati0_.alias as alias2_3_1_, >> installati0_.deviceToken as deviceTo3_3_1_, installati0_.deviceType as >> deviceTy4_3_1_, installati0_.enabled as enabled5_3_1_, >> installati0_.operatingSystem as operatin6_3_1_, installati0_.osVersion as >> osVersio7_3_1_, installati0_.platform as platform8_3_1_, >> installati0_.simplePushEndpoint as simplePu9_3_1_ from InstallationImpl >> installati0_ where installati0_.variantID=$1 >> >> >> >> as the slow query. I am pretty sure that eager collection >> AbstractVariant.installations is the root cause of the problem. >> >> >> >> Please let me know if you need any more information. >> >> >> >> Thanks >> >> Vivek >> >> >> >> *From:* mwessendorf at gmail.com [mailto:mwessendorf at gmail.com >> ] *On Behalf Of *Matthias Wessendorf >> *Sent:* Wednesday, May 21, 2014 5:55 PM >> *To:* vivek.pandey at pinelabs.com; AeroGear Developer Mailing List >> *Subject:* Re: [aerogear-dev] UPS Production worthiness >> >> >> >> Hello Vivek! >> >> >> >> On Wed, May 21, 2014 at 2:07 PM, Vivek Pandey >> wrote: >> >> Hi Jay, >> >> >> >> Thanks for your reply. >> >> >> >> While we have not faced any issues in using UPS in our limited testing, I >> often see info stacktraces in ups logs >> >> >> >> 2014-05-16 10:19:20,032 INFO >> [com.notnoop.apns.internal.ApnsConnectionImpl] (Thread-118) Exception while >> waiting for error code: java.net.SocketException: Socket closed >> >> at java.net.SocketInputStream.socketRead0(Native Method) >> [rt.jar:1.7.0_51] >> >> at java.net.SocketInputStream.read(SocketInputStream.java:152) >> [rt.jar:1.7.0_51] >> >> at java.net.SocketInputStream.read(SocketInputStream.java:122) >> [rt.jar:1.7.0_51] >> >> ????? >> >> at >> com.notnoop.apns.internal.ApnsConnectionImpl$1MonitoringThread.run(ApnsConnectionImpl.java:114) >> [apns-0.2.3.jar:] >> >> >> >> >> >> These stacktraces coupled with low dev activity of noop/java-apns project >> are disconcerting to me. >> >> >> >> the stack-trace is no harm - it's only happening w/ doing a monitoring of >> the thread (that's what we currently do, when setting up ApnsService - I >> thought about explicitly disable that) >> >> >> >> The activity of the underlying java-apns is very low, yes! However >> @froh42 is getting back: >> >> https://github.com/notnoop/java-apns/commits/master >> >> >> >> There will be a new release in the near future; @froh42 asked me if I >> could help with pushing the bits to maven central >> >> >> >> >> >> That said, I recently started looking at pushy: >> >> https://github.com/relayrides/pushy >> >> >> >> I also sent a PR that would allow us to feed pushy w/ our certificate >> from the database: >> >> https://github.com/relayrides/pushy/pull/87 >> >> >> >> Hope that helps >> >> -Matthias >> >> >> >> >> >> I am currently using UPS 0.10.2 war. >> >> >> >> Thanks, >> >> Vivek >> >> *From:* Jay Balunas [mailto:jbalunas at redhat.com] >> *Sent:* Tuesday, May 20, 2014 11:36 PM >> *To:* vivek.pandey at pinelabs.com; AeroGear Developer Mailing List >> *Cc:* Jay Balunas >> *Subject:* Re: [aerogear-dev] UPS Production worthiness >> >> >> >> Hi Vivek, >> >> >> >> It's awesome to hear that you have integrated the UPS into your backend >> systems and some of your mobile apps! >> >> >> >> We have a lot of confidence around the UPS, its functionality, and >> performance. Our team has been working hard on improvements and stability >> including our QE team. Also, as you may have seen we're planning a 1.0 >> release of the UPS this summer. >> >> >> >> However at this time we don't have specific references or success stories >> outside of what you can see in the community mailing lists - other users >> using it ;-) We're also about to kick off some performance and scale >> testing in the next couple of months. >> >> >> >> Have you run into any issues that drove these questions about production >> worthiness? If so please let us know and we'll certainly take a look. >> >> >> >> Hope this helps! >> >> >> >> Thanks, >> >> Jay Balunas >> >> >> >> On May 20, 2014, at 8:09 AM, Vivek Pandey >> wrote: >> >> >> >> Hello Aerogear dev team, >> >> >> >> We integrated UPS into our backend server which is serving various mobile >> apps. While the development and testing phase went well, my manager is >> questioning me about production worthiness about Aerogear. It would be >> great help if you could point me to references/success stories where UPS is >> being used in production environments and scaling well in medium to high >> loads. >> >> >> >> Thanks, >> >> Vivek >> >> >> >> >> >> >> ------------------------------ >> >> This message may contain privileged and confidential information and is >> solely for the use of intended recipient. The views expressed in this email >> are those of the sender and not of Pine Labs. The recipient should check >> this email and attachments for the presence of viruses / malwares etc. Pine >> Labs accepts no liability for any damage caused by any virus transmitted by >> this email. Pine Labs may monitor and record all emails. >> ------------------------------ >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> >> >> ------------------------------ >> >> This message may contain privileged and confidential information and is >> solely for the use of intended recipient. The views expressed in this email >> are those of the sender and not of Pine Labs. The recipient should check >> this email and attachments for the presence of viruses / malwares etc. Pine >> Labs accepts no liability for any damage caused by any virus transmitted by >> this email. Pine Labs may monitor and record all emails. >> ------------------------------ >> >> >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> >> >> >> -- >> Matthias Wessendorf >> >> blog: http://matthiaswessendorf.wordpress.com/ >> sessions: http://www.slideshare.net/mwessendorf >> twitter: http://twitter.com/mwessendorf >> >> >> ------------------------------ >> >> This message may contain privileged and confidential information and is >> solely for the use of intended recipient. The views expressed in this email >> are those of the sender and not of Pine Labs. The recipient should check >> this email and attachments for the presence of viruses / malwares etc. Pine >> Labs accepts no liability for any damage caused by any virus transmitted by >> this email. Pine Labs may monitor and record all emails. >> ------------------------------ >> >> >> >> _______________________________________________ >> >> >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> >> >> >> -- >> Matthias Wessendorf >> >> blog: http://matthiaswessendorf.wordpress.com/ >> sessions: http://www.slideshare.net/mwessendorf >> twitter: http://twitter.com/mwessendorf >> >> >> >> >> >> -- >> Matthias Wessendorf >> >> blog: http://matthiaswessendorf.wordpress.com/ >> sessions: http://www.slideshare.net/mwessendorf >> twitter: http://twitter.com/mwessendorf >> >> >> ------------------------------ >> >> This message may contain privileged and confidential information and is >> solely for the use of intended recipient. The views expressed in this email >> are those of the sender and not of Pine Labs. The recipient should check >> this email and attachments for the presence of viruses / malwares etc. Pine >> Labs accepts no liability for any damage caused by any virus transmitted by >> this email. Pine Labs may monitor and record all emails. >> ------------------------------ >> >> >> >> >> >> >> >> -- >> Matthias Wessendorf >> >> blog: http://matthiaswessendorf.wordpress.com/ >> sessions: http://www.slideshare.net/mwessendorf >> twitter: http://twitter.com/mwessendorf >> >> ------------------------------ >> This message may contain privileged and confidential information and is >> solely for the use of intended recipient. The views expressed in this email >> are those of the sender and not of Pine Labs. The recipient should check >> this email and attachments for the presence of viruses / malwares etc. Pine >> Labs accepts no liability for any damage caused by any virus transmitted by >> this email. Pine Labs may monitor and record all emails. >> ------------------------------ >> >> > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140711/42eb7ccc/attachment-0001.html From bruno at abstractj.org Fri Jul 11 17:11:09 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Fri, 11 Jul 2014 18:11:09 -0300 Subject: [aerogear-dev] admin-ui dependencies Message-ID: <20140711211109.GA68261@abstractj.org> Good morning, I would like to include 2 new dependencies to deal with session timeouts at the admin-ui: - jquery-idletimer: https://github.com/thorst/jquery-idletimer - jquery-idleTimeout: https://github.com/JillElaine/jquery-idleTimeout These dependencies are not available on Bower. Which way is the best to include them as dependency? -- abstractj From corinnekrych at gmail.com Fri Jul 11 17:20:08 2014 From: corinnekrych at gmail.com (Corinne Krych) Date: Fri, 11 Jul 2014 23:20:08 +0200 Subject: [aerogear-dev] News from iOS Modules front Message-ID: <78957F0D-27BC-49B8-9F47-5905FA3F55A7@gmail.com> Hello Guys, Last Tuesday during our (favourite) iOS meeting [1] [2] we talked about modularization. We agreed with Android team modularization is scheduled for 2.0. For iOS we have several actions: 1. rename existing repos (too bad we don?t follow well Android convention) ? aerogear-ios-crypto ? aerogear-ios-push (thanks passos for the suggestion) ? aerogear-ios-otp ? aerogear-ios-xcode-template ? aerogear-ios-cookbook Since we?re talking about renaming, what about dropping ?arerogear? for the repo name? all those repos belong to aerogear organization anyway. Maybe removing the aerogear part will stress more the small libraries aspect. Maybe sth we already discussed but can?t remember/find it. wdyt? 2. Pipe and Store deprecated. All aerogear-ios we?ll stick to 1.7 version and will be marked deprecated. But ?. don?t be scared new modules will replace them: ? aerogear-ios-http : Lightweight lib around NSURLSession to ease HTTP calls with pluggable request and response Serializers. Very very Draft version [3] with some cookbook recipe [4]. With this module we will work directly with NSURLSession (iOS foundation networking) instead of using AFNetworking. Sure Andrea will like it: no dependency :) ? aerogear-ios-oauth2 : dependent on aerogear-ios-http, bring all the good stuff like AccountManager, OAuth2 extensible adapters, fluid http post/get ... ? aerogear-ios-storage usage of incrementalStorage to plug into Core Data Those modules will be written in Swift code. We?ll test them both in iOS7 and iOS8. 3. Cookbook recipes rpo ? tag our repo 1.7: we didn?t have a tag strategy for cookbook demos but with the move from 1.X to 2.) I think we should * Swift demo naming convention add ?-swift? for Swift version like we did [5]. We should also append ?-objc? to other recipes to be consistent. 4. Differentiate Swift vs Objective-C libs How to differenctiate Swift code. Specially for aerogear-ios-push which will be declined in 2 versions? One suggestion from Matthias was to have 2 separate branches. master -> objc-c until iOS8 is released and stable. I?m +1 with that idea. Let me know if you have suggestions/objections. When we reach an agreement, I?ll create associated JIRA. ++ Corinne [1] http://oksoclap.com/p/aerogear_ios_meeting_01072014 [2] http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2014/aerogear.2014-07-08-11.42.txt [3] https://github.com/corinnekrych/aerogear-ios-http [4] https://github.com/corinnekrych/Weather [5] https://github.com/aerogear/aerogear-push-helloworld/tree/master/ios-swift From scm.blanc at gmail.com Fri Jul 11 17:23:55 2014 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Fri, 11 Jul 2014 23:23:55 +0200 Subject: [aerogear-dev] admin-ui dependencies In-Reply-To: <20140711211109.GA68261@abstractj.org> References: <20140711211109.GA68261@abstractj.org> Message-ID: I just made the test and it seems to do the trick , add this to admin-ui/bower.json , in dependencies : "jquery-idletimer" : "git at github.com:thorst/jquery-idletimer", "jquery-idleTimeout" : "git at github.com:JillElaine/jquery-idleTimeout" Then bower install, you should see them in the folder app/bower_components now On Fri, Jul 11, 2014 at 11:11 PM, Bruno Oliveira wrote: > Good morning, > > I would like to include 2 new dependencies to deal with session timeouts > at the admin-ui: > > - jquery-idletimer: https://github.com/thorst/jquery-idletimer > - jquery-idleTimeout: https://github.com/JillElaine/jquery-idleTimeout > > These dependencies are not available on Bower. Which way is the best to > include them as dependency? > > -- > > abstractj > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140711/d85febef/attachment.html From corinnekrych at gmail.com Fri Jul 11 17:44:53 2014 From: corinnekrych at gmail.com (Corinne Krych) Date: Fri, 11 Jul 2014 23:44:53 +0200 Subject: [aerogear-dev] News from iOS Modules front In-Reply-To: <78957F0D-27BC-49B8-9F47-5905FA3F55A7@gmail.com> References: <78957F0D-27BC-49B8-9F47-5905FA3F55A7@gmail.com> Message-ID: I forgot a last topic (but not least) to end our iOS modules discussion 5. dynamic framework iOS8 Swift app using speudo objective-c fwk (static lib packaged in fwk shell) works ok Swift app using dynamic fwk packagec lib still lots of issues in xcode6beta3. We're working on it. ++ Corinne On Friday, July 11, 2014, Corinne Krych wrote: > Hello Guys, > > Last Tuesday during our (favourite) iOS meeting [1] [2] we talked about > modularization. We agreed with Android team modularization is scheduled for > 2.0. > > For iOS we have several actions: > > 1. rename existing repos (too bad we don?t follow well Android convention) > ? aerogear-ios-crypto > ? aerogear-ios-push (thanks passos for the suggestion) > ? aerogear-ios-otp > ? aerogear-ios-xcode-template > ? aerogear-ios-cookbook > > Since we?re talking about renaming, what about dropping ?arerogear? for > the repo name? all those repos belong to aerogear organization anyway. > Maybe removing the aerogear part will stress more the small libraries > aspect. Maybe sth we already discussed but can?t remember/find it. wdyt? > > 2. Pipe and Store deprecated. All aerogear-ios we?ll stick to 1.7 version > and will be marked deprecated. > But ?. don?t be scared new modules will replace them: > > ? aerogear-ios-http : Lightweight lib around NSURLSession to ease HTTP > calls with pluggable request and response Serializers. Very very Draft > version [3] with some cookbook recipe [4]. With this module we will work > directly with NSURLSession (iOS foundation networking) instead of using > AFNetworking. Sure Andrea will like it: no dependency :) > ? aerogear-ios-oauth2 : dependent on aerogear-ios-http, bring all the good > stuff like AccountManager, OAuth2 extensible adapters, fluid http post/get > ... > ? aerogear-ios-storage usage of incrementalStorage to plug into Core Data > > Those modules will be written in Swift code. We?ll test them both in iOS7 > and iOS8. > > 3. Cookbook recipes rpo > ? tag our repo 1.7: we didn?t have a tag strategy for cookbook demos but > with the move from 1.X to 2.) I think we should > * Swift demo naming convention add ?-swift? for Swift version like we did > [5]. We should also append ?-objc? to other recipes to be consistent. > > 4. Differentiate Swift vs Objective-C libs > How to differenctiate Swift code. Specially for aerogear-ios-push which > will be declined in 2 versions? One suggestion from Matthias was to have 2 > separate branches. > master -> objc-c > until iOS8 is released and stable. > I?m +1 with that idea. > > Let me know if you have suggestions/objections. When we reach an > agreement, I?ll create associated JIRA. > > ++ > Corinne > > [1] http://oksoclap.com/p/aerogear_ios_meeting_01072014 > [2] > http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2014/aerogear.2014-07-08-11.42.txt > [3] https://github.com/corinnekrych/aerogear-ios-http > [4] https://github.com/corinnekrych/Weather > [5] > https://github.com/aerogear/aerogear-push-helloworld/tree/master/ios-swift -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140711/4a302348/attachment.html From bruno at abstractj.org Sat Jul 12 09:40:27 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Sat, 12 Jul 2014 10:40:27 -0300 Subject: [aerogear-dev] admin-ui dependencies In-Reply-To: References: <20140711211109.GA68261@abstractj.org> Message-ID: <20140712134027.GB68261@abstractj.org> Thank you Sebi! On 2014-07-11, Sebastien Blanc wrote: > I just made the test and it seems to do the trick , add this to > admin-ui/bower.json , in dependencies : > > "jquery-idletimer" : "git at github.com:thorst/jquery-idletimer", > "jquery-idleTimeout" : "git at github.com:JillElaine/jquery-idleTimeout" > > Then bower install, you should see them in the folder app/bower_components > now > > > > > On Fri, Jul 11, 2014 at 11:11 PM, Bruno Oliveira > wrote: > > > Good morning, > > > > I would like to include 2 new dependencies to deal with session timeouts > > at the admin-ui: > > > > - jquery-idletimer: https://github.com/thorst/jquery-idletimer > > - jquery-idleTimeout: https://github.com/JillElaine/jquery-idleTimeout > > > > These dependencies are not available on Bower. Which way is the best to > > include them as dependency? > > > > -- > > > > abstractj > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -- abstractj From daniel.bevenius at gmail.com Sun Jul 13 03:51:07 2014 From: daniel.bevenius at gmail.com (Daniel Bevenius) Date: Sun, 13 Jul 2014 09:51:07 +0200 Subject: [aerogear-dev] SimplePush Server 0.12.0 Message-ID: I've moved the release of SimplePush Server 0.12.0 to August instead of July. There were only about four tickets for this release not all effected the server at all really (Docker and docs are examples). I've instead moved the release to August and will move some task targeted for "future". I've already moved the SockJS[1] but let me know if there are any tasks you'd like to see in the release. I've updated the roadmap in this pr: https://github.com/aerogear/aerogear.org/pull/320 Thanks, /Dan [1] https://issues.jboss.org/browse/AGSMPLPUSH-30 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140713/4eff05ee/attachment.html From daniel.bevenius at gmail.com Mon Jul 14 01:08:28 2014 From: daniel.bevenius at gmail.com (Daniel Bevenius) Date: Mon, 14 Jul 2014 07:08:28 +0200 Subject: [aerogear-dev] Team meeting Message-ID: Agenda: http://oksoclap.com/p/aerogear-team-mgt-20140714 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140714/62fb21f5/attachment-0001.html From matzew at apache.org Mon Jul 14 05:55:57 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Mon, 14 Jul 2014 11:55:57 +0200 Subject: [aerogear-dev] SimplePush Server 0.12.0 In-Reply-To: References: Message-ID: sounds good to me! On Sun, Jul 13, 2014 at 9:51 AM, Daniel Bevenius wrote: > I've moved the release of SimplePush Server 0.12.0 to August instead of > July. There were only about four tickets for this release not all effected > the server at all really (Docker and docs are examples). > I've instead moved the release to August and will move some task targeted > for "future". I've already moved the SockJS[1] but let me know if there are > any tasks you'd like to see in the release. > > I've updated the roadmap in this pr: > https://github.com/aerogear/aerogear.org/pull/320 > > Thanks, > > /Dan > > [1] https://issues.jboss.org/browse/AGSMPLPUSH-30 > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140714/41b95f7d/attachment.html From scm.blanc at gmail.com Mon Jul 14 06:32:05 2014 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Mon, 14 Jul 2014 12:32:05 +0200 Subject: [aerogear-dev] Get all open Pull Requests for an org Message-ID: Hi All, This is a bit off topic but , IMO, can be useful to the project. I have been looking for a way to get all the Open Pull Requests that are open for the AeroGear org, since I could not really find the tool I was looking for I created one :) http://myopenprs-sblanc.rhcloud.com/ It's a small app that will retrieve all the open PRs for an GH org or a GH user. Just type "aerogear" and hit search and all the open PRs will be retrieved. For those interested, under the hood, it is a Vert.x App, using the Event Bus to stream the open PRs back to the Browser. Have fun ! Sebi ps : no results returned ? Could be that the rate limit of the github API (5000 req/hour) has been reached, please wait a bit before retrying. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140714/ad970793/attachment.html From matzew at apache.org Mon Jul 14 06:42:35 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Mon, 14 Jul 2014 12:42:35 +0200 Subject: [aerogear-dev] Get all open Pull Requests for an org In-Reply-To: References: Message-ID: On Mon, Jul 14, 2014 at 12:32 PM, Sebastien Blanc wrote: > Hi All, > This is a bit off topic but , IMO, can be useful to the project. > I have been looking for a way to get all the Open Pull Requests that are > open for the AeroGear org, since I could not really find the tool I was > looking for I created one :) > > http://myopenprs-sblanc.rhcloud.com/ > > It's a small app that will retrieve all the open PRs for an GH org or a GH > user. Just type "aerogear" and hit search and all the open PRs will be > retrieved. > wow! that is really cool !!!! Great job, Sebi ! > > For those interested, under the hood, it is a Vert.x App, using the Event > Bus to stream the open PRs back to the Browser. > I notice that b/c of a ton of sockjs requests :-) > > Have fun ! > > Sebi > > ps : no results returned ? Could be that the rate limit of the github API > (5000 req/hour) has been reached, please wait a bit before retrying. > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140714/aa091ca0/attachment.html From chau at bliphead.com Mon Jul 14 07:58:25 2014 From: chau at bliphead.com (Chau Thai) Date: Mon, 14 Jul 2014 13:58:25 +0200 Subject: [aerogear-dev] AeroGear Cordova Push Plugin: Device Token before registry Message-ID: <53C3C5E1.70904@bliphead.com> Dear AeroGear developers, I'm building a geo based push system and want to use the device token as the alias in the registration process. I noticed there is no way to get the device token with the AeroGear Cordova Push Plugin before you send the registration request to the server. I'm hacking into the Android Plugin at the moment and would be very glad if you could give me some hints to get the device token, since the libs are all in jars... Thanks Chau/Cydmax -- Chau Thai BLIPhead GmbH Paradiesstr. 9 80538 M?nchen Tel +49 89 21111069 Fax +49 89 21111061 Mobil +49 176 70660664 chau at bliphead.com www.spreya.com Gesch?ftsf?hrer: Michael M?hlberger Amtsgericht M?nchen, HRB 190699 From scm.blanc at gmail.com Mon Jul 14 08:07:17 2014 From: scm.blanc at gmail.com (=?utf-8?Q?S=C3=A9bastien_Blanc?=) Date: Mon, 14 Jul 2014 14:07:17 +0200 Subject: [aerogear-dev] AeroGear Cordova Push Plugin: Device Token before registry In-Reply-To: <53C3C5E1.70904@bliphead.com> References: <53C3C5E1.70904@bliphead.com> Message-ID: <8FDA2DEA-F077-4B80-8157-319B3B96F8EB@gmail.com> Hi ! Do you really need the device token ? Or do you just need an unique identifier and that is transparent for the user ? In the latest , and since you are using Cordova, you could consider the device plugin that offers an uuid property. S?bi Envoy? de mon iPhone > Le 14 juil. 2014 ? 13:58, Chau Thai a ?crit : > > Dear AeroGear developers, > > I'm building a geo based push system and want to use the device token as > the alias in the registration process. > I noticed there is no way to get the device token with the AeroGear > Cordova Push Plugin before you send the registration request to the server. > I'm hacking into the Android Plugin at the moment and would be very glad > if you could give me some hints to get the device token, since the libs > are all in jars... > > Thanks > > Chau/Cydmax > > -- > Chau Thai > > BLIPhead GmbH > Paradiesstr. 9 > 80538 M?nchen > > Tel +49 89 21111069 > Fax +49 89 21111061 > Mobil +49 176 70660664 > > chau at bliphead.com > www.spreya.com > > Gesch?ftsf?hrer: Michael M?hlberger > Amtsgericht M?nchen, HRB 190699 > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev From cvasilak at gmail.com Mon Jul 14 10:16:21 2014 From: cvasilak at gmail.com (Christos Vasilakis) Date: Mon, 14 Jul 2014 17:16:21 +0300 Subject: [aerogear-dev] Team meeting In-Reply-To: References: Message-ID: fyi, meeting minutes Meeting ended Mon Jul 14 13:55:16 2014 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) Minutes: http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2014/aerogear.2014-07-14-13.41.html Minutes (text): http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2014/aerogear.2014-07-14-13.41.txt Log: http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2014/aerogear.2014-07-14-13.41.log.html On Jul 14, 2014, at 8:08 AM, Daniel Bevenius wrote: > Agenda: > http://oksoclap.com/p/aerogear-team-mgt-20140714 > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140714/2a840336/attachment.html From chau at bliphead.com Mon Jul 14 12:29:28 2014 From: chau at bliphead.com (Chau Thai) Date: Mon, 14 Jul 2014 18:29:28 +0200 Subject: [aerogear-dev] Use Case: Geo Location Pushes Message-ID: <53C40568.4090003@bliphead.com> Hello dear developers, We would like to build a push service triggered by the location of users. We have build a service with which users can save notes on a map. To inform other users of the creation of the note, we want to send all users in a given radius a push notification. The relevance of his current location is very important to fullfil this scenario. It would really help us if you could implement a feature to save the current geo location of the user via the existing register method. Thanks in advance Chau/Cydmax -- Chau Thai BLIPhead GmbH Paradiesstr. 9 80538 M?nchen Tel +49 89 21111069 Fax +49 89 21111061 Mobil +49 176 70660664 chau at bliphead.com www.spreya.com Gesch?ftsf?hrer: Michael M?hlberger Amtsgericht M?nchen, HRB 190699 From matzew at apache.org Mon Jul 14 12:42:07 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Mon, 14 Jul 2014 18:42:07 +0200 Subject: [aerogear-dev] Use Case: Geo Location Pushes In-Reply-To: <53C40568.4090003@bliphead.com> References: <53C40568.4090003@bliphead.com> Message-ID: Hello, this summer we will have our 1.0.0, after that we might be looking at Geo location for Push. We discussed that at our Face2Face meeting a few weeks ago. Thanks for the reminder that I should be filing some JIRAs for that subject :-) -M On Mon, Jul 14, 2014 at 6:29 PM, Chau Thai wrote: > Hello dear developers, > > We would like to build a push service triggered by the location of > users. We have build a service with which users can save notes on a map. > To inform other users of the creation of the note, we want to send all > users in a given radius a push notification. > The relevance of his current location is very important to fullfil this > scenario. > It would really help us if you could implement a feature to save the > current geo location of the user via the existing register method. > > Thanks in advance > Chau/Cydmax > > -- > Chau Thai > > BLIPhead GmbH > Paradiesstr. 9 > 80538 M?nchen > > Tel +49 89 21111069 > Fax +49 89 21111061 > Mobil +49 176 70660664 > > chau at bliphead.com > www.spreya.com > > Gesch?ftsf?hrer: Michael M?hlberger > Amtsgericht M?nchen, HRB 190699 > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140714/213adb9f/attachment-0001.html From keith at kdmooreconsulting.com Mon Jul 14 12:58:50 2014 From: keith at kdmooreconsulting.com (keithdmoore94) Date: Mon, 14 Jul 2014 09:58:50 -0700 (PDT) Subject: [aerogear-dev] Aerogear Feature Request - Auto Increment Badge Message-ID: <1405357130449-8396.post@n5.nabble.com> I noticed some of the other push server providers offer the ability to keep track of the badge and increment it as a new notification comes in. Maybe the client could set the badge to "increment" or "+1", etc. The Aerogear Unified Push Server would then increment the badge and send the notification. Any thoughts ? -- View this message in context: http://aerogear-dev.1069024.n5.nabble.com/Aerogear-Feature-Request-Auto-Increment-Badge-tp8396.html Sent from the aerogear-dev mailing list archive at Nabble.com. From matzew at apache.org Mon Jul 14 13:27:09 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Mon, 14 Jul 2014 19:27:09 +0200 Subject: [aerogear-dev] Aerogear Feature Request - Auto Increment Badge In-Reply-To: <1405357130449-8396.post@n5.nabble.com> References: <1405357130449-8396.post@n5.nabble.com> Message-ID: On Android that concept really is not there, as far as I know; Natvie iOS this is what you get for free, when badge reaches the app. In Cordova-iOS this should be the same! Greetings! Matthias On Monday, July 14, 2014, keithdmoore94 wrote: > I noticed some of the other push server providers offer the ability to keep > track of the badge and increment it as a new notification comes in. Maybe > the client could set the badge to "increment" or "+1", etc. The Aerogear > Unified Push Server would then increment the badge and send the > notification. > > Any thoughts ? > > > > > > -- > View this message in context: > http://aerogear-dev.1069024.n5.nabble.com/Aerogear-Feature-Request-Auto-Increment-Badge-tp8396.html > Sent from the aerogear-dev mailing list archive at Nabble.com. > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Sent from Gmail Mobile -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140714/76ca4d34/attachment.html From matzew at apache.org Tue Jul 15 02:07:27 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Tue, 15 Jul 2014 08:07:27 +0200 Subject: [aerogear-dev] broken build (master and 0.11.0 tag) Message-ID: Hi, since Friday, all in a sudden, the node.js part of the build (triggered by the frontend plugin inside the 'server' module) is failing on different ways. Extremely odd: the 0.11.0 tag is effected as well. The release (on maven central) is good, but ATM we are not able to build the source on the 0.11.0 tag :-( Oh, yeah, Travis-CI notice the broken build as well ;-) and thankfully abstractj put in a PR to have a temporary fix for the build failure: https://github.com/aerogear/aerogear-unifiedpush-server/pull/293 Thanks Bruno! Yesterday Bruno, Villiam and Luke looked at this already, and they noticed a failure like this: [INFO] --- frontend-maven-plugin:0.0.15:npm (npm install) @ unifiedpush-server --- [INFO] Running 'npm install --color=false' in /home/travis/build/aerogear/aerogear-unifiedpush-server/admin-ui [INFO] npm WARN package.json newadmin at 0.0.0 No repository field. [INFO] [INFO] --- frontend-maven-plugin:0.0.15:grunt (grunt build) @ unifiedpush-server --- [INFO] Running 'grunt dist --no-color' in /home/travis/build/aerogear/aerogear-unifiedpush-server/admin-ui [INFO] >> Local Npm module "grunt-cli" not found. Is it installed? [INFO] [INFO] Running "bower:install" (bower) task [INFO] Fatal error: Arguments to path.join must be strings [INFO] ------------------------------------------------------------------------ [INFO] Reactor Summary: Note: "grunt-cli" *IS* installed, even globally. If I am correct, at the moment we are not 100% sure what the "Fatal error: Arguments to path.join must be strings" really means... On my machine, I noticed the npm stuff downloads half of the internet, but gets stuck in the middle: [INFO] npm http 304 https://registry.npmjs.org/oauth-sign [INFO] npm http 304 https://registry.npmjs.org/aws-sign2 [INFO] npm http 304 https://registry.npmjs.org/hawk [INFO] npm http GET https://registry.npmjs.org/combined-stream [INFO] npm http GET https://registry.npmjs.org/async [INFO] npm http GET https://registry.npmjs.org/assert-plus [INFO] npm http GET https://registry.npmjs.org/asn1 [INFO] npm http GET https://registry.npmjs.org/ctype [INFO] npm http GET https://registry.npmjs.org/punycode [INFO] npm http GET https://registry.npmjs.org/hoek [INFO] npm http GET https://registry.npmjs.org/boom [INFO] npm http GET https://registry.npmjs.org/sntp [INFO] npm http GET https://registry.npmjs.org/cryptiles [INFO] npm http 304 https://registry.npmjs.org/async [INFO] npm http 304 https://registry.npmjs.org/combined-stream [INFO] npm http 304 https://registry.npmjs.org/assert-plus [INFO] npm http 304 https://registry.npmjs.org/asn1 [INFO] npm http GET https://registry.npmjs.org/delayed-stream [INFO] npm http 304 https://registry.npmjs.org/ctype [INFO] npm http 304 https://registry.npmjs.org/punycode [INFO] npm http 304 https://registry.npmjs.org/boom [INFO] npm http 304 https://registry.npmjs.org/hoek [INFO] npm http 304 https://registry.npmjs.org/cryptiles [INFO] npm http 304 https://registry.npmjs.org/sntp [INFO] npm http 304 https://registry.npmjs.org/delayed-stream Now, after more than one hour of 'waiting', I cancled the build, resulting in: [INFO] > optipng-bin at 0.3.9 postinstall /Users/matzew/Work/JBoss/UPS/admin-ui/node_modules/grunt-contrib-imagemin/node_modules/imagemin/node_modules/imagemin-optipng/node_modules/optipng-bin [INFO] > node index.js [INFO] [INFO] ? pre-build test passed successfully [INFO] npm http 304 https://registry.npmjs.org/hoek [INFO] npm http 304 https://registry.npmjs.org/boom [INFO] npm http 304 https://registry.npmjs.org/cryptiles [INFO] npm http 304 https://registry.npmjs.org/sntp [INFO] npm http 304 https://registry.npmjs.org/delayed-stream ^C[INFO] ------------------------------------------------------------------------ [INFO] Reactor Summary: [INFO] [INFO] AeroGear UnifiedPush Server ....................... SUCCESS [3.884s] [INFO] UnifiedPush Model Layer ........................... SUCCESS [0.146s] [INFO] UnifiedPush Server Model API ...................... SUCCESS [2.699s] [INFO] UnifiedPush Server Model JPA implementation ....... SUCCESS [15.036s] [INFO] UnifiedPush Service Layer ......................... SUCCESS [7.757s] [INFO] UnifiedPush Push Notification Networks ............ SUCCESS [2.009s] [INFO] UnifiedPush RESTful Endpoint ...................... SUCCESS [2.811s] [INFO] UnifiedPush Server (WAR) .......................... FAILURE [1:30:54.769s] [INFO] UnifiedPush Auth Server ........................... SKIPPED [INFO] ------------------------------------------------------------------------ [INFO] BUILD FAILURE [INFO] ------------------------------------------------------------------------ [INFO] Total time: 1:31:29.994s [INFO] Finished at: Tue Jul 15 07:48:37 CEST 2014 [INFO] Final Memory: 80M/191M [INFO] ------------------------------------------------------------------------ [ERROR] Failed to execute goal com.github.eirslett:frontend-maven-plugin:0.0.15:npm (npm install) on project unifiedpush-server: 'npm install --color=false' failed. (error code 130) -> [Help 1] [ERROR] [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch. [ERROR] Re-run Maven using the -X switch to enable full debug logging. [ERROR] [ERROR] For more information about the errors and possible solutions, please read the following articles: [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException [ERROR] [ERROR] After correcting the problems, you can resume the build with the command [ERROR] mvn -rf :unifiedpush-server This is more a FYI on what's going on - I will file a JIRA ticket for that; *PS:* According to yesterday's IRC discussions, a manual `grunt server does work, so development is not*directly* effected -Matthias -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140715/d1ea82ff/attachment.html From cvasilak at gmail.com Tue Jul 15 02:34:50 2014 From: cvasilak at gmail.com (Christos Vasilakis) Date: Tue, 15 Jul 2014 09:34:50 +0300 Subject: [aerogear-dev] broken build (master and 0.11.0 tag) In-Reply-To: References: Message-ID: Hi, the same failure output "[INFO] Fatal error: Arguments to path.join must be strings" have been noticed also when building liveoak 'master'. I suspect some change on the nodes tools broke builds.. :( [1] https://projectodd.ci.cloudbees.com/job/liveoak/371/console On Tue, Jul 15, 2014 at 9:07 AM, Matthias Wessendorf wrote: > Hi, > > since Friday, all in a sudden, the node.js part of the build (triggered by > the frontend plugin inside the 'server' module) is failing on different > ways. > > Extremely odd: the 0.11.0 tag is effected as well. The release (on maven > central) is good, but ATM we are not able to build the source on the 0.11.0 > tag :-( > > Oh, yeah, Travis-CI notice the broken build as well ;-) and thankfully > abstractj put in a PR to have a temporary fix for the build failure: > https://github.com/aerogear/aerogear-unifiedpush-server/pull/293 > > Thanks Bruno! > > Yesterday Bruno, Villiam and Luke looked at this already, and they noticed > a failure like this: > > [INFO] --- frontend-maven-plugin:0.0.15:npm (npm install) @ unifiedpush-server --- > [INFO] Running 'npm install --color=false' in /home/travis/build/aerogear/aerogear-unifiedpush-server/admin-ui > [INFO] npm WARN package.json newadmin at 0.0.0 No repository field. > [INFO] > [INFO] --- frontend-maven-plugin:0.0.15:grunt (grunt build) @ unifiedpush-server --- > [INFO] Running 'grunt dist --no-color' in /home/travis/build/aerogear/aerogear-unifiedpush-server/admin-ui > [INFO] >> Local Npm module "grunt-cli" not found. Is it installed? > [INFO] > [INFO] Running "bower:install" (bower) task > [INFO] Fatal error: Arguments to path.join must be strings > [INFO] ------------------------------------------------------------------------ > [INFO] Reactor Summary: > > Note: "grunt-cli" *IS* installed, even globally. If I am correct, at the > moment we are not 100% sure what the "Fatal error: Arguments to path.join > must be strings" really means... > > On my machine, I noticed the npm stuff downloads half of the internet, but > gets stuck in the middle: > > [INFO] npm http 304 https://registry.npmjs.org/oauth-sign > [INFO] npm http 304 https://registry.npmjs.org/aws-sign2 > [INFO] npm http 304 https://registry.npmjs.org/hawk > [INFO] npm http GET https://registry.npmjs.org/combined-stream > [INFO] npm http GET https://registry.npmjs.org/async > [INFO] npm http GET https://registry.npmjs.org/assert-plus > [INFO] npm http GET https://registry.npmjs.org/asn1 > [INFO] npm http GET https://registry.npmjs.org/ctype > [INFO] npm http GET https://registry.npmjs.org/punycode > [INFO] npm http GET https://registry.npmjs.org/hoek > [INFO] npm http GET https://registry.npmjs.org/boom > [INFO] npm http GET https://registry.npmjs.org/sntp > [INFO] npm http GET https://registry.npmjs.org/cryptiles > [INFO] npm http 304 https://registry.npmjs.org/async > [INFO] npm http 304 https://registry.npmjs.org/combined-stream > [INFO] npm http 304 https://registry.npmjs.org/assert-plus > [INFO] npm http 304 https://registry.npmjs.org/asn1 > [INFO] npm http GET https://registry.npmjs.org/delayed-stream > [INFO] npm http 304 https://registry.npmjs.org/ctype > [INFO] npm http 304 https://registry.npmjs.org/punycode > [INFO] npm http 304 https://registry.npmjs.org/boom > [INFO] npm http 304 https://registry.npmjs.org/hoek > [INFO] npm http 304 https://registry.npmjs.org/cryptiles > [INFO] npm http 304 https://registry.npmjs.org/sntp > [INFO] npm http 304 https://registry.npmjs.org/delayed-stream > > Now, after more than one hour of 'waiting', I cancled the build, resulting > in: > > [INFO] > optipng-bin at 0.3.9 postinstall /Users/matzew/Work/JBoss/UPS/admin-ui/node_modules/grunt-contrib-imagemin/node_modules/imagemin/node_modules/imagemin-optipng/node_modules/optipng-bin > [INFO] > node index.js > [INFO] > [INFO] ? pre-build test passed successfully > [INFO] npm http 304 https://registry.npmjs.org/hoek > [INFO] npm http 304 https://registry.npmjs.org/boom > [INFO] npm http 304 https://registry.npmjs.org/cryptiles > [INFO] npm http 304 https://registry.npmjs.org/sntp > [INFO] npm http 304 https://registry.npmjs.org/delayed-stream > ^C[INFO] ------------------------------------------------------------------------ > [INFO] Reactor Summary: > [INFO] > [INFO] AeroGear UnifiedPush Server ....................... SUCCESS [3.884s] > [INFO] UnifiedPush Model Layer ........................... SUCCESS [0.146s] > [INFO] UnifiedPush Server Model API ...................... SUCCESS [2.699s] > [INFO] UnifiedPush Server Model JPA implementation ....... SUCCESS [15.036s] > [INFO] UnifiedPush Service Layer ......................... SUCCESS [7.757s] > [INFO] UnifiedPush Push Notification Networks ............ SUCCESS [2.009s] > [INFO] UnifiedPush RESTful Endpoint ...................... SUCCESS [2.811s] > [INFO] UnifiedPush Server (WAR) .......................... FAILURE [1:30:54.769s] > [INFO] UnifiedPush Auth Server ........................... SKIPPED > [INFO] ------------------------------------------------------------------------ > [INFO] BUILD FAILURE > [INFO] ------------------------------------------------------------------------ > [INFO] Total time: 1:31:29.994s > [INFO] Finished at: Tue Jul 15 07:48:37 CEST 2014 > [INFO] Final Memory: 80M/191M > [INFO] ------------------------------------------------------------------------ > [ERROR] Failed to execute goal com.github.eirslett:frontend-maven-plugin:0.0.15:npm (npm install) on project unifiedpush-server: 'npm install --color=false' failed. (error code 130) -> [Help 1] > [ERROR] > [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch. > [ERROR] Re-run Maven using the -X switch to enable full debug logging. > [ERROR] > [ERROR] For more information about the errors and possible solutions, please read the following articles: > [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException > [ERROR] > [ERROR] After correcting the problems, you can resume the build with the command > [ERROR] mvn -rf :unifiedpush-server > > This is more a FYI on what's going on - I will file a JIRA ticket for that; > > *PS:* According to yesterday's IRC discussions, a manual `grunt server does > work, so development is not*directly* effected > > -Matthias > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140715/3635e7dd/attachment-0001.html From scm.blanc at gmail.com Tue Jul 15 02:50:23 2014 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Tue, 15 Jul 2014 08:50:23 +0200 Subject: [aerogear-dev] broken build (master and 0.11.0 tag) In-Reply-To: References: Message-ID: Looks like Bower is aware of this issue : https://twitter.com/bower/status/487704111832252417 Let me check if I can do something On Tue, Jul 15, 2014 at 8:34 AM, Christos Vasilakis wrote: > Hi, > > the same failure output "[INFO] Fatal error: Arguments to path.join must > be strings" have been noticed also when building liveoak 'master'. I > suspect some change on the nodes tools broke builds.. :( > > > [1] https://projectodd.ci.cloudbees.com/job/liveoak/371/console > > > > On Tue, Jul 15, 2014 at 9:07 AM, Matthias Wessendorf > wrote: > >> Hi, >> >> since Friday, all in a sudden, the node.js part of the build (triggered >> by the frontend plugin inside the 'server' module) is failing on different >> ways. >> >> Extremely odd: the 0.11.0 tag is effected as well. The release (on maven >> central) is good, but ATM we are not able to build the source on the 0.11.0 >> tag :-( >> >> Oh, yeah, Travis-CI notice the broken build as well ;-) and thankfully >> abstractj put in a PR to have a temporary fix for the build failure: >> https://github.com/aerogear/aerogear-unifiedpush-server/pull/293 >> >> Thanks Bruno! >> >> Yesterday Bruno, Villiam and Luke looked at this already, and they >> noticed a failure like this: >> >> [INFO] --- frontend-maven-plugin:0.0.15:npm (npm install) @ unifiedpush-server --- >> [INFO] Running 'npm install --color=false' in /home/travis/build/aerogear/aerogear-unifiedpush-server/admin-ui >> [INFO] npm WARN package.json newadmin at 0.0.0 No repository field. >> [INFO] >> [INFO] --- frontend-maven-plugin:0.0.15:grunt (grunt build) @ unifiedpush-server --- >> [INFO] Running 'grunt dist --no-color' in /home/travis/build/aerogear/aerogear-unifiedpush-server/admin-ui >> [INFO] >> Local Npm module "grunt-cli" not found. Is it installed? >> [INFO] >> [INFO] Running "bower:install" (bower) task >> [INFO] Fatal error: Arguments to path.join must be strings >> [INFO] ------------------------------------------------------------------------ >> [INFO] Reactor Summary: >> >> Note: "grunt-cli" *IS* installed, even globally. If I am correct, at the >> moment we are not 100% sure what the "Fatal error: Arguments to path.join >> must be strings" really means... >> >> On my machine, I noticed the npm stuff downloads half of the internet, >> but gets stuck in the middle: >> >> [INFO] npm http 304 https://registry.npmjs.org/oauth-sign >> [INFO] npm http 304 https://registry.npmjs.org/aws-sign2 >> [INFO] npm http 304 https://registry.npmjs.org/hawk >> [INFO] npm http GET https://registry.npmjs.org/combined-stream >> [INFO] npm http GET https://registry.npmjs.org/async >> [INFO] npm http GET https://registry.npmjs.org/assert-plus >> [INFO] npm http GET https://registry.npmjs.org/asn1 >> [INFO] npm http GET https://registry.npmjs.org/ctype >> [INFO] npm http GET https://registry.npmjs.org/punycode >> [INFO] npm http GET https://registry.npmjs.org/hoek >> [INFO] npm http GET https://registry.npmjs.org/boom >> [INFO] npm http GET https://registry.npmjs.org/sntp >> [INFO] npm http GET https://registry.npmjs.org/cryptiles >> [INFO] npm http 304 https://registry.npmjs.org/async >> [INFO] npm http 304 https://registry.npmjs.org/combined-stream >> [INFO] npm http 304 https://registry.npmjs.org/assert-plus >> [INFO] npm http 304 https://registry.npmjs.org/asn1 >> [INFO] npm http GET https://registry.npmjs.org/delayed-stream >> [INFO] npm http 304 https://registry.npmjs.org/ctype >> [INFO] npm http 304 https://registry.npmjs.org/punycode >> [INFO] npm http 304 https://registry.npmjs.org/boom >> [INFO] npm http 304 https://registry.npmjs.org/hoek >> [INFO] npm http 304 https://registry.npmjs.org/cryptiles >> [INFO] npm http 304 https://registry.npmjs.org/sntp >> [INFO] npm http 304 https://registry.npmjs.org/delayed-stream >> >> Now, after more than one hour of 'waiting', I cancled the build, >> resulting in: >> >> [INFO] > optipng-bin at 0.3.9 postinstall /Users/matzew/Work/JBoss/UPS/admin-ui/node_modules/grunt-contrib-imagemin/node_modules/imagemin/node_modules/imagemin-optipng/node_modules/optipng-bin >> [INFO] > node index.js >> [INFO] >> [INFO] ? pre-build test passed successfully >> [INFO] npm http 304 https://registry.npmjs.org/hoek >> [INFO] npm http 304 https://registry.npmjs.org/boom >> [INFO] npm http 304 https://registry.npmjs.org/cryptiles >> [INFO] npm http 304 https://registry.npmjs.org/sntp >> [INFO] npm http 304 https://registry.npmjs.org/delayed-stream >> ^C[INFO] ------------------------------------------------------------------------ >> [INFO] Reactor Summary: >> [INFO] >> [INFO] AeroGear UnifiedPush Server ....................... SUCCESS [3.884s] >> [INFO] UnifiedPush Model Layer ........................... SUCCESS [0.146s] >> [INFO] UnifiedPush Server Model API ...................... SUCCESS [2.699s] >> [INFO] UnifiedPush Server Model JPA implementation ....... SUCCESS [15.036s] >> [INFO] UnifiedPush Service Layer ......................... SUCCESS [7.757s] >> [INFO] UnifiedPush Push Notification Networks ............ SUCCESS [2.009s] >> [INFO] UnifiedPush RESTful Endpoint ...................... SUCCESS [2.811s] >> [INFO] UnifiedPush Server (WAR) .......................... FAILURE [1:30:54.769s] >> [INFO] UnifiedPush Auth Server ........................... SKIPPED >> [INFO] ------------------------------------------------------------------------ >> [INFO] BUILD FAILURE >> [INFO] ------------------------------------------------------------------------ >> [INFO] Total time: 1:31:29.994s >> [INFO] Finished at: Tue Jul 15 07:48:37 CEST 2014 >> [INFO] Final Memory: 80M/191M >> [INFO] ------------------------------------------------------------------------ >> [ERROR] Failed to execute goal com.github.eirslett:frontend-maven-plugin:0.0.15:npm (npm install) on project unifiedpush-server: 'npm install --color=false' failed. (error code 130) -> [Help 1] >> [ERROR] >> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch. >> [ERROR] Re-run Maven using the -X switch to enable full debug logging. >> [ERROR] >> [ERROR] For more information about the errors and possible solutions, please read the following articles: >> [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException >> [ERROR] >> [ERROR] After correcting the problems, you can resume the build with the command >> [ERROR] mvn -rf :unifiedpush-server >> >> This is more a FYI on what's going on - I will file a JIRA ticket for >> that; >> >> *PS:* According to yesterday's IRC discussions, a manual `grunt server does >> work, so development is not*directly* effected >> >> -Matthias >> >> -- >> Matthias Wessendorf >> >> blog: http://matthiaswessendorf.wordpress.com/ >> sessions: http://www.slideshare.net/mwessendorf >> twitter: http://twitter.com/mwessendorf >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140715/22341957/attachment.html From tolisemm at gmail.com Tue Jul 15 03:17:36 2014 From: tolisemm at gmail.com (tolis emmanouilidis) Date: Tue, 15 Jul 2014 10:17:36 +0300 Subject: [aerogear-dev] broken build (master and 0.11.0 tag) In-Reply-To: References: Message-ID: +1 Sebi The builds started failing 3 days ago. 3 days ago bower ( https://www.npmjs.org/package/bower) was updated to v1.3.8. The last successful Travis UPS build logs contains bower at 1.3.7 node_modules/bower. The rest failed successful Travis UPS build logs contain bower at 1.3.8 node_modules/bower Maybe enforcing bower version 1.3.7 will resolve the issue. 2014-07-15 9:50 GMT+03:00 Sebastien Blanc : > Looks like Bower is aware of this issue : > https://twitter.com/bower/status/487704111832252417 > Let me check if I can do something > > > > On Tue, Jul 15, 2014 at 8:34 AM, Christos Vasilakis > wrote: > >> Hi, >> >> the same failure output "[INFO] Fatal error: Arguments to path.join >> must be strings" have been noticed also when building liveoak 'master'. >> I suspect some change on the nodes tools broke builds.. :( >> >> >> [1] https://projectodd.ci.cloudbees.com/job/liveoak/371/console >> >> >> >> On Tue, Jul 15, 2014 at 9:07 AM, Matthias Wessendorf >> wrote: >> >>> Hi, >>> >>> since Friday, all in a sudden, the node.js part of the build (triggered >>> by the frontend plugin inside the 'server' module) is failing on different >>> ways. >>> >>> Extremely odd: the 0.11.0 tag is effected as well. The release (on maven >>> central) is good, but ATM we are not able to build the source on the 0.11.0 >>> tag :-( >>> >>> Oh, yeah, Travis-CI notice the broken build as well ;-) and thankfully >>> abstractj put in a PR to have a temporary fix for the build failure: >>> https://github.com/aerogear/aerogear-unifiedpush-server/pull/293 >>> >>> Thanks Bruno! >>> >>> Yesterday Bruno, Villiam and Luke looked at this already, and they >>> noticed a failure like this: >>> >>> [INFO] --- frontend-maven-plugin:0.0.15:npm (npm install) @ unifiedpush-server --- >>> [INFO] Running 'npm install --color=false' in /home/travis/build/aerogear/aerogear-unifiedpush-server/admin-ui >>> [INFO] npm WARN package.json newadmin at 0.0.0 No repository field. >>> [INFO] >>> [INFO] --- frontend-maven-plugin:0.0.15:grunt (grunt build) @ unifiedpush-server --- >>> [INFO] Running 'grunt dist --no-color' in /home/travis/build/aerogear/aerogear-unifiedpush-server/admin-ui >>> [INFO] >> Local Npm module "grunt-cli" not found. Is it installed? >>> [INFO] >>> [INFO] Running "bower:install" (bower) task >>> [INFO] Fatal error: Arguments to path.join must be strings >>> [INFO] ------------------------------------------------------------------------ >>> [INFO] Reactor Summary: >>> >>> Note: "grunt-cli" *IS* installed, even globally. If I am correct, at >>> the moment we are not 100% sure what the "Fatal error: Arguments to >>> path.join must be strings" really means... >>> >>> On my machine, I noticed the npm stuff downloads half of the internet, >>> but gets stuck in the middle: >>> >>> [INFO] npm http 304 https://registry.npmjs.org/oauth-sign >>> [INFO] npm http 304 https://registry.npmjs.org/aws-sign2 >>> [INFO] npm http 304 https://registry.npmjs.org/hawk >>> [INFO] npm http GET https://registry.npmjs.org/combined-stream >>> [INFO] npm http GET https://registry.npmjs.org/async >>> [INFO] npm http GET https://registry.npmjs.org/assert-plus >>> [INFO] npm http GET https://registry.npmjs.org/asn1 >>> [INFO] npm http GET https://registry.npmjs.org/ctype >>> [INFO] npm http GET https://registry.npmjs.org/punycode >>> [INFO] npm http GET https://registry.npmjs.org/hoek >>> [INFO] npm http GET https://registry.npmjs.org/boom >>> [INFO] npm http GET https://registry.npmjs.org/sntp >>> [INFO] npm http GET https://registry.npmjs.org/cryptiles >>> [INFO] npm http 304 https://registry.npmjs.org/async >>> [INFO] npm http 304 https://registry.npmjs.org/combined-stream >>> [INFO] npm http 304 https://registry.npmjs.org/assert-plus >>> [INFO] npm http 304 https://registry.npmjs.org/asn1 >>> [INFO] npm http GET https://registry.npmjs.org/delayed-stream >>> [INFO] npm http 304 https://registry.npmjs.org/ctype >>> [INFO] npm http 304 https://registry.npmjs.org/punycode >>> [INFO] npm http 304 https://registry.npmjs.org/boom >>> [INFO] npm http 304 https://registry.npmjs.org/hoek >>> [INFO] npm http 304 https://registry.npmjs.org/cryptiles >>> [INFO] npm http 304 https://registry.npmjs.org/sntp >>> [INFO] npm http 304 https://registry.npmjs.org/delayed-stream >>> >>> Now, after more than one hour of 'waiting', I cancled the build, >>> resulting in: >>> >>> [INFO] > optipng-bin at 0.3.9 postinstall /Users/matzew/Work/JBoss/UPS/admin-ui/node_modules/grunt-contrib-imagemin/node_modules/imagemin/node_modules/imagemin-optipng/node_modules/optipng-bin >>> [INFO] > node index.js >>> [INFO] >>> [INFO] ? pre-build test passed successfully >>> [INFO] npm http 304 https://registry.npmjs.org/hoek >>> [INFO] npm http 304 https://registry.npmjs.org/boom >>> [INFO] npm http 304 https://registry.npmjs.org/cryptiles >>> [INFO] npm http 304 https://registry.npmjs.org/sntp >>> [INFO] npm http 304 https://registry.npmjs.org/delayed-stream >>> ^C[INFO] ------------------------------------------------------------------------ >>> [INFO] Reactor Summary: >>> [INFO] >>> [INFO] AeroGear UnifiedPush Server ....................... SUCCESS [3.884s] >>> [INFO] UnifiedPush Model Layer ........................... SUCCESS [0.146s] >>> [INFO] UnifiedPush Server Model API ...................... SUCCESS [2.699s] >>> [INFO] UnifiedPush Server Model JPA implementation ....... SUCCESS [15.036s] >>> [INFO] UnifiedPush Service Layer ......................... SUCCESS [7.757s] >>> [INFO] UnifiedPush Push Notification Networks ............ SUCCESS [2.009s] >>> [INFO] UnifiedPush RESTful Endpoint ...................... SUCCESS [2.811s] >>> [INFO] UnifiedPush Server (WAR) .......................... FAILURE [1:30:54.769s] >>> [INFO] UnifiedPush Auth Server ........................... SKIPPED >>> [INFO] ------------------------------------------------------------------------ >>> [INFO] BUILD FAILURE >>> [INFO] ------------------------------------------------------------------------ >>> [INFO] Total time: 1:31:29.994s >>> [INFO] Finished at: Tue Jul 15 07:48:37 CEST 2014 >>> [INFO] Final Memory: 80M/191M >>> [INFO] ------------------------------------------------------------------------ >>> [ERROR] Failed to execute goal com.github.eirslett:frontend-maven-plugin:0.0.15:npm (npm install) on project unifiedpush-server: 'npm install --color=false' failed. (error code 130) -> [Help 1] >>> [ERROR] >>> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch. >>> [ERROR] Re-run Maven using the -X switch to enable full debug logging. >>> [ERROR] >>> [ERROR] For more information about the errors and possible solutions, please read the following articles: >>> [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException >>> [ERROR] >>> [ERROR] After correcting the problems, you can resume the build with the command >>> [ERROR] mvn -rf :unifiedpush-server >>> >>> This is more a FYI on what's going on - I will file a JIRA ticket for >>> that; >>> >>> *PS:* According to yesterday's IRC discussions, a manual `grunt server does >>> work, so development is not*directly* effected >>> >>> -Matthias >>> >>> -- >>> Matthias Wessendorf >>> >>> blog: http://matthiaswessendorf.wordpress.com/ >>> sessions: http://www.slideshare.net/mwessendorf >>> twitter: http://twitter.com/mwessendorf >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140715/e553e4ab/attachment-0001.html From matzew at apache.org Tue Jul 15 03:20:52 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Tue, 15 Jul 2014 09:20:52 +0200 Subject: [aerogear-dev] broken build (master and 0.11.0 tag) In-Reply-To: References: Message-ID: Sebi, christos! Thanks for the info! Can you reach out to Villiam regarding this? Cheers! Matthias On Tuesday, July 15, 2014, Sebastien Blanc wrote: > Looks like Bower is aware of this issue : > https://twitter.com/bower/status/487704111832252417 > Let me check if I can do something > > > > On Tue, Jul 15, 2014 at 8:34 AM, Christos Vasilakis > wrote: > >> Hi, >> >> the same failure output "[INFO] Fatal error: Arguments to path.join >> must be strings" have been noticed also when building liveoak 'master'. >> I suspect some change on the nodes tools broke builds.. :( >> >> >> [1] https://projectodd.ci.cloudbees.com/job/liveoak/371/console >> >> >> >> On Tue, Jul 15, 2014 at 9:07 AM, Matthias Wessendorf > > wrote: >> >>> Hi, >>> >>> since Friday, all in a sudden, the node.js part of the build (triggered >>> by the frontend plugin inside the 'server' module) is failing on different >>> ways. >>> >>> Extremely odd: the 0.11.0 tag is effected as well. The release (on maven >>> central) is good, but ATM we are not able to build the source on the 0.11.0 >>> tag :-( >>> >>> Oh, yeah, Travis-CI notice the broken build as well ;-) and thankfully >>> abstractj put in a PR to have a temporary fix for the build failure: >>> https://github.com/aerogear/aerogear-unifiedpush-server/pull/293 >>> >>> Thanks Bruno! >>> >>> Yesterday Bruno, Villiam and Luke looked at this already, and they >>> noticed a failure like this: >>> >>> [INFO] --- frontend-maven-plugin:0.0.15:npm (npm install) @ unifiedpush-server --- >>> [INFO] Running 'npm install --color=false' in /home/travis/build/aerogear/aerogear-unifiedpush-server/admin-ui >>> [INFO] npm WARN package.json newadmin at 0.0.0 No repository field. >>> [INFO] >>> [INFO] --- frontend-maven-plugin:0.0.15:grunt (grunt build) @ unifiedpush-server --- >>> [INFO] Running 'grunt dist --no-color' in /home/travis/build/aerogear/aerogear-unifiedpush-server/admin-ui >>> [INFO] >> Local Npm module "grunt-cli" not found. Is it installed? >>> [INFO] >>> [INFO] Running "bower:install" (bower) task >>> [INFO] Fatal error: Arguments to path.join must be strings >>> [INFO] ------------------------------------------------------------------------ >>> [INFO] Reactor Summary: >>> >>> Note: "grunt-cli" *IS* installed, even globally. If I am correct, at >>> the moment we are not 100% sure what the "Fatal error: Arguments to >>> path.join must be strings" really means... >>> >>> On my machine, I noticed the npm stuff downloads half of the internet, >>> but gets stuck in the middle: >>> >>> [INFO] npm http 304 https://registry.npmjs.org/oauth-sign >>> [INFO] npm http 304 https://registry.npmjs.org/aws-sign2 >>> [INFO] npm http 304 https://registry.npmjs.org/hawk >>> [INFO] npm http GET https://registry.npmjs.org/combined-stream >>> [INFO] npm http GET https://registry.npmjs.org/async >>> [INFO] npm http GET https://registry.npmjs.org/assert-plus >>> [INFO] npm http GET https://registry.npmjs.org/asn1 >>> [INFO] npm http GET https://registry.npmjs.org/ctype >>> [INFO] npm http GET https://registry.npmjs.org/punycode >>> [INFO] npm http GET https://registry.npmjs.org/hoek >>> [INFO] npm http GET https://registry.npmjs.org/boom >>> [INFO] npm http GET https://registry.npmjs.org/sntp >>> [INFO] npm http GET https://registry.npmjs.org/cryptiles >>> [INFO] npm http 304 https://registry.npmjs.org/async >>> [INFO] npm http 304 https://registry.npmjs.org/combined-stream >>> [INFO] npm http 304 https://registry.npmjs.org/assert-plus >>> [INFO] npm http 304 https://registry.npmjs.org/asn1 >>> [INFO] npm http GET https://registry.npmjs.org/delayed-stream >>> [INFO] npm http 304 https://registry.npmjs.org/ctype >>> [INFO] npm http 304 https://registry.npmjs.org/punycode >>> [INFO] npm http 304 https://registry.npmjs.org/boom >>> [INFO] npm http 304 https://registry.npmjs.org/hoek >>> [INFO] npm http 304 https://registry.npmjs.org/cryptiles >>> [INFO] npm http 304 https://registry.npmjs.org/sntp >>> [INFO] npm http 304 https://registry.npmjs.org/delayed-stream >>> >>> Now, after more than one hour of 'waiting', I cancled the build, >>> resulting in: >>> >>> [INFO] > optipng-bin at 0.3.9 postinstall /Users/matzew/Work/JBoss/UPS/admin-ui/node_modules/grunt-contrib-imagemin/node_modules/imagemin/node_modules/imagemin-optipng/node_modules/optipng-bin >>> [INFO] > node index.js >>> [INFO] >>> [INFO] ? pre-build test passed successfully >>> [INFO] npm http 304 https://registry.npmjs.org/hoek >>> [INFO] npm http 304 https://registry.npmjs.org/boom >>> [INFO] npm http 304 https://registry.npmjs.org/cryptiles >>> [INFO] npm http 304 https://registry.npmjs.org/sntp >>> [INFO] npm http 304 https://registry.npmjs.org/delayed-stream >>> ^C[INFO] ------------------------------------------------------------------------ >>> [INFO] Reactor Summary: >>> [INFO] >>> [INFO] AeroGear UnifiedPush Server ....................... SUCCESS [3.884s] >>> [INFO] UnifiedPush Model Layer ........................... SUCCESS [0.146s] >>> [INFO] UnifiedPush Server Model API ...................... SUCCESS [2.699s] >>> [INFO] UnifiedPush Server Model JPA implementation ....... SUCCESS [15.036s] >>> [INFO] UnifiedPush Service Layer ......................... SUCCESS [7.757s] >>> [INFO] UnifiedPush Push Notification Networks ............ SUCCESS [2.009s] >>> [INFO] UnifiedPush RESTful Endpoint ...................... SUCCESS [2.811s] >>> [INFO] UnifiedPush Server (WAR) .......................... FAILURE [1:30:54.769s] >>> [INFO] UnifiedPush Auth Server ........................... SKIPPED >>> [INFO] ------------------------------------------------------------------------ >>> [INFO] BUILD FAILURE >>> [INFO] ------------------------------------------------------------------------ >>> [INFO] Total time: 1:31:29.994s >>> [INFO] Finished at: Tue Jul 15 07:48:37 CEST 2014 >>> [INFO] Final Memory: 80M/191M >>> [INFO] ------------------------------------------------------------------------ >>> [ERROR] Failed to execute goal com.github.eirslett:frontend-maven-plugin:0.0.15:npm (npm install) on project unifiedpush-server: 'npm install --color=false' failed. (error code 130) -> [Help 1] >>> [ERROR] >>> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch. >>> [ERROR] Re-run Maven using the -X switch to enable full debug logging. >>> [ERROR] >>> [ERROR] For more information about the errors and possible solutions, please read the following articles: >>> [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException >>> [ERROR] >>> [ERROR] After correcting the problems, you can resume the build with the command >>> [ERROR] mvn -rf :unifiedpush-server >>> >>> This is more a FYI on what's going on - I will file a JIRA ticket for >>> that; >>> >>> *PS:* According to yesterday's IRC discussions, a manual `grunt server does >>> work, so development is not*directly* effected >>> >>> -Matthias >>> >>> -- >>> Matthias Wessendorf >>> >>> blog: http://matthiaswessendorf.wordpress.com/ >>> sessions: http://www.slideshare.net/mwessendorf >>> twitter: http://twitter.com/mwessendorf >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > -- Sent from Gmail Mobile -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140715/970e37d8/attachment.html From matzew at apache.org Tue Jul 15 03:21:43 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Tue, 15 Jul 2014 09:21:43 +0200 Subject: [aerogear-dev] broken build (master and 0.11.0 tag) In-Reply-To: References: Message-ID: On Tuesday, July 15, 2014, tolis emmanouilidis wrote: > +1 Sebi > > The builds started failing 3 days ago. 3 days ago bower ( > https://www.npmjs.org/package/bower) was updated to v1.3.8. > > The last successful Travis UPS build logs contains bower at 1.3.7 > node_modules/bower. > The rest failed successful Travis UPS build logs contain bower at 1.3.8 > node_modules/bower > > Maybe enforcing bower version 1.3.7 will resolve the issue. > +9001 We should lock all versions :-) > > > 2014-07-15 9:50 GMT+03:00 Sebastien Blanc >: > >> Looks like Bower is aware of this issue : >> https://twitter.com/bower/status/487704111832252417 >> Let me check if I can do something >> >> >> >> On Tue, Jul 15, 2014 at 8:34 AM, Christos Vasilakis > > wrote: >> >>> Hi, >>> >>> the same failure output "[INFO] Fatal error: Arguments to path.join >>> must be strings" have been noticed also when building liveoak 'master'. >>> I suspect some change on the nodes tools broke builds.. :( >>> >>> >>> [1] https://projectodd.ci.cloudbees.com/job/liveoak/371/console >>> >>> >>> >>> On Tue, Jul 15, 2014 at 9:07 AM, Matthias Wessendorf >> > wrote: >>> >>>> Hi, >>>> >>>> since Friday, all in a sudden, the node.js part of the build (triggered >>>> by the frontend plugin inside the 'server' module) is failing on different >>>> ways. >>>> >>>> Extremely odd: the 0.11.0 tag is effected as well. The release (on >>>> maven central) is good, but ATM we are not able to build the source on the >>>> 0.11.0 tag :-( >>>> >>>> Oh, yeah, Travis-CI notice the broken build as well ;-) and thankfully >>>> abstractj put in a PR to have a temporary fix for the build failure: >>>> https://github.com/aerogear/aerogear-unifiedpush-server/pull/293 >>>> >>>> Thanks Bruno! >>>> >>>> Yesterday Bruno, Villiam and Luke looked at this already, and they >>>> noticed a failure like this: >>>> >>>> [INFO] --- frontend-maven-plugin:0.0.15:npm (npm install) @ unifiedpush-server --- >>>> [INFO] Running 'npm install --color=false' in /home/travis/build/aerogear/aerogear-unifiedpush-server/admin-ui >>>> [INFO] npm WARN package.json newadmin at 0.0.0 No repository field. >>>> [INFO] >>>> [INFO] --- frontend-maven-plugin:0.0.15:grunt (grunt build) @ unifiedpush-server --- >>>> [INFO] Running 'grunt dist --no-color' in /home/travis/build/aerogear/aerogear-unifiedpush-server/admin-ui >>>> [INFO] >> Local Npm module "grunt-cli" not found. Is it installed? >>>> [INFO] >>>> [INFO] Running "bower:install" (bower) task >>>> [INFO] Fatal error: Arguments to path.join must be strings >>>> [INFO] ------------------------------------------------------------------------ >>>> [INFO] Reactor Summary: >>>> >>>> Note: "grunt-cli" *IS* installed, even globally. If I am correct, at >>>> the moment we are not 100% sure what the "Fatal error: Arguments to >>>> path.join must be strings" really means... >>>> >>>> On my machine, I noticed the npm stuff downloads half of the internet, >>>> but gets stuck in the middle: >>>> >>>> [INFO] npm http 304 https://registry.npmjs.org/oauth-sign >>>> [INFO] npm http 304 https://registry.npmjs.org/aws-sign2 >>>> [INFO] npm http 304 https://registry.npmjs.org/hawk >>>> [INFO] npm http GET https://registry.npmjs.org/combined-stream >>>> [INFO] npm http GET https://registry.npmjs.org/async >>>> [INFO] npm http GET https://registry.npmjs.org/assert-plus >>>> [INFO] npm http GET https://registry.npmjs.org/asn1 >>>> [INFO] npm http GET https://registry.npmjs.org/ctype >>>> [INFO] npm http GET https://registry.npmjs.org/punycode >>>> [INFO] npm http GET https://registry.npmjs.org/hoek >>>> [INFO] npm http GET https://registry.npmjs.org/boom >>>> [INFO] npm http GET https://registry.npmjs.org/sntp >>>> [INFO] npm http GET https://registry.npmjs.org/cryptiles >>>> [INFO] npm http 304 https://registry.npmjs.org/async >>>> [INFO] npm http 304 https://registry.npmjs.org/combined-stream >>>> [INFO] npm http 304 https://registry.npmjs.org/assert-plus >>>> [INFO] npm http 304 https://registry.npmjs.org/asn1 >>>> [INFO] npm http GET https://registry.npmjs.org/delayed-stream >>>> [INFO] npm http 304 https://registry.npmjs.org/ctype >>>> [INFO] npm http 304 https://registry.npmjs.org/punycode >>>> [INFO] npm http 304 https://registry.npmjs.org/boom >>>> [INFO] npm http 304 https://registry.npmjs.org/hoek >>>> [INFO] npm http 304 https://registry.npmjs.org/cryptiles >>>> [INFO] npm http 304 https://registry.npmjs.org/sntp >>>> [INFO] npm http 304 https://registry.npmjs.org/delayed-stream >>>> >>>> Now, after more than one hour of 'waiting', I cancled the build, >>>> resulting in: >>>> >>>> [INFO] > optipng-bin at 0.3.9 postinstall /Users/matzew/Work/JBoss/UPS/admin-ui/node_modules/grunt-contrib-imagemin/node_modules/imagemin/node_modules/imagemin-optipng/node_modules/optipng-bin >>>> [INFO] > node index.js >>>> [INFO] >>>> [INFO] ? pre-build test passed successfully >>>> [INFO] npm http 304 https://registry.npmjs.org/hoek >>>> [INFO] npm http 304 https://registry.npmjs.org/boom >>>> [INFO] npm http 304 https://registry.npmjs.org/cryptiles >>>> [INFO] npm http 304 https://registry.npmjs.org/sntp >>>> [INFO] npm http 304 https://registry.npmjs.org/delayed-stream >>>> ^C[INFO] ------------------------------------------------------------------------ >>>> [INFO] Reactor Summary: >>>> [INFO] >>>> [INFO] AeroGear UnifiedPush Server ....................... SUCCESS [3.884s] >>>> [INFO] UnifiedPush Model Layer ........................... SUCCESS [0.146s] >>>> [INFO] UnifiedPush Server Model API ...................... SUCCESS [2.699s] >>>> [INFO] UnifiedPush Server Model JPA implementation ....... SUCCESS [15.036s] >>>> [INFO] UnifiedPush Service Layer ......................... SUCCESS [7.757s] >>>> [INFO] UnifiedPush Push Notification Networks ............ SUCCESS [2.009s] >>>> [INFO] UnifiedPush RESTful Endpoint ...................... SUCCESS [2.811s] >>>> [INFO] UnifiedPush Server (WAR) .......................... FAILURE [1:30:54.769s] >>>> [INFO] UnifiedPush Auth Server ........................... SKIPPED >>>> [INFO] ------------------------------------------------------------------------ >>>> [INFO] BUILD FAILURE >>>> [INFO] ------------------------------------------------------------------------ >>>> [INFO] Total time: 1:31:29.994s >>>> [INFO] Finished at: Tue Jul 15 07:48:37 CEST 2014 >>>> [INFO] Final Memory: 80M/191M >>>> [INFO] ------------------------------------------------------------------------ >>>> [ERROR] Failed to execute goal com.github.eirslett:frontend-maven-plugin:0.0.15:npm (npm install) on project unifiedpush-server: 'npm install --color=false' failed. (error code 130) -> [Help 1] >>>> [ERROR] >>>> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch. >>>> [ERROR] Re-run Maven using the -X switch to enable full debug logging. >>>> [ERROR] >>>> [ERROR] For more information about the errors and possible solutions, please read the following articles: >>>> [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException >>>> [ERROR] >>>> [ERROR] After correcting the problems, you can resume the build with the command >>>> [ERROR] mvn -rf :unifiedpush-server >>>> >>>> This is more a FYI on what's going on - I will file a JIRA ticket for >>>> that; >>>> >>>> *PS:* According to yesterday's IRC discussions, a manual `grunt server does >>>> work, so development is not*directly* effected >>>> >>>> -Matthias >>>> >>>> -- >>>> Matthias Wessendorf >>>> >>>> blog: http://matthiaswessendorf.wordpress.com/ >>>> sessions: http://www.slideshare.net/mwessendorf >>>> twitter: http://twitter.com/mwessendorf >>>> >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev at lists.jboss.org >>>> >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> >>> >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > -- Sent from Gmail Mobile -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140715/91015005/attachment-0001.html From scm.blanc at gmail.com Tue Jul 15 03:29:19 2014 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Tue, 15 Jul 2014 09:29:19 +0200 Subject: [aerogear-dev] broken build (master and 0.11.0 tag) In-Reply-To: References: Message-ID: Ok, Some extra info : As suggested I tried to update Bower to 1.3.8 : - https://github.com/aerogear/aerogear-unifiedpush-server/commit/87dadc04ab2c0bfbb482706ecba5ab55d04ae30c But that did not helped , maybe the maven frontend pugin overides the Bower version, looking at this now BUT, on twitter someone suggested this : https://twitter.com/chrisfrancis27/status/488701380207448064 Basically adding a "temp" dependencies to package.json , o_0 => indeed but it WORKS : https://travis-ci.org/aerogear/aerogear-unifiedpush-server/builds/29953927 ! So good news , with this "temp" dep we can build again and in the same time let's find out how we can update bower On Tue, Jul 15, 2014 at 9:21 AM, Matthias Wessendorf wrote: > > > On Tuesday, July 15, 2014, tolis emmanouilidis wrote: > >> +1 Sebi >> >> The builds started failing 3 days ago. 3 days ago bower ( >> https://www.npmjs.org/package/bower) was updated to v1.3.8. >> >> The last successful Travis UPS build logs contains bower at 1.3.7 >> node_modules/bower. >> The rest failed successful Travis UPS build logs contain bower at 1.3.8 >> node_modules/bower >> >> Maybe enforcing bower version 1.3.7 will resolve the issue. >> > > > +9001 > We should lock all versions :-) > > >> >> >> 2014-07-15 9:50 GMT+03:00 Sebastien Blanc : >> >>> Looks like Bower is aware of this issue : >>> https://twitter.com/bower/status/487704111832252417 >>> Let me check if I can do something >>> >>> >>> >>> On Tue, Jul 15, 2014 at 8:34 AM, Christos Vasilakis >>> wrote: >>> >>>> Hi, >>>> >>>> the same failure output "[INFO] Fatal error: Arguments to path.join >>>> must be strings" have been noticed also when building liveoak >>>> 'master'. I suspect some change on the nodes tools broke builds.. :( >>>> >>>> >>>> [1] https://projectodd.ci.cloudbees.com/job/liveoak/371/console >>>> >>>> >>>> >>>> On Tue, Jul 15, 2014 at 9:07 AM, Matthias Wessendorf >>> > wrote: >>>> >>>>> Hi, >>>>> >>>>> since Friday, all in a sudden, the node.js part of the build >>>>> (triggered by the frontend plugin inside the 'server' module) is failing on >>>>> different ways. >>>>> >>>>> Extremely odd: the 0.11.0 tag is effected as well. The release (on >>>>> maven central) is good, but ATM we are not able to build the source on the >>>>> 0.11.0 tag :-( >>>>> >>>>> Oh, yeah, Travis-CI notice the broken build as well ;-) and thankfully >>>>> abstractj put in a PR to have a temporary fix for the build failure: >>>>> https://github.com/aerogear/aerogear-unifiedpush-server/pull/293 >>>>> >>>>> Thanks Bruno! >>>>> >>>>> Yesterday Bruno, Villiam and Luke looked at this already, and they >>>>> noticed a failure like this: >>>>> >>>>> [INFO] --- frontend-maven-plugin:0.0.15:npm (npm install) @ unifiedpush-server --- >>>>> [INFO] Running 'npm install --color=false' in /home/travis/build/aerogear/aerogear-unifiedpush-server/admin-ui >>>>> [INFO] npm WARN package.json newadmin at 0.0.0 No repository field. >>>>> [INFO] >>>>> [INFO] --- frontend-maven-plugin:0.0.15:grunt (grunt build) @ unifiedpush-server --- >>>>> [INFO] Running 'grunt dist --no-color' in /home/travis/build/aerogear/aerogear-unifiedpush-server/admin-ui >>>>> [INFO] >> Local Npm module "grunt-cli" not found. Is it installed? >>>>> [INFO] >>>>> [INFO] Running "bower:install" (bower) task >>>>> [INFO] Fatal error: Arguments to path.join must be strings >>>>> [INFO] ------------------------------------------------------------------------ >>>>> [INFO] Reactor Summary: >>>>> >>>>> Note: "grunt-cli" *IS* installed, even globally. If I am correct, at >>>>> the moment we are not 100% sure what the "Fatal error: Arguments to >>>>> path.join must be strings" really means... >>>>> >>>>> On my machine, I noticed the npm stuff downloads half of the internet, >>>>> but gets stuck in the middle: >>>>> >>>>> [INFO] npm http 304 https://registry.npmjs.org/oauth-sign >>>>> [INFO] npm http 304 https://registry.npmjs.org/aws-sign2 >>>>> [INFO] npm http 304 https://registry.npmjs.org/hawk >>>>> [INFO] npm http GET https://registry.npmjs.org/combined-stream >>>>> [INFO] npm http GET https://registry.npmjs.org/async >>>>> [INFO] npm http GET https://registry.npmjs.org/assert-plus >>>>> [INFO] npm http GET https://registry.npmjs.org/asn1 >>>>> [INFO] npm http GET https://registry.npmjs.org/ctype >>>>> [INFO] npm http GET https://registry.npmjs.org/punycode >>>>> [INFO] npm http GET https://registry.npmjs.org/hoek >>>>> [INFO] npm http GET https://registry.npmjs.org/boom >>>>> [INFO] npm http GET https://registry.npmjs.org/sntp >>>>> [INFO] npm http GET https://registry.npmjs.org/cryptiles >>>>> [INFO] npm http 304 https://registry.npmjs.org/async >>>>> [INFO] npm http 304 https://registry.npmjs.org/combined-stream >>>>> [INFO] npm http 304 https://registry.npmjs.org/assert-plus >>>>> [INFO] npm http 304 https://registry.npmjs.org/asn1 >>>>> [INFO] npm http GET https://registry.npmjs.org/delayed-stream >>>>> [INFO] npm http 304 https://registry.npmjs.org/ctype >>>>> [INFO] npm http 304 https://registry.npmjs.org/punycode >>>>> [INFO] npm http 304 https://registry.npmjs.org/boom >>>>> [INFO] npm http 304 https://registry.npmjs.org/hoek >>>>> [INFO] npm http 304 https://registry.npmjs.org/cryptiles >>>>> [INFO] npm http 304 https://registry.npmjs.org/sntp >>>>> [INFO] npm http 304 https://registry.npmjs.org/delayed-stream >>>>> >>>>> Now, after more than one hour of 'waiting', I cancled the build, >>>>> resulting in: >>>>> >>>>> [INFO] > optipng-bin at 0.3.9 postinstall /Users/matzew/Work/JBoss/UPS/admin-ui/node_modules/grunt-contrib-imagemin/node_modules/imagemin/node_modules/imagemin-optipng/node_modules/optipng-bin >>>>> [INFO] > node index.js >>>>> [INFO] >>>>> [INFO] ? pre-build test passed successfully >>>>> [INFO] npm http 304 https://registry.npmjs.org/hoek >>>>> [INFO] npm http 304 https://registry.npmjs.org/boom >>>>> [INFO] npm http 304 https://registry.npmjs.org/cryptiles >>>>> [INFO] npm http 304 https://registry.npmjs.org/sntp >>>>> [INFO] npm http 304 https://registry.npmjs.org/delayed-stream >>>>> ^C[INFO] ------------------------------------------------------------------------ >>>>> [INFO] Reactor Summary: >>>>> [INFO] >>>>> [INFO] AeroGear UnifiedPush Server ....................... SUCCESS [3.884s] >>>>> [INFO] UnifiedPush Model Layer ........................... SUCCESS [0.146s] >>>>> [INFO] UnifiedPush Server Model API ...................... SUCCESS [2.699s] >>>>> [INFO] UnifiedPush Server Model JPA implementation ....... SUCCESS [15.036s] >>>>> [INFO] UnifiedPush Service Layer ......................... SUCCESS [7.757s] >>>>> [INFO] UnifiedPush Push Notification Networks ............ SUCCESS [2.009s] >>>>> [INFO] UnifiedPush RESTful Endpoint ...................... SUCCESS [2.811s] >>>>> [INFO] UnifiedPush Server (WAR) .......................... FAILURE [1:30:54.769s] >>>>> [INFO] UnifiedPush Auth Server ........................... SKIPPED >>>>> [INFO] ------------------------------------------------------------------------ >>>>> [INFO] BUILD FAILURE >>>>> [INFO] ------------------------------------------------------------------------ >>>>> [INFO] Total time: 1:31:29.994s >>>>> [INFO] Finished at: Tue Jul 15 07:48:37 CEST 2014 >>>>> [INFO] Final Memory: 80M/191M >>>>> [INFO] ------------------------------------------------------------------------ >>>>> [ERROR] Failed to execute goal com.github.eirslett:frontend-maven-plugin:0.0.15:npm (npm install) on project unifiedpush-server: 'npm install --color=false' failed. (error code 130) -> [Help 1] >>>>> [ERROR] >>>>> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch. >>>>> [ERROR] Re-run Maven using the -X switch to enable full debug logging. >>>>> [ERROR] >>>>> [ERROR] For more information about the errors and possible solutions, please read the following articles: >>>>> [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException >>>>> [ERROR] >>>>> [ERROR] After correcting the problems, you can resume the build with the command >>>>> [ERROR] mvn -rf :unifiedpush-server >>>>> >>>>> This is more a FYI on what's going on - I will file a JIRA ticket for >>>>> that; >>>>> >>>>> *PS:* According to yesterday's IRC discussions, a manual `grunt server does >>>>> work, so development is not*directly* effected >>>>> >>>>> -Matthias >>>>> >>>>> -- >>>>> Matthias Wessendorf >>>>> >>>>> blog: http://matthiaswessendorf.wordpress.com/ >>>>> sessions: http://www.slideshare.net/mwessendorf >>>>> twitter: http://twitter.com/mwessendorf >>>>> >>>>> _______________________________________________ >>>>> aerogear-dev mailing list >>>>> aerogear-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>> >>>> >>>> >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> >>> >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >> >> > > -- > Sent from Gmail Mobile > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140715/c1c32412/attachment-0001.html From scm.blanc at gmail.com Tue Jul 15 03:44:06 2014 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Tue, 15 Jul 2014 09:44:06 +0200 Subject: [aerogear-dev] broken build (master and 0.11.0 tag) In-Reply-To: References: Message-ID: FYI : I merged my fix and master is building again :) On Tue, Jul 15, 2014 at 9:29 AM, Sebastien Blanc wrote: > Ok, > Some extra info : > As suggested I tried to update Bower to 1.3.8 : > - > https://github.com/aerogear/aerogear-unifiedpush-server/commit/87dadc04ab2c0bfbb482706ecba5ab55d04ae30c > But that did not helped , maybe the maven frontend pugin overides the > Bower version, looking at this now > > BUT, on twitter someone suggested this : > https://twitter.com/chrisfrancis27/status/488701380207448064 > > Basically adding a "temp" dependencies to package.json , o_0 => indeed but > it WORKS : > > https://travis-ci.org/aerogear/aerogear-unifiedpush-server/builds/29953927 > ! > > So good news , with this "temp" dep we can build again and in the same > time let's find out how we can update bower > > > On Tue, Jul 15, 2014 at 9:21 AM, Matthias Wessendorf > wrote: > >> >> >> On Tuesday, July 15, 2014, tolis emmanouilidis >> wrote: >> >>> +1 Sebi >>> >>> The builds started failing 3 days ago. 3 days ago bower ( >>> https://www.npmjs.org/package/bower) was updated to v1.3.8. >>> >>> The last successful Travis UPS build logs contains bower at 1.3.7 >>> node_modules/bower. >>> The rest failed successful Travis UPS build logs contain bower at 1.3.8 >>> node_modules/bower >>> >>> Maybe enforcing bower version 1.3.7 will resolve the issue. >>> >> >> >> +9001 >> We should lock all versions :-) >> >> >>> >>> >>> 2014-07-15 9:50 GMT+03:00 Sebastien Blanc : >>> >>>> Looks like Bower is aware of this issue : >>>> https://twitter.com/bower/status/487704111832252417 >>>> Let me check if I can do something >>>> >>>> >>>> >>>> On Tue, Jul 15, 2014 at 8:34 AM, Christos Vasilakis >>> > wrote: >>>> >>>>> Hi, >>>>> >>>>> the same failure output "[INFO] Fatal error: Arguments to path.join >>>>> must be strings" have been noticed also when building liveoak >>>>> 'master'. I suspect some change on the nodes tools broke builds.. :( >>>>> >>>>> >>>>> [1] https://projectodd.ci.cloudbees.com/job/liveoak/371/console >>>>> >>>>> >>>>> >>>>> On Tue, Jul 15, 2014 at 9:07 AM, Matthias Wessendorf < >>>>> matzew at apache.org> wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> since Friday, all in a sudden, the node.js part of the build >>>>>> (triggered by the frontend plugin inside the 'server' module) is failing on >>>>>> different ways. >>>>>> >>>>>> Extremely odd: the 0.11.0 tag is effected as well. The release (on >>>>>> maven central) is good, but ATM we are not able to build the source on the >>>>>> 0.11.0 tag :-( >>>>>> >>>>>> Oh, yeah, Travis-CI notice the broken build as well ;-) and >>>>>> thankfully abstractj put in a PR to have a temporary fix for the build >>>>>> failure: >>>>>> https://github.com/aerogear/aerogear-unifiedpush-server/pull/293 >>>>>> >>>>>> Thanks Bruno! >>>>>> >>>>>> Yesterday Bruno, Villiam and Luke looked at this already, and they >>>>>> noticed a failure like this: >>>>>> >>>>>> [INFO] --- frontend-maven-plugin:0.0.15:npm (npm install) @ unifiedpush-server --- >>>>>> [INFO] Running 'npm install --color=false' in /home/travis/build/aerogear/aerogear-unifiedpush-server/admin-ui >>>>>> [INFO] npm WARN package.json newadmin at 0.0.0 No repository field. >>>>>> [INFO] >>>>>> [INFO] --- frontend-maven-plugin:0.0.15:grunt (grunt build) @ unifiedpush-server --- >>>>>> [INFO] Running 'grunt dist --no-color' in /home/travis/build/aerogear/aerogear-unifiedpush-server/admin-ui >>>>>> [INFO] >> Local Npm module "grunt-cli" not found. Is it installed? >>>>>> [INFO] >>>>>> [INFO] Running "bower:install" (bower) task >>>>>> [INFO] Fatal error: Arguments to path.join must be strings >>>>>> [INFO] ------------------------------------------------------------------------ >>>>>> [INFO] Reactor Summary: >>>>>> >>>>>> Note: "grunt-cli" *IS* installed, even globally. If I am correct, at >>>>>> the moment we are not 100% sure what the "Fatal error: Arguments to >>>>>> path.join must be strings" really means... >>>>>> >>>>>> On my machine, I noticed the npm stuff downloads half of the >>>>>> internet, but gets stuck in the middle: >>>>>> >>>>>> [INFO] npm http 304 https://registry.npmjs.org/oauth-sign >>>>>> [INFO] npm http 304 https://registry.npmjs.org/aws-sign2 >>>>>> [INFO] npm http 304 https://registry.npmjs.org/hawk >>>>>> [INFO] npm http GET https://registry.npmjs.org/combined-stream >>>>>> [INFO] npm http GET https://registry.npmjs.org/async >>>>>> [INFO] npm http GET https://registry.npmjs.org/assert-plus >>>>>> [INFO] npm http GET https://registry.npmjs.org/asn1 >>>>>> [INFO] npm http GET https://registry.npmjs.org/ctype >>>>>> [INFO] npm http GET https://registry.npmjs.org/punycode >>>>>> [INFO] npm http GET https://registry.npmjs.org/hoek >>>>>> [INFO] npm http GET https://registry.npmjs.org/boom >>>>>> [INFO] npm http GET https://registry.npmjs.org/sntp >>>>>> [INFO] npm http GET https://registry.npmjs.org/cryptiles >>>>>> [INFO] npm http 304 https://registry.npmjs.org/async >>>>>> [INFO] npm http 304 https://registry.npmjs.org/combined-stream >>>>>> [INFO] npm http 304 https://registry.npmjs.org/assert-plus >>>>>> [INFO] npm http 304 https://registry.npmjs.org/asn1 >>>>>> [INFO] npm http GET https://registry.npmjs.org/delayed-stream >>>>>> [INFO] npm http 304 https://registry.npmjs.org/ctype >>>>>> [INFO] npm http 304 https://registry.npmjs.org/punycode >>>>>> [INFO] npm http 304 https://registry.npmjs.org/boom >>>>>> [INFO] npm http 304 https://registry.npmjs.org/hoek >>>>>> [INFO] npm http 304 https://registry.npmjs.org/cryptiles >>>>>> [INFO] npm http 304 https://registry.npmjs.org/sntp >>>>>> [INFO] npm http 304 https://registry.npmjs.org/delayed-stream >>>>>> >>>>>> Now, after more than one hour of 'waiting', I cancled the build, >>>>>> resulting in: >>>>>> >>>>>> [INFO] > optipng-bin at 0.3.9 postinstall /Users/matzew/Work/JBoss/UPS/admin-ui/node_modules/grunt-contrib-imagemin/node_modules/imagemin/node_modules/imagemin-optipng/node_modules/optipng-bin >>>>>> [INFO] > node index.js >>>>>> [INFO] >>>>>> [INFO] ? pre-build test passed successfully >>>>>> [INFO] npm http 304 https://registry.npmjs.org/hoek >>>>>> [INFO] npm http 304 https://registry.npmjs.org/boom >>>>>> [INFO] npm http 304 https://registry.npmjs.org/cryptiles >>>>>> [INFO] npm http 304 https://registry.npmjs.org/sntp >>>>>> [INFO] npm http 304 https://registry.npmjs.org/delayed-stream >>>>>> ^C[INFO] ------------------------------------------------------------------------ >>>>>> [INFO] Reactor Summary: >>>>>> [INFO] >>>>>> [INFO] AeroGear UnifiedPush Server ....................... SUCCESS [3.884s] >>>>>> [INFO] UnifiedPush Model Layer ........................... SUCCESS [0.146s] >>>>>> [INFO] UnifiedPush Server Model API ...................... SUCCESS [2.699s] >>>>>> [INFO] UnifiedPush Server Model JPA implementation ....... SUCCESS [15.036s] >>>>>> [INFO] UnifiedPush Service Layer ......................... SUCCESS [7.757s] >>>>>> [INFO] UnifiedPush Push Notification Networks ............ SUCCESS [2.009s] >>>>>> [INFO] UnifiedPush RESTful Endpoint ...................... SUCCESS [2.811s] >>>>>> [INFO] UnifiedPush Server (WAR) .......................... FAILURE [1:30:54.769s] >>>>>> [INFO] UnifiedPush Auth Server ........................... SKIPPED >>>>>> [INFO] ------------------------------------------------------------------------ >>>>>> [INFO] BUILD FAILURE >>>>>> [INFO] ------------------------------------------------------------------------ >>>>>> [INFO] Total time: 1:31:29.994s >>>>>> [INFO] Finished at: Tue Jul 15 07:48:37 CEST 2014 >>>>>> [INFO] Final Memory: 80M/191M >>>>>> [INFO] ------------------------------------------------------------------------ >>>>>> [ERROR] Failed to execute goal com.github.eirslett:frontend-maven-plugin:0.0.15:npm (npm install) on project unifiedpush-server: 'npm install --color=false' failed. (error code 130) -> [Help 1] >>>>>> [ERROR] >>>>>> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch. >>>>>> [ERROR] Re-run Maven using the -X switch to enable full debug logging. >>>>>> [ERROR] >>>>>> [ERROR] For more information about the errors and possible solutions, please read the following articles: >>>>>> [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException >>>>>> [ERROR] >>>>>> [ERROR] After correcting the problems, you can resume the build with the command >>>>>> [ERROR] mvn -rf :unifiedpush-server >>>>>> >>>>>> This is more a FYI on what's going on - I will file a JIRA ticket for >>>>>> that; >>>>>> >>>>>> *PS:* According to yesterday's IRC discussions, a manual `grunt >>>>>> server does work, so development is not*directly* effected >>>>>> >>>>>> -Matthias >>>>>> >>>>>> -- >>>>>> Matthias Wessendorf >>>>>> >>>>>> blog: http://matthiaswessendorf.wordpress.com/ >>>>>> sessions: http://www.slideshare.net/mwessendorf >>>>>> twitter: http://twitter.com/mwessendorf >>>>>> >>>>>> _______________________________________________ >>>>>> aerogear-dev mailing list >>>>>> aerogear-dev at lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> aerogear-dev mailing list >>>>> aerogear-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>> >>>> >>>> >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> >>> >>> >> >> -- >> Sent from Gmail Mobile >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140715/c54bd666/attachment-0001.html From edewit at redhat.com Tue Jul 15 02:23:04 2014 From: edewit at redhat.com (Erik Jan de Wit) Date: Tue, 15 Jul 2014 08:23:04 +0200 Subject: [aerogear-dev] AeroGear Cordova Push Plugin: Device Token before registry In-Reply-To: <53C3C5E1.70904@bliphead.com> References: <53C3C5E1.70904@bliphead.com> Message-ID: If you still want to look at the source code of the included jar you can find that at: https://github.com/aerogear/aerogear-android-push On 14 Jul,2014, at 13:58 , Chau Thai wrote: > Dear AeroGear developers, > > I'm building a geo based push system and want to use the device token as > the alias in the registration process. > I noticed there is no way to get the device token with the AeroGear > Cordova Push Plugin before you send the registration request to the server. > I'm hacking into the Android Plugin at the moment and would be very glad > if you could give me some hints to get the device token, since the libs > are all in jars... > > Thanks > > Chau/Cydmax > > -- > Chau Thai > > BLIPhead GmbH > Paradiesstr. 9 > 80538 M?nchen > > Tel +49 89 21111069 > Fax +49 89 21111061 > Mobil +49 176 70660664 > > chau at bliphead.com > www.spreya.com > > Gesch?ftsf?hrer: Michael M?hlberger > Amtsgericht M?nchen, HRB 190699 > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140715/e9726f39/attachment.html From lholmqui at redhat.com Mon Jul 14 09:52:16 2014 From: lholmqui at redhat.com (Lucas Holmquist) Date: Mon, 14 Jul 2014 09:52:16 -0400 Subject: [aerogear-dev] Differences between Firefox OS "native" Push lib and AeroGear's Push adapter In-Reply-To: References: <9B70BDB9-4774-4BF0-9FF7-5213185E4F52@redhat.com> <51C9D854-0730-4B2A-9A92-9DC92649947D@redhat.com> <8AEB32A5-0F61-495B-8EA5-767F48312B9C@redhat.com> <3B256910-96B3-4F55-8456-D890F4B37B2B! @redhat.com> Message-ID: <28EA872A-87E3-4035-9C63-DA04EF034580@redhat.com> On Jul 11, 2014, at 6:33 AM, Matthias Wessendorf wrote: > Hey Luke, > > I created this JIRA: > https://issues.jboss.org/browse/AGPUSH-802 > > As I plan working on AGPUSH-532 next week, to make sure we have the 'right' model in place for 1.0.0. I think once the server bits are merged, we should address AGPUSH-802 kk > > -Matthias > > > On Thu, Apr 10, 2014 at 5:22 PM, Lucas Holmquist wrote: > so after testing this thing out with encodeURIComponent, the delete does work, however, we need to "double up" the encode. > > this works: > > https://gist.github.com/lholmquist/10393357 > > > this doesn't: > > https://gist.github.com/lholmquist/10393450 > > > > On Apr 7, 2014, at 2:09 PM, Lucas Holmquist wrote: > >> >> On Apr 7, 2014, at 12:52 PM, Matthias Wessendorf wrote: >> >>> Ok, >>> >>> So as token, we use the endpointURL, and on client we perform the encodeURIComponent() function ? >> >> i think so( as suggested 2 months ago :) ) i just need to see how this will affect how we store stuff in LS. >> >> >> >>> >>> -Matthias >>> >>> On Monday, April 7, 2014, Lucas Holmquist wrote: >>> so i went back to look at what i had, >>> >>> >>> i don't think we need to get to complicated here, >>> >>> reading the spec stuff, and this example >>> >>> https://wiki.mozilla.org/WebAPI/SimplePush#Client_.28WebApp.29_code >>> >>> they show sending the pushEndpoint to the "App server", so i think we could just use and keep it simple >>> >>> it is also recommended that the channelID is never exposed to the application. >>> >>> >>> On Apr 1, 2014, at 3:34 PM, Lucas Holmquist wrote: >>> >>>> i had something, now i forgot what it was, need to go back and check >>>> On Apr 1, 2014, at 3:05 PM, Matthias Wessendorf wrote: >>>> >>>>> >>>>> On Fri, Feb 14, 2014 at 2:06 PM, Lucas Holmquist wrote: >>>>> still exploring >>>>> >>>>> :-) any recent thoughts on 'encodeURIComponent()' ? >>>>> >>>>> >>>>> On Feb 13, 2014, at 3:39 PM, Sebastien Blanc wrote: >>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Wed, Feb 12, 2014 at 2:30 PM, Lucas Holmquist wrote: >>>>>> i might have a couple thoughts, but i need to try some things out first >>>>>> >>>>>> Any update on that or does the solution proposed by Matzew (using encodeURIComponent() ) could be enough ? >>>>>> >>>>>> On Feb 12, 2014, at 3:53 AM, Sebastien Blanc wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Tue, Feb 11, 2014 at 7:15 PM, Sebastien Blanc wrote: >>>>>>> Ok, >>>>>>> I've been doing some tests by using the PushEndpoint as device token. For registration it works but I just faced an issue by trying to unregister because the URL for the DELETE looks like : >>>>>>> >>>>>>> https://judconpush-sblanc.rhcloud.com/rest/registry/device/https://updates.push.services.mozilla.com/update/my_personnal_psuhendpoint_id [ >>>>>>> >>>>>>> And the REST endpoint get a bit crazy by the extra "/" present in the endpoint URL. Therefore, I think we must just use the last URL fragment as deviceToken. >>>>>>> >>>>>>> Ok answering to myself ;) That won't work neither since if we do that UPS won't have the compllete push endpoint URL. >>>>>>> So how do we deal with that ? >>>>>>> >>>>>>> >>>>>>> On Thu, Feb 6, 2014 at 3:27 PM, Matthias Wessendorf wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Thu, Feb 6, 2014 at 3:11 PM, Sebastien Blanc >>> >>> >>> -- >>> Sent from Gmail Mobile >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140714/75f52472/attachment.html From supittma at redhat.com Mon Jul 14 09:55:41 2014 From: supittma at redhat.com (Summers Pittman) Date: Mon, 14 Jul 2014 09:55:41 -0400 Subject: [aerogear-dev] News from iOS Modules front In-Reply-To: <78957F0D-27BC-49B8-9F47-5905FA3F55A7@gmail.com> References: <78957F0D-27BC-49B8-9F47-5905FA3F55A7@gmail.com> Message-ID: <53C3E15D.10808@redhat.com> On 07/11/2014 05:20 PM, Corinne Krych wrote: > Hello Guys, > > Last Tuesday during our (favourite) iOS meeting [1] [2] we talked about modularization. We agreed with Android team modularization is scheduled for 2.0. > > For iOS we have several actions: > > 1. rename existing repos (too bad we don?t follow well Android convention) > ? aerogear-ios-crypto > ? aerogear-ios-push (thanks passos for the suggestion) > ? aerogear-ios-otp > ? aerogear-ios-xcode-template > ? aerogear-ios-cookbook > > Since we?re talking about renaming, what about dropping ?arerogear? for the repo name? all those repos belong to aerogear organization anyway. Maybe removing the aerogear part will stress more the small libraries aspect. Maybe sth we already discussed but can?t remember/find it. wdyt? Less typing, looks better in my bom/gradle/whatever, +1 > > 2. Pipe and Store deprecated. All aerogear-ios we?ll stick to 1.7 version and will be marked deprecated. > But ?. don?t be scared new modules will replace them: > > ? aerogear-ios-http : Lightweight lib around NSURLSession to ease HTTP calls with pluggable request and response Serializers. Very very Draft version [3] with some cookbook recipe [4]. With this module we will work directly with NSURLSession (iOS foundation networking) instead of using AFNetworking. Sure Andrea will like it: no dependency :) > ? aerogear-ios-oauth2 : dependent on aerogear-ios-http, bring all the good stuff like AccountManager, OAuth2 extensible adapters, fluid http post/get ... > ? aerogear-ios-storage usage of incrementalStorage to plug into Core Data Yeah I'm not sure if Android will drop Pipe and Store, I personally use them a lot. But I understand that on other platforms they are much simpler. > > Those modules will be written in Swift code. We?ll test them both in iOS7 and iOS8. > > 3. Cookbook recipes rpo > ? tag our repo 1.7: we didn?t have a tag strategy for cookbook demos but with the move from 1.X to 2.) I think we should > * Swift demo naming convention add ?-swift? for Swift version like we did [5]. We should also append ?-objc? to other recipes to be consistent. > > 4. Differentiate Swift vs Objective-C libs > How to differenctiate Swift code. Specially for aerogear-ios-push which will be declined in 2 versions? One suggestion from Matthias was to have 2 separate branches. > master -> objc-c > until iOS8 is released and stable. > I?m +1 with that idea. Sounds like a good plan. I don't know if naming '-swift' or '-objc' is necessary if they are cross compatible, but I'm not that passionate either way. > > Let me know if you have suggestions/objections. When we reach an agreement, I?ll create associated JIRA. > > ++ > Corinne > > [1] http://oksoclap.com/p/aerogear_ios_meeting_01072014 > [2] http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2014/aerogear.2014-07-08-11.42.txt > [3] https://github.com/corinnekrych/aerogear-ios-http > [4] https://github.com/corinnekrych/Weather > [5] https://github.com/aerogear/aerogear-push-helloworld/tree/master/ios-swift > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -- Summers Pittman >>Phone:404 941 4698 >>Java is my crack. From matzew at apache.org Tue Jul 15 06:15:05 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Tue, 15 Jul 2014 12:15:05 +0200 Subject: [aerogear-dev] broken build (master and 0.11.0 tag) In-Reply-To: References: Message-ID: Awesome, thsnks! On Tuesday, July 15, 2014, Sebastien Blanc wrote: > FYI : I merged my fix and master is building again :) > > > > On Tue, Jul 15, 2014 at 9:29 AM, Sebastien Blanc > wrote: > >> Ok, >> Some extra info : >> As suggested I tried to update Bower to 1.3.8 : >> - >> https://github.com/aerogear/aerogear-unifiedpush-server/commit/87dadc04ab2c0bfbb482706ecba5ab55d04ae30c >> But that did not helped , maybe the maven frontend pugin overides the >> Bower version, looking at this now >> >> BUT, on twitter someone suggested this : >> https://twitter.com/chrisfrancis27/status/488701380207448064 >> >> Basically adding a "temp" dependencies to package.json , o_0 => indeed >> but it WORKS : >> >> https://travis-ci.org/aerogear/aerogear-unifiedpush-server/builds/29953927 >> ! >> >> So good news , with this "temp" dep we can build again and in the same >> time let's find out how we can update bower >> >> >> On Tue, Jul 15, 2014 at 9:21 AM, Matthias Wessendorf > > wrote: >> >>> >>> >>> On Tuesday, July 15, 2014, tolis emmanouilidis >> > wrote: >>> >>>> +1 Sebi >>>> >>>> The builds started failing 3 days ago. 3 days ago bower ( >>>> https://www.npmjs.org/package/bower) was updated to v1.3.8. >>>> >>>> The last successful Travis UPS build logs contains bower at 1.3.7 >>>> node_modules/bower. >>>> The rest failed successful Travis UPS build logs contain bower at 1.3.8 >>>> node_modules/bower >>>> >>>> Maybe enforcing bower version 1.3.7 will resolve the issue. >>>> >>> >>> >>> +9001 >>> We should lock all versions :-) >>> >>> >>>> >>>> >>>> 2014-07-15 9:50 GMT+03:00 Sebastien Blanc : >>>> >>>>> Looks like Bower is aware of this issue : >>>>> https://twitter.com/bower/status/487704111832252417 >>>>> Let me check if I can do something >>>>> >>>>> >>>>> >>>>> On Tue, Jul 15, 2014 at 8:34 AM, Christos Vasilakis < >>>>> cvasilak at gmail.com> wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> the same failure output "[INFO] Fatal error: Arguments to path.join >>>>>> must be strings" have been noticed also when building liveoak >>>>>> 'master'. I suspect some change on the nodes tools broke builds.. :( >>>>>> >>>>>> >>>>>> [1] https://projectodd.ci.cloudbees.com/job/liveoak/371/console >>>>>> >>>>>> >>>>>> >>>>>> On Tue, Jul 15, 2014 at 9:07 AM, Matthias Wessendorf < >>>>>> matzew at apache.org> wrote: >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> since Friday, all in a sudden, the node.js part of the build >>>>>>> (triggered by the frontend plugin inside the 'server' module) is failing on >>>>>>> different ways. >>>>>>> >>>>>>> Extremely odd: the 0.11.0 tag is effected as well. The release (on >>>>>>> maven central) is good, but ATM we are not able to build the source on the >>>>>>> 0.11.0 tag :-( >>>>>>> >>>>>>> Oh, yeah, Travis-CI notice the broken build as well ;-) and >>>>>>> thankfully abstractj put in a PR to have a temporary fix for the build >>>>>>> failure: >>>>>>> https://github.com/aerogear/aerogear-unifiedpush-server/pull/293 >>>>>>> >>>>>>> Thanks Bruno! >>>>>>> >>>>>>> Yesterday Bruno, Villiam and Luke looked at this already, and they >>>>>>> noticed a failure like this: >>>>>>> >>>>>>> [INFO] --- frontend-maven-plugin:0.0.15:npm (npm install) @ unifiedpush-server --- >>>>>>> [INFO] Running 'npm install --color=false' in /home/travis/build/aerogear/aerogear-unifiedpush-server/admin-ui >>>>>>> [INFO] npm WARN package.json newadmin at 0.0.0 No repository field. >>>>>>> [INFO] >>>>>>> [INFO] --- frontend-maven-plugin:0.0.15:grunt (grunt build) @ unifiedpush-server --- >>>>>>> [INFO] Running 'grunt dist --no-color' in /home/travis/build/aerogear/aerogear-unifiedpush-server/admin-ui >>>>>>> [INFO] >> Local Npm module "grunt-cli" not found. Is it installed? >>>>>>> [INFO] >>>>>>> [INFO] Running "bower:install" (bower) task >>>>>>> [INFO] Fatal error: Arguments to path.join must be strings >>>>>>> [INFO] ------------------------------------------------------------------------ >>>>>>> [INFO] Reactor Summary: >>>>>>> >>>>>>> Note: "grunt-cli" *IS* installed, even globally. If I am correct, >>>>>>> at the moment we are not 100% sure what the "Fatal error: Arguments to >>>>>>> path.join must be strings" really means... >>>>>>> >>>>>>> On my machine, I noticed the npm stuff downloads half of the >>>>>>> internet, but gets stuck in the middle: >>>>>>> >>>>>>> [INFO] npm http 304 https://registry.npmjs.org/oauth-sign >>>>>>> [INFO] npm http 304 https://registry.npmjs.org/aws-sign2 >>>>>>> [INFO] npm http 304 https://registry.npmjs.org/hawk >>>>>>> [INFO] npm http GET https://registry.npmjs.org/combined-stream >>>>>>> [INFO] npm http GET https://registry.npmjs.org/async >>>>>>> [INFO] npm http GET https://registry.npmjs.org/assert-plus >>>>>>> [INFO] npm http GET https://registry.npmjs.org/asn1 >>>>>>> [INFO] npm http GET https://registry.npmjs.org/ctype >>>>>>> [INFO] npm http GET https://registry.npmjs.org/punycode >>>>>>> [INFO] npm http GET https://registry.npmjs.org/hoek >>>>>>> [INFO] npm http GET https://registry.npmjs.org/boom >>>>>>> [INFO] npm http GET https://registry.npmjs.org/sntp >>>>>>> [INFO] npm http GET https://registry.npmjs.org/cryptiles >>>>>>> [INFO] npm http 304 https://registry.npmjs.org/async >>>>>>> [INFO] npm http 304 https://registry.npmjs.org/combined-stream >>>>>>> [INFO] npm http 304 https://registry.npmjs.org/assert-plus >>>>>>> [INFO] npm http 304 https://registry.npmjs.org/asn1 >>>>>>> [INFO] npm http GET https://registry.npmjs.org/delayed-stream >>>>>>> [INFO] npm http 304 https://registry.npmjs.org/ctype >>>>>>> [INFO] npm http 304 https://registry.npmjs.org/punycode >>>>>>> [INFO] npm http 304 https://registry.npmjs.org/boom >>>>>>> [INFO] npm http 304 https://registry.npmjs.org/hoek >>>>>>> [INFO] npm http 304 https://registry.npmjs.org/cryptiles >>>>>>> [INFO] npm http 304 https://registry.npmjs.org/sntp >>>>>>> [INFO] npm http 304 https://registry.npmjs.org/delayed-stream >>>>>>> >>>>>>> Now, after more than one hour of 'waiting', I cancled the build, >>>>>>> resulting in: >>>>>>> >>>>>>> [INFO] > optipng-bin at 0.3.9 postinstall /Users/matzew/Work/JBoss/UPS/admin-ui/node_modules/grunt-contrib-imagemin/node_modules/imagemin/node_modules/imagemin-optipng/node_modules/optipng-bin >>>>>>> [INFO] > node index.js >>>>>>> [INFO] >>>>>>> [INFO] ? pre-build test passed successfully >>>>>>> [INFO] npm http 304 https://registry.npmjs.org/hoek >>>>>>> [INFO] npm http 304 https://registry.npmjs.org/boom >>>>>>> [INFO] npm http 304 https://registry.npmjs.org/cryptiles >>>>>>> [INFO] npm http 304 https://registry.npmjs.org/sntp >>>>>>> [INFO] npm http 304 https://registry.npmjs.org/delayed-stream >>>>>>> ^C[INFO] ------------------------------------------------------------------------ >>>>>>> [INFO] Reactor Summary: >>>>>>> [INFO] >>>>>>> [INFO] AeroGear UnifiedPush Server ....................... SUCCESS [3.884s] >>>>>>> [INFO] UnifiedPush Model Layer ........................... SUCCESS [0.146s] >>>>>>> [INFO] UnifiedPush Server Model API ...................... SUCCESS [2.699s] >>>>>>> [INFO] UnifiedPush Server Model JPA implementation ....... SUCCESS [15.036s] >>>>>>> [INFO] UnifiedPush Service Layer ......................... SUCCESS [7.757s] >>>>>>> [INFO] UnifiedPush Push Notification Networks ............ SUCCESS [2.009s] >>>>>>> [INFO] UnifiedPush RESTful Endpoint ...................... SUCCESS [2.811s] >>>>>>> [INFO] UnifiedPush Server (WAR) .......................... FAILURE [1:30:54.769s] >>>>>>> [INFO] UnifiedPush Auth Server ........................... SKIPPED >>>>>>> [INFO] ------------------------------------------------------------------------ >>>>>>> [INFO] BUILD FAILURE >>>>>>> [INFO] ------------------------------------------------------------------------ >>>>>>> [INFO] Total time: 1:31:29.994s >>>>>>> [INFO] Finished at: Tue Jul 15 07:48:37 CEST 2014 >>>>>>> [INFO] Final Memory: 80M/191M >>>>>>> [INFO] ------------------------------------------------------------------------ >>>>>>> [ERROR] Failed to execute goal com.github.eirslett:frontend-maven-plugin:0.0.15:npm (npm install) on project unifiedpush-server: 'npm install --color=false' failed. (error code 130) -> [Help 1] >>>>>>> [ERROR] >>>>>>> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch. >>>>>>> [ERROR] Re-run Maven using the -X switch to enable full debug logging. >>>>>>> [ERROR] >>>>>>> [ERROR] For more information about the errors and possible solutions, please read the following articles: >>>>>>> [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException >>>>>>> [ERROR] >>>>>>> [ERROR] After correcting the problems, you can resume the build with the command >>>>>>> [ERROR] mvn -rf :unifiedpush-server >>>>>>> >>>>>>> This is more a FYI on what's going on - I will file a JIRA ticket >>>>>>> for that; >>>>>>> >>>>>>> *PS:* According to yesterday's IRC discussions, a manual `grunt >>>>>>> server does work, so development is not*directly* effected >>>>>>> >>>>>>> -Matthias >>>>>>> >>>>>>> -- >>>>>>> Matthias Wessendorf >>>>>>> >>>>>>> blog: http://matthiaswessendorf.wordpress.com/ >>>>>>> sessions: http://www.slideshare.net/mwessendorf >>>>>>> twitter: http://twitter.com/mwessendorf >>>>>>> >>>>>>> _______________________________________________ >>>>>>> aerogear-dev mailing list >>>>>>> aerogear-dev at lists.jboss.org >>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> aerogear-dev mailing list >>>>>> aerogear-dev at lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> aerogear-dev mailing list >>>>> aerogear-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>> >>>> >>>> >>> >>> -- >>> Sent from Gmail Mobile >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >> >> > -- Sent from Gmail Mobile -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140715/9149f243/attachment-0001.html From edewit at redhat.com Tue Jul 15 08:40:19 2014 From: edewit at redhat.com (Erik Jan de Wit) Date: Tue, 15 Jul 2014 14:40:19 +0200 Subject: [aerogear-dev] UPS Production worthiness In-Reply-To: References: <002b01cf7424$528dc0a0$f7a941e0$@pinelabs.com> <005d01cf74ed$3d977140$b8c653c0$@pinelabs.com> <003c01cf78cd$1095df40$31c19dc0$@pinelabs.com> <17C1B903-C13B-482F-93FA-1B9B55AEF707@redhat.com> <008f01cf9603$9cf11fb0$d6d35f10$@pinelabs.com> <008701cf9aa5$09290bc0$1b7b2340$@pinelabs.com> Message-ID: <3414709C-0914-41D6-93D0-44D372B85322@redhat.com> Hi Vivek, We?ve taken your patch and updated it a bit with the things you had as TODO. Could you have a look at our latest master to double check that all your issues have been solved? Thanks again for contributing, Cheers, Erik Jan On 11 Jul,2014, at 16:34 , Matthias Wessendorf wrote: > Hello Vivek, > > I pasted the patch to this gist: > https://gist.github.com/matzew/95471393bc2a485fce10 > > since not all team members were able to open the attachment. > > Thanks again for sharing > > -Matthias > > > On Tue, Jul 8, 2014 at 3:13 PM, Matthias Wessendorf wrote: > Hello Vivek! > > thanks a lot for the patch! We will take a look at that for sure! The benefit of getting a PR out is that you are actually captured inside of the GH as an official contributor :-) > > But thanks again, very happy to see your patch ! > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140715/4204874f/attachment.html From vivek.pandey at pinelabs.com Wed Jul 16 04:45:18 2014 From: vivek.pandey at pinelabs.com (Vivek Pandey) Date: Wed, 16 Jul 2014 14:15:18 +0530 Subject: [aerogear-dev] UPS Production worthiness In-Reply-To: <3414709C-0914-41D6-93D0-44D372B85322@redhat.com> References: <002b01cf7424$528dc0a0$f7a941e0$@pinelabs.com> <005d01cf74ed$3d977140$b8c653c0$@pinelabs.com> <003c01cf78cd$1095df40$31c19dc0$@pinelabs.com> <17C1B903-C13B-482F-93FA-1B9B55AEF707@redhat.com> <008f01cf9603$9cf11fb0$d6d35f10$@pinelabs.com> <008701cf9aa5$09290bc0$1b7b2340$@pinelabs.com> <3414709C-0914-41D6-93D0-44D372B85322@redhat.com> Message-ID: <002b01cfa0d2$45c21f80$d1465e80$@pinelabs.com> Thanks Erik, I will build master sometime this week or early next week and let you know. From: Erik Jan de Wit [mailto:edewit at redhat.com] Sent: Tuesday, July 15, 2014 6:10 PM To: AeroGear Developer Mailing List Cc: vivek.pandey at pinelabs.com Subject: Re: [aerogear-dev] UPS Production worthiness Hi Vivek, We've taken your patch and updated it a bit with the things you had as TODO. Could you have a look at our latest master to double check that all your issues have been solved? Thanks again for contributing, Cheers, Erik Jan On 11 Jul,2014, at 16:34 , Matthias Wessendorf wrote: Hello Vivek, I pasted the patch to this gist: https://gist.github.com/matzew/95471393bc2a485fce10 since not all team members were able to open the attachment. Thanks again for sharing -Matthias On Tue, Jul 8, 2014 at 3:13 PM, Matthias Wessendorf wrote: Hello Vivek! thanks a lot for the patch! We will take a look at that for sure! The benefit of getting a PR out is that you are actually captured inside of the GH as an official contributor :-) But thanks again, very happy to see your patch ! This message may contain privileged and confidential information and is solely for the use of intended recipient. The views expressed in this email are those of the sender and not of Pine Labs. The recipient should check this email and attachments for the presence of viruses / malwares etc. Pine Labs accepts no liability for any damage caused by any virus transmitted by this email. Pine Labs may monitor and record all emails. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140716/1a1a2a72/attachment.html From supittma at redhat.com Wed Jul 16 10:27:48 2014 From: supittma at redhat.com (Summers Pittman) Date: Wed, 16 Jul 2014 10:27:48 -0400 Subject: [aerogear-dev] Use Case: Geo Location Pushes In-Reply-To: <53C40568.4090003@bliphead.com> References: <53C40568.4090003@bliphead.com> Message-ID: <53C68BE4.2040306@redhat.com> On 07/14/2014 12:29 PM, Chau Thai wrote: > Hello dear developers, > > We would like to build a push service triggered by the location of > users. We have build a service with which users can save notes on a map. > To inform other users of the creation of the note, we want to send all > users in a given radius a push notification. > The relevance of his current location is very important to fullfil this > scenario. > It would really help us if you could implement a feature to save the > current geo location of the user via the existing register method. > > Thanks in advance > Chau/Cydmax > This is a great idea and is in out thought sphere. As matzew said, we will probably be updating roadmaps and Jiras to include this after we hit 1.0.0. I believe Google has pretty good Push geo-fencing APIs for Google Play Services for Android. One of the first hurdles to overcome will be how we make a good Open Source product without having to be so tightly attached to Google's proprietary blobs. Heck we are even still working on that with Push in general... -- Summers Pittman >>Phone:404 941 4698 >>Java is my crack. From supittma at redhat.com Wed Jul 16 10:31:04 2014 From: supittma at redhat.com (Summers Pittman) Date: Wed, 16 Jul 2014 10:31:04 -0400 Subject: [aerogear-dev] Aerogear Feature Request - Auto Increment Badge In-Reply-To: References: <1405357130449-8396.post@n5.nabble.com> Message-ID: <53C68CA8.3090808@redhat.com> On Mon 14 Jul 2014 01:27:09 PM EDT, Matthias Wessendorf wrote: > On Android that concept really is not there, as far as I know; Correct. GCM does have allowances for grouping push messages but that isn't quite the same thing as Badges. From what I understand, badges are a hack in iOS to get around the lack of a proper Notification System before version 5. In Android to get similar behavior the user would have to install a widget on their launcher which looked like the icon for the app but updated with the number of notifications. It is my advised opinion that the notification shade should be used instead. > > Natvie iOS this is what you get for free, when badge reaches the app. > > In Cordova-iOS this should be the same! > > Greetings! > Matthias > > On Monday, July 14, 2014, keithdmoore94 > wrote: > > I noticed some of the other push server providers offer the > ability to keep > track of the badge and increment it as a new notification comes > in. Maybe > the client could set the badge to "increment" or "+1", etc. The > Aerogear > Unified Push Server would then increment the badge and send the > notification. > > Any thoughts ? > > > > > > -- > View this message in context: > http://aerogear-dev.1069024.n5.nabble.com/Aerogear-Feature-Request-Auto-Increment-Badge-tp8396.html > Sent from the aerogear-dev mailing list archive at Nabble.com. > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > -- > Sent from Gmail Mobile > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -- Summers Pittman >>Phone:404 941 4698 >>Java is my crack. From supittma at redhat.com Wed Jul 16 10:39:38 2014 From: supittma at redhat.com (Summers Pittman) Date: Wed, 16 Jul 2014 10:39:38 -0400 Subject: [aerogear-dev] Android Registrations Message-ID: <53C68EAA.3070909@redhat.com> We've mentioned moving from the factory/producer/headache pattern that we currently use (Pipeline, etc) to something more fluent and more maintainable. See this JIRA : https://issues.jboss.org/browse/AGDROID-259 To that end I've stubbed out some classes and made a strawman set of unit tests for Pipeline : https://gist.github.com/secondsun/8478a5f0527fc97b2456 In the comments of some of the tests I've added questions for the implementation portion of Registrations. The ultimate goal is to make the factories and feature classes(Pipe, AuthModule, etc) flexible enough that circular dependencies can be broken and 1) modularization can happen and 2) feature additions can be quicker and change fewer stable APIs. Comments, questions, and tomatoes are welcome. -- Summers Pittman >>Phone:404 941 4698 >>Java is my crack. From bruno at abstractj.org Wed Jul 16 11:32:25 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Wed, 16 Jul 2014 12:32:25 -0300 Subject: [aerogear-dev] broken build (master and 0.11.0 tag) In-Reply-To: References: Message-ID: <20140716153225.GA58871@abstractj.org> Thanks for the fix Sebi, it took me 1 day trying to figure this out. IMO would be nice to take some action on this, otherwise the build is fixed until the next bower update. 1. Lock the versions like Matthias suggested 2. Or, do not break the build only because the admin-ui can't be installed. The option 1 would be nice, but I can't understand why we need to build the admin-ui on CI if we don't have any tests on it, is pretty much npm install + bower install and grunt tasks copying files. Thoughts? On 2014-07-15, Sebastien Blanc wrote: > Ok, > Some extra info : > As suggested I tried to update Bower to 1.3.8 : > - > https://github.com/aerogear/aerogear-unifiedpush-server/commit/87dadc04ab2c0bfbb482706ecba5ab55d04ae30c > But that did not helped , maybe the maven frontend pugin overides the Bower > version, looking at this now > > BUT, on twitter someone suggested this : > https://twitter.com/chrisfrancis27/status/488701380207448064 > > Basically adding a "temp" dependencies to package.json , o_0 => indeed but > it WORKS : > > https://travis-ci.org/aerogear/aerogear-unifiedpush-server/builds/29953927 > ! > > So good news , with this "temp" dep we can build again and in the same time > let's find out how we can update bower > > > On Tue, Jul 15, 2014 at 9:21 AM, Matthias Wessendorf > wrote: > > > > > > > On Tuesday, July 15, 2014, tolis emmanouilidis wrote: > > > >> +1 Sebi > >> > >> The builds started failing 3 days ago. 3 days ago bower ( > >> https://www.npmjs.org/package/bower) was updated to v1.3.8. > >> > >> The last successful Travis UPS build logs contains bower at 1.3.7 > >> node_modules/bower. > >> The rest failed successful Travis UPS build logs contain bower at 1.3.8 > >> node_modules/bower > >> > >> Maybe enforcing bower version 1.3.7 will resolve the issue. > >> > > > > > > +9001 > > We should lock all versions :-) > > > > > >> > >> > >> 2014-07-15 9:50 GMT+03:00 Sebastien Blanc : > >> > >>> Looks like Bower is aware of this issue : > >>> https://twitter.com/bower/status/487704111832252417 > >>> Let me check if I can do something > >>> > >>> > >>> > >>> On Tue, Jul 15, 2014 at 8:34 AM, Christos Vasilakis > >>> wrote: > >>> > >>>> Hi, > >>>> > >>>> the same failure output "[INFO] Fatal error: Arguments to path.join > >>>> must be strings" have been noticed also when building liveoak > >>>> 'master'. I suspect some change on the nodes tools broke builds.. :( > >>>> > >>>> > >>>> [1] https://projectodd.ci.cloudbees.com/job/liveoak/371/console > >>>> > >>>> > >>>> > >>>> On Tue, Jul 15, 2014 at 9:07 AM, Matthias Wessendorf >>>> > wrote: > >>>> > >>>>> Hi, > >>>>> > >>>>> since Friday, all in a sudden, the node.js part of the build > >>>>> (triggered by the frontend plugin inside the 'server' module) is failing on > >>>>> different ways. > >>>>> > >>>>> Extremely odd: the 0.11.0 tag is effected as well. The release (on > >>>>> maven central) is good, but ATM we are not able to build the source on the > >>>>> 0.11.0 tag :-( > >>>>> > >>>>> Oh, yeah, Travis-CI notice the broken build as well ;-) and thankfully > >>>>> abstractj put in a PR to have a temporary fix for the build failure: > >>>>> https://github.com/aerogear/aerogear-unifiedpush-server/pull/293 > >>>>> > >>>>> Thanks Bruno! > >>>>> > >>>>> Yesterday Bruno, Villiam and Luke looked at this already, and they > >>>>> noticed a failure like this: > >>>>> > >>>>> [INFO] --- frontend-maven-plugin:0.0.15:npm (npm install) @ unifiedpush-server --- > >>>>> [INFO] Running 'npm install --color=false' in /home/travis/build/aerogear/aerogear-unifiedpush-server/admin-ui > >>>>> [INFO] npm WARN package.json newadmin at 0.0.0 No repository field. > >>>>> [INFO] > >>>>> [INFO] --- frontend-maven-plugin:0.0.15:grunt (grunt build) @ unifiedpush-server --- > >>>>> [INFO] Running 'grunt dist --no-color' in /home/travis/build/aerogear/aerogear-unifiedpush-server/admin-ui > >>>>> [INFO] >> Local Npm module "grunt-cli" not found. Is it installed? > >>>>> [INFO] > >>>>> [INFO] Running "bower:install" (bower) task > >>>>> [INFO] Fatal error: Arguments to path.join must be strings > >>>>> [INFO] ------------------------------------------------------------------------ > >>>>> [INFO] Reactor Summary: > >>>>> > >>>>> Note: "grunt-cli" *IS* installed, even globally. If I am correct, at > >>>>> the moment we are not 100% sure what the "Fatal error: Arguments to > >>>>> path.join must be strings" really means... > >>>>> > >>>>> On my machine, I noticed the npm stuff downloads half of the internet, > >>>>> but gets stuck in the middle: > >>>>> > >>>>> [INFO] npm http 304 https://registry.npmjs.org/oauth-sign > >>>>> [INFO] npm http 304 https://registry.npmjs.org/aws-sign2 > >>>>> [INFO] npm http 304 https://registry.npmjs.org/hawk > >>>>> [INFO] npm http GET https://registry.npmjs.org/combined-stream > >>>>> [INFO] npm http GET https://registry.npmjs.org/async > >>>>> [INFO] npm http GET https://registry.npmjs.org/assert-plus > >>>>> [INFO] npm http GET https://registry.npmjs.org/asn1 > >>>>> [INFO] npm http GET https://registry.npmjs.org/ctype > >>>>> [INFO] npm http GET https://registry.npmjs.org/punycode > >>>>> [INFO] npm http GET https://registry.npmjs.org/hoek > >>>>> [INFO] npm http GET https://registry.npmjs.org/boom > >>>>> [INFO] npm http GET https://registry.npmjs.org/sntp > >>>>> [INFO] npm http GET https://registry.npmjs.org/cryptiles > >>>>> [INFO] npm http 304 https://registry.npmjs.org/async > >>>>> [INFO] npm http 304 https://registry.npmjs.org/combined-stream > >>>>> [INFO] npm http 304 https://registry.npmjs.org/assert-plus > >>>>> [INFO] npm http 304 https://registry.npmjs.org/asn1 > >>>>> [INFO] npm http GET https://registry.npmjs.org/delayed-stream > >>>>> [INFO] npm http 304 https://registry.npmjs.org/ctype > >>>>> [INFO] npm http 304 https://registry.npmjs.org/punycode > >>>>> [INFO] npm http 304 https://registry.npmjs.org/boom > >>>>> [INFO] npm http 304 https://registry.npmjs.org/hoek > >>>>> [INFO] npm http 304 https://registry.npmjs.org/cryptiles > >>>>> [INFO] npm http 304 https://registry.npmjs.org/sntp > >>>>> [INFO] npm http 304 https://registry.npmjs.org/delayed-stream > >>>>> > >>>>> Now, after more than one hour of 'waiting', I cancled the build, > >>>>> resulting in: > >>>>> > >>>>> [INFO] > optipng-bin at 0.3.9 postinstall /Users/matzew/Work/JBoss/UPS/admin-ui/node_modules/grunt-contrib-imagemin/node_modules/imagemin/node_modules/imagemin-optipng/node_modules/optipng-bin > >>>>> [INFO] > node index.js > >>>>> [INFO] > >>>>> [INFO] ? pre-build test passed successfully > >>>>> [INFO] npm http 304 https://registry.npmjs.org/hoek > >>>>> [INFO] npm http 304 https://registry.npmjs.org/boom > >>>>> [INFO] npm http 304 https://registry.npmjs.org/cryptiles > >>>>> [INFO] npm http 304 https://registry.npmjs.org/sntp > >>>>> [INFO] npm http 304 https://registry.npmjs.org/delayed-stream > >>>>> ^C[INFO] ------------------------------------------------------------------------ > >>>>> [INFO] Reactor Summary: > >>>>> [INFO] > >>>>> [INFO] AeroGear UnifiedPush Server ....................... SUCCESS [3.884s] > >>>>> [INFO] UnifiedPush Model Layer ........................... SUCCESS [0.146s] > >>>>> [INFO] UnifiedPush Server Model API ...................... SUCCESS [2.699s] > >>>>> [INFO] UnifiedPush Server Model JPA implementation ....... SUCCESS [15.036s] > >>>>> [INFO] UnifiedPush Service Layer ......................... SUCCESS [7.757s] > >>>>> [INFO] UnifiedPush Push Notification Networks ............ SUCCESS [2.009s] > >>>>> [INFO] UnifiedPush RESTful Endpoint ...................... SUCCESS [2.811s] > >>>>> [INFO] UnifiedPush Server (WAR) .......................... FAILURE [1:30:54.769s] > >>>>> [INFO] UnifiedPush Auth Server ........................... SKIPPED > >>>>> [INFO] ------------------------------------------------------------------------ > >>>>> [INFO] BUILD FAILURE > >>>>> [INFO] ------------------------------------------------------------------------ > >>>>> [INFO] Total time: 1:31:29.994s > >>>>> [INFO] Finished at: Tue Jul 15 07:48:37 CEST 2014 > >>>>> [INFO] Final Memory: 80M/191M > >>>>> [INFO] ------------------------------------------------------------------------ > >>>>> [ERROR] Failed to execute goal com.github.eirslett:frontend-maven-plugin:0.0.15:npm (npm install) on project unifiedpush-server: 'npm install --color=false' failed. (error code 130) -> [Help 1] > >>>>> [ERROR] > >>>>> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch. > >>>>> [ERROR] Re-run Maven using the -X switch to enable full debug logging. > >>>>> [ERROR] > >>>>> [ERROR] For more information about the errors and possible solutions, please read the following articles: > >>>>> [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException > >>>>> [ERROR] > >>>>> [ERROR] After correcting the problems, you can resume the build with the command > >>>>> [ERROR] mvn -rf :unifiedpush-server > >>>>> > >>>>> This is more a FYI on what's going on - I will file a JIRA ticket for > >>>>> that; > >>>>> > >>>>> *PS:* According to yesterday's IRC discussions, a manual `grunt server does > >>>>> work, so development is not*directly* effected > >>>>> > >>>>> -Matthias > >>>>> > >>>>> -- > >>>>> Matthias Wessendorf > >>>>> > >>>>> blog: http://matthiaswessendorf.wordpress.com/ > >>>>> sessions: http://www.slideshare.net/mwessendorf > >>>>> twitter: http://twitter.com/mwessendorf > >>>>> > >>>>> _______________________________________________ > >>>>> aerogear-dev mailing list > >>>>> aerogear-dev at lists.jboss.org > >>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev > >>>>> > >>>> > >>>> > >>>> _______________________________________________ > >>>> aerogear-dev mailing list > >>>> aerogear-dev at lists.jboss.org > >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev > >>>> > >>> > >>> > >>> _______________________________________________ > >>> aerogear-dev mailing list > >>> aerogear-dev at lists.jboss.org > >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev > >>> > >> > >> > > > > -- > > Sent from Gmail Mobile > > > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -- abstractj From kpiwko at redhat.com Wed Jul 16 12:50:41 2014 From: kpiwko at redhat.com (Karel Piwko) Date: Wed, 16 Jul 2014 16:52:41 +0002 Subject: [aerogear-dev] broken build (master and 0.11.0 tag) In-Reply-To: <20140716153225.GA58871@abstractj.org> References: <20140716153225.GA58871@abstractj.org> Message-ID: <1405529441.32747.1@smtp.corp.redhat.com> I'm +1 on locking version as well. The very same issue is causing us pain in Jenkins CI. Wrt to not having any tests on admin-ui - QE needs to rewrite original Ember.js UI tests to Angular.js tests. These test will be located (instead of separate admin-ui repository) in aerogear-unifiedpush-server-integration-tests and we plan to execute them in travis as well, together with integration tests. We'll need to build Admin UI there for sure. Karel On Wed, Jul 16, 2014 at 5:32 PM, Bruno Oliveira wrote: > Thanks for the fix Sebi, it took me 1 day trying to figure this out. > IMO > would be nice to take some action on this, otherwise the build is > fixed > until the next bower update. > > 1. Lock the versions like Matthias suggested > 2. Or, do not break the build only because the admin-ui can't be > installed. > > The option 1 would be nice, but I can't understand why we need to > build > the admin-ui on CI if we don't have any tests on it, is pretty much > npm > install + bower install and grunt tasks copying files. > > Thoughts? > > On 2014-07-15, Sebastien Blanc wrote: >> Ok, >> Some extra info : >> As suggested I tried to update Bower to 1.3.8 : >> - >> >> https://github.com/aerogear/aerogear-unifiedpush-server/commit/87dadc04ab2c0bfbb482706ecba5ab55d04ae30c >> But that did not helped , maybe the maven frontend pugin overides >> the Bower >> version, looking at this now >> >> BUT, on twitter someone suggested this : >> https://twitter.com/chrisfrancis27/status/488701380207448064 >> >> Basically adding a "temp" dependencies to package.json , o_0 => >> indeed but >> it WORKS : >> >> >> https://travis-ci.org/aerogear/aerogear-unifiedpush-server/builds/29953927 >> ! >> >> So good news , with this "temp" dep we can build again and in the >> same time >> let's find out how we can update bower >> >> >> On Tue, Jul 15, 2014 at 9:21 AM, Matthias Wessendorf >> >> wrote: >> >> > >> > >> > On Tuesday, July 15, 2014, tolis emmanouilidis >> wrote: >> > >> >> +1 Sebi >> >> >> >> The builds started failing 3 days ago. 3 days ago bower ( >> >> https://www.npmjs.org/package/bower) was updated to v1.3.8. >> >> >> >> The last successful Travis UPS build logs contains bower at 1.3.7 >> >> node_modules/bower. >> >> The rest failed successful Travis UPS build logs contain >> bower at 1.3.8 >> >> node_modules/bower >> >> >> >> Maybe enforcing bower version 1.3.7 will resolve the issue. >> >> >> > >> > >> > +9001 >> > We should lock all versions :-) >> > >> > >> >> >> >> >> >> 2014-07-15 9:50 GMT+03:00 Sebastien Blanc : >> >> >> >>> Looks like Bower is aware of this issue : >> >>> https://twitter.com/bower/status/487704111832252417 >> >>> Let me check if I can do something >> >>> >> >>> >> >>> >> >>> On Tue, Jul 15, 2014 at 8:34 AM, Christos Vasilakis >> >> >>> wrote: >> >>> >> >>>> Hi, >> >>>> >> >>>> the same failure output "[INFO] Fatal error: Arguments to >> path.join >> >>>> must be strings" have been noticed also when building liveoak >> >>>> 'master'. I suspect some change on the nodes tools broke >> builds.. :( >> >>>> >> >>>> >> >>>> [1] https://projectodd.ci.cloudbees.com/job/liveoak/371/console >> >>>> >> >>>> >> >>>> >> >>>> On Tue, Jul 15, 2014 at 9:07 AM, Matthias Wessendorf >> > >>>> > wrote: >> >>>> >> >>>>> Hi, >> >>>>> >> >>>>> since Friday, all in a sudden, the node.js part of the build >> >>>>> (triggered by the frontend plugin inside the 'server' module) >> is failing on >> >>>>> different ways. >> >>>>> >> >>>>> Extremely odd: the 0.11.0 tag is effected as well. The >> release (on >> >>>>> maven central) is good, but ATM we are not able to build the >> source on the >> >>>>> 0.11.0 tag :-( >> >>>>> >> >>>>> Oh, yeah, Travis-CI notice the broken build as well ;-) and >> thankfully >> >>>>> abstractj put in a PR to have a temporary fix for the build >> failure: >> >>>>> >> https://github.com/aerogear/aerogear-unifiedpush-server/pull/293 >> >>>>> >> >>>>> Thanks Bruno! >> >>>>> >> >>>>> Yesterday Bruno, Villiam and Luke looked at this already, and >> they >> >>>>> noticed a failure like this: >> >>>>> >> >>>>> [INFO] --- frontend-maven-plugin:0.0.15:npm (npm install) @ >> unifiedpush-server --- >> >>>>> [INFO] Running 'npm install --color=false' in >> /home/travis/build/aerogear/aerogear-unifiedpush-server/admin-ui >> >>>>> [INFO] npm WARN package.json newadmin at 0.0.0 No repository >> field. >> >>>>> [INFO] >> >>>>> [INFO] --- frontend-maven-plugin:0.0.15:grunt (grunt build) @ >> unifiedpush-server --- >> >>>>> [INFO] Running 'grunt dist --no-color' in >> /home/travis/build/aerogear/aerogear-unifiedpush-server/admin-ui >> >>>>> [INFO] >> Local Npm module "grunt-cli" not found. Is it >> installed? >> >>>>> [INFO] >> >>>>> [INFO] Running "bower:install" (bower) task >> >>>>> [INFO] Fatal error: Arguments to path.join must be strings >> >>>>> [INFO] >> ------------------------------------------------------------------------ >> >>>>> [INFO] Reactor Summary: >> >>>>> >> >>>>> Note: "grunt-cli" *IS* installed, even globally. If I am >> correct, at >> >>>>> the moment we are not 100% sure what the "Fatal error: >> Arguments to >> >>>>> path.join must be strings" really means... >> >>>>> >> >>>>> On my machine, I noticed the npm stuff downloads half of the >> internet, >> >>>>> but gets stuck in the middle: >> >>>>> >> >>>>> [INFO] npm http 304 https://registry.npmjs.org/oauth-sign >> >>>>> [INFO] npm http 304 https://registry.npmjs.org/aws-sign2 >> >>>>> [INFO] npm http 304 https://registry.npmjs.org/hawk >> >>>>> [INFO] npm http GET https://registry.npmjs.org/combined-stream >> >>>>> [INFO] npm http GET https://registry.npmjs.org/async >> >>>>> [INFO] npm http GET https://registry.npmjs.org/assert-plus >> >>>>> [INFO] npm http GET https://registry.npmjs.org/asn1 >> >>>>> [INFO] npm http GET https://registry.npmjs.org/ctype >> >>>>> [INFO] npm http GET https://registry.npmjs.org/punycode >> >>>>> [INFO] npm http GET https://registry.npmjs.org/hoek >> >>>>> [INFO] npm http GET https://registry.npmjs.org/boom >> >>>>> [INFO] npm http GET https://registry.npmjs.org/sntp >> >>>>> [INFO] npm http GET https://registry.npmjs.org/cryptiles >> >>>>> [INFO] npm http 304 https://registry.npmjs.org/async >> >>>>> [INFO] npm http 304 https://registry.npmjs.org/combined-stream >> >>>>> [INFO] npm http 304 https://registry.npmjs.org/assert-plus >> >>>>> [INFO] npm http 304 https://registry.npmjs.org/asn1 >> >>>>> [INFO] npm http GET https://registry.npmjs.org/delayed-stream >> >>>>> [INFO] npm http 304 https://registry.npmjs.org/ctype >> >>>>> [INFO] npm http 304 https://registry.npmjs.org/punycode >> >>>>> [INFO] npm http 304 https://registry.npmjs.org/boom >> >>>>> [INFO] npm http 304 https://registry.npmjs.org/hoek >> >>>>> [INFO] npm http 304 https://registry.npmjs.org/cryptiles >> >>>>> [INFO] npm http 304 https://registry.npmjs.org/sntp >> >>>>> [INFO] npm http 304 https://registry.npmjs.org/delayed-stream >> >>>>> >> >>>>> Now, after more than one hour of 'waiting', I cancled the >> build, >> >>>>> resulting in: >> >>>>> >> >>>>> [INFO] > optipng-bin at 0.3.9 postinstall >> /Users/matzew/Work/JBoss/UPS/admin-ui/node_modules/grunt-contrib-imagemin/node_modules/imagemin/node_modules/imagemin-optipng/node_modules/optipng-bin >> >>>>> [INFO] > node index.js >> >>>>> [INFO] >> >>>>> [INFO] ? pre-build test passed successfully >> >>>>> [INFO] npm http 304 https://registry.npmjs.org/hoek >> >>>>> [INFO] npm http 304 https://registry.npmjs.org/boom >> >>>>> [INFO] npm http 304 https://registry.npmjs.org/cryptiles >> >>>>> [INFO] npm http 304 https://registry.npmjs.org/sntp >> >>>>> [INFO] npm http 304 https://registry.npmjs.org/delayed-stream >> >>>>> ^C[INFO] >> ------------------------------------------------------------------------ >> >>>>> [INFO] Reactor Summary: >> >>>>> [INFO] >> >>>>> [INFO] AeroGear UnifiedPush Server ....................... >> SUCCESS [3.884s] >> >>>>> [INFO] UnifiedPush Model Layer ........................... >> SUCCESS [0.146s] >> >>>>> [INFO] UnifiedPush Server Model API ...................... >> SUCCESS [2.699s] >> >>>>> [INFO] UnifiedPush Server Model JPA implementation ....... >> SUCCESS [15.036s] >> >>>>> [INFO] UnifiedPush Service Layer ......................... >> SUCCESS [7.757s] >> >>>>> [INFO] UnifiedPush Push Notification Networks ............ >> SUCCESS [2.009s] >> >>>>> [INFO] UnifiedPush RESTful Endpoint ...................... >> SUCCESS [2.811s] >> >>>>> [INFO] UnifiedPush Server (WAR) .......................... >> FAILURE [1:30:54.769s] >> >>>>> [INFO] UnifiedPush Auth Server ........................... >> SKIPPED >> >>>>> [INFO] >> ------------------------------------------------------------------------ >> >>>>> [INFO] BUILD FAILURE >> >>>>> [INFO] >> ------------------------------------------------------------------------ >> >>>>> [INFO] Total time: 1:31:29.994s >> >>>>> [INFO] Finished at: Tue Jul 15 07:48:37 CEST 2014 >> >>>>> [INFO] Final Memory: 80M/191M >> >>>>> [INFO] >> ------------------------------------------------------------------------ >> >>>>> [ERROR] Failed to execute goal >> com.github.eirslett:frontend-maven-plugin:0.0.15:npm (npm install) >> on project unifiedpush-server: 'npm install --color=false' failed. >> (error code 130) -> [Help 1] >> >>>>> [ERROR] >> >>>>> [ERROR] To see the full stack trace of the errors, re-run >> Maven with the -e switch. >> >>>>> [ERROR] Re-run Maven using the -X switch to enable full debug >> logging. >> >>>>> [ERROR] >> >>>>> [ERROR] For more information about the errors and possible >> solutions, please read the following articles: >> >>>>> [ERROR] [Help 1] >> http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException >> >>>>> [ERROR] >> >>>>> [ERROR] After correcting the problems, you can resume the >> build with the command >> >>>>> [ERROR] mvn -rf :unifiedpush-server >> >>>>> >> >>>>> This is more a FYI on what's going on - I will file a JIRA >> ticket for >> >>>>> that; >> >>>>> >> >>>>> *PS:* According to yesterday's IRC discussions, a manual >> `grunt server does >> >>>>> work, so development is not*directly* effected >> >>>>> >> >>>>> -Matthias >> >>>>> >> >>>>> -- >> >>>>> Matthias Wessendorf >> >>>>> >> >>>>> blog: http://matthiaswessendorf.wordpress.com/ >> >>>>> sessions: http://www.slideshare.net/mwessendorf >> >>>>> twitter: http://twitter.com/mwessendorf >> >>>>> >> >>>>> _______________________________________________ >> >>>>> aerogear-dev mailing list >> >>>>> aerogear-dev at lists.jboss.org >> >>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >>>>> >> >>>> >> >>>> >> >>>> _______________________________________________ >> >>>> aerogear-dev mailing list >> >>>> aerogear-dev at lists.jboss.org >> >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >>>> >> >>> >> >>> >> >>> _______________________________________________ >> >>> aerogear-dev mailing list >> >>> aerogear-dev at lists.jboss.org >> >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >>> >> >> >> >> >> > >> > -- >> > Sent from Gmail Mobile >> > >> > _______________________________________________ >> > aerogear-dev mailing list >> > aerogear-dev at lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > -- > > abstractj > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140716/cc23e050/attachment-0001.html From scm.blanc at gmail.com Wed Jul 16 12:53:25 2014 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Wed, 16 Jul 2014 18:53:25 +0200 Subject: [aerogear-dev] [Android] UnifiedPush Registration as a separate module ? Message-ID: Hi ! This is just an idea (for later/future) I had when I looked at the Amazon Device Messaging bits (the GCM variant from Amazon). Basically it's just Java/Android code : https://developer.amazon.com/public/apis/engage/device-messaging/tech-docs/04-integrating-your-app-with-adm But when we will implement the UPS Amazon library there will be some duplication (basically the UPS registration process). It would be nice if this was extracted into a small module (i.e : android-unifiedpush-registration) that could be used by the "pure" android bits (i.e : android-unifiedpush-gcm) and by the Amazon bits (android-unifiedpush-adm) and maybe later by other system based on Android but using their own Push infra. wdyt ? Sebi -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140716/8eec1726/attachment.html From kpiwko at redhat.com Wed Jul 16 12:57:46 2014 From: kpiwko at redhat.com (Karel Piwko) Date: Wed, 16 Jul 2014 16:59:46 +0002 Subject: [aerogear-dev] Get all open Pull Requests for an org In-Reply-To: References: Message-ID: <1405529866.32747.2@smtp.corp.redhat.com> Nice! As for API request limit, app could retrieve personal acess token (OAuth) from GitHub first, we do that in arquillian.org. Do you have code somewhere handy for a PR? ;-) Karel On Mon, Jul 14, 2014 at 12:32 PM, Sebastien Blanc wrote: > Hi All, > This is a bit off topic but , IMO, can be useful to the project. > I have been looking for a way to get all the Open Pull Requests that > are open for the AeroGear org, since I could not really find the tool > I was looking for I created one :) > > http://myopenprs-sblanc.rhcloud.com/ > > It's a small app that will retrieve all the open PRs for an GH org or > a GH user. Just type "aerogear" and hit search and all the open PRs > will be retrieved. > > For those interested, under the hood, it is a Vert.x App, using the > Event Bus to stream the open PRs back to the Browser. > > Have fun ! > > Sebi > > ps : no results returned ? Could be that the rate limit of the github > API (5000 req/hour) has been reached, please wait a bit before > retrying. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140716/fcca85c5/attachment.html From kpiwko at redhat.com Wed Jul 16 13:00:32 2014 From: kpiwko at redhat.com (Karel Piwko) Date: Wed, 16 Jul 2014 17:02:32 +0002 Subject: [aerogear-dev] admin-ui dependencies In-Reply-To: References: <20140711211109.GA68261@abstractj.org> Message-ID: <1405530032.32747.3@smtp.corp.redhat.com> Would you guys mind if I send a PR with current master commits for both jquery-idletimer and jquery-idleTimeout to lock versions down? I believe that's another place where we should ensure builds are reproducible. Thanks, Karel On Fri, Jul 11, 2014 at 11:23 PM, Sebastien Blanc wrote: > I just made the test and it seems to do the trick , add this to > admin-ui/bower.json , in dependencies : > > "jquery-idletimer" : "git at github.com:thorst/jquery-idletimer", > "jquery-idleTimeout" : "git at github.com:JillElaine/jquery-idleTimeout" > > Then bower install, you should see them in the folder > app/bower_components now > > > > > On Fri, Jul 11, 2014 at 11:11 PM, Bruno Oliveira > wrote: >> Good morning, >> >> I would like to include 2 new dependencies to deal with session >> timeouts >> at the admin-ui: >> >> - jquery-idletimer: https://github.com/thorst/jquery-idletimer >> - jquery-idleTimeout: >> https://github.com/JillElaine/jquery-idleTimeout >> >> These dependencies are not available on Bower. Which way is the best >> to >> include them as dependency? >> >> -- >> >> abstractj >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140716/c484c540/attachment.html From scm.blanc at gmail.com Wed Jul 16 13:02:06 2014 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Wed, 16 Jul 2014 19:02:06 +0200 Subject: [aerogear-dev] Get all open Pull Requests for an org In-Reply-To: <1405529866.32747.2@smtp.corp.redhat.com> References: <1405529866.32747.2@smtp.corp.redhat.com> Message-ID: On Wed, Jul 16, 2014 at 6:57 PM, Karel Piwko wrote: > Nice! > > As for API request limit, app could retrieve personal acess token (OAuth) > from GitHub first, we do that in arquillian.org. Do you have code > somewhere handy for a PR? ;-) > I already use my OAuth token on the server side , otherwise the limit is 60 req/hour and will be reached in just one call :) (Because I retrieve firt all the repo and for each repo I do a call for Open PR). I will share soon the code, have to clean it up a bit ;) > > Karel > > > On Mon, Jul 14, 2014 at 12:32 PM, Sebastien Blanc > wrote: > > Hi All, > This is a bit off topic but , IMO, can be useful to the project. > I have been looking for a way to get all the Open Pull Requests that are > open for the AeroGear org, since I could not really find the tool I was > looking for I created one :) > > http://myopenprs-sblanc.rhcloud.com/ > > It's a small app that will retrieve all the open PRs for an GH org or a GH > user. Just type "aerogear" and hit search and all the open PRs will be > retrieved. > > For those interested, under the hood, it is a Vert.x App, using the Event > Bus to stream the open PRs back to the Browser. > > Have fun ! > > Sebi > > ps : no results returned ? Could be that the rate limit of the github API > (5000 req/hour) has been reached, please wait a bit before retrying. > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140716/eadfd976/attachment.html From keith at kdmooreconsulting.com Wed Jul 16 13:05:22 2014 From: keith at kdmooreconsulting.com (keithdmoore94) Date: Wed, 16 Jul 2014 10:05:22 -0700 (PDT) Subject: [aerogear-dev] Aerogear Feature Request - Auto Increment Badge In-Reply-To: References: <1405357130449-8396.post@n5.nabble.com> Message-ID: <1405530322518-8421.post@n5.nabble.com> Currently, the cordova push plugin sets the badge number to zero which clears out the notifications upon launching the app. What I am saying is that I would like for the badge number to be incremented as the notification center receives the notification, not the mobile device app. So in my server side application, I would like to be able to set the badge number in the java push client to "increment" and then have the Aerogear Push Server keep track of the badge number and increment it every time a push notification is sent. In the mobile app, I can always call the method to decrement the badge number upon receiving the notification. Or even better would be to have the aerogear cordova plugin do that for me when it sends the notification. Should I open a feature request for this in Jira ? -- View this message in context: http://aerogear-dev.1069024.n5.nabble.com/Aerogear-Feature-Request-Auto-Increment-Badge-tp8396p8421.html Sent from the aerogear-dev mailing list archive at Nabble.com. From lholmqui at redhat.com Wed Jul 16 13:05:56 2014 From: lholmqui at redhat.com (Lucas Holmquist) Date: Wed, 16 Jul 2014 13:05:56 -0400 Subject: [aerogear-dev] [Android] UnifiedPush Registration as a separate module ? In-Reply-To: References: Message-ID: <8375DB00-7E0D-412C-8A6C-432C4513222E@redhat.com> the same will probably happen with iOS when adding in safari push On Jul 16, 2014, at 12:53 PM, Sebastien Blanc wrote: > Hi ! > This is just an idea (for later/future) I had when I looked at the Amazon Device Messaging bits (the GCM variant from Amazon). > > Basically it's just Java/Android code : https://developer.amazon.com/public/apis/engage/device-messaging/tech-docs/04-integrating-your-app-with-adm > > But when we will implement the UPS Amazon library there will be some duplication (basically the UPS registration process). > > It would be nice if this was extracted into a small module (i.e : android-unifiedpush-registration) that could be used by the "pure" android bits (i.e : android-unifiedpush-gcm) and by the Amazon bits (android-unifiedpush-adm) and maybe later by other system based on Android but using their own Push infra. > > wdyt ? > > Sebi > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140716/e1d833fc/attachment.html From bruno at abstractj.org Wed Jul 16 13:17:41 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Wed, 16 Jul 2014 14:17:41 -0300 Subject: [aerogear-dev] admin-ui dependencies In-Reply-To: <1405530032.32747.3@smtp.corp.redhat.com> References: <20140711211109.GA68261@abstractj.org> <1405530032.32747.3@smtp.corp.redhat.com> Message-ID: <20140716171741.GA61871@abstractj.org> Go for it Karel. On 2014-07-16, Karel Piwko wrote: > Would you guys mind if I send a PR with current master commits for both > jquery-idletimer and jquery-idleTimeout to lock versions down? > > I believe that's another place where we should ensure builds are > reproducible. > > Thanks, > > Karel > > On Fri, Jul 11, 2014 at 11:23 PM, Sebastien Blanc > wrote: > >I just made the test and it seems to do the trick , add this to > >admin-ui/bower.json , in dependencies : > > > > "jquery-idletimer" : "git at github.com:thorst/jquery-idletimer", > > "jquery-idleTimeout" : "git at github.com:JillElaine/jquery-idleTimeout" > > > >Then bower install, you should see them in the folder app/bower_components > >now > > > > > > > > > >On Fri, Jul 11, 2014 at 11:11 PM, Bruno Oliveira > >wrote: > >>Good morning, > >> > >>I would like to include 2 new dependencies to deal with session timeouts > >>at the admin-ui: > >> > >>- jquery-idletimer: https://github.com/thorst/jquery-idletimer > >>- jquery-idleTimeout: https://github.com/JillElaine/jquery-idleTimeout > >> > >>These dependencies are not available on Bower. Which way is the best to > >>include them as dependency? > >> > >>-- > >> > >>abstractj > >>_______________________________________________ > >>aerogear-dev mailing list > >>aerogear-dev at lists.jboss.org > >>https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -- abstractj From kpiwko at redhat.com Thu Jul 17 03:01:40 2014 From: kpiwko at redhat.com (Karel Piwko) Date: Thu, 17 Jul 2014 07:03:40 +0002 Subject: [aerogear-dev] admin-ui dependencies In-Reply-To: <20140716171741.GA61871@abstractj.org> References: <20140711211109.GA68261@abstractj.org> <1405530032.32747.3@smtp.corp.redhat.com> <20140716171741.GA61871@abstractj.org> Message-ID: <1405580500.32747.4@smtp.corp.redhat.com> Locked here: https://github.com/aerogear/aerogear-unifiedpush-server/pull/298 I haven't added any new deps, I've just locked existing github ones (patternfly and idle-timeout. Karel On Wed, Jul 16, 2014 at 7:17 PM, Bruno Oliveira wrote: > Go for it Karel. > > On 2014-07-16, Karel Piwko wrote: >> Would you guys mind if I send a PR with current master commits for >> both >> jquery-idletimer and jquery-idleTimeout to lock versions down? >> >> I believe that's another place where we should ensure builds are >> reproducible. >> >> Thanks, >> >> Karel >> >> On Fri, Jul 11, 2014 at 11:23 PM, Sebastien Blanc >> >> wrote: >> >I just made the test and it seems to do the trick , add this to >> >admin-ui/bower.json , in dependencies : >> > >> > "jquery-idletimer" : "git at github.com:thorst/jquery-idletimer", >> > "jquery-idleTimeout" : >> "git at github.com:JillElaine/jquery-idleTimeout" >> > >> >Then bower install, you should see them in the folder >> app/bower_components >> >now >> > >> > >> > >> > >> >On Fri, Jul 11, 2014 at 11:11 PM, Bruno Oliveira >> >> >wrote: >> >>Good morning, >> >> >> >>I would like to include 2 new dependencies to deal with session >> timeouts >> >>at the admin-ui: >> >> >> >>- jquery-idletimer: https://github.com/thorst/jquery-idletimer >> >>- jquery-idleTimeout: >> https://github.com/JillElaine/jquery-idleTimeout >> >> >> >>These dependencies are not available on Bower. Which way is the >> best to >> >>include them as dependency? >> >> >> >>-- >> >> >> >>abstractj >> >>_______________________________________________ >> >>aerogear-dev mailing list >> >>aerogear-dev at lists.jboss.org >> >>https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > -- > > abstractj > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140717/f9103f1b/attachment.html From matzew at apache.org Thu Jul 17 06:34:31 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Thu, 17 Jul 2014 12:34:31 +0200 Subject: [aerogear-dev] Aerogear Feature Request - Auto Increment Badge In-Reply-To: <1405530322518-8421.post@n5.nabble.com> References: <1405357130449-8396.post@n5.nabble.com> <1405530322518-8421.post@n5.nabble.com> Message-ID: Hi Keith! On Wed, Jul 16, 2014 at 7:05 PM, keithdmoore94 wrote: > Currently, the cordova push plugin sets the badge number to zero which > clears > out the notifications upon launching the app. > > What I am saying is that I would like for the badge number to be > incremented > as the notification center receives the notification, not the mobile device > app. > yeah, the push plugin should set the arrived number. Can you file a ticket for that ? > > So in my server side application, I would like to be able to set the badge > number in the java push client to "increment" and then have the Aerogear > Push Server keep track of the badge number and increment it every time a > push notification is sent. > Nope, the push server won't keep track. It just delivers the given number to APNs. The number can be totally different per user (e.g. number of messages in a messanger). > > In the mobile app, I can always call the method to decrement the badge > number upon receiving the notification. Or even better would be to have > the > aerogear cordova plugin do that for me when it sends the notification. > decrement (or setting back to zero) is app logic, and Apple treats it that way. IMO the Push Plugin should follow that as well Thanks for sharing your toughts! Greetings, Matthias > > Should I open a feature request for this in Jira ? > > > > -- > View this message in context: > http://aerogear-dev.1069024.n5.nabble.com/Aerogear-Feature-Request-Auto-Increment-Badge-tp8396p8421.html > Sent from the aerogear-dev mailing list archive at Nabble.com. > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140717/7f7f1eae/attachment.html From matzew at apache.org Thu Jul 17 06:37:50 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Thu, 17 Jul 2014 12:37:50 +0200 Subject: [aerogear-dev] broken build (master and 0.11.0 tag) In-Reply-To: <20140716153225.GA58871@abstractj.org> References: <20140716153225.GA58871@abstractj.org> Message-ID: On Wed, Jul 16, 2014 at 5:32 PM, Bruno Oliveira wrote: but I can't understand why we need to build > the admin-ui on CI if we don't have any tests on it, is pretty much npm > install + bower install and grunt tasks copying files. > IMO that's part of the build - without the copying and node tools, the produced WAR is useless > > Thoughts? > > On 2014-07-15, Sebastien Blanc wrote: > > Ok, > > Some extra info : > > As suggested I tried to update Bower to 1.3.8 : > > - > > > https://github.com/aerogear/aerogear-unifiedpush-server/commit/87dadc04ab2c0bfbb482706ecba5ab55d04ae30c > > But that did not helped , maybe the maven frontend pugin overides the > Bower > > version, looking at this now > > > > BUT, on twitter someone suggested this : > > https://twitter.com/chrisfrancis27/status/488701380207448064 > > > > Basically adding a "temp" dependencies to package.json , o_0 => indeed > but > > it WORKS : > > > > > https://travis-ci.org/aerogear/aerogear-unifiedpush-server/builds/29953927 > > ! > > > > So good news , with this "temp" dep we can build again and in the same > time > > let's find out how we can update bower > > > > > > On Tue, Jul 15, 2014 at 9:21 AM, Matthias Wessendorf > > wrote: > > > > > > > > > > > On Tuesday, July 15, 2014, tolis emmanouilidis > wrote: > > > > > >> +1 Sebi > > >> > > >> The builds started failing 3 days ago. 3 days ago bower ( > > >> https://www.npmjs.org/package/bower) was updated to v1.3.8. > > >> > > >> The last successful Travis UPS build logs contains bower at 1.3.7 > > >> node_modules/bower. > > >> The rest failed successful Travis UPS build logs contain bower at 1.3.8 > > >> node_modules/bower > > >> > > >> Maybe enforcing bower version 1.3.7 will resolve the issue. > > >> > > > > > > > > > +9001 > > > We should lock all versions :-) > > > > > > > > >> > > >> > > >> 2014-07-15 9:50 GMT+03:00 Sebastien Blanc : > > >> > > >>> Looks like Bower is aware of this issue : > > >>> https://twitter.com/bower/status/487704111832252417 > > >>> Let me check if I can do something > > >>> > > >>> > > >>> > > >>> On Tue, Jul 15, 2014 at 8:34 AM, Christos Vasilakis < > cvasilak at gmail.com> > > >>> wrote: > > >>> > > >>>> Hi, > > >>>> > > >>>> the same failure output "[INFO] Fatal error: Arguments to path.join > > >>>> must be strings" have been noticed also when building liveoak > > >>>> 'master'. I suspect some change on the nodes tools broke builds.. :( > > >>>> > > >>>> > > >>>> [1] https://projectodd.ci.cloudbees.com/job/liveoak/371/console > > >>>> > > >>>> > > >>>> > > >>>> On Tue, Jul 15, 2014 at 9:07 AM, Matthias Wessendorf < > matzew at apache.org > > >>>> > wrote: > > >>>> > > >>>>> Hi, > > >>>>> > > >>>>> since Friday, all in a sudden, the node.js part of the build > > >>>>> (triggered by the frontend plugin inside the 'server' module) is > failing on > > >>>>> different ways. > > >>>>> > > >>>>> Extremely odd: the 0.11.0 tag is effected as well. The release (on > > >>>>> maven central) is good, but ATM we are not able to build the > source on the > > >>>>> 0.11.0 tag :-( > > >>>>> > > >>>>> Oh, yeah, Travis-CI notice the broken build as well ;-) and > thankfully > > >>>>> abstractj put in a PR to have a temporary fix for the build > failure: > > >>>>> https://github.com/aerogear/aerogear-unifiedpush-server/pull/293 > > >>>>> > > >>>>> Thanks Bruno! > > >>>>> > > >>>>> Yesterday Bruno, Villiam and Luke looked at this already, and they > > >>>>> noticed a failure like this: > > >>>>> > > >>>>> [INFO] --- frontend-maven-plugin:0.0.15:npm (npm install) @ > unifiedpush-server --- > > >>>>> [INFO] Running 'npm install --color=false' in > /home/travis/build/aerogear/aerogear-unifiedpush-server/admin-ui > > >>>>> [INFO] npm WARN package.json newadmin at 0.0.0 No repository field. > > >>>>> [INFO] > > >>>>> [INFO] --- frontend-maven-plugin:0.0.15:grunt (grunt build) @ > unifiedpush-server --- > > >>>>> [INFO] Running 'grunt dist --no-color' in > /home/travis/build/aerogear/aerogear-unifiedpush-server/admin-ui > > >>>>> [INFO] >> Local Npm module "grunt-cli" not found. Is it installed? > > >>>>> [INFO] > > >>>>> [INFO] Running "bower:install" (bower) task > > >>>>> [INFO] Fatal error: Arguments to path.join must be strings > > >>>>> [INFO] > ------------------------------------------------------------------------ > > >>>>> [INFO] Reactor Summary: > > >>>>> > > >>>>> Note: "grunt-cli" *IS* installed, even globally. If I am correct, > at > > >>>>> the moment we are not 100% sure what the "Fatal error: Arguments to > > >>>>> path.join must be strings" really means... > > >>>>> > > >>>>> On my machine, I noticed the npm stuff downloads half of the > internet, > > >>>>> but gets stuck in the middle: > > >>>>> > > >>>>> [INFO] npm http 304 https://registry.npmjs.org/oauth-sign > > >>>>> [INFO] npm http 304 https://registry.npmjs.org/aws-sign2 > > >>>>> [INFO] npm http 304 https://registry.npmjs.org/hawk > > >>>>> [INFO] npm http GET https://registry.npmjs.org/combined-stream > > >>>>> [INFO] npm http GET https://registry.npmjs.org/async > > >>>>> [INFO] npm http GET https://registry.npmjs.org/assert-plus > > >>>>> [INFO] npm http GET https://registry.npmjs.org/asn1 > > >>>>> [INFO] npm http GET https://registry.npmjs.org/ctype > > >>>>> [INFO] npm http GET https://registry.npmjs.org/punycode > > >>>>> [INFO] npm http GET https://registry.npmjs.org/hoek > > >>>>> [INFO] npm http GET https://registry.npmjs.org/boom > > >>>>> [INFO] npm http GET https://registry.npmjs.org/sntp > > >>>>> [INFO] npm http GET https://registry.npmjs.org/cryptiles > > >>>>> [INFO] npm http 304 https://registry.npmjs.org/async > > >>>>> [INFO] npm http 304 https://registry.npmjs.org/combined-stream > > >>>>> [INFO] npm http 304 https://registry.npmjs.org/assert-plus > > >>>>> [INFO] npm http 304 https://registry.npmjs.org/asn1 > > >>>>> [INFO] npm http GET https://registry.npmjs.org/delayed-stream > > >>>>> [INFO] npm http 304 https://registry.npmjs.org/ctype > > >>>>> [INFO] npm http 304 https://registry.npmjs.org/punycode > > >>>>> [INFO] npm http 304 https://registry.npmjs.org/boom > > >>>>> [INFO] npm http 304 https://registry.npmjs.org/hoek > > >>>>> [INFO] npm http 304 https://registry.npmjs.org/cryptiles > > >>>>> [INFO] npm http 304 https://registry.npmjs.org/sntp > > >>>>> [INFO] npm http 304 https://registry.npmjs.org/delayed-stream > > >>>>> > > >>>>> Now, after more than one hour of 'waiting', I cancled the build, > > >>>>> resulting in: > > >>>>> > > >>>>> [INFO] > optipng-bin at 0.3.9 postinstall > /Users/matzew/Work/JBoss/UPS/admin-ui/node_modules/grunt-contrib-imagemin/node_modules/imagemin/node_modules/imagemin-optipng/node_modules/optipng-bin > > >>>>> [INFO] > node index.js > > >>>>> [INFO] > > >>>>> [INFO] ? pre-build test passed successfully > > >>>>> [INFO] npm http 304 https://registry.npmjs.org/hoek > > >>>>> [INFO] npm http 304 https://registry.npmjs.org/boom > > >>>>> [INFO] npm http 304 https://registry.npmjs.org/cryptiles > > >>>>> [INFO] npm http 304 https://registry.npmjs.org/sntp > > >>>>> [INFO] npm http 304 https://registry.npmjs.org/delayed-stream > > >>>>> ^C[INFO] > ------------------------------------------------------------------------ > > >>>>> [INFO] Reactor Summary: > > >>>>> [INFO] > > >>>>> [INFO] AeroGear UnifiedPush Server ....................... SUCCESS > [3.884s] > > >>>>> [INFO] UnifiedPush Model Layer ........................... SUCCESS > [0.146s] > > >>>>> [INFO] UnifiedPush Server Model API ...................... SUCCESS > [2.699s] > > >>>>> [INFO] UnifiedPush Server Model JPA implementation ....... SUCCESS > [15.036s] > > >>>>> [INFO] UnifiedPush Service Layer ......................... SUCCESS > [7.757s] > > >>>>> [INFO] UnifiedPush Push Notification Networks ............ SUCCESS > [2.009s] > > >>>>> [INFO] UnifiedPush RESTful Endpoint ...................... SUCCESS > [2.811s] > > >>>>> [INFO] UnifiedPush Server (WAR) .......................... FAILURE > [1:30:54.769s] > > >>>>> [INFO] UnifiedPush Auth Server ........................... SKIPPED > > >>>>> [INFO] > ------------------------------------------------------------------------ > > >>>>> [INFO] BUILD FAILURE > > >>>>> [INFO] > ------------------------------------------------------------------------ > > >>>>> [INFO] Total time: 1:31:29.994s > > >>>>> [INFO] Finished at: Tue Jul 15 07:48:37 CEST 2014 > > >>>>> [INFO] Final Memory: 80M/191M > > >>>>> [INFO] > ------------------------------------------------------------------------ > > >>>>> [ERROR] Failed to execute goal > com.github.eirslett:frontend-maven-plugin:0.0.15:npm (npm install) on > project unifiedpush-server: 'npm install --color=false' failed. (error code > 130) -> [Help 1] > > >>>>> [ERROR] > > >>>>> [ERROR] To see the full stack trace of the errors, re-run Maven > with the -e switch. > > >>>>> [ERROR] Re-run Maven using the -X switch to enable full debug > logging. > > >>>>> [ERROR] > > >>>>> [ERROR] For more information about the errors and possible > solutions, please read the following articles: > > >>>>> [ERROR] [Help 1] > http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException > > >>>>> [ERROR] > > >>>>> [ERROR] After correcting the problems, you can resume the build > with the command > > >>>>> [ERROR] mvn -rf :unifiedpush-server > > >>>>> > > >>>>> This is more a FYI on what's going on - I will file a JIRA ticket > for > > >>>>> that; > > >>>>> > > >>>>> *PS:* According to yesterday's IRC discussions, a manual `grunt > server does > > >>>>> work, so development is not*directly* effected > > >>>>> > > >>>>> -Matthias > > >>>>> > > >>>>> -- > > >>>>> Matthias Wessendorf > > >>>>> > > >>>>> blog: http://matthiaswessendorf.wordpress.com/ > > >>>>> sessions: http://www.slideshare.net/mwessendorf > > >>>>> twitter: http://twitter.com/mwessendorf > > >>>>> > > >>>>> _______________________________________________ > > >>>>> aerogear-dev mailing list > > >>>>> aerogear-dev at lists.jboss.org > > >>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > >>>>> > > >>>> > > >>>> > > >>>> _______________________________________________ > > >>>> aerogear-dev mailing list > > >>>> aerogear-dev at lists.jboss.org > > >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > >>>> > > >>> > > >>> > > >>> _______________________________________________ > > >>> aerogear-dev mailing list > > >>> aerogear-dev at lists.jboss.org > > >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > >>> > > >> > > >> > > > > > > -- > > > Sent from Gmail Mobile > > > > > > _______________________________________________ > > > aerogear-dev mailing list > > > aerogear-dev at lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > -- > > abstractj > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140717/d4138b8b/attachment-0001.html From scm.blanc at gmail.com Thu Jul 17 06:39:37 2014 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Thu, 17 Jul 2014 12:39:37 +0200 Subject: [aerogear-dev] Aerogear Feature Request - Auto Increment Badge In-Reply-To: References: <1405357130449-8396.post@n5.nabble.com> <1405530322518-8421.post@n5.nabble.com> Message-ID: On Thu, Jul 17, 2014 at 12:34 PM, Matthias Wessendorf wrote: > Hi Keith! > > > On Wed, Jul 16, 2014 at 7:05 PM, keithdmoore94 < > keith at kdmooreconsulting.com> wrote: > >> Currently, the cordova push plugin sets the badge number to zero which >> clears >> out the notifications upon launching the app. >> >> What I am saying is that I would like for the badge number to be >> incremented >> as the notification center receives the notification, not the mobile >> device >> app. >> > yeah, the push plugin should set the arrived number. Can you file a ticket > for that ? > > > >> >> So in my server side application, I would like to be able to set the badge >> number in the java push client to "increment" and then have the Aerogear >> Push Server keep track of the badge number and increment it every time a >> push notification is sent. >> > > Nope, the push server won't keep track. It just delivers the given number > to APNs. > The number can be totally different per user (e.g. number of messages in a > messanger). > I think what Keith means is that on installation level the auto-increment badge number could be stored (and incremented). > >> >> In the mobile app, I can always call the method to decrement the badge >> number upon receiving the notification. Or even better would be to have >> the >> aerogear cordova plugin do that for me when it sends the notification. >> > > decrement (or setting back to zero) is app logic, and Apple treats it that > way. > IMO the Push Plugin should follow that as well > > Thanks for sharing your toughts! > > Greetings, > Matthias > > >> >> Should I open a feature request for this in Jira ? >> >> >> >> -- >> View this message in context: >> http://aerogear-dev.1069024.n5.nabble.com/Aerogear-Feature-Request-Auto-Increment-Badge-tp8396p8421.html >> Sent from the aerogear-dev mailing list archive at Nabble.com. >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140717/d6668a1e/attachment.html From matzew at apache.org Thu Jul 17 07:07:58 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Thu, 17 Jul 2014 13:07:58 +0200 Subject: [aerogear-dev] Aerogear Feature Request - Auto Increment Badge In-Reply-To: References: <1405357130449-8396.post@n5.nabble.com> <1405530322518-8421.post@n5.nabble.com> Message-ID: On Thu, Jul 17, 2014 at 12:39 PM, Sebastien Blanc wrote: > > > > On Thu, Jul 17, 2014 at 12:34 PM, Matthias Wessendorf > wrote: > >> Hi Keith! >> >> >> On Wed, Jul 16, 2014 at 7:05 PM, keithdmoore94 < >> keith at kdmooreconsulting.com> wrote: >> >>> Currently, the cordova push plugin sets the badge number to zero which >>> clears >>> out the notifications upon launching the app. >>> >>> What I am saying is that I would like for the badge number to be >>> incremented >>> as the notification center receives the notification, not the mobile >>> device >>> app. >>> >> yeah, the push plugin should set the arrived number. Can you file a >> ticket for that ? >> >> >> >>> >>> So in my server side application, I would like to be able to set the >>> badge >>> number in the java push client to "increment" and then have the Aerogear >>> Push Server keep track of the badge number and increment it every time a >>> push notification is sent. >>> >> >> Nope, the push server won't keep track. It just delivers the given number >> to APNs. >> The number can be totally different per user (e.g. number of messages in >> a messanger). >> > I think what Keith means is that on installation level the auto-increment > badge number could be stored (and incremented). > Ok, that means we always increment? but what if the sales agent gets three new brochures on Monday, two on Tuesday. IMO there is zero value in having our server apply some magic. The meaning of the badge number is in most cases really something that the business backend already knows (Mr. T has 12 new mails). -Matthias > > >> >>> >>> In the mobile app, I can always call the method to decrement the badge >>> number upon receiving the notification. Or even better would be to have >>> the >>> aerogear cordova plugin do that for me when it sends the notification. >>> >> >> decrement (or setting back to zero) is app logic, and Apple treats it >> that way. >> IMO the Push Plugin should follow that as well >> >> Thanks for sharing your toughts! >> >> Greetings, >> Matthias >> >> >>> >>> Should I open a feature request for this in Jira ? >>> >>> >>> >>> -- >>> View this message in context: >>> http://aerogear-dev.1069024.n5.nabble.com/Aerogear-Feature-Request-Auto-Increment-Badge-tp8396p8421.html >>> Sent from the aerogear-dev mailing list archive at Nabble.com. >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >> >> >> >> -- >> Matthias Wessendorf >> >> blog: http://matthiaswessendorf.wordpress.com/ >> sessions: http://www.slideshare.net/mwessendorf >> twitter: http://twitter.com/mwessendorf >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140717/22d0aecf/attachment.html From kpiwko at redhat.com Thu Jul 17 07:42:29 2014 From: kpiwko at redhat.com (Karel Piwko) Date: Thu, 17 Jul 2014 11:44:29 +0002 Subject: [aerogear-dev] Aerogear Test BOM updates Message-ID: <1405597349.32747.6@smtp.corp.redhat.com> Hi, I've updated test dependencies in Aerogear Test BOM, https://github.com/aerogear/aerogear-parent/pull/10. It's time for QE to maintain dependency versions at the same place ;-) While this does not represent a full set of dependencies we use yet, it would be handy to have it in 0.2.3 or 0.3.0 release of Aerogear BOM. Is there such release planned? Thanks, Karel From matzew at apache.org Thu Jul 17 07:47:42 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Thu, 17 Jul 2014 13:47:42 +0200 Subject: [aerogear-dev] Aerogear Test BOM updates In-Reply-To: <1405597349.32747.6@smtp.corp.redhat.com> References: <1405597349.32747.6@smtp.corp.redhat.com> Message-ID: On Thu, Jul 17, 2014 at 1:42 PM, Karel Piwko wrote: > Hi, > > I've updated test dependencies in Aerogear Test BOM, > https://github.com/aerogear/aerogear-parent/pull/10. It's time for QE > to maintain dependency versions at the same place ;-) > awesome! > > While this does not represent a full set of dependencies we use yet, it > would be handy to have it in 0.2.3 or 0.3.0 release of Aerogear BOM. > > Is there such release planned? > sure, we can release what ever version number you want :-) > > Thanks, > > Karel > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140717/7d3cea87/attachment.html From bruno at abstractj.org Thu Jul 17 09:00:48 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Thu, 17 Jul 2014 10:00:48 -0300 Subject: [aerogear-dev] Android Registrations In-Reply-To: <53C68EAA.3070909@redhat.com> References: <53C68EAA.3070909@redhat.com> Message-ID: <20140717130048.GA71531@abstractj.org> Good morning Summers, make sure to assign that Jira for you, please. The gist for an Android outsider like me seems ok, but I would like to see these changes in at your fork for more context. Do you have any pointers? On 2014-07-16, Summers Pittman wrote: > We've mentioned moving from the factory/producer/headache pattern that > we currently use (Pipeline, etc) to something more fluent and more > maintainable. See this JIRA : https://issues.jboss.org/browse/AGDROID-259 > > To that end I've stubbed out some classes and made a strawman set of > unit tests for Pipeline : > https://gist.github.com/secondsun/8478a5f0527fc97b2456 > > In the comments of some of the tests I've added questions for the > implementation portion of Registrations. > > The ultimate goal is to make the factories and feature classes(Pipe, > AuthModule, etc) flexible enough that circular dependencies can be > broken and 1) modularization can happen and 2) feature additions can be > quicker and change fewer stable APIs. > > Comments, questions, and tomatoes are welcome. > > -- > Summers Pittman > >>Phone:404 941 4698 > >>Java is my crack. > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -- abstractj From lholmqui at redhat.com Thu Jul 17 09:26:31 2014 From: lholmqui at redhat.com (Lucas Holmquist) Date: Thu, 17 Jul 2014 09:26:31 -0400 Subject: [aerogear-dev] AeroGear JS 1.5.1 Message-ID: <38917BA6-8A33-43E4-8786-0EFD852AFA05@redhat.com> Hi, We are hoping to release a 1.5.1 version of the JS libs very soon. I?ve just tagged a 1.5.1-beta, https://github.com/aerogear/aerogear-js/releases/tag/1.5.1-beta This includes some pesky bug fixes and some enhancements https://issues.jboss.org/issues/?jql=project%20%3D%20AGJS%20AND%20fixVersion%20%3D%201.5.1%20ORDER%20BY%20status%20DESC%2C%20priority%20DESC Thanks again to Tolis Emmanouilidis, https://github.com/tolis-e, for his help again!! the plan is to release on monday afternoon -Luke -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140717/9fa3329a/attachment.html From matzew at apache.org Thu Jul 17 09:38:04 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Thu, 17 Jul 2014 15:38:04 +0200 Subject: [aerogear-dev] AeroGear JS 1.5.1 In-Reply-To: <38917BA6-8A33-43E4-8786-0EFD852AFA05@redhat.com> References: <38917BA6-8A33-43E4-8786-0EFD852AFA05@redhat.com> Message-ID: will AGJS-139 be included ? On Thu, Jul 17, 2014 at 3:26 PM, Lucas Holmquist wrote: > Hi, > > We are hoping to release a 1.5.1 version of the JS libs very soon. I?ve > just tagged a 1.5.1-beta, > https://github.com/aerogear/aerogear-js/releases/tag/1.5.1-beta > > This includes some pesky bug fixes and some enhancements > > > https://issues.jboss.org/issues/?jql=project%20%3D%20AGJS%20AND%20fixVersion%20%3D%201.5.1%20ORDER%20BY%20status%20DESC%2C%20priority%20DESC > > > > Thanks again to Tolis Emmanouilidis, https://github.com/tolis-e, for his > help again!! > > the plan is to release on monday afternoon > > -Luke > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140717/aecb94d7/attachment.html From lholmqui at redhat.com Thu Jul 17 09:52:58 2014 From: lholmqui at redhat.com (Lucas Holmquist) Date: Thu, 17 Jul 2014 09:52:58 -0400 Subject: [aerogear-dev] AeroGear JS 1.5.1 In-Reply-To: References: <38917BA6-8A33-43E4-8786-0EFD852AFA05@redhat.com> Message-ID: <528B6A4A-D1E7-4869-A21B-AFA8E2393F54@redhat.com> On Jul 17, 2014, at 9:38 AM, Matthias Wessendorf wrote: > will AGJS-139 be included ? not in this release, it will be in the next one, most likely with this change, https://issues.jboss.org/browse/AGJS-52 > > > On Thu, Jul 17, 2014 at 3:26 PM, Lucas Holmquist wrote: > Hi, > > We are hoping to release a 1.5.1 version of the JS libs very soon. I?ve just tagged a 1.5.1-beta, https://github.com/aerogear/aerogear-js/releases/tag/1.5.1-beta > > This includes some pesky bug fixes and some enhancements > > https://issues.jboss.org/issues/?jql=project%20%3D%20AGJS%20AND%20fixVersion%20%3D%201.5.1%20ORDER%20BY%20status%20DESC%2C%20priority%20DESC > > > Thanks again to Tolis Emmanouilidis, https://github.com/tolis-e, for his help again!! > > the plan is to release on monday afternoon > > -Luke > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140717/6ab16fbb/attachment.html From matzew at apache.org Thu Jul 17 10:51:29 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Thu, 17 Jul 2014 16:51:29 +0200 Subject: [aerogear-dev] AeroGear JS 1.5.1 In-Reply-To: <528B6A4A-D1E7-4869-A21B-AFA8E2393F54@redhat.com> References: <38917BA6-8A33-43E4-8786-0EFD852AFA05@redhat.com> <528B6A4A-D1E7-4869-A21B-AFA8E2393F54@redhat.com> Message-ID: ok, it would be good to have AGJS-139 in a JS release that is out when our 1.0.0 of the UPS is out as well On Thu, Jul 17, 2014 at 3:52 PM, Lucas Holmquist wrote: > > On Jul 17, 2014, at 9:38 AM, Matthias Wessendorf > wrote: > > will AGJS-139 be included ? > > > not in this release, it will be in the next one, most likely with this > change, https://issues.jboss.org/browse/AGJS-52 > > > > > On Thu, Jul 17, 2014 at 3:26 PM, Lucas Holmquist > wrote: > >> Hi, >> >> We are hoping to release a 1.5.1 version of the JS libs very soon. I?ve >> just tagged a 1.5.1-beta, >> https://github.com/aerogear/aerogear-js/releases/tag/1.5.1-beta >> >> This includes some pesky bug fixes and some enhancements >> >> >> https://issues.jboss.org/issues/?jql=project%20%3D%20AGJS%20AND%20fixVersion%20%3D%201.5.1%20ORDER%20BY%20status%20DESC%2C%20priority%20DESC >> >> >> >> Thanks again to Tolis Emmanouilidis, https://github.com/tolis-e, for his >> help again!! >> >> the plan is to release on monday afternoon >> >> -Luke >> >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140717/943cc9e1/attachment.html From supittma at redhat.com Thu Jul 17 10:52:20 2014 From: supittma at redhat.com (Summers Pittman) Date: Thu, 17 Jul 2014 10:52:20 -0400 Subject: [aerogear-dev] Android Registrations In-Reply-To: <20140717130048.GA71531@abstractj.org> References: <53C68EAA.3070909@redhat.com> <20140717130048.GA71531@abstractj.org> Message-ID: <53C7E324.4000700@redhat.com> On 07/17/2014 09:00 AM, Bruno Oliveira wrote: > Good morning Summers, make sure to assign that Jira for you, please. The > gist for an Android outsider like me seems ok, but I would like to see > these changes in at your fork for more context. > > Do you have any pointers? No it is written in Java. Right now I am more interested in discussion around the direction of the changes (in the TODO comments) before I spend a few weeks of time and get a HUGE PR build up. As such all the implementation is "throw new NotImplementedException()". But, since it seems like it will help, I will grab the JIRA ball and link to the gist as well as my current working repo. > > On 2014-07-16, Summers Pittman wrote: >> We've mentioned moving from the factory/producer/headache pattern that >> we currently use (Pipeline, etc) to something more fluent and more >> maintainable. See this JIRA : https://issues.jboss.org/browse/AGDROID-259 >> >> To that end I've stubbed out some classes and made a strawman set of >> unit tests for Pipeline : >> https://gist.github.com/secondsun/8478a5f0527fc97b2456 >> >> In the comments of some of the tests I've added questions for the >> implementation portion of Registrations. >> >> The ultimate goal is to make the factories and feature classes(Pipe, >> AuthModule, etc) flexible enough that circular dependencies can be >> broken and 1) modularization can happen and 2) feature additions can be >> quicker and change fewer stable APIs. >> >> Comments, questions, and tomatoes are welcome. >> >> -- >> Summers Pittman >>>> Phone:404 941 4698 >>>> Java is my crack. >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- > > abstractj > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -- Summers Pittman >>Phone:404 941 4698 >>Java is my crack. From keith at kdmooreconsulting.com Thu Jul 17 16:21:28 2014 From: keith at kdmooreconsulting.com (keithdmoore94) Date: Thu, 17 Jul 2014 13:21:28 -0700 (PDT) Subject: [aerogear-dev] Aerogear Feature Request - Auto Increment Badge In-Reply-To: References: <1405357130449-8396.post@n5.nabble.com> <1405530322518-8421.post@n5.nabble.com> Message-ID: <1405628488573-8437.post@n5.nabble.com> Matthias Wessendorf wrote > On Thu, Jul 17, 2014 at 12:39 PM, Sebastien Blanc > < > scm.blanc at gmail.com > > > wrote: > >> >> >> >> On Thu, Jul 17, 2014 at 12:34 PM, Matthias Wessendorf > < > matzew at apache.org > > >> wrote: >> >>> Hi Keith! >>> >>> >>> On Wed, Jul 16, 2014 at 7:05 PM, keithdmoore94 < >>> keith at kdmooreconsulting.com> wrote: >>> >>>> Currently, the cordova push plugin sets the badge number to zero which >>>> clears >>>> out the notifications upon launching the app. >>>> >>>> What I am saying is that I would like for the badge number to be >>>> incremented >>>> as the notification center receives the notification, not the mobile >>>> device >>>> app. >>>> >>> yeah, the push plugin should set the arrived number. Can you file a >>> ticket for that ? >>> >>> >>> >>>> >>>> So in my server side application, I would like to be able to set the >>>> badge >>>> number in the java push client to "increment" and then have the >>>> Aerogear >>>> Push Server keep track of the badge number and increment it every time >>>> a >>>> push notification is sent. >>>> >>> >>> Nope, the push server won't keep track. It just delivers the given >>> number >>> to APNs. >>> The number can be totally different per user (e.g. number of messages in >>> a messanger). >>> >> I think what Keith means is that on installation level the >> auto-increment >> badge number could be stored (and incremented). >> > > Ok, that means we always increment? but what if the sales agent gets three > new brochures on Monday, two on Tuesday. > IMO there is zero value in having our server apply some magic. The meaning > of the badge number is in most cases really something that the business > backend already knows (Mr. T has 12 new mails). > > -Matthias > > What I am saying is that, I don't want to have to keep track of the badge > number. I want the Aerogear push server to keep track of it. > I don't know how many notifications that I have sent to the user. Also, > if I had multiple disparate systems, I would have a much harder time > getting the badge number correct. Seems like the Aerogear push server is > an ideal candidate for this task. There would need to be some > minor changes to the cordova plugin (right now it sets the count to zero > which clears the badges and all of the notifications for that matter). > The developer would be responsible for setting the badge number by calling > the existing JS Push api function to set the badge number upon receiving > the notification. I think that API should also make a call back to the > Aerogear push server to update the badge number on the > server. > > -Keith > >> >> >>> >>>> >>>> In the mobile app, I can always call the method to decrement the badge >>>> number upon receiving the notification. Or even better would be to >>>> have >>>> the >>>> aerogear cordova plugin do that for me when it sends the notification. >>>> >>> >>> decrement (or setting back to zero) is app logic, and Apple treats it >>> that way. >>> IMO the Push Plugin should follow that as well >>> >>> Thanks for sharing your toughts! >>> >>> Greetings, >>> Matthias >>> >>> >>>> >>>> Should I open a feature request for this in Jira ? >>>> >>>> >>>> >>>> -- >>>> View this message in context: >>>> http://aerogear-dev.1069024.n5.nabble.com/Aerogear-Feature-Request-Auto-Increment-Badge-tp8396p8421.html >>>> Sent from the aerogear-dev mailing list archive at Nabble.com. >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> >>> >>> >>> >>> -- >>> Matthias Wessendorf >>> >>> blog: http://matthiaswessendorf.wordpress.com/ >>> sessions: http://www.slideshare.net/mwessendorf >>> twitter: http://twitter.com/mwessendorf >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev Quoted from: http://aerogear-dev.1069024.n5.nabble.com/Aerogear-Feature-Request-Auto-Increment-Badge-tp8396p8428.html -- View this message in context: http://aerogear-dev.1069024.n5.nabble.com/Aerogear-Feature-Request-Auto-Increment-Badge-tp8396p8437.html Sent from the aerogear-dev mailing list archive at Nabble.com. From bruno at abstractj.org Fri Jul 18 01:27:43 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Fri, 18 Jul 2014 02:27:43 -0300 Subject: [aerogear-dev] Get all open Pull Requests for an org In-Reply-To: References: Message-ID: <20140718052743.GA56383@abstractj.org> Good morning, it's not a big deal, but I'm a big lover of console. Just in case you are interested, today I released it on rubygems: https://github.com/abstractj/gawky. Enjoy On 2014-07-14, Sebastien Blanc wrote: > Hi All, > This is a bit off topic but , IMO, can be useful to the project. > I have been looking for a way to get all the Open Pull Requests that are > open for the AeroGear org, since I could not really find the tool I was > looking for I created one :) > > http://myopenprs-sblanc.rhcloud.com/ > > It's a small app that will retrieve all the open PRs for an GH org or a GH > user. Just type "aerogear" and hit search and all the open PRs will be > retrieved. > > For those interested, under the hood, it is a Vert.x App, using the Event > Bus to stream the open PRs back to the Browser. > > Have fun ! > > Sebi > > ps : no results returned ? Could be that the rate limit of the github API > (5000 req/hour) has been reached, please wait a bit before retrying. > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -- abstractj From matzew at apache.org Fri Jul 18 06:19:54 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Fri, 18 Jul 2014 12:19:54 +0200 Subject: [aerogear-dev] 0.2.3 release (was Re: Aerogear Test BOM updates) Message-ID: Hey Karel, here is the staging repo: http://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-3586/ please let me know if we can ship it to maven central -M On Thu, Jul 17, 2014 at 1:47 PM, Matthias Wessendorf wrote: > > > > On Thu, Jul 17, 2014 at 1:42 PM, Karel Piwko wrote: > >> Hi, >> >> I've updated test dependencies in Aerogear Test BOM, >> https://github.com/aerogear/aerogear-parent/pull/10. It's time for QE >> to maintain dependency versions at the same place ;-) >> > > > awesome! > > >> >> While this does not represent a full set of dependencies we use yet, it >> would be handy to have it in 0.2.3 or 0.3.0 release of Aerogear BOM. >> >> Is there such release planned? >> > > sure, we can release what ever version number you want :-) > > >> >> Thanks, >> >> Karel >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140718/2af80865/attachment.html From corinnekrych at gmail.com Fri Jul 18 06:35:59 2014 From: corinnekrych at gmail.com (Corinne Krych) Date: Fri, 18 Jul 2014 12:35:59 +0200 Subject: [aerogear-dev] iOS meeting Message-ID: <02232370-3C6A-4ADB-922C-4F61F2D42B66@gmail.com> Hello iOS lovers, Let?s make a point we?re we are for July release and discuss 2.0 for September. We'll use our usual Tuesday slot. See you Tuesday 22nd July at 2pm (CEST - UTC + 2hours). Here is a proposal agenda: http://oksoclap.com/p/aerogear_ios_22July2014 Feel free to add topics you would like to discuss. See you all Tuesday! ++ Corinne From matzew at apache.org Fri Jul 18 09:33:12 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Fri, 18 Jul 2014 15:33:12 +0200 Subject: [aerogear-dev] GCM limit with 1000 registrationIDs In-Reply-To: References: <1400672454662-7879.post@n5.nabble.com> <1400679220199-7887.post@n5.nabble.com> Message-ID: Hello Antoine, I am running the test again, w/ the 1.0.0.Beta1 branch. It's faster now. I am getting now 100ms per request, I am in the middle of importing a 100k devices (48.000 devices are now updated). Also, I still want to write a special endpoint that takes a (large) JSON file, and imports all the device metadata in one step. greetings, Matthias On Mon, May 26, 2014 at 10:59 AM, Matthias Wessendorf wrote: > Hello Antoine, > > I noticed the same issue, I will be looking into this, so that we can have > a better 'batch' import. > > Thanks for reporting! > Matthias > > > On Wed, May 21, 2014 at 4:33 PM, Matthias Wessendorf > wrote: > >> hey Antoine, >> >> thanks for explaining - I will take a look at this: >> https://issues.jboss.org/browse/AGPUSH-661 >> >> I will think about making the endpoint completely async (there is no real >> benefit in returning a JSON of the device metadata anyways + do some >> overhaul on the actual database) >> >> >> On Wed, May 21, 2014 at 3:33 PM, A577127 >> wrote: >> >>> Uh wrong translation I mean register tokens. We wrote a java sender that >>> registers lots of token (we wanted to register 1M tokens) with the REST >>> api >>> http://aerogear.org/docs/specs/aerogear-push-rest/DeviceRegistration/ >>> >>> But it was very slow (~1/s), looks like the database slows the thing by >>> making big requests (huge joins ?). >>> >>> >>> >>> -- >>> View this message in context: >>> http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-GCM-limit-with-1000-registrationIDs-tp7858p7887.html >>> Sent from the aerogear-dev mailing list archive at Nabble.com. >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >> >> >> >> -- >> Matthias Wessendorf >> >> blog: http://matthiaswessendorf.wordpress.com/ >> sessions: http://www.slideshare.net/mwessendorf >> twitter: http://twitter.com/mwessendorf >> > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140718/95864eee/attachment.html From matzew at apache.org Fri Jul 18 09:41:28 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Fri, 18 Jul 2014 15:41:28 +0200 Subject: [aerogear-dev] UPS Production worthiness In-Reply-To: <008f01cf9603$9cf11fb0$d6d35f10$@pinelabs.com> References: <002b01cf7424$528dc0a0$f7a941e0$@pinelabs.com> <005d01cf74ed$3d977140$b8c653c0$@pinelabs.com> <003c01cf78cd$1095df40$31c19dc0$@pinelabs.com> <17C1B903-C13B-482F-93FA-1B9B55AEF707@redhat.com> <008f01cf9603$9cf11fb0$d6d35f10$@pinelabs.com> Message-ID: On Wed, Jul 2, 2014 at 4:40 PM, Vivek Pandey wrote: > Hello Matthias, > > > > An ?importer? might help, but smaller changes in existing domain/service > might help more. > > I ran a stress test on the installation endpoint yesterday, after merging > Eric?s changes on source code of 0.10.x branch. > > I saw that even after using the merged code, the response worsened > continuously. > > Looking closing, I saw that GenericVariantServiceImpl. addInstallation > causes initialization of the now ?lazy? collection > AbstractVariant.installations. > > > > I changed the model a bit, by adding variantID to Installation, and made > it the owner of the variant-installation relationship. > > That changed the code in InstallationRegistrationEndpoint. registerInstallation > from > > // store the installation: > > entity = clientInstallationService.addInstallation(entity); > > // add installation to the matching variant > > genericVariantService.addInstallation(variant, entity); > > > > to > > // store the installation: > > > entity.setVariantID(variant); > > entity = > clientInstallationService.addInstallation(entity); > > > > This fixed the problem for me and now I am getting constant time > installation registration with dramatically better performance > Hey Vivek!, as a FYI - I ran some perf. tests as well, and noticed a huge improvement on the regitration as well, after Erik included (parts of) your patch > > > Please let me know if you want me to add this to AGPUSH-661 > > > > Thanks > > Vivek > > > > *From:* mwessendorf at gmail.com [mailto:mwessendorf at gmail.com] *On Behalf > Of *Matthias Wessendorf > *Sent:* Wednesday, July 02, 2014 6:26 PM > *To:* AeroGear Developer Mailing List; vivek.pandey at pinelabs.com > > *Subject:* Re: [aerogear-dev] UPS Production worthiness > > > > Hello Vivek, > > > > On Mon, May 26, 2014 at 1:23 PM, Matthias Wessendorf > wrote: > > > > > > On Mon, May 26, 2014 at 12:59 PM, Erik Jan de Wit > wrote: > > Hi Vivek, > > > > We?ve fixed that > https://github.com/aerogear/aerogear-unifiedpush-server/commit/1357c9e834286a9227a90e9ab618226aa54bbbf3 the > collection is now lazy. But I?m sure other query optimisations can be made. > > > > +1 > > > > btw. Vivek, I added your mail to an existing ticket: > > https://issues.jboss.org/browse/AGPUSH-661 > > > > > > coming back from vacation and going over the JIRAs, I was wondering if an > 'importer' helps? > > > > That would be a RESTful endpoint that accepts a JSON file, containing all > the devices you want to register (for a given variant). > > > > That way it would be also a bit nicer on your side, to perform the import: > > * generate a "large" JSON file (instead of a ton of requests) > > * only one HTTP request > > * server accepts and will process it in the background > > > > I think that would be a nice migration tool. > > > > Let me know what you think! > > > > -Matthias > > > > > > -Matthias > > > > > > Cheers, > > Erik Jan > > > > On 26 May,2014, at 12:27 , Vivek Pandey wrote: > > > > Hi Matthias, > > > > It is good to know that activity in java-apns is picking up and also that > you are looking at pushy. > > > > I did a few tests which added installations to UPS with a concurrency of > 4-8 threads. I was using Postgres 9.3 and UPS 0.10.3 war > > > > I noticed that response slowed down considerably after some time with high > CPU usage and continued to get worse. After doing some profiling, I found > that bulk of CPU cycles are being taken by > org.postgresql.core.VisibleBufferedInputStream.readMore. The entire thread > stack is attached. Also postgres continuously flagged > > > > select installati0_.variantID as variant10_0_0_, installati0_.id as > id1_3_0_, installati0_.id as id1_3_1_, installati0_.alias as alias2_3_1_, > installati0_.deviceToken as deviceTo3_3_1_, installati0_.deviceType as > deviceTy4_3_1_, installati0_.enabled as enabled5_3_1_, > installati0_.operatingSystem as operatin6_3_1_, installati0_.osVersion as > osVersio7_3_1_, installati0_.platform as platform8_3_1_, > installati0_.simplePushEndpoint as simplePu9_3_1_ from InstallationImpl > installati0_ where installati0_.variantID=$1 > > > > as the slow query. I am pretty sure that eager collection > AbstractVariant.installations is the root cause of the problem. > > > > Please let me know if you need any more information. > > > > Thanks > > Vivek > > > > *From:* mwessendorf at gmail.com [mailto:mwessendorf at gmail.com > ] *On Behalf Of *Matthias Wessendorf > *Sent:* Wednesday, May 21, 2014 5:55 PM > *To:* vivek.pandey at pinelabs.com; AeroGear Developer Mailing List > *Subject:* Re: [aerogear-dev] UPS Production worthiness > > > > Hello Vivek! > > > > On Wed, May 21, 2014 at 2:07 PM, Vivek Pandey > wrote: > > Hi Jay, > > > > Thanks for your reply. > > > > While we have not faced any issues in using UPS in our limited testing, I > often see info stacktraces in ups logs > > > > 2014-05-16 10:19:20,032 INFO > [com.notnoop.apns.internal.ApnsConnectionImpl] (Thread-118) Exception while > waiting for error code: java.net.SocketException: Socket closed > > at java.net.SocketInputStream.socketRead0(Native Method) > [rt.jar:1.7.0_51] > > at java.net.SocketInputStream.read(SocketInputStream.java:152) > [rt.jar:1.7.0_51] > > at java.net.SocketInputStream.read(SocketInputStream.java:122) > [rt.jar:1.7.0_51] > > ????? > > at > com.notnoop.apns.internal.ApnsConnectionImpl$1MonitoringThread.run(ApnsConnectionImpl.java:114) > [apns-0.2.3.jar:] > > > > > > These stacktraces coupled with low dev activity of noop/java-apns project > are disconcerting to me. > > > > the stack-trace is no harm - it's only happening w/ doing a monitoring of > the thread (that's what we currently do, when setting up ApnsService - I > thought about explicitly disable that) > > > > The activity of the underlying java-apns is very low, yes! However @froh42 > is getting back: > > https://github.com/notnoop/java-apns/commits/master > > > > There will be a new release in the near future; @froh42 asked me if I > could help with pushing the bits to maven central > > > > > > That said, I recently started looking at pushy: > > https://github.com/relayrides/pushy > > > > I also sent a PR that would allow us to feed pushy w/ our certificate from > the database: > > https://github.com/relayrides/pushy/pull/87 > > > > Hope that helps > > -Matthias > > > > > > I am currently using UPS 0.10.2 war. > > > > Thanks, > > Vivek > > *From:* Jay Balunas [mailto:jbalunas at redhat.com] > *Sent:* Tuesday, May 20, 2014 11:36 PM > *To:* vivek.pandey at pinelabs.com; AeroGear Developer Mailing List > *Cc:* Jay Balunas > *Subject:* Re: [aerogear-dev] UPS Production worthiness > > > > Hi Vivek, > > > > It's awesome to hear that you have integrated the UPS into your backend > systems and some of your mobile apps! > > > > We have a lot of confidence around the UPS, its functionality, and > performance. Our team has been working hard on improvements and stability > including our QE team. Also, as you may have seen we're planning a 1.0 > release of the UPS this summer. > > > > However at this time we don't have specific references or success stories > outside of what you can see in the community mailing lists - other users > using it ;-) We're also about to kick off some performance and scale > testing in the next couple of months. > > > > Have you run into any issues that drove these questions about production > worthiness? If so please let us know and we'll certainly take a look. > > > > Hope this helps! > > > > Thanks, > > Jay Balunas > > > > On May 20, 2014, at 8:09 AM, Vivek Pandey > wrote: > > > > Hello Aerogear dev team, > > > > We integrated UPS into our backend server which is serving various mobile > apps. While the development and testing phase went well, my manager is > questioning me about production worthiness about Aerogear. It would be > great help if you could point me to references/success stories where UPS is > being used in production environments and scaling well in medium to high > loads. > > > > Thanks, > > Vivek > > > > > > > ------------------------------ > > This message may contain privileged and confidential information and is > solely for the use of intended recipient. The views expressed in this email > are those of the sender and not of Pine Labs. The recipient should check > this email and attachments for the presence of viruses / malwares etc. Pine > Labs accepts no liability for any damage caused by any virus transmitted by > this email. Pine Labs may monitor and record all emails. > ------------------------------ > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > ------------------------------ > > This message may contain privileged and confidential information and is > solely for the use of intended recipient. The views expressed in this email > are those of the sender and not of Pine Labs. The recipient should check > this email and attachments for the presence of viruses / malwares etc. Pine > Labs accepts no liability for any damage caused by any virus transmitted by > this email. Pine Labs may monitor and record all emails. > ------------------------------ > > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > > > ------------------------------ > > This message may contain privileged and confidential information and is > solely for the use of intended recipient. The views expressed in this email > are those of the sender and not of Pine Labs. The recipient should check > this email and attachments for the presence of viruses / malwares etc. Pine > Labs accepts no liability for any damage caused by any virus transmitted by > this email. Pine Labs may monitor and record all emails. > ------------------------------ > > > > _______________________________________________ > > > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > > > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > > ------------------------------ > This message may contain privileged and confidential information and is > solely for the use of intended recipient. The views expressed in this email > are those of the sender and not of Pine Labs. The recipient should check > this email and attachments for the presence of viruses / malwares etc. Pine > Labs accepts no liability for any damage caused by any virus transmitted by > this email. Pine Labs may monitor and record all emails. > ------------------------------ > > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140718/248a7296/attachment-0001.html From avibelli at redhat.com Fri Jul 18 18:46:50 2014 From: avibelli at redhat.com (Andrea Vibelli) Date: Fri, 18 Jul 2014 15:46:50 -0700 (PDT) Subject: [aerogear-dev] 0.2.3 release (was Re: Aerogear Test BOM updates) In-Reply-To: References: Message-ID: <1405723610459-8443.post@n5.nabble.com> Hi Matt, looks ok for me, go for it :-) Thanks Andrea Matthias Wessendorf wrote > Hey Karel, > > here is the staging repo: > http://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-3586/ > > please let me know if we can ship it to maven central > > -M > > > On Thu, Jul 17, 2014 at 1:47 PM, Matthias Wessendorf < > matzew@ > > > wrote: > >> >> >> >> On Thu, Jul 17, 2014 at 1:42 PM, Karel Piwko < > kpiwko@ > > wrote: >> >>> Hi, >>> >>> I've updated test dependencies in Aerogear Test BOM, >>> https://github.com/aerogear/aerogear-parent/pull/10. It's time for QE >>> to maintain dependency versions at the same place ;-) >>> >> >> >> awesome! >> >> >>> >>> While this does not represent a full set of dependencies we use yet, it >>> would be handy to have it in 0.2.3 or 0.3.0 release of Aerogear BOM. >>> >>> Is there such release planned? >>> >> >> sure, we can release what ever version number you want :-) >> >> >>> >>> Thanks, >>> >>> Karel >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> > aerogear-dev at .jboss >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >> >> >> >> -- >> Matthias Wessendorf >> >> blog: http://matthiaswessendorf.wordpress.com/ >> sessions: http://www.slideshare.net/mwessendorf >> twitter: http://twitter.com/mwessendorf >> > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at .jboss > https://lists.jboss.org/mailman/listinfo/aerogear-dev -- View this message in context: http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-0-2-3-release-was-Re-Aerogear-Test-BOM-updates-tp8439p8443.html Sent from the aerogear-dev mailing list archive at Nabble.com. From daniel.bevenius at gmail.com Mon Jul 21 01:07:14 2014 From: daniel.bevenius at gmail.com (Daniel Bevenius) Date: Mon, 21 Jul 2014 07:07:14 +0200 Subject: [aerogear-dev] Team meeting Message-ID: Agenda: http://oksoclap.com/p/aerogear-team-mgt-20140721 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140721/f8d0270a/attachment.html From kpiwko at redhat.com Mon Jul 21 04:53:47 2014 From: kpiwko at redhat.com (Karel Piwko) Date: Mon, 21 Jul 2014 08:55:47 +0002 Subject: [aerogear-dev] 0.2.3 release (was Re: Aerogear Test BOM updates) In-Reply-To: References: Message-ID: <1405932827.26287.2@smtp.corp.redhat.com> Looks good, thanks! Any expectations when it will be synced to Maven Central? Thanks, Karel On Fri, Jul 18, 2014 at 12:19 PM, Matthias Wessendorf wrote: > Hey Karel, > > here is the staging repo: > http://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-3586/ > > please let me know if we can ship it to maven central > > -M > > > On Thu, Jul 17, 2014 at 1:47 PM, Matthias Wessendorf > wrote: >> >> >> >> On Thu, Jul 17, 2014 at 1:42 PM, Karel Piwko >> wrote: >>> Hi, >>> >>> I've updated test dependencies in Aerogear Test BOM, >>> https://github.com/aerogear/aerogear-parent/pull/10. It's time for >>> QE >>> to maintain dependency versions at the same place ;-) >> >> >> awesome! >> >>> >>> While this does not represent a full set of dependencies we use >>> yet, it >>> would be handy to have it in 0.2.3 or 0.3.0 release of Aerogear BOM. >>> >>> Is there such release planned? >> >> sure, we can release what ever version number you want :-) >> >>> >>> Thanks, >>> >>> Karel >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> >> -- >> Matthias Wessendorf >> >> blog: http://matthiaswessendorf.wordpress.com/ >> sessions: http://www.slideshare.net/mwessendorf >> twitter: http://twitter.com/mwessendorf > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf From matzew at apache.org Mon Jul 21 05:01:15 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Mon, 21 Jul 2014 11:01:15 +0200 Subject: [aerogear-dev] 0.2.3 release (was Re: Aerogear Test BOM updates) In-Reply-To: <1405932827.26287.2@smtp.corp.redhat.com> References: <1405932827.26287.2@smtp.corp.redhat.com> Message-ID: just pushed out to Maven Central On Mon, Jul 21, 2014 at 10:53 AM, Karel Piwko wrote: > Looks good, thanks! Any expectations when it will be synced to Maven > Central? > > Thanks, > > Karel > > On Fri, Jul 18, 2014 at 12:19 PM, Matthias Wessendorf > wrote: > > Hey Karel, > > > > here is the staging repo: > > > http://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-3586/ > > > > please let me know if we can ship it to maven central > > > > -M > > > > > > On Thu, Jul 17, 2014 at 1:47 PM, Matthias Wessendorf > > wrote: > >> > >> > >> > >> On Thu, Jul 17, 2014 at 1:42 PM, Karel Piwko > >> wrote: > >>> Hi, > >>> > >>> I've updated test dependencies in Aerogear Test BOM, > >>> https://github.com/aerogear/aerogear-parent/pull/10. It's time for > >>> QE > >>> to maintain dependency versions at the same place ;-) > >> > >> > >> awesome! > >> > >>> > >>> While this does not represent a full set of dependencies we use > >>> yet, it > >>> would be handy to have it in 0.2.3 or 0.3.0 release of Aerogear BOM. > >>> > >>> Is there such release planned? > >> > >> sure, we can release what ever version number you want :-) > >> > >>> > >>> Thanks, > >>> > >>> Karel > >>> > >>> _______________________________________________ > >>> aerogear-dev mailing list > >>> aerogear-dev at lists.jboss.org > >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev > >> > >> > >> > >> -- > >> Matthias Wessendorf > >> > >> blog: http://matthiaswessendorf.wordpress.com/ > >> sessions: http://www.slideshare.net/mwessendorf > >> twitter: http://twitter.com/mwessendorf > > > > > > > > -- > > Matthias Wessendorf > > > > blog: http://matthiaswessendorf.wordpress.com/ > > sessions: http://www.slideshare.net/mwessendorf > > twitter: http://twitter.com/mwessendorf > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140721/b8212307/attachment.html From matzew at apache.org Mon Jul 21 07:33:24 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Mon, 21 Jul 2014 13:33:24 +0200 Subject: [aerogear-dev] Use Case: Geo Location Pushes In-Reply-To: References: <53C40568.4090003@bliphead.com> Message-ID: here is the Epic to start tracking the "geo work" for our 1.1.x release https://issues.jboss.org/browse/AGPUSH-828 -Matthias On Mon, Jul 14, 2014 at 6:42 PM, Matthias Wessendorf wrote: > Hello, > > this summer we will have our 1.0.0, after that we might be looking at Geo > location for Push. We discussed that at our Face2Face meeting a few weeks > ago. > Thanks for the reminder that I should be filing some JIRAs for that > subject :-) > > -M > > > On Mon, Jul 14, 2014 at 6:29 PM, Chau Thai wrote: > >> Hello dear developers, >> >> We would like to build a push service triggered by the location of >> users. We have build a service with which users can save notes on a map. >> To inform other users of the creation of the note, we want to send all >> users in a given radius a push notification. >> The relevance of his current location is very important to fullfil this >> scenario. >> It would really help us if you could implement a feature to save the >> current geo location of the user via the existing register method. >> >> Thanks in advance >> Chau/Cydmax >> >> -- >> Chau Thai >> >> BLIPhead GmbH >> Paradiesstr. 9 >> 80538 M?nchen >> >> Tel +49 89 21111069 >> Fax +49 89 21111061 >> Mobil +49 176 70660664 >> >> chau at bliphead.com >> www.spreya.com >> >> Gesch?ftsf?hrer: Michael M?hlberger >> Amtsgericht M?nchen, HRB 190699 >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140721/c9415c04/attachment.html From cvasilak at gmail.com Mon Jul 21 10:18:56 2014 From: cvasilak at gmail.com (Christos Vasilakis) Date: Mon, 21 Jul 2014 17:18:56 +0300 Subject: [aerogear-dev] Team meeting In-Reply-To: References: Message-ID: <773BD0BC-4D04-48D3-B259-D5F3D50172CA@gmail.com> fyi, meeting minutes: Meeting ended Mon Jul 21 13:55:56 2014 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) Minutes: http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2014/aerogear.2014-07-21-13.41.html Minutes (text): http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2014/aerogear.2014-07-21-13.41.txt Log: http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2014/aerogear.2014-07-21-13.41.log.html On Jul 21, 2014, at 8:07 AM, Daniel Bevenius wrote: > Agenda: > > http://oksoclap.com/p/aerogear-team-mgt-20140721 > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140721/2f2c8d76/attachment-0001.html From supittma at redhat.com Mon Jul 21 11:36:01 2014 From: supittma at redhat.com (Summers Pittman) Date: Mon, 21 Jul 2014 11:36:01 -0400 Subject: [aerogear-dev] Authentication and Modularization Message-ID: <53CD3361.2060805@redhat.com> There's an open PR for the modularization of the Authentication APIs open on aerogear-android right now. [1] The Goal of this PR is, when we break the library into modules, we don't have circular dependencies between Authentication, Authorization, and Pipes. The PipeModule has been created for this purpose. Pipe module defines several points in the lifecycle of a request that a module can provide information to or edit. Currently this is based very heavily on the Authenticationmodule and AuthorizationModule classes. To get an idea of the idea I have for its end user usage, check Pipeline2 class and tests in my aerogear-android repo [2]. wdyt? 1) https://github.com/aerogear/aerogear-android/pull/155 2) https://github.com/secondsun/aerogear-android/blob/5095663fd216fe631545a19d0b9d0f8dbe493cf5/test/org/jboss/aerogear/android/impl/pipeline/ModularizedPipelineTest.java -- Summers Pittman >>Phone:404 941 4698 >>Java is my crack. From matzew at apache.org Mon Jul 21 11:59:38 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Mon, 21 Jul 2014 17:59:38 +0200 Subject: [aerogear-dev] Docs: update on the UPS docs Message-ID: Hi, right now we have a lot of different 'documentation files', like the README, some specs, and guides and tutorials. I'd like to restructure that a bit and centralize the documentation a bit. On the "push" landing page ([1]), I'd like to change the "Lean More" link to a new page that has all the UPS centric documentations - AeroGear UnifiedPush Server User/Reference Guide - Tutorials AeroGear UnifiedPush Server User/Reference Guide - Overview - some generic information - Installation and configuration - what's needed (e.g. JBoss and a database) - Running on OpenShift - using the UI on OpenShift - using the rhc command line - Using the Admin UI - doing an overhaul of our existing Admin UI guide (e.g. taking new screenshots and updating based on new UI features) The format of the *reference guide* would be similar to the one from Keycloak ([2]). But... I will continue using asciidoc ;-) The README will be extremely quick and simply link to the homepage ;-) After this *new* reference guide, I think some of the current specs can be removed, as the *reference guide* hopefully covers all of their content :-) For the RESTful APIs, I have to look what Keycloak did to get something like: http://docs.jboss.org/keycloak/docs/1.0-beta-3/rest-api/overview-index.html After the work as been completed, I will be revisiting the specs and evaluate their need ;-) Tutorials This section will contain links to all the different tutorials we have: - http://aerogear.org/docs/guides/aerogear-push-ios/ - http://aerogear.org/docs/guides/aerogear-push-js/ - http://aerogear.org/docs/guides/aerogear-push-android/ - http://aerogear.org/docs/guides/aerogear-push-chrome/ - http://aerogear.org/docs/guides/GetStartedwithJavaSender/ For Cordova we will have one single document, instead of three: - http://aerogear.org/docs/guides/aerogear-push-cordova-android/ - http://aerogear.org/docs/guides/aerogear-push-cordova-ios/ - http://aerogear.org/docs/guides/aerogear-cordova/AerogearCordovaPush/ There is already a JIRA for that ([4]). To make it more clear (or clean?), I will remove the UPS/Push related docs from our guides ([3]) and replace all those links by a single link to the above mentioned new page (also referenced from [1]). Greetings, Matthias - [1] http://aerogear.org/push/ - [2] http://docs.jboss.org/keycloak/docs/1.0-beta-3/userguide/html/index.html - [3] http://aerogear.org/docs/guides/ - [4] https://issues.jboss.org/browse/AGPUSH-805 -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140721/0e526044/attachment.html From bruno at abstractj.org Mon Jul 21 12:12:41 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Mon, 21 Jul 2014 09:12:41 -0700 (PDT) Subject: [aerogear-dev] Docs: update on the UPS docs In-Reply-To: References: Message-ID: <1405959161005.c69ee354@Nodemailer> +1? abstractj On Mon, Jul 21, 2014 at 1:00 PM, Matthias Wessendorf wrote: > Hi, > right now we have a lot of different 'documentation files', like the > README, some specs, and guides and tutorials. > I'd like to restructure that a bit and centralize the documentation a bit. > On the "push" landing page ([1]), I'd like to change the "Lean More" link > to a new page that has all the UPS centric documentations > - AeroGear UnifiedPush Server User/Reference Guide > - Tutorials > AeroGear > UnifiedPush Server User/Reference Guide > - Overview > - some generic information > - Installation and configuration > - what's needed (e.g. JBoss and a database) > - Running on OpenShift > - using the UI on OpenShift > - using the rhc command line > - Using the Admin UI > - doing an overhaul of our existing Admin UI guide (e.g. taking new > screenshots and updating based on new UI features) > The format of the *reference guide* would be similar to the one from > Keycloak ([2]). But... I will continue using asciidoc ;-) > The README will be extremely quick and simply link to the homepage ;-) > After this *new* reference guide, I think some of the current specs can be > removed, as the *reference guide* hopefully covers all of their content :-) > For the RESTful APIs, I have to look what Keycloak did to get something > like: > http://docs.jboss.org/keycloak/docs/1.0-beta-3/rest-api/overview-index.html > After the work as been completed, I will be revisiting the specs and > evaluate their need ;-) > Tutorials > This section will contain links to all the different tutorials we have: > - http://aerogear.org/docs/guides/aerogear-push-ios/ > - http://aerogear.org/docs/guides/aerogear-push-js/ > - http://aerogear.org/docs/guides/aerogear-push-android/ > - http://aerogear.org/docs/guides/aerogear-push-chrome/ > - http://aerogear.org/docs/guides/GetStartedwithJavaSender/ > For Cordova we will have one single document, instead of three: > - http://aerogear.org/docs/guides/aerogear-push-cordova-android/ > - http://aerogear.org/docs/guides/aerogear-push-cordova-ios/ > - http://aerogear.org/docs/guides/aerogear-cordova/AerogearCordovaPush/ > There is already a JIRA for that ([4]). > To make it more clear (or clean?), I will remove the UPS/Push related docs > from our guides ([3]) and replace all those links by a single link to the > above mentioned new page (also referenced from [1]). > Greetings, > Matthias > - [1] http://aerogear.org/push/ > - [2] > http://docs.jboss.org/keycloak/docs/1.0-beta-3/userguide/html/index.html > - [3] http://aerogear.org/docs/guides/ > - [4] https://issues.jboss.org/browse/AGPUSH-805 > -- > Matthias Wessendorf > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140721/daf1f91e/attachment-0001.html From daniel at passos.me Mon Jul 21 12:32:22 2014 From: daniel at passos.me (Daniel Passos) Date: Mon, 21 Jul 2014 13:32:22 -0300 Subject: [aerogear-dev] Docs: update on the UPS docs In-Reply-To: <1405959161005.c69ee354@Nodemailer> References: <1405959161005.c69ee354@Nodemailer> Message-ID: +9001 On Mon, Jul 21, 2014 at 1:12 PM, Bruno Oliveira wrote: > +1 > ? > abstractj > > > On Mon, Jul 21, 2014 at 1:00 PM, Matthias Wessendorf > wrote: > >> Hi, >> >> right now we have a lot of different 'documentation files', like the >> README, some specs, and guides and tutorials. >> >> I'd like to restructure that a bit and centralize the documentation a bit. >> >> On the "push" landing page ([1]), I'd like to change the "Lean More" link >> to a new page that has all the UPS centric documentations >> >> - AeroGear UnifiedPush Server User/Reference Guide >> - Tutorials >> >> >> AeroGear >> UnifiedPush Server User/Reference Guide >> >> - Overview >> - some generic information >> - Installation and configuration >> - what's needed (e.g. JBoss and a database) >> - Running on OpenShift >> - using the UI on OpenShift >> - using the rhc command line >> - Using the Admin UI >> - doing an overhaul of our existing Admin UI guide (e.g. taking >> new screenshots and updating based on new UI features) >> >> The format of the *reference guide* would be similar to the one from >> Keycloak ([2]). But... I will continue using asciidoc ;-) >> >> The README will be extremely quick and simply link to the homepage ;-) >> After this *new* reference guide, I think some of the current specs can >> be removed, as the *reference guide* hopefully covers all of their >> content :-) >> >> For the RESTful APIs, I have to look what Keycloak did to get something >> like: >> http://docs.jboss.org/keycloak/docs/1.0-beta-3/rest-api/overview-index.html >> >> After the work as been completed, I will be revisiting the specs and >> evaluate their need ;-) >> Tutorials >> >> This section will contain links to all the different tutorials we have: >> >> - http://aerogear.org/docs/guides/aerogear-push-ios/ >> - http://aerogear.org/docs/guides/aerogear-push-js/ >> - http://aerogear.org/docs/guides/aerogear-push-android/ >> - http://aerogear.org/docs/guides/aerogear-push-chrome/ >> - http://aerogear.org/docs/guides/GetStartedwithJavaSender/ >> >> For Cordova we will have one single document, instead of three: >> >> - http://aerogear.org/docs/guides/aerogear-push-cordova-android/ >> - http://aerogear.org/docs/guides/aerogear-push-cordova-ios/ >> - >> http://aerogear.org/docs/guides/aerogear-cordova/AerogearCordovaPush/ >> >> There is already a JIRA for that ([4]). >> >> To make it more clear (or clean?), I will remove the UPS/Push related >> docs from our guides ([3]) and replace all those links by a single link to >> the above mentioned new page (also referenced from [1]). >> >> Greetings, >> Matthias >> >> >> >> - [1] http://aerogear.org/push/ >> - [2] >> http://docs.jboss.org/keycloak/docs/1.0-beta-3/userguide/html/index.html >> - [3] http://aerogear.org/docs/guides/ >> - [4] https://issues.jboss.org/browse/AGPUSH-805 >> >> >> -- >> Matthias Wessendorf >> >> blog: http://matthiaswessendorf.wordpress.com/ >> sessions: http://www.slideshare.net/mwessendorf >> twitter: http://twitter.com/mwessendorf >> > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140721/d63cbb81/attachment.html From daniel.bevenius at gmail.com Mon Jul 21 12:38:15 2014 From: daniel.bevenius at gmail.com (Daniel Bevenius) Date: Mon, 21 Jul 2014 18:38:15 +0200 Subject: [aerogear-dev] Docs: update on the UPS docs In-Reply-To: References: <1405959161005.c69ee354@Nodemailer> Message-ID: +1 On 21 July 2014 18:32, Daniel Passos wrote: > +9001 > > > On Mon, Jul 21, 2014 at 1:12 PM, Bruno Oliveira > wrote: > >> +1 >> ? >> abstractj >> >> >> On Mon, Jul 21, 2014 at 1:00 PM, Matthias Wessendorf >> wrote: >> >>> Hi, >>> >>> right now we have a lot of different 'documentation files', like the >>> README, some specs, and guides and tutorials. >>> >>> I'd like to restructure that a bit and centralize the documentation a >>> bit. >>> >>> On the "push" landing page ([1]), I'd like to change the "Lean More" >>> link to a new page that has all the UPS centric documentations >>> >>> - AeroGear UnifiedPush Server User/Reference Guide >>> - Tutorials >>> >>> >>> AeroGear >>> UnifiedPush Server User/Reference Guide >>> >>> - Overview >>> - some generic information >>> - Installation and configuration >>> - what's needed (e.g. JBoss and a database) >>> - Running on OpenShift >>> - using the UI on OpenShift >>> - using the rhc command line >>> - Using the Admin UI >>> - doing an overhaul of our existing Admin UI guide (e.g. taking >>> new screenshots and updating based on new UI features) >>> >>> The format of the *reference guide* would be similar to the one from >>> Keycloak ([2]). But... I will continue using asciidoc ;-) >>> >>> The README will be extremely quick and simply link to the homepage ;-) >>> After this *new* reference guide, I think some of the current specs can >>> be removed, as the *reference guide* hopefully covers all of their >>> content :-) >>> >>> For the RESTful APIs, I have to look what Keycloak did to get something >>> like: >>> http://docs.jboss.org/keycloak/docs/1.0-beta-3/rest-api/overview-index.html >>> >>> After the work as been completed, I will be revisiting the specs and >>> evaluate their need ;-) >>> >>> Tutorials >>> >>> This section will contain links to all the different tutorials we have: >>> >>> - http://aerogear.org/docs/guides/aerogear-push-ios/ >>> - http://aerogear.org/docs/guides/aerogear-push-js/ >>> - http://aerogear.org/docs/guides/aerogear-push-android/ >>> - http://aerogear.org/docs/guides/aerogear-push-chrome/ >>> - http://aerogear.org/docs/guides/GetStartedwithJavaSender/ >>> >>> For Cordova we will have one single document, instead of three: >>> >>> - http://aerogear.org/docs/guides/aerogear-push-cordova-android/ >>> - http://aerogear.org/docs/guides/aerogear-push-cordova-ios/ >>> - >>> http://aerogear.org/docs/guides/aerogear-cordova/AerogearCordovaPush/ >>> >>> There is already a JIRA for that ([4]). >>> >>> To make it more clear (or clean?), I will remove the UPS/Push related >>> docs from our guides ([3]) and replace all those links by a single link to >>> the above mentioned new page (also referenced from [1]). >>> >>> Greetings, >>> Matthias >>> >>> >>> >>> - [1] http://aerogear.org/push/ >>> - [2] >>> http://docs.jboss.org/keycloak/docs/1.0-beta-3/userguide/html/index.html >>> - [3] http://aerogear.org/docs/guides/ >>> - [4] https://issues.jboss.org/browse/AGPUSH-805 >>> >>> >>> -- >>> Matthias Wessendorf >>> >>> blog: http://matthiaswessendorf.wordpress.com/ >>> sessions: http://www.slideshare.net/mwessendorf >>> twitter: http://twitter.com/mwessendorf >>> >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140721/c8dfb97f/attachment-0001.html From matzew at apache.org Tue Jul 22 04:00:45 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Tue, 22 Jul 2014 10:00:45 +0200 Subject: [aerogear-dev] UPS: Java Sender release Message-ID: Hi, I'd like to release the 0.8.0 version of the java-sender. The staging repo is here: http://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-3597/ Changes since last release: * AGPUSH-800 (need to be tested against master of UPS server) * AGPUSH-783 Please test and let me know! Thanks! -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140722/1056c16a/attachment.html From cvasilak at gmail.com Tue Jul 22 04:09:10 2014 From: cvasilak at gmail.com (Christos Vasilakis) Date: Tue, 22 Jul 2014 11:09:10 +0300 Subject: [aerogear-dev] Swift - Frameworks/Static libs and Cocoapods Message-ID: <47C5BA14-CB44-49EC-AF52-7D55DAFD26FD@gmail.com> Hi all, want to give a heads up on the current status of Swift frameworks/static libs generation and cocoapods support. This is based on the current state of affairs, as in Xcode beta 4 (released yesterday). Note: "Since rapid developments are taking place, will update this thread as more information becomes available and with any breaking changes" First, let me start by making three observations: a) quoting Apple release notes[1], "Xcode does not support building static libraries that include Swift code?. You can notice that in Xcode 6 when choosing ?Cocoa Touch Static Library? there is no option to select ?Swift? as the preferred language. b) new in Xcode 6 is the generation of ?dynamic? frameworks for library targets. The reason for ?dynamic? linking, as explained by apple in [2], is to enable the new functionality in iOS 8 called ?extensions?. Per apple quote "Frameworks work perfectly with extensions, sharing logic that can be used by both the main application, and the bundled extensions? c) Dynamic framework for a swift library (the only option offered by Xcode) , in the current state requires the source code of the library to be build together with the app that uses it. This is due to the binary interface, which has not being finalised yet. Quoting apple blog [3] ("Binary Compatibility and Frameworks? section): ? "While your app?s runtime compatibility is ensured, the Swift language itself will continue to evolve, and the binary interface will also change. To be safe, all components of your app should be built with the same version of Xcode and the Swift compiler to ensure that they work together. This means that frameworks need to be managed carefully. For instance, if your project uses frameworks to share code with an embedded extension, you will want to build the frameworks, app, and extensions together. It would be dangerous to rely upon binary frameworks that use Swift ? especially from third parties. As Swift changes, those frameworks will be incompatible with the rest of your app. When the binary interface stabilizes in a year or two, the Swift runtime will become part of the host OS and this limitation will no longer exist.? ? What does all that gives us? In plain form, "Distribution of the push-sdk (swift port) should be done in source form with polished documentation on how the user can add it to their own project.? Already, looking at the various swift-libs currently in existence[4], that is the current approach, a well-written README.md on how the user can add the library dependency into their own projects. For example, something like the section ?How to Install Library? found here [5] As for cocoapods, currently no support is provided for swift projects. There is an on-going discussion on the issues list found here [6] on how to effectively support ?dynamic framework? for swift projects, and still keep backwards compatibility, but things are not yet finalised. Let me know your thoughts / comments. Thanks, Christos [1] http://adcdownload.apple.com//Developer_Tools/xcode_6_beta_4_o2p8fz/xcode_6_beta_4_release_notes.pdf [2] https://developer.apple.com/library/prerelease/ios/documentation/DeveloperTools/Conceptual/WhatsNewXcode/Articles/xcode_6_0.html#//apple_ref/doc/uid/TP40014509-SW14 [3] https://developer.apple.com/swift/blog/?id=2 [4] http://www.swifttoolbox.io [5] https://github.com/Quick/Quick [6] https://github.com/CocoaPods/CocoaPods/issues/2272 From tkriz at redhat.com Tue Jul 22 04:13:19 2014 From: tkriz at redhat.com (Tadeas Kriz) Date: Tue, 22 Jul 2014 10:13:19 +0200 Subject: [aerogear-dev] UPS: Java Sender release In-Reply-To: References: Message-ID: <46E8BE1A-B34A-4729-903B-DD27D70974D1@redhat.com> Hey, it will get tested in the same run as UnifiedPush server using our integration tests suite. ? Tadeas Kriz On 22 Jul 2014, at 10:00 am, Matthias Wessendorf wrote: > Hi, > > I'd like to release the 0.8.0 version of the java-sender. The staging repo is here: > http://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-3597/ > > > Changes since last release: > * AGPUSH-800 (need to be tested against master of UPS server) > * AGPUSH-783 > > Please test and let me know! > > Thanks! > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140722/d804d303/attachment.html From matzew at apache.org Tue Jul 22 04:31:15 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Tue, 22 Jul 2014 10:31:15 +0200 Subject: [aerogear-dev] UPS: Java Sender release In-Reply-To: <46E8BE1A-B34A-4729-903B-DD27D70974D1@redhat.com> References: <46E8BE1A-B34A-4729-903B-DD27D70974D1@redhat.com> Message-ID: awesome! On Tue, Jul 22, 2014 at 10:13 AM, Tadeas Kriz wrote: > Hey, > > it will get tested in the same run as UnifiedPush server using our > integration tests suite. > > ? > Tadeas Kriz > > On 22 Jul 2014, at 10:00 am, Matthias Wessendorf > wrote: > > Hi, > > I'd like to release the 0.8.0 version of the java-sender. The staging repo > is here: > > http://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-3597/ > > > Changes since last release: > * AGPUSH-800 (need to be tested against master of UPS server) > * AGPUSH-783 > > Please test and let me know! > > Thanks! > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140722/61e956cc/attachment.html From corinnekrych at gmail.com Tue Jul 22 04:48:30 2014 From: corinnekrych at gmail.com (Corinne Krych) Date: Tue, 22 Jul 2014 10:48:30 +0200 Subject: [aerogear-dev] Swift - Frameworks/Static libs and Cocoapods In-Reply-To: <47C5BA14-CB44-49EC-AF52-7D55DAFD26FD@gmail.com> References: <47C5BA14-CB44-49EC-AF52-7D55DAFD26FD@gmail.com> Message-ID: Thanks for this detailled explantion on the state of dynamic fwk in Swift! #agree with you, things are changing rapidly. Specially OSS dev around it. For now github submodule/Xcode project included with Readme instruction will do. With a better cocoapods support we will eventually get rid of gh submodules. As per Apple dynamic fwk, quoting yout quote: ?... stabilizes in a year or two? sounds like a longer run. Let?s keep a close watch on how it evolves. ++ Corinne On 22 Jul 2014, at 10:09, Christos Vasilakis wrote: > Hi all, > > want to give a heads up on the current status of Swift frameworks/static libs generation and cocoapods support. This is based on the current state of affairs, as in Xcode beta 4 (released yesterday). > > Note: "Since rapid developments are taking place, will update this thread as more information becomes available and with any breaking changes" > > First, let me start by making three observations: > > a) quoting Apple release notes[1], "Xcode does not support building static libraries that include Swift code?. You can notice that in Xcode 6 when choosing ?Cocoa Touch Static Library? there is no option to select ?Swift? as the preferred language. > > b) new in Xcode 6 is the generation of ?dynamic? frameworks for library targets. The reason for ?dynamic? linking, as explained by apple in [2], is to enable the new functionality in iOS 8 called ?extensions?. Per apple quote "Frameworks work perfectly with extensions, sharing logic that can be used by both the main application, and the bundled extensions? > > c) Dynamic framework for a swift library (the only option offered by Xcode) , in the current state requires the source code of the library to be build together with the app that uses it. This is due to the binary interface, which has not being finalised yet. Quoting apple blog [3] ("Binary Compatibility and Frameworks? section): > > ? > "While your app?s runtime compatibility is ensured, the Swift language itself will continue to evolve, and the binary interface will also change. To be safe, all components of your app should be built with the same version of Xcode and the Swift compiler to ensure that they work together. > > This means that frameworks need to be managed carefully. For instance, if your project uses frameworks to share code with an embedded extension, you will want to build the frameworks, app, and extensions together. It would be dangerous to rely upon binary frameworks that use Swift ? especially from third parties. As Swift changes, those frameworks will be incompatible with the rest of your app. When the binary interface stabilizes in a year or two, the Swift runtime will become part of the host OS and this limitation will no longer exist.? > ? > > What does all that gives us? > In plain form, "Distribution of the push-sdk (swift port) should be done in source form with polished documentation on how the user can add it to their own project.? > > Already, looking at the various swift-libs currently in existence[4], that is the current approach, a well-written README.md on how the user can add the library dependency into their own projects. For example, something like the section ?How to Install Library? found here [5] > > As for cocoapods, currently no support is provided for swift projects. There is an on-going discussion on the issues list found here [6] on how to effectively support ?dynamic framework? for swift projects, and still keep backwards compatibility, but things are not yet finalised. > > Let me know your thoughts / comments. > > Thanks, > Christos > > [1] http://adcdownload.apple.com//Developer_Tools/xcode_6_beta_4_o2p8fz/xcode_6_beta_4_release_notes.pdf > [2] https://developer.apple.com/library/prerelease/ios/documentation/DeveloperTools/Conceptual/WhatsNewXcode/Articles/xcode_6_0.html#//apple_ref/doc/uid/TP40014509-SW14 > [3] https://developer.apple.com/swift/blog/?id=2 > [4] http://www.swifttoolbox.io > [5] https://github.com/Quick/Quick > [6] https://github.com/CocoaPods/CocoaPods/issues/2272 > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev From scm.blanc at gmail.com Tue Jul 22 04:58:02 2014 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Tue, 22 Jul 2014 10:58:02 +0200 Subject: [aerogear-dev] Simplify Security of AeroDoc Message-ID: Hi All ! I'm currently working on APGUSH-810[1] which consist in removing the dependency we still had on the deprecated aerogear-security project (RIP my friend). But now, if I want to keep AeroDoc, feature equal as before, I have to add a LOT of code around security (to handle role, annotations etc ...). AeroDoc is already quite complex and time consuming to maintain and the core scope is not security but advanced Push. So ... What I would like to propose is to keep only the authentification (log in) and remove all the role handling part to simplify it. The only effect that this will introduce, is that a logged in user can also access the admin to create leads. Wdyt ? Sebi [1] https://issues.jboss.org/browse/AGPUSH-810 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140722/c576d255/attachment-0001.html From matzew at apache.org Tue Jul 22 05:00:14 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Tue, 22 Jul 2014 11:00:14 +0200 Subject: [aerogear-dev] Simplify Security of AeroDoc In-Reply-To: References: Message-ID: On Tue, Jul 22, 2014 at 10:58 AM, Sebastien Blanc wrote: > Hi All ! > > I'm currently working on APGUSH-810[1] which consist in removing the > dependency we still had on the deprecated aerogear-security project (RIP my > friend). > > But now, if I want to keep AeroDoc, feature equal as before, I have to add > a LOT of code around security (to handle role, annotations etc ...). > AeroDoc is already quite complex and time consuming to maintain and the > core scope is not security but advanced Push. > > So ... What I would like to propose is to keep only the authentification > (log in) and remove all the role handling part to simplify it. > > The only effect that this will introduce, is that a logged in user can > also access the admin to create leads. > that is fine w/ me > > > Wdyt ? > > Sebi > > > [1] https://issues.jboss.org/browse/AGPUSH-810 > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140722/5930f720/attachment.html From daniel.bevenius at gmail.com Tue Jul 22 05:02:12 2014 From: daniel.bevenius at gmail.com (Daniel Bevenius) Date: Tue, 22 Jul 2014 11:02:12 +0200 Subject: [aerogear-dev] Simplify Security of AeroDoc In-Reply-To: References: Message-ID: +1 Less maintenance sounds good to me. On 22 July 2014 11:00, Matthias Wessendorf wrote: > > > > On Tue, Jul 22, 2014 at 10:58 AM, Sebastien Blanc > wrote: > >> Hi All ! >> >> I'm currently working on APGUSH-810[1] which consist in removing the >> dependency we still had on the deprecated aerogear-security project (RIP my >> friend). >> >> But now, if I want to keep AeroDoc, feature equal as before, I have to >> add a LOT of code around security (to handle role, annotations etc ...). >> AeroDoc is already quite complex and time consuming to maintain and the >> core scope is not security but advanced Push. >> >> So ... What I would like to propose is to keep only the authentification >> (log in) and remove all the role handling part to simplify it. >> >> The only effect that this will introduce, is that a logged in user can >> also access the admin to create leads. >> > > that is fine w/ me > >> >> >> Wdyt ? >> >> Sebi >> >> >> [1] https://issues.jboss.org/browse/AGPUSH-810 >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140722/c65c3ff8/attachment.html From bruno at abstractj.org Tue Jul 22 06:42:20 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Tue, 22 Jul 2014 07:42:20 -0300 Subject: [aerogear-dev] AeroGear Crypto Java 0.1.4 Staged Message-ID: <20140722104220.GA42479@abstractj.org> Good morning peeps, AeroGear Crypto 0.1.4 was staged today for testing at https://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-3599. The major changes relates to PKCS validation, borrowed from AG Security -- abstractj PGP: 0x84DC9914 From bruno at abstractj.org Tue Jul 22 07:10:26 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Tue, 22 Jul 2014 08:10:26 -0300 Subject: [aerogear-dev] Simplify Security of AeroDoc In-Reply-To: References: Message-ID: <20140722111026.GA43037@abstractj.org> +1 What about make use of KC instead? On 2014-07-22, Daniel Bevenius wrote: > +1 Less maintenance sounds good to me. > > > On 22 July 2014 11:00, Matthias Wessendorf wrote: > > > > > > > > > On Tue, Jul 22, 2014 at 10:58 AM, Sebastien Blanc > > wrote: > > > >> Hi All ! > >> > >> I'm currently working on APGUSH-810[1] which consist in removing the > >> dependency we still had on the deprecated aerogear-security project (RIP my > >> friend). > >> > >> But now, if I want to keep AeroDoc, feature equal as before, I have to > >> add a LOT of code around security (to handle role, annotations etc ...). > >> AeroDoc is already quite complex and time consuming to maintain and the > >> core scope is not security but advanced Push. > >> > >> So ... What I would like to propose is to keep only the authentification > >> (log in) and remove all the role handling part to simplify it. > >> > >> The only effect that this will introduce, is that a logged in user can > >> also access the admin to create leads. > >> > > > > that is fine w/ me > > > >> > >> > >> Wdyt ? > >> > >> Sebi > >> > >> > >> [1] https://issues.jboss.org/browse/AGPUSH-810 > >> > >> _______________________________________________ > >> aerogear-dev mailing list > >> aerogear-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > >> > > > > > > > > -- > > Matthias Wessendorf > > > > blog: http://matthiaswessendorf.wordpress.com/ > > sessions: http://www.slideshare.net/mwessendorf > > twitter: http://twitter.com/mwessendorf > > > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -- abstractj PGP: 0x84DC9914 From matzew at apache.org Tue Jul 22 07:15:14 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Tue, 22 Jul 2014 13:15:14 +0200 Subject: [aerogear-dev] Simplify Security of AeroDoc In-Reply-To: <20140722111026.GA43037@abstractj.org> References: <20140722111026.GA43037@abstractj.org> Message-ID: I think moving to Keycloak would be nice once we have the 1.0.0 mobile push release, as this has impact on login of all the different AeroDoc client apps (Android, iOS, FirefoxOS and JavaScript). -Matthias On Tue, Jul 22, 2014 at 1:10 PM, Bruno Oliveira wrote: > +1 What about make use of KC instead? > > On 2014-07-22, Daniel Bevenius wrote: > > +1 Less maintenance sounds good to me. > > > > > > On 22 July 2014 11:00, Matthias Wessendorf wrote: > > > > > > > > > > > > > > On Tue, Jul 22, 2014 at 10:58 AM, Sebastien Blanc > > > > wrote: > > > > > >> Hi All ! > > >> > > >> I'm currently working on APGUSH-810[1] which consist in removing the > > >> dependency we still had on the deprecated aerogear-security project > (RIP my > > >> friend). > > >> > > >> But now, if I want to keep AeroDoc, feature equal as before, I have to > > >> add a LOT of code around security (to handle role, annotations etc > ...). > > >> AeroDoc is already quite complex and time consuming to maintain and > the > > >> core scope is not security but advanced Push. > > >> > > >> So ... What I would like to propose is to keep only the > authentification > > >> (log in) and remove all the role handling part to simplify it. > > >> > > >> The only effect that this will introduce, is that a logged in user can > > >> also access the admin to create leads. > > >> > > > > > > that is fine w/ me > > > > > >> > > >> > > >> Wdyt ? > > >> > > >> Sebi > > >> > > >> > > >> [1] https://issues.jboss.org/browse/AGPUSH-810 > > >> > > >> _______________________________________________ > > >> aerogear-dev mailing list > > >> aerogear-dev at lists.jboss.org > > >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > >> > > > > > > > > > > > > -- > > > Matthias Wessendorf > > > > > > blog: http://matthiaswessendorf.wordpress.com/ > > > sessions: http://www.slideshare.net/mwessendorf > > > twitter: http://twitter.com/mwessendorf > > > > > > _______________________________________________ > > > aerogear-dev mailing list > > > aerogear-dev at lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > -- > > abstractj > PGP: 0x84DC9914 > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140722/e63f36bf/attachment-0001.html From matzew at apache.org Tue Jul 22 07:17:56 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Tue, 22 Jul 2014 13:17:56 +0200 Subject: [aerogear-dev] AeroGear Crypto Java 0.1.4 Staged In-Reply-To: <20140722104220.GA42479@abstractj.org> References: <20140722104220.GA42479@abstractj.org> Message-ID: +1 on this release! (have tested and build the tag) -M On Tue, Jul 22, 2014 at 12:42 PM, Bruno Oliveira wrote: > Good morning peeps, > > AeroGear Crypto 0.1.4 was staged today for testing at > > https://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-3599 > . > The major changes relates to PKCS validation, borrowed from AG > Security > -- > > abstractj > PGP: 0x84DC9914 > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140722/86462d3b/attachment.html From scm.blanc at gmail.com Tue Jul 22 08:14:33 2014 From: scm.blanc at gmail.com (=?utf-8?Q?S=C3=A9bastien_Blanc?=) Date: Tue, 22 Jul 2014 14:14:33 +0200 Subject: [aerogear-dev] Simplify Security of AeroDoc In-Reply-To: <20140722111026.GA43037@abstractj.org> References: <20140722111026.GA43037@abstractj.org> Message-ID: Yep , I had the same idea and will be a good showcase for the client KC sdks. But as Matzew , let's do that after 1.0 Envoy? de mon iPhone > Le 22 juil. 2014 ? 13:10, Bruno Oliveira a ?crit : > > +1 What about make use of KC instead? > >> On 2014-07-22, Daniel Bevenius wrote: >> +1 Less maintenance sounds good to me. >> >> >>> On 22 July 2014 11:00, Matthias Wessendorf wrote: >>> >>> >>> >>> >>> On Tue, Jul 22, 2014 at 10:58 AM, Sebastien Blanc >>> wrote: >>> >>>> Hi All ! >>>> >>>> I'm currently working on APGUSH-810[1] which consist in removing the >>>> dependency we still had on the deprecated aerogear-security project (RIP my >>>> friend). >>>> >>>> But now, if I want to keep AeroDoc, feature equal as before, I have to >>>> add a LOT of code around security (to handle role, annotations etc ...). >>>> AeroDoc is already quite complex and time consuming to maintain and the >>>> core scope is not security but advanced Push. >>>> >>>> So ... What I would like to propose is to keep only the authentification >>>> (log in) and remove all the role handling part to simplify it. >>>> >>>> The only effect that this will introduce, is that a logged in user can >>>> also access the admin to create leads. >>> >>> that is fine w/ me >>> >>>> >>>> >>>> Wdyt ? >>>> >>>> Sebi >>>> >>>> >>>> [1] https://issues.jboss.org/browse/AGPUSH-810 >>>> >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >>> >>> >>> -- >>> Matthias Wessendorf >>> >>> blog: http://matthiaswessendorf.wordpress.com/ >>> sessions: http://www.slideshare.net/mwessendorf >>> twitter: http://twitter.com/mwessendorf >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev > >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > -- > > abstractj > PGP: 0x84DC9914 > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev From cvasilak at gmail.com Tue Jul 22 08:30:49 2014 From: cvasilak at gmail.com (Christos Vasilakis) Date: Tue, 22 Jul 2014 15:30:49 +0300 Subject: [aerogear-dev] iOS meeting In-Reply-To: <02232370-3C6A-4ADB-922C-4F61F2D42B66@gmail.com> References: <02232370-3C6A-4ADB-922C-4F61F2D42B66@gmail.com> Message-ID: fyi, meeting minutes: Meeting ended Tue Jul 22 12:10:05 2014 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) Minutes: http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2014/aerogear.2014-07-22-11.49.html Minutes (text): http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2014/aerogear.2014-07-22-11.49.txt Log: http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2014/aerogear.2014-07-22-11.49.log.html On Jul 18, 2014, at 1:35 PM, Corinne Krych wrote: > Hello iOS lovers, > > Let?s make a point we?re we are for July release and discuss 2.0 for September. > We'll use our usual Tuesday slot. See you Tuesday 22nd July at 2pm (CEST - UTC + 2hours). Here is a proposal agenda: > > http://oksoclap.com/p/aerogear_ios_22July2014 > > Feel free to add topics you would like to discuss. > > See you all Tuesday! > > ++ > Corinne > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev From lholmqui at redhat.com Tue Jul 22 08:52:53 2014 From: lholmqui at redhat.com (Lucas Holmquist) Date: Tue, 22 Jul 2014 08:52:53 -0400 Subject: [aerogear-dev] Swift - Frameworks/Static libs and Cocoapods In-Reply-To: <47C5BA14-CB44-49EC-AF52-7D55DAFD26FD@gmail.com> References: <47C5BA14-CB44-49EC-AF52-7D55DAFD26FD@gmail.com> Message-ID: <4EA4D267-9C96-4727-AED4-C0D2D232C703@redhat.com> very interesting On Jul 22, 2014, at 4:09 AM, Christos Vasilakis wrote: > Hi all, > > want to give a heads up on the current status of Swift frameworks/static libs generation and cocoapods support. This is based on the current state of affairs, as in Xcode beta 4 (released yesterday). > > Note: "Since rapid developments are taking place, will update this thread as more information becomes available and with any breaking changes" > > First, let me start by making three observations: > > a) quoting Apple release notes[1], "Xcode does not support building static libraries that include Swift code?. You can notice that in Xcode 6 when choosing ?Cocoa Touch Static Library? there is no option to select ?Swift? as the preferred language. > > b) new in Xcode 6 is the generation of ?dynamic? frameworks for library targets. The reason for ?dynamic? linking, as explained by apple in [2], is to enable the new functionality in iOS 8 called ?extensions?. Per apple quote "Frameworks work perfectly with extensions, sharing logic that can be used by both the main application, and the bundled extensions? > > c) Dynamic framework for a swift library (the only option offered by Xcode) , in the current state requires the source code of the library to be build together with the app that uses it. This is due to the binary interface, which has not being finalised yet. Quoting apple blog [3] ("Binary Compatibility and Frameworks? section): > > ? > "While your app?s runtime compatibility is ensured, the Swift language itself will continue to evolve, and the binary interface will also change. To be safe, all components of your app should be built with the same version of Xcode and the Swift compiler to ensure that they work together. > > This means that frameworks need to be managed carefully. For instance, if your project uses frameworks to share code with an embedded extension, you will want to build the frameworks, app, and extensions together. It would be dangerous to rely upon binary frameworks that use Swift ? especially from third parties. As Swift changes, those frameworks will be incompatible with the rest of your app. When the binary interface stabilizes in a year or two, the Swift runtime will become part of the host OS and this limitation will no longer exist.? > ? > > What does all that gives us? > In plain form, "Distribution of the push-sdk (swift port) should be done in source form with polished documentation on how the user can add it to their own project.? > > Already, looking at the various swift-libs currently in existence[4], that is the current approach, a well-written README.md on how the user can add the library dependency into their own projects. For example, something like the section ?How to Install Library? found here [5] > > As for cocoapods, currently no support is provided for swift projects. There is an on-going discussion on the issues list found here [6] on how to effectively support ?dynamic framework? for swift projects, and still keep backwards compatibility, but things are not yet finalised. > > Let me know your thoughts / comments. > > Thanks, > Christos > > [1] http://adcdownload.apple.com//Developer_Tools/xcode_6_beta_4_o2p8fz/xcode_6_beta_4_release_notes.pdf > [2] https://developer.apple.com/library/prerelease/ios/documentation/DeveloperTools/Conceptual/WhatsNewXcode/Articles/xcode_6_0.html#//apple_ref/doc/uid/TP40014509-SW14 > [3] https://developer.apple.com/swift/blog/?id=2 > [4] http://www.swifttoolbox.io > [5] https://github.com/Quick/Quick > [6] https://github.com/CocoaPods/CocoaPods/issues/2272 > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev From daniel at passos.me Tue Jul 22 10:11:20 2014 From: daniel at passos.me (Daniel Passos) Date: Tue, 22 Jul 2014 11:11:20 -0300 Subject: [aerogear-dev] Travis discussion about android Message-ID: Hey Guys, Today travis-ci have no native support for Android projects. We need to download the sdk, install a lot of things just to run our test suite. This process turns our builds slow and sometimes the test run just timeouts. Some months ago the travis-ci team started to take a look at some solutions to support Android build natively. I?m in touch with some travis-ci guys, doing some tests[1] and participating on some discussions. Travis released a first beta version for the community to test, but unfortunately it doesn?t support maven-sdk-deploy[2] - we are talking[3] about it for the next release. See more: - https://github.com/travis-ci/travis-ci/issues/2296#issuecomment-47421718 - http://docs.travis-ci.com/user/languages/android/ [1] https://github.com/danielpassos/aerogear-android-push/blob/travis_android/.travis.yml [2] https://github.com/mosabua/maven-android-sdk-deployer [3] https://github.com/travis-ci/travis-ci/issues/2280 -- Passos ? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140722/a39a4099/attachment.html From daniel at passos.me Tue Jul 22 10:12:07 2014 From: daniel at passos.me (Daniel Passos) Date: Tue, 22 Jul 2014 11:12:07 -0300 Subject: [aerogear-dev] Modularizing the Android Library In-Reply-To: <4CD71A7A-EDE1-4648-AB3E-E4DDB383D824@gmail.com> References: <5317317F.1010209@redhat.com> <20140306143829.65e1e4aa@kapy-ntb-x220> <20140508192800.GB69433@abstractj.org> <4CD71A7A-EDE1-4648-AB3E-E4DDB383D824@gmail.com> Message-ID: Hey Guys, Summers and I started working on agdroid modules and remove some cyclic dependencies. So we plan to split the agdroid on these modules: - aerogear-android-core - aerogear-android-pipe - aerogear-android-auth - aerogear-android-autz - aerogear-android-store (with option security dependecy to use EncryptedStores) - aerogear-android-security - aerogear-android-push - aerogear-android-push-ups - aerogear-android-offline -- Passos ? On Fri, May 9, 2014 at 3:55 AM, Corinne Krych wrote: > Oops > [2] https://issues.jboss.org/browse/AGIOS-187 > > On 09 May 2014, at 08:52, Corinne Krych wrote: > > > [2] https://issues.jboss.org/browse/AGIOS-192 > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140722/54475497/attachment-0001.html From lholmqui at redhat.com Tue Jul 22 10:14:03 2014 From: lholmqui at redhat.com (Lucas Holmquist) Date: Tue, 22 Jul 2014 10:14:03 -0400 Subject: [aerogear-dev] Modularizing the Android Library In-Reply-To: References: <5317317F.1010209@redhat.com> <20140306143829.65e1e4aa@kapy-ntb-x220> <20140508192800.GB69433@abstractj.org> <4CD71A7A-EDE1-4648-AB3E-E4DDB383D824@gmail.com> Message-ID: On Jul 22, 2014, at 10:12 AM, Daniel Passos wrote: > Hey Guys, > > Summers and I started working on agdroid modules and remove some cyclic dependencies. So we plan to split the agdroid on these modules: > > aerogear-android-core > aerogear-android-pipe > aerogear-android-auth > aerogear-android-autz should that be authz > aerogear-android-store (with option security dependecy to use EncryptedStores) > aerogear-android-security > aerogear-android-push > aerogear-android-push-ups > aerogear-android-offline > -- Passos > ? > > > On Fri, May 9, 2014 at 3:55 AM, Corinne Krych wrote: > Oops > [2] https://issues.jboss.org/browse/AGIOS-187 > > On 09 May 2014, at 08:52, Corinne Krych wrote: > > > [2] https://issues.jboss.org/browse/AGIOS-192 > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140722/18a79e96/attachment.html From daniel.bevenius at gmail.com Tue Jul 22 10:14:58 2014 From: daniel.bevenius at gmail.com (Daniel Bevenius) Date: Tue, 22 Jul 2014 16:14:58 +0200 Subject: [aerogear-dev] Travis discussion about android In-Reply-To: References: Message-ID: nice! On 22 July 2014 16:11, Daniel Passos wrote: > Hey Guys, > > Today travis-ci have no native support for Android projects. We need to > download the sdk, install a lot of things just to run our test suite. This > process turns our builds slow and sometimes the test run just timeouts. > > Some months ago the travis-ci team started to take a look at some > solutions to support Android build natively. > > I?m in touch with some travis-ci guys, doing some tests[1] and > participating on some discussions. Travis released a first beta version for > the community to test, but unfortunately it doesn?t support > maven-sdk-deploy[2] - we are talking[3] about it for the next release. > > See more: > > - > https://github.com/travis-ci/travis-ci/issues/2296#issuecomment-47421718 > - http://docs.travis-ci.com/user/languages/android/ > > [1] > https://github.com/danielpassos/aerogear-android-push/blob/travis_android/.travis.yml > [2] https://github.com/mosabua/maven-android-sdk-deployer > [3] https://github.com/travis-ci/travis-ci/issues/2280 > > -- Passos > ? > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140722/b54a379b/attachment.html From daniel at passos.me Tue Jul 22 10:16:10 2014 From: daniel at passos.me (Daniel Passos) Date: Tue, 22 Jul 2014 11:16:10 -0300 Subject: [aerogear-dev] Modularizing the Android Library In-Reply-To: References: <5317317F.1010209@redhat.com> <20140306143829.65e1e4aa@kapy-ntb-x220> <20140508192800.GB69433@abstractj.org> <4CD71A7A-EDE1-4648-AB3E-E4DDB383D824@gmail.com> Message-ID: Yeap, a little typo :) On Tue, Jul 22, 2014 at 11:14 AM, Lucas Holmquist wrote: > > On Jul 22, 2014, at 10:12 AM, Daniel Passos wrote: > > Hey Guys, > > Summers and I started working on agdroid modules and remove some cyclic > dependencies. So we plan to split the agdroid on these modules: > > - aerogear-android-core > - aerogear-android-pipe > - aerogear-android-auth > - aerogear-android-autz > > should that be authz > > > - aerogear-android-store (with option security dependecy to use > EncryptedStores) > - aerogear-android-security > - aerogear-android-push > - aerogear-android-push-ups > - aerogear-android-offline > > -- Passos > ? > > > On Fri, May 9, 2014 at 3:55 AM, Corinne Krych > wrote: > >> Oops >> [2] https://issues.jboss.org/browse/AGIOS-187 >> >> On 09 May 2014, at 08:52, Corinne Krych wrote: >> >> > [2] https://issues.jboss.org/browse/AGIOS-192 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140722/f79bc053/attachment.html From corinnekrych at gmail.com Tue Jul 22 10:20:24 2014 From: corinnekrych at gmail.com (Corinne Krych) Date: Tue, 22 Jul 2014 16:20:24 +0200 Subject: [aerogear-dev] Modularizing the Android Library In-Reply-To: References: <5317317F.1010209@redhat.com> <20140306143829.65e1e4aa@kapy-ntb-x220> <20140508192800.GB69433@abstractj.org> <4CD71A7A-EDE1-4648-AB3E-E4DDB383D824@gmail.com> Message-ID: <4E71A4E1-4E3F-4A89-B8F1-65D0003B4A9B@gmail.com> On 22 Jul 2014, at 16:12, Daniel Passos wrote: > Hey Guys, > > Summers and I started working on agdroid modules and remove some cyclic dependencies. So we plan to split the agdroid on these modules: > > ? aerogear-android-core > ? aerogear-android-pipe > ? aerogear-android-auth > ? aerogear-android-autz > ? aerogear-android-store (with option security dependecy to use EncryptedStores) > ? aerogear-android-security > ? aerogear-android-push > ? aerogear-android-push-ups what will be the difference between push and push-ups? > ? aerogear-android-offline > -- Passos > ? > > > On Fri, May 9, 2014 at 3:55 AM, Corinne Krych wrote: > Oops > [2] https://issues.jboss.org/browse/AGIOS-187 > > On 09 May 2014, at 08:52, Corinne Krych wrote: > > > [2] https://issues.jboss.org/browse/AGIOS-192 > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev From matzew at apache.org Tue Jul 22 10:52:27 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Tue, 22 Jul 2014 16:52:27 +0200 Subject: [aerogear-dev] Travis discussion about android In-Reply-To: References: Message-ID: Awesome! Thanks for the heads-up! On Tue, Jul 22, 2014 at 4:14 PM, Daniel Bevenius wrote: > nice! > > > On 22 July 2014 16:11, Daniel Passos wrote: > >> Hey Guys, >> >> Today travis-ci have no native support for Android projects. We need to >> download the sdk, install a lot of things just to run our test suite. This >> process turns our builds slow and sometimes the test run just timeouts. >> >> Some months ago the travis-ci team started to take a look at some >> solutions to support Android build natively. >> >> I?m in touch with some travis-ci guys, doing some tests[1] and >> participating on some discussions. Travis released a first beta version for >> the community to test, but unfortunately it doesn?t support >> maven-sdk-deploy[2] - we are talking[3] about it for the next release. >> >> See more: >> >> - >> https://github.com/travis-ci/travis-ci/issues/2296#issuecomment-47421718 >> - http://docs.travis-ci.com/user/languages/android/ >> >> [1] >> https://github.com/danielpassos/aerogear-android-push/blob/travis_android/.travis.yml >> [2] https://github.com/mosabua/maven-android-sdk-deployer >> [3] https://github.com/travis-ci/travis-ci/issues/2280 >> >> -- Passos >> ? >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140722/c78c1258/attachment-0001.html From cvasilak at gmail.com Tue Jul 22 11:00:27 2014 From: cvasilak at gmail.com (Christos Vasilakis) Date: Tue, 22 Jul 2014 18:00:27 +0300 Subject: [aerogear-dev] Travis discussion about android In-Reply-To: References: Message-ID: nice Passos thanks for the heads up! - Christos On Jul 22, 2014, at 5:11 PM, Daniel Passos wrote: > Hey Guys, > > Today travis-ci have no native support for Android projects. We need to download the sdk, install a lot of things just to run our test suite. This process turns our builds slow and sometimes the test run just timeouts. > > Some months ago the travis-ci team started to take a look at some solutions to support Android build natively. > > I?m in touch with some travis-ci guys, doing some tests[1] and participating on some discussions. Travis released a first beta version for the community to test, but unfortunately it doesn?t support maven-sdk-deploy[2] - we are talking[3] about it for the next release. > > See more: > > https://github.com/travis-ci/travis-ci/issues/2296#issuecomment-47421718 > http://docs.travis-ci.com/user/languages/android/ > [1] https://github.com/danielpassos/aerogear-android-push/blob/travis_android/.travis.yml > [2] https://github.com/mosabua/maven-android-sdk-deployer > [3] https://github.com/travis-ci/travis-ci/issues/2280 > > -- Passos > > ? > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140722/58ddfd8c/attachment.html From bruno at abstractj.org Tue Jul 22 11:06:11 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Tue, 22 Jul 2014 12:06:11 -0300 Subject: [aerogear-dev] Modularizing the Android Library In-Reply-To: References: <5317317F.1010209@redhat.com> <20140306143829.65e1e4aa@kapy-ntb-x220> <20140508192800.GB69433@abstractj.org> <4CD71A7A-EDE1-4648-AB3E-E4DDB383D824@gmail.com> Message-ID: <20140722150611.GA58163@abstractj.org> Passos, what does aerogear-android-security stands for? Do we really need the authz module? My question is due to the fact that mostly it will be together with auth module, but I could be wrong. On 2014-07-22, Daniel Passos wrote: > Hey Guys, > > Summers and I started working on agdroid modules and remove some cyclic > dependencies. So we plan to split the agdroid on these modules: > > - aerogear-android-core > - aerogear-android-pipe > - aerogear-android-auth > - aerogear-android-autz > - aerogear-android-store (with option security dependecy to use > EncryptedStores) > - aerogear-android-security > - aerogear-android-push > - aerogear-android-push-ups > - aerogear-android-offline > > -- Passos > ? > > > On Fri, May 9, 2014 at 3:55 AM, Corinne Krych > wrote: > > > Oops > > [2] https://issues.jboss.org/browse/AGIOS-187 > > > > On 09 May 2014, at 08:52, Corinne Krych wrote: > > > > > [2] https://issues.jboss.org/browse/AGIOS-192 > > > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -- abstractj PGP: 0x84DC9914 From kpiwko at redhat.com Tue Jul 22 13:22:04 2014 From: kpiwko at redhat.com (Karel Piwko) Date: Tue, 22 Jul 2014 17:24:04 +0002 Subject: [aerogear-dev] Travis discussion about android In-Reply-To: References: Message-ID: <1406049724.14164.4@smtp.corp.redhat.com> Awesome news! And [3] will also help Jenkins CI. On Tue, Jul 22, 2014 at 4:11 PM, Daniel Passos wrote: > Hey Guys, > > Today travis-ci have no native support for Android projects. We need > to download the sdk, install a lot of things just to run our test > suite. This process turns our builds slow and sometimes the test run > just timeouts. > > Some months ago the travis-ci team started to take a look at some > solutions to support Android build natively. > > I?m in touch with some travis-ci guys, doing some tests[1] and > participating on some discussions. Travis released a first beta > version for the community to test, but unfortunately it doesn?t > support maven-sdk-deploy[2] - we are talking[3] about it for the next > release. > > See more: > > https://github.com/travis-ci/travis-ci/issues/2296#issuecomment-47421718 > http://docs.travis-ci.com/user/languages/android/ > [1] > https://github.com/danielpassos/aerogear-android-push/blob/travis_android/.travis.yml > [2] https://github.com/mosabua/maven-android-sdk-deployer > [3] https://github.com/travis-ci/travis-ci/issues/2280 > > -- Passos > > ? From matzew at apache.org Wed Jul 23 03:01:32 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Wed, 23 Jul 2014 09:01:32 +0200 Subject: [aerogear-dev] [Vote] Release of UPS 1.0.0.Beta1 Message-ID: Good morning folks! we are getting closer and closer to our 1.0.0 release! Thank you very much, guys! However, before we are moving towards the 1.0.0.Final community release, I'd love to get the current work out as 1.0.0.Beta1 Note this release contains a ton of work and new features. To name a few highlights: * increased APNs payload (2k) * iOS8 interactive notification support * Pagination for analytics * improved callback for details on actual push delivery * optimisations and improvements Besides these changes, a ton of more work was done by the team: https://issues.jboss.org/browse/AGPUSH/fixforversion/12323753 The staging repository is located here: https://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-3598 NOTE: Once this release has been approved the matching tag will be used to get the OpenShift online bits updated! Let me know the results of your testing! If I hear nothing bad by Friday evening, the release to maven central will happen on Monday; Greetings, Matthias -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140723/a48571be/attachment.html From matzew at apache.org Wed Jul 23 10:54:14 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Wed, 23 Jul 2014 16:54:14 +0200 Subject: [aerogear-dev] Quickstarts 1.0.0.Beta1 release ? Message-ID: Hi, with the upcoming UPS 1.0.0.Beta1 release, I'd also like to have a release for both quickstarts: * https://github.com/aerogear/aerogear-push-helloworld * https://github.com/aerogear/aerogear-push-quickstarts Basically the idea is to simply create a TAG in GH. In the announcement of the new server version, we link to the tarball/zip from github of the quickstart 1.0.0.Beta1 release tag Or... is someone planing to add fixes to the quickstarts, this week ? Thanks, Matthias -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140723/21913a20/attachment.html From scm.blanc at gmail.com Wed Jul 23 10:59:56 2014 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Wed, 23 Jul 2014 16:59:56 +0200 Subject: [aerogear-dev] Quickstarts 1.0.0.Beta1 release ? In-Reply-To: References: Message-ID: Sounds good ! No new features planned, I know QE is testing but thier eventual findings could go with Beta2 ? On Wed, Jul 23, 2014 at 4:54 PM, Matthias Wessendorf wrote: > Hi, > > with the upcoming UPS 1.0.0.Beta1 release, I'd also like to have a release > for both quickstarts: > > * https://github.com/aerogear/aerogear-push-helloworld > * https://github.com/aerogear/aerogear-push-quickstarts > > > Basically the idea is to simply create a TAG in GH. In the announcement of > the new server version, we link to the tarball/zip from github of the > quickstart 1.0.0.Beta1 release tag > > Or... is someone planing to add fixes to the quickstarts, this week ? > > > Thanks, > Matthias > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140723/31d2c7b3/attachment-0001.html From matzew at apache.org Wed Jul 23 11:14:49 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Wed, 23 Jul 2014 17:14:49 +0200 Subject: [aerogear-dev] Quickstarts 1.0.0.Beta1 release ? In-Reply-To: References: Message-ID: On Wed, Jul 23, 2014 at 4:59 PM, Sebastien Blanc wrote: > Sounds good ! No new features planned, > I know QE is testing but thier eventual findings could go with Beta2 ? > yeah, some fixes already were done for QE findings. Mainly on Cordova and its plugin. Makes me wonder, should we roll a new Cordova Plugin release ? -Matthias > > > > > On Wed, Jul 23, 2014 at 4:54 PM, Matthias Wessendorf > wrote: > >> Hi, >> >> with the upcoming UPS 1.0.0.Beta1 release, I'd also like to have a >> release for both quickstarts: >> >> * https://github.com/aerogear/aerogear-push-helloworld >> * https://github.com/aerogear/aerogear-push-quickstarts >> >> >> Basically the idea is to simply create a TAG in GH. In the announcement >> of the new server version, we link to the tarball/zip from github of the >> quickstart 1.0.0.Beta1 release tag >> >> Or... is someone planing to add fixes to the quickstarts, this week ? >> >> >> Thanks, >> Matthias >> >> -- >> Matthias Wessendorf >> >> blog: http://matthiaswessendorf.wordpress.com/ >> sessions: http://www.slideshare.net/mwessendorf >> twitter: http://twitter.com/mwessendorf >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140723/b0fca561/attachment.html From matzew at apache.org Wed Jul 23 11:22:15 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Wed, 23 Jul 2014 17:22:15 +0200 Subject: [aerogear-dev] Non-Java release processes In-Reply-To: <5831F96D-8A89-465E-A5D3-1CD8063215B4@gmail.com> References: <8FB4F8C8-208E-458E-9436-0F1D15CB9A8B@gmail.com> <9E6655A3-CA1C-49DD-8761-BF50B41F82A6@gmail.com> <5831F96D-8A89-465E-A5D3-1CD8063215B4@gmail.com> Message-ID: Thanks for all the feedback ! I have added the Cordova and iOS processes to our wiki - linking to those from its landing page: https://github.com/aerogear/collateral/wiki Regarding plain JavaScrip, is this gist correct: https://gist.github.com/matzew/14f93693c8362b753782 if so, I will add a JS section - others, a JS centric fork of that document is more than welcome -M On Tue, Jul 8, 2014 at 10:31 AM, Corinne Krych wrote: > > On 08 Jul 2014, at 10:29, Christos Vasilakis wrote: > > >> > >> On Jul 8, 2014, at 11:17 AM, Corinne Krych > wrote: > >> > >> > >> On 08 Jul 2014, at 10:12, Christos Vasilakis > wrote: > >> > >>>> > >>>> On Jul 8, 2014, at 10:07 AM, Matthias Wessendorf > wrote: > >>>> > >>>> Hi, > >>>> > >>>> at the face2face we had a discussion about formalizing our release > processes for non-java project. > >>>> The Java guide is, IMO, still relevant and up-to-date: > >>>> https://github.com/aerogear/collateral/wiki/Release-Process-(Java) > >>>> > >>>> > >>>> For the non-java projects I started a few gists > >>>> > >>>> * for Cordova and JavaScript, I think this could be used: > >>>> https://gist.github.com/matzew/14f93693c8362b753782 > >>>> > >>>> Note: I am not sure if some extra steps are missing for things like > npm oe bower > >>>> > >>>> * for iOS, I think we can formalize on something like this: > >>>> https://gist.github.com/matzew/941883df5bd0abcf1d61 > >>> > >>> looks good +1 > >>> did some changes here [1] and modified the ?Perform? section adding > cocoapods new approach to spec publish and the step to update the spec > itself. > >>> > >>> If we are fine with it, will go ahead and add it on our ' > https://github.com/aerogear/collateral/wiki' > >>> > >> > >> > >> don?t we miss: > >> - step 0: ?send PR to cocoa pod? > > > > this step was replaced from cocoa pods with the 'pod trunk push? > command, no need to send PR on their repo any more. That was my update on > matzew gist :) > > > Ahhhh! > Good to clarify with a doc actually :) > > > > > > >> - step 5: update all demo Podfile with relevant tag > > > > +1, have updated my gist[1] with this step too > > > > Thanks, > > Christos > > > > > > > > > >> > >>> Thanks > >>> Christos > >>> > >>> [1] https://gist.github.com/cvasilak/114c7280b627ae6bcd9f > >>> > >>> [ > >>>> > >>>> > >>>> Greetings, > >>>> Matthias > >>>> > >>>> > >>>> -- > >>>> Matthias Wessendorf > >>>> > >>>> blog: http://matthiaswessendorf.wordpress.com/ > >>>> sessions: http://www.slideshare.net/mwessendorf > >>>> twitter: http://twitter.com/mwessendorf > >>>> _______________________________________________ > >>>> aerogear-dev mailing list > >>>> aerogear-dev at lists.jboss.org > >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev > >>> > >>> _______________________________________________ > >>> aerogear-dev mailing list > >>> aerogear-dev at lists.jboss.org > >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev > >> > >> > >> _______________________________________________ > >> aerogear-dev mailing list > >> aerogear-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140723/b7b05d6e/attachment.html From lholmqui at redhat.com Wed Jul 23 11:40:52 2014 From: lholmqui at redhat.com (Lucas Holmquist) Date: Wed, 23 Jul 2014 11:40:52 -0400 Subject: [aerogear-dev] Non-Java release processes In-Reply-To: References: <8FB4F8C8-208E-458E-9436-0F1D15CB9A8B@gmail.com> <9E6655A3-CA1C-49DD-8761-BF50B41F82A6@gmail.com> <5831F96D-8A89-465E-A5D3-1CD8063215B4@gmail.com> Message-ID: <0322EEF0-4A54-465B-B9A0-BADF5D84F836@redhat.com> On Jul 23, 2014, at 11:22 AM, Matthias Wessendorf wrote: > Thanks for all the feedback ! > > I have added the Cordova and iOS processes to our wiki - linking to those from its landing page: > https://github.com/aerogear/collateral/wiki > > > Regarding plain JavaScrip, is this gist correct: > https://gist.github.com/matzew/14f93693c8362b753782 well, not sure about "JavaScrip", but that is pretty much what i do for the ?JavaScript? stuff. i currently don?t sign the release, but do "git tag -a ?x.y.z? -m?x.y.z?? while i create a branch for the new pending release, i also like to create a tag for it. so x.y.z-beta or something like that. > > if so, I will add a JS section - others, a JS centric fork of that document is more than welcome > > -M > > > On Tue, Jul 8, 2014 at 10:31 AM, Corinne Krych wrote: > > On 08 Jul 2014, at 10:29, Christos Vasilakis wrote: > > >> > >> On Jul 8, 2014, at 11:17 AM, Corinne Krych wrote: > >> > >> > >> On 08 Jul 2014, at 10:12, Christos Vasilakis wrote: > >> > >>>> > >>>> On Jul 8, 2014, at 10:07 AM, Matthias Wessendorf wrote: > >>>> > >>>> Hi, > >>>> > >>>> at the face2face we had a discussion about formalizing our release processes for non-java project. > >>>> The Java guide is, IMO, still relevant and up-to-date: > >>>> https://github.com/aerogear/collateral/wiki/Release-Process-(Java) > >>>> > >>>> > >>>> For the non-java projects I started a few gists > >>>> > >>>> * for Cordova and JavaScript, I think this could be used: > >>>> https://gist.github.com/matzew/14f93693c8362b753782 > >>>> > >>>> Note: I am not sure if some extra steps are missing for things like npm oe bower > >>>> > >>>> * for iOS, I think we can formalize on something like this: > >>>> https://gist.github.com/matzew/941883df5bd0abcf1d61 > >>> > >>> looks good +1 > >>> did some changes here [1] and modified the ?Perform? section adding cocoapods new approach to spec publish and the step to update the spec itself. > >>> > >>> If we are fine with it, will go ahead and add it on our 'https://github.com/aerogear/collateral/wiki' > >>> > >> > >> > >> don?t we miss: > >> - step 0: ?send PR to cocoa pod? > > > > this step was replaced from cocoa pods with the 'pod trunk push? command, no need to send PR on their repo any more. That was my update on matzew gist :) > > > Ahhhh! > Good to clarify with a doc actually :) > > > > > > >> - step 5: update all demo Podfile with relevant tag > > > > +1, have updated my gist[1] with this step too > > > > Thanks, > > Christos > > > > > > > > > >> > >>> Thanks > >>> Christos > >>> > >>> [1] https://gist.github.com/cvasilak/114c7280b627ae6bcd9f > >>> > >>> [ > >>>> > >>>> > >>>> Greetings, > >>>> Matthias > >>>> > >>>> > >>>> -- > >>>> Matthias Wessendorf > >>>> > >>>> blog: http://matthiaswessendorf.wordpress.com/ > >>>> sessions: http://www.slideshare.net/mwessendorf > >>>> twitter: http://twitter.com/mwessendorf > >>>> _______________________________________________ > >>>> aerogear-dev mailing list > >>>> aerogear-dev at lists.jboss.org > >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev > >>> > >>> _______________________________________________ > >>> aerogear-dev mailing list > >>> aerogear-dev at lists.jboss.org > >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev > >> > >> > >> _______________________________________________ > >> aerogear-dev mailing list > >> aerogear-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140723/17fbe91f/attachment-0001.html From kpiwko at redhat.com Wed Jul 23 11:41:21 2014 From: kpiwko at redhat.com (Karel Piwko) Date: Wed, 23 Jul 2014 15:43:21 +0002 Subject: [aerogear-dev] Quickstarts 1.0.0.Beta1 release ? In-Reply-To: References: Message-ID: <1406130081.29031.0@smtp.corp.redhat.com> On Wed, Jul 23, 2014 at 5:14 PM, Matthias Wessendorf wrote: > > > > On Wed, Jul 23, 2014 at 4:59 PM, Sebastien Blanc > wrote: >> Sounds good ! No new features planned, >> I know QE is testing but thier eventual findings could go with Beta2 >> ? I guess that's the plan. We've just started with the latter repository, some of the fixes were included and overall it does not look bad for Beta1 :-). > > yeah, some fixes already were done for QE findings. Mainly on Cordova > and its plugin. Makes me wonder, should we roll a new Cordova Plugin > release ? > > -Matthias > >> >> >> >> >> On Wed, Jul 23, 2014 at 4:54 PM, Matthias Wessendorf >> wrote: >>> Hi, >>> >>> with the upcoming UPS 1.0.0.Beta1 release, I'd also like to have a >>> release for both quickstarts: >>> >>> * https://github.com/aerogear/aerogear-push-helloworld >>> * https://github.com/aerogear/aerogear-push-quickstarts >>> >>> >>> Basically the idea is to simply create a TAG in GH. In the >>> announcement of the new server version, we link to the tarball/zip >>> from github of the quickstart 1.0.0.Beta1 release tag >>> >>> Or... is someone planing to add fixes to the quickstarts, this week >>> ? >>> >>> >>> Thanks, >>> Matthias >>> >>> -- >>> Matthias Wessendorf >>> >>> blog: http://matthiaswessendorf.wordpress.com/ >>> sessions: http://www.slideshare.net/mwessendorf >>> twitter: http://twitter.com/mwessendorf >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf From kpiwko at redhat.com Wed Jul 23 11:42:02 2014 From: kpiwko at redhat.com (Karel Piwko) Date: Wed, 23 Jul 2014 15:44:02 +0002 Subject: [aerogear-dev] Simplify Security of AeroDoc In-Reply-To: References: <20140722111026.GA43037@abstractj.org> Message-ID: <1406130122.29031.1@smtp.corp.redhat.com> +1 On Tue, Jul 22, 2014 at 2:14 PM, S?bastien Blanc wrote: > Yep , I had the same idea and will be a good showcase for the client > KC sdks. > But as Matzew , let's do that after 1.0 > > Envoy? de mon iPhone > >> Le 22 juil. 2014 ? 13:10, Bruno Oliveira a >> ?crit : >> >> +1 What about make use of KC instead? >> >>> On 2014-07-22, Daniel Bevenius wrote: >>> +1 Less maintenance sounds good to me. >>> >>> >>>> On 22 July 2014 11:00, Matthias Wessendorf >>>> wrote: >>>> >>>> >>>> >>>> >>>> On Tue, Jul 22, 2014 at 10:58 AM, Sebastien Blanc >>>> >>>> wrote: >>>> >>>>> Hi All ! >>>>> >>>>> I'm currently working on APGUSH-810[1] which consist in removing >>>>> the >>>>> dependency we still had on the deprecated aerogear-security >>>>> project (RIP my >>>>> friend). >>>>> >>>>> But now, if I want to keep AeroDoc, feature equal as before, I >>>>> have to >>>>> add a LOT of code around security (to handle role, annotations >>>>> etc ...). >>>>> AeroDoc is already quite complex and time consuming to maintain >>>>> and the >>>>> core scope is not security but advanced Push. >>>>> >>>>> So ... What I would like to propose is to keep only the >>>>> authentification >>>>> (log in) and remove all the role handling part to simplify it. >>>>> >>>>> The only effect that this will introduce, is that a logged in >>>>> user can >>>>> also access the admin to create leads. >>>> >>>> that is fine w/ me >>>> >>>>> >>>>> >>>>> Wdyt ? >>>>> >>>>> Sebi >>>>> >>>>> >>>>> [1] https://issues.jboss.org/browse/AGPUSH-810 >>>>> >>>>> _______________________________________________ >>>>> aerogear-dev mailing list >>>>> aerogear-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> >>>> >>>> >>>> -- >>>> Matthias Wessendorf >>>> >>>> blog: http://matthiaswessendorf.wordpress.com/ >>>> sessions: http://www.slideshare.net/mwessendorf >>>> twitter: http://twitter.com/mwessendorf >>>> >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> -- >> >> abstractj >> PGP: 0x84DC9914 >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev From matzew at apache.org Wed Jul 23 11:46:28 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Wed, 23 Jul 2014 17:46:28 +0200 Subject: [aerogear-dev] Non-Java release processes In-Reply-To: <0322EEF0-4A54-465B-B9A0-BADF5D84F836@redhat.com> References: <8FB4F8C8-208E-458E-9436-0F1D15CB9A8B@gmail.com> <9E6655A3-CA1C-49DD-8761-BF50B41F82A6@gmail.com> <5831F96D-8A89-465E-A5D3-1CD8063215B4@gmail.com> <0322EEF0-4A54-465B-B9A0-BADF5D84F836@redhat.com> Message-ID: On Wed, Jul 23, 2014 at 5:40 PM, Lucas Holmquist wrote: > > On Jul 23, 2014, at 11:22 AM, Matthias Wessendorf > wrote: > > Thanks for all the feedback ! > > I have added the Cordova and iOS processes to our wiki - linking to those > from its landing page: > https://github.com/aerogear/collateral/wiki > > > Regarding plain JavaScrip, is this gist correct: > https://gist.github.com/matzew/14f93693c8362b753782 > > > well, not sure about "JavaScrip", but that is pretty much what i do for > the ?JavaScript? stuff. i currently don?t sign the release, but do "git > tag -a ?x.y.z? -m?x.y.z?? > > while i create a branch for the new pending release, i also like to > create a tag for it. so x.y.z-beta or something like that. > cool! I am sure the JavaScrip folks are OK w/ that too :) Can you fork and update the gist, as needed ? @branches: I do that, on UPS, as needed, out of the tag - I guess that's what you do too, right ? > > > > if so, I will add a JS section - others, a JS centric fork of that > document is more than welcome > > -M > > > On Tue, Jul 8, 2014 at 10:31 AM, Corinne Krych > wrote: > >> >> On 08 Jul 2014, at 10:29, Christos Vasilakis wrote: >> >> >> >> >> On Jul 8, 2014, at 11:17 AM, Corinne Krych >> wrote: >> >> >> >> >> >> On 08 Jul 2014, at 10:12, Christos Vasilakis >> wrote: >> >> >> >>>> >> >>>> On Jul 8, 2014, at 10:07 AM, Matthias Wessendorf >> wrote: >> >>>> >> >>>> Hi, >> >>>> >> >>>> at the face2face we had a discussion about formalizing our release >> processes for non-java project. >> >>>> The Java guide is, IMO, still relevant and up-to-date: >> >>>> https://github.com/aerogear/collateral/wiki/Release-Process-(Java) >> >>>> >> >>>> >> >>>> For the non-java projects I started a few gists >> >>>> >> >>>> * for Cordova and JavaScript, I think this could be used: >> >>>> https://gist.github.com/matzew/14f93693c8362b753782 >> >>>> >> >>>> Note: I am not sure if some extra steps are missing for things like >> npm oe bower >> >>>> >> >>>> * for iOS, I think we can formalize on something like this: >> >>>> https://gist.github.com/matzew/941883df5bd0abcf1d61 >> >>> >> >>> looks good +1 >> >>> did some changes here [1] and modified the ?Perform? section adding >> cocoapods new approach to spec publish and the step to update the spec >> itself. >> >>> >> >>> If we are fine with it, will go ahead and add it on our ' >> https://github.com/aerogear/collateral/wiki' >> >>> >> >> >> >> >> >> don?t we miss: >> >> - step 0: ?send PR to cocoa pod? >> > >> > this step was replaced from cocoa pods with the 'pod trunk push? >> command, no need to send PR on their repo any more. That was my update on >> matzew gist :) >> >> >> Ahhhh! >> Good to clarify with a doc actually :) >> >> > >> > >> >> - step 5: update all demo Podfile with relevant tag >> > >> > +1, have updated my gist[1] with this step too >> > >> > Thanks, >> > Christos >> > >> > >> > >> > >> >> >> >>> Thanks >> >>> Christos >> >>> >> >>> [1] https://gist.github.com/cvasilak/114c7280b627ae6bcd9f >> >>> >> >>> [ >> >>>> >> >>>> >> >>>> Greetings, >> >>>> Matthias >> >>>> >> >>>> >> >>>> -- >> >>>> Matthias Wessendorf >> >>>> >> >>>> blog: http://matthiaswessendorf.wordpress.com/ >> >>>> sessions: http://www.slideshare.net/mwessendorf >> >>>> twitter: http://twitter.com/mwessendorf >> >>>> _______________________________________________ >> >>>> aerogear-dev mailing list >> >>>> aerogear-dev at lists.jboss.org >> >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >>> >> >>> _______________________________________________ >> >>> aerogear-dev mailing list >> >>> aerogear-dev at lists.jboss.org >> >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> >> >> >> _______________________________________________ >> >> aerogear-dev mailing list >> >> aerogear-dev at lists.jboss.org >> >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > >> > >> > _______________________________________________ >> > aerogear-dev mailing list >> > aerogear-dev at lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140723/a43bf6e2/attachment.html From matzew at apache.org Wed Jul 23 11:47:10 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Wed, 23 Jul 2014 17:47:10 +0200 Subject: [aerogear-dev] Simplify Security of AeroDoc In-Reply-To: References: <20140722111026.GA43037@abstractj.org> Message-ID: On Tue, Jul 22, 2014 at 2:14 PM, S?bastien Blanc wrote: > Yep , I had the same idea and will be a good showcase for the client KC > sdks. > But as Matzew , let's do that after 1.0 > JIRA ? :) > > Envoy? de mon iPhone > > > Le 22 juil. 2014 ? 13:10, Bruno Oliveira a ?crit : > > > > +1 What about make use of KC instead? > > > >> On 2014-07-22, Daniel Bevenius wrote: > >> +1 Less maintenance sounds good to me. > >> > >> > >>> On 22 July 2014 11:00, Matthias Wessendorf wrote: > >>> > >>> > >>> > >>> > >>> On Tue, Jul 22, 2014 at 10:58 AM, Sebastien Blanc > > >>> wrote: > >>> > >>>> Hi All ! > >>>> > >>>> I'm currently working on APGUSH-810[1] which consist in removing the > >>>> dependency we still had on the deprecated aerogear-security project > (RIP my > >>>> friend). > >>>> > >>>> But now, if I want to keep AeroDoc, feature equal as before, I have to > >>>> add a LOT of code around security (to handle role, annotations etc > ...). > >>>> AeroDoc is already quite complex and time consuming to maintain and > the > >>>> core scope is not security but advanced Push. > >>>> > >>>> So ... What I would like to propose is to keep only the > authentification > >>>> (log in) and remove all the role handling part to simplify it. > >>>> > >>>> The only effect that this will introduce, is that a logged in user can > >>>> also access the admin to create leads. > >>> > >>> that is fine w/ me > >>> > >>>> > >>>> > >>>> Wdyt ? > >>>> > >>>> Sebi > >>>> > >>>> > >>>> [1] https://issues.jboss.org/browse/AGPUSH-810 > >>>> > >>>> _______________________________________________ > >>>> aerogear-dev mailing list > >>>> aerogear-dev at lists.jboss.org > >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev > >>> > >>> > >>> > >>> -- > >>> Matthias Wessendorf > >>> > >>> blog: http://matthiaswessendorf.wordpress.com/ > >>> sessions: http://www.slideshare.net/mwessendorf > >>> twitter: http://twitter.com/mwessendorf > >>> > >>> _______________________________________________ > >>> aerogear-dev mailing list > >>> aerogear-dev at lists.jboss.org > >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > >> _______________________________________________ > >> aerogear-dev mailing list > >> aerogear-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > > -- > > > > abstractj > > PGP: 0x84DC9914 > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140723/1104856a/attachment-0001.html From lholmqui at redhat.com Wed Jul 23 11:48:40 2014 From: lholmqui at redhat.com (Lucas Holmquist) Date: Wed, 23 Jul 2014 11:48:40 -0400 Subject: [aerogear-dev] Non-Java release processes In-Reply-To: References: <8FB4F8C8-208E-458E-9436-0F1D15CB9A8B@gmail.com> <9E6655A3-CA1C-49DD-8761-BF50B41F82A6@gmail.com> <5831F96D-8A89-465E-A5D3-1CD8063215B4@gmail.com> <0322EEF0-4A54-465B-B9A0-BADF5D84F836@redhat.com> Message-ID: On Jul 23, 2014, at 11:46 AM, Matthias Wessendorf wrote: > > > > On Wed, Jul 23, 2014 at 5:40 PM, Lucas Holmquist wrote: > > On Jul 23, 2014, at 11:22 AM, Matthias Wessendorf wrote: > >> Thanks for all the feedback ! >> >> I have added the Cordova and iOS processes to our wiki - linking to those from its landing page: >> https://github.com/aerogear/collateral/wiki >> >> >> Regarding plain JavaScrip, is this gist correct: >> https://gist.github.com/matzew/14f93693c8362b753782 > > well, not sure about "JavaScrip", but that is pretty much what i do for the ?JavaScript? stuff. i currently don?t sign the release, but do "git tag -a ?x.y.z? -m?x.y.z?? > > while i create a branch for the new pending release, i also like to create a tag for it. so x.y.z-beta or something like that. > > > cool! I am sure the JavaScrip folks are OK w/ that too :) > > Can you fork and update the gist, as needed ? > sure > > @branches: I do that, on UPS, as needed, out of the tag - I guess that's what you do too, right ? yea, > > > >> >> if so, I will add a JS section - others, a JS centric fork of that document is more than welcome >> >> -M >> >> >> On Tue, Jul 8, 2014 at 10:31 AM, Corinne Krych wrote: >> >> On 08 Jul 2014, at 10:29, Christos Vasilakis wrote: >> >> >> >> >> On Jul 8, 2014, at 11:17 AM, Corinne Krych wrote: >> >> >> >> >> >> On 08 Jul 2014, at 10:12, Christos Vasilakis wrote: >> >> >> >>>> >> >>>> On Jul 8, 2014, at 10:07 AM, Matthias Wessendorf wrote: >> >>>> >> >>>> Hi, >> >>>> >> >>>> at the face2face we had a discussion about formalizing our release processes for non-java project. >> >>>> The Java guide is, IMO, still relevant and up-to-date: >> >>>> https://github.com/aerogear/collateral/wiki/Release-Process-(Java) >> >>>> >> >>>> >> >>>> For the non-java projects I started a few gists >> >>>> >> >>>> * for Cordova and JavaScript, I think this could be used: >> >>>> https://gist.github.com/matzew/14f93693c8362b753782 >> >>>> >> >>>> Note: I am not sure if some extra steps are missing for things like npm oe bower >> >>>> >> >>>> * for iOS, I think we can formalize on something like this: >> >>>> https://gist.github.com/matzew/941883df5bd0abcf1d61 >> >>> >> >>> looks good +1 >> >>> did some changes here [1] and modified the ?Perform? section adding cocoapods new approach to spec publish and the step to update the spec itself. >> >>> >> >>> If we are fine with it, will go ahead and add it on our 'https://github.com/aerogear/collateral/wiki' >> >>> >> >> >> >> >> >> don?t we miss: >> >> - step 0: ?send PR to cocoa pod? >> > >> > this step was replaced from cocoa pods with the 'pod trunk push? command, no need to send PR on their repo any more. That was my update on matzew gist :) >> >> >> Ahhhh! >> Good to clarify with a doc actually :) >> >> > >> > >> >> - step 5: update all demo Podfile with relevant tag >> > >> > +1, have updated my gist[1] with this step too >> > >> > Thanks, >> > Christos >> > >> > >> > >> > >> >> >> >>> Thanks >> >>> Christos >> >>> >> >>> [1] https://gist.github.com/cvasilak/114c7280b627ae6bcd9f >> >>> >> >>> [ >> >>>> >> >>>> >> >>>> Greetings, >> >>>> Matthias >> >>>> >> >>>> >> >>>> -- >> >>>> Matthias Wessendorf >> >>>> >> >>>> blog: http://matthiaswessendorf.wordpress.com/ >> >>>> sessions: http://www.slideshare.net/mwessendorf >> >>>> twitter: http://twitter.com/mwessendorf >> >>>> _______________________________________________ >> >>>> aerogear-dev mailing list >> >>>> aerogear-dev at lists.jboss.org >> >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >>> >> >>> _______________________________________________ >> >>> aerogear-dev mailing list >> >>> aerogear-dev at lists.jboss.org >> >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> >> >> >> _______________________________________________ >> >> aerogear-dev mailing list >> >> aerogear-dev at lists.jboss.org >> >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > >> > >> > _______________________________________________ >> > aerogear-dev mailing list >> > aerogear-dev at lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> >> -- >> Matthias Wessendorf >> >> blog: http://matthiaswessendorf.wordpress.com/ >> sessions: http://www.slideshare.net/mwessendorf >> twitter: http://twitter.com/mwessendorf >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140723/caf141cd/attachment.html From lholmqui at redhat.com Wed Jul 23 15:56:53 2014 From: lholmqui at redhat.com (Lucas Holmquist) Date: Wed, 23 Jul 2014 15:56:53 -0400 Subject: [aerogear-dev] Differences between Firefox OS "native" Push lib and AeroGear's Push adapter In-Reply-To: <28EA872A-87E3-4035-9C63-DA04EF034580@redhat.com> References: <9B70BDB9-4774-4BF0-9FF7-5213185E4F52@redhat.com> <51C9D854-0730-4B2A-9A92-9DC92649947D@redhat.com> <8AEB32A5-0F61-495B-8EA5-767F48312B9C@redhat.com> <3B256910-96B3-4F55-8456-D890F4B37B2B! ! @redhat.com> <28EA872A-87E3-4035-9C63-DA04EF034580@redhat.com> Message-ID: so there is this issue, , about not being able to delete a simplePush installation. using the UPS js client, i registered the ?deviceToken? with the push server, but when trying to use CURL or even the JS lib, i was getting a 404, and i noticed that it would never actually hit the server( i was in debug mode in IntelliJ ) this was a demo that i had working back in april https://github.com/lholmquist/mobileweek/blob/master/mobileweek-ffos/js/app.js#L17 i noticed that when i registered the deviceToken, i was doing a encodeURIComponent before sending it to the UPS. i modified the UPS JS client to do it this way, and then when i tried to do the remove, i actually hit the breakpoints i set. but the server could not find the installation doing Installation installation = clientInstallationService.findInstallationForVariantByDeviceToken(variant.getVariantID(), token); I changed the JS client to only do 1 encode instead of 2 but it still couldn?t find the installation. I?m not really familiar with JPA and all that, so i don?t know how the query stuff works in this case But i do think we should be encoding the deviceToken( which is the pushEndpointURL ) when registering with the UPS, or else i don?t think we can ever get access to that endpoint On Jul 14, 2014, at 9:52 AM, Lucas Holmquist wrote: > > On Jul 11, 2014, at 6:33 AM, Matthias Wessendorf wrote: > >> Hey Luke, >> >> I created this JIRA: >> https://issues.jboss.org/browse/AGPUSH-802 >> >> As I plan working on AGPUSH-532 next week, to make sure we have the 'right' model in place for 1.0.0. I think once the server bits are merged, we should address AGPUSH-802 > > kk > >> >> -Matthias >> >> >> On Thu, Apr 10, 2014 at 5:22 PM, Lucas Holmquist wrote: >> so after testing this thing out with encodeURIComponent, the delete does work, however, we need to "double up" the encode. >> >> this works: >> >> https://gist.github.com/lholmquist/10393357 >> >> >> this doesn't: >> >> https://gist.github.com/lholmquist/10393450 >> >> >> >> On Apr 7, 2014, at 2:09 PM, Lucas Holmquist wrote: >> >>> >>> On Apr 7, 2014, at 12:52 PM, Matthias Wessendorf wrote: >>> >>>> Ok, >>>> >>>> So as token, we use the endpointURL, and on client we perform the encodeURIComponent() function ? >>> >>> i think so( as suggested 2 months ago :) ) i just need to see how this will affect how we store stuff in LS. >>> >>> >>> >>>> >>>> -Matthias >>>> >>>> On Monday, April 7, 2014, Lucas Holmquist wrote: >>>> so i went back to look at what i had, >>>> >>>> >>>> i don't think we need to get to complicated here, >>>> >>>> reading the spec stuff, and this example >>>> >>>> https://wiki.mozilla.org/WebAPI/SimplePush#Client_.28WebApp.29_code >>>> >>>> they show sending the pushEndpoint to the "App server", so i think we could just use and keep it simple >>>> >>>> it is also recommended that the channelID is never exposed to the application. >>>> >>>> >>>> On Apr 1, 2014, at 3:34 PM, Lucas Holmquist wrote: >>>> >>>>> i had something, now i forgot what it was, need to go back and check >>>>> On Apr 1, 2014, at 3:05 PM, Matthias Wessendorf wrote: >>>>> >>>>>> >>>>>> On Fri, Feb 14, 2014 at 2:06 PM, Lucas Holmquist wrote: >>>>>> still exploring >>>>>> >>>>>> :-) any recent thoughts on 'encodeURIComponent()' ? >>>>>> >>>>>> >>>>>> On Feb 13, 2014, at 3:39 PM, Sebastien Blanc wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Wed, Feb 12, 2014 at 2:30 PM, Lucas Holmquist wrote: >>>>>>> i might have a couple thoughts, but i need to try some things out first >>>>>>> >>>>>>> Any update on that or does the solution proposed by Matzew (using encodeURIComponent() ) could be enough ? >>>>>>> >>>>>>> On Feb 12, 2014, at 3:53 AM, Sebastien Blanc wrote: >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Tue, Feb 11, 2014 at 7:15 PM, Sebastien Blanc wrote: >>>>>>>> Ok, >>>>>>>> I've been doing some tests by using the PushEndpoint as device token. For registration it works but I just faced an issue by trying to unregister because the URL for the DELETE looks like : >>>>>>>> >>>>>>>> https://judconpush-sblanc.rhcloud.com/rest/registry/device/https://updates.push.services.mozilla.com/update/my_personnal_psuhendpoint_id [ >>>>>>>> >>>>>>>> And the REST endpoint get a bit crazy by the extra "/" present in the endpoint URL. Therefore, I think we must just use the last URL fragment as deviceToken. >>>>>>>> >>>>>>>> Ok answering to myself ;) That won't work neither since if we do that UPS won't have the compllete push endpoint URL. >>>>>>>> So how do we deal with that ? >>>>>>>> >>>>>>>> >>>>>>>> On Thu, Feb 6, 2014 at 3:27 PM, Matthias Wessendorf wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Thu, Feb 6, 2014 at 3:11 PM, Sebastien Blanc >>>> >>>> >>>> -- >>>> Sent from Gmail Mobile >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> >> -- >> Matthias Wessendorf >> >> blog: http://matthiaswessendorf.wordpress.com/ >> sessions: http://www.slideshare.net/mwessendorf >> twitter: http://twitter.com/mwessendorf >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140723/8b471073/attachment-0001.html From lholmqui at redhat.com Wed Jul 23 15:59:33 2014 From: lholmqui at redhat.com (Lucas Holmquist) Date: Wed, 23 Jul 2014 15:59:33 -0400 Subject: [aerogear-dev] Differences between Firefox OS "native" Push lib and AeroGear's Push adapter In-Reply-To: References: <9B70BDB9-4774-4BF0-9FF7-5213185E4F52@redhat.com> <51C9D854-0730-4B2A-9A92-9DC92649947D@redhat.com> <8AEB32A5-0F61-495B-8EA5-767F48312B9C@redhat.com> <3B256910-96B3-4F55-8456-D890F4B37B2B! ! ! @redhat.com> <28EA872A-87E3-4035-9C63-DA04EF034580@redhat.com> Message-ID: <80896717-EB38-4D1F-801C-12DD22ACFE91@redhat.com> would help if i actually put the issue in https://issues.jboss.org/browse/AGPUSH-833 On Jul 23, 2014, at 3:56 PM, Lucas Holmquist wrote: > > so there is this issue, , about not being able to delete a simplePush installation. > > using the UPS js client, i registered the ?deviceToken? with the push server, but when trying to use CURL or even the JS lib, i was getting a 404, and i noticed that it would never actually hit the server( i was in debug mode in IntelliJ ) > > this was a demo that i had working back in april https://github.com/lholmquist/mobileweek/blob/master/mobileweek-ffos/js/app.js#L17 > > i noticed that when i registered the deviceToken, i was doing a encodeURIComponent before sending it to the UPS. > > i modified the UPS JS client to do it this way, and then when i tried to do the remove, i actually hit the breakpoints i set. but the server could not find the installation doing > > Installation installation = > clientInstallationService.findInstallationForVariantByDeviceToken(variant.getVariantID(), token); > > > I changed the JS client to only do 1 encode instead of 2 but it still couldn?t find the installation. > > I?m not really familiar with JPA and all that, so i don?t know how the query stuff works in this case > > > But i do think we should be encoding the deviceToken( which is the pushEndpointURL ) when registering with the UPS, or else i don?t think we can ever get access to that endpoint > > > On Jul 14, 2014, at 9:52 AM, Lucas Holmquist wrote: > >> >> On Jul 11, 2014, at 6:33 AM, Matthias Wessendorf wrote: >> >>> Hey Luke, >>> >>> I created this JIRA: >>> https://issues.jboss.org/browse/AGPUSH-802 >>> >>> As I plan working on AGPUSH-532 next week, to make sure we have the 'right' model in place for 1.0.0. I think once the server bits are merged, we should address AGPUSH-802 >> >> kk >> >>> >>> -Matthias >>> >>> >>> On Thu, Apr 10, 2014 at 5:22 PM, Lucas Holmquist wrote: >>> so after testing this thing out with encodeURIComponent, the delete does work, however, we need to "double up" the encode. >>> >>> this works: >>> >>> https://gist.github.com/lholmquist/10393357 >>> >>> >>> this doesn't: >>> >>> https://gist.github.com/lholmquist/10393450 >>> >>> >>> >>> On Apr 7, 2014, at 2:09 PM, Lucas Holmquist wrote: >>> >>>> >>>> On Apr 7, 2014, at 12:52 PM, Matthias Wessendorf wrote: >>>> >>>>> Ok, >>>>> >>>>> So as token, we use the endpointURL, and on client we perform the encodeURIComponent() function ? >>>> >>>> i think so( as suggested 2 months ago :) ) i just need to see how this will affect how we store stuff in LS. >>>> >>>> >>>> >>>>> >>>>> -Matthias >>>>> >>>>> On Monday, April 7, 2014, Lucas Holmquist wrote: >>>>> so i went back to look at what i had, >>>>> >>>>> >>>>> i don't think we need to get to complicated here, >>>>> >>>>> reading the spec stuff, and this example >>>>> >>>>> https://wiki.mozilla.org/WebAPI/SimplePush#Client_.28WebApp.29_code >>>>> >>>>> they show sending the pushEndpoint to the "App server", so i think we could just use and keep it simple >>>>> >>>>> it is also recommended that the channelID is never exposed to the application. >>>>> >>>>> >>>>> On Apr 1, 2014, at 3:34 PM, Lucas Holmquist wrote: >>>>> >>>>>> i had something, now i forgot what it was, need to go back and check >>>>>> On Apr 1, 2014, at 3:05 PM, Matthias Wessendorf wrote: >>>>>> >>>>>>> >>>>>>> On Fri, Feb 14, 2014 at 2:06 PM, Lucas Holmquist wrote: >>>>>>> still exploring >>>>>>> >>>>>>> :-) any recent thoughts on 'encodeURIComponent()' ? >>>>>>> >>>>>>> >>>>>>> On Feb 13, 2014, at 3:39 PM, Sebastien Blanc wrote: >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Wed, Feb 12, 2014 at 2:30 PM, Lucas Holmquist wrote: >>>>>>>> i might have a couple thoughts, but i need to try some things out first >>>>>>>> >>>>>>>> Any update on that or does the solution proposed by Matzew (using encodeURIComponent() ) could be enough ? >>>>>>>> >>>>>>>> On Feb 12, 2014, at 3:53 AM, Sebastien Blanc wrote: >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Tue, Feb 11, 2014 at 7:15 PM, Sebastien Blanc wrote: >>>>>>>>> Ok, >>>>>>>>> I've been doing some tests by using the PushEndpoint as device token. For registration it works but I just faced an issue by trying to unregister because the URL for the DELETE looks like : >>>>>>>>> >>>>>>>>> https://judconpush-sblanc.rhcloud.com/rest/registry/device/https://updates.push.services.mozilla.com/update/my_personnal_psuhendpoint_id [ >>>>>>>>> >>>>>>>>> And the REST endpoint get a bit crazy by the extra "/" present in the endpoint URL. Therefore, I think we must just use the last URL fragment as deviceToken. >>>>>>>>> >>>>>>>>> Ok answering to myself ;) That won't work neither since if we do that UPS won't have the compllete push endpoint URL. >>>>>>>>> So how do we deal with that ? >>>>>>>>> >>>>>>>>> >>>>>>>>> On Thu, Feb 6, 2014 at 3:27 PM, Matthias Wessendorf wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Thu, Feb 6, 2014 at 3:11 PM, Sebastien Blanc >>>>> >>>>> >>>>> -- >>>>> Sent from Gmail Mobile >>>>> _______________________________________________ >>>>> aerogear-dev mailing list >>>>> aerogear-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >>> >>> >>> -- >>> Matthias Wessendorf >>> >>> blog: http://matthiaswessendorf.wordpress.com/ >>> sessions: http://www.slideshare.net/mwessendorf >>> twitter: http://twitter.com/mwessendorf >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140723/f4cce786/attachment.html From matzew at apache.org Wed Jul 23 16:48:27 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Wed, 23 Jul 2014 22:48:27 +0200 Subject: [aerogear-dev] Differences between Firefox OS "native" Push lib and AeroGear's Push adapter In-Reply-To: References: <9B70BDB9-4774-4BF0-9FF7-5213185E4F52@redhat.com> <51C9D854-0730-4B2A-9A92-9DC92649947D@redhat.com> <8AEB32A5-0F61-495B-8EA5-767F48312B9C@redhat.com> <28EA872A-87E3-4035-9C63-DA04EF034580@redhat.com> Message-ID: Did you try it w/ the 1.0.0.Beta1? Or with the last release, the 0.11.0 ? -Matthias On Wed, Jul 23, 2014 at 9:56 PM, Lucas Holmquist wrote: > > so there is this issue, , about not being able to delete a simplePush > installation. > > using the UPS js client, i registered the ?deviceToken? with the push > server, but when trying to use CURL or even the JS lib, i was getting a > 404, and i noticed that it would never actually hit the server( i was in > debug mode in IntelliJ ) > > this was a demo that i had working back in april > https://github.com/lholmquist/mobileweek/blob/master/mobileweek-ffos/js/app.js#L17 > > i noticed that when i registered the deviceToken, i was doing a > encodeURIComponent before sending it to the UPS. > > i modified the UPS JS client to do it this way, and then when i tried to > do the remove, i actually hit the breakpoints i set. but the server could > not find the installation doing > > Installation installation = > > clientInstallationService.findInstallationForVariantByDeviceToken(variant.getVariantID(), > token); > > > I changed the JS client to only do 1 encode instead of 2 but it still > couldn?t find the installation. > > I?m not really familiar with JPA and all that, so i don?t know how the > query stuff works in this case > > > But i do think we should be encoding the deviceToken( which is the > pushEndpointURL ) when registering with the UPS, or else i don?t think we > can ever get access to that endpoint > > > On Jul 14, 2014, at 9:52 AM, Lucas Holmquist wrote: > > > On Jul 11, 2014, at 6:33 AM, Matthias Wessendorf > wrote: > > Hey Luke, > > I created this JIRA: > https://issues.jboss.org/browse/AGPUSH-802 > > As I plan working on AGPUSH-532 next week, to make sure we have the > 'right' model in place for 1.0.0. I think once the server bits are merged, > we should address AGPUSH-802 > > > kk > > > -Matthias > > > On Thu, Apr 10, 2014 at 5:22 PM, Lucas Holmquist > wrote: > >> so after testing this thing out with encodeURIComponent, the delete does >> work, however, we need to "double up" the encode. >> >> this works: >> >> https://gist.github.com/lholmquist/10393357 >> >> >> this doesn't: >> >> https://gist.github.com/lholmquist/10393450 >> >> >> >> On Apr 7, 2014, at 2:09 PM, Lucas Holmquist wrote: >> >> >> On Apr 7, 2014, at 12:52 PM, Matthias Wessendorf >> wrote: >> >> Ok, >> >> So as token, we use the endpointURL, and on client we perform the >> encodeURIComponent() function ? >> >> >> i think so( as suggested 2 months ago :) ) i just need to see how this >> will affect how we store stuff in LS. >> >> >> >> >> -Matthias >> >> On Monday, April 7, 2014, Lucas Holmquist wrote: >> >>> so i went back to look at what i had, >>> >>> >>> i don't think we need to get to complicated here, >>> >>> reading the spec stuff, and this example >>> >>> https://wiki.mozilla.org/WebAPI/SimplePush#Client_.28WebApp.29_code >>> >>> they show sending the pushEndpoint to the "App server", so i think we >>> could just use and keep it simple >>> >>> it is also recommended that the channelID is never exposed to the >>> application. >>> >>> >>> On Apr 1, 2014, at 3:34 PM, Lucas Holmquist wrote: >>> >>> i had something, now i forgot what it was, need to go back and check >>> On Apr 1, 2014, at 3:05 PM, Matthias Wessendorf >>> wrote: >>> >>> >>> On Fri, Feb 14, 2014 at 2:06 PM, Lucas Holmquist >>> wrote: >>> >>> still exploring >>> >>> >>> :-) any recent thoughts on 'encodeURIComponent()' ? >>> >>> >>> >>> On Feb 13, 2014, at 3:39 PM, Sebastien Blanc >>> wrote: >>> >>> >>> >>> >>> On Wed, Feb 12, 2014 at 2:30 PM, Lucas Holmquist >>> wrote: >>> >>> i might have a couple thoughts, but i need to try some things out first >>> >>> >>> Any update on that or does the solution proposed by Matzew (using encodeURIComponent() >>> ) could be enough ? >>> >>> >>> On Feb 12, 2014, at 3:53 AM, Sebastien Blanc >>> wrote: >>> >>> >>> >>> >>> On Tue, Feb 11, 2014 at 7:15 PM, Sebastien Blanc >>> wrote: >>> >>> Ok, >>> I've been doing some tests by using the PushEndpoint as device token. >>> For registration it works but I just faced an issue by trying to unregister >>> because the URL for the DELETE looks like : >>> >>> >>> https://judconpush-sblanc.rhcloud.com/rest/registry/device/https://updates.push.services.mozilla.com/update/my_personnal_psuhendpoint_id >>> [ >>> >>> And the REST endpoint get a bit crazy by the extra "/" present in the >>> endpoint URL. Therefore, I think we must just use the last URL fragment as >>> deviceToken. >>> >>> >>> Ok answering to myself ;) That won't work neither since if we do that >>> UPS won't have the compllete push endpoint URL. >>> So how do we deal with that ? >>> >>> >>> >>> On Thu, Feb 6, 2014 at 3:27 PM, Matthias Wessendorf >>> wrote: >>> >>> >>> >>> >>> On Thu, Feb 6, 2014 at 3:11 PM, Sebastien Blanc >>> >>> >> >> -- >> Sent from Gmail Mobile >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140723/270b527b/attachment-0001.html From lholmqui at redhat.com Wed Jul 23 16:53:42 2014 From: lholmqui at redhat.com (Lucas Holmquist) Date: Wed, 23 Jul 2014 16:53:42 -0400 Subject: [aerogear-dev] Differences between Firefox OS "native" Push lib and AeroGear's Push adapter In-Reply-To: References: <9B70BDB9-4774-4BF0-9FF7-5213185E4F52@redhat.com> <51C9D854-0730-4B2A-9A92-9DC92649947D@redhat.com> <8AEB32A5-0F61-495B-8EA5-767F48312B9C@redhat.com> <28EA872A-87E3-4035-9C63-DA04EF034580@redhat.com> Message-ID: not sure, i?ll check On Jul 23, 2014, at 4:48 PM, Matthias Wessendorf wrote: > Did you try it w/ the 1.0.0.Beta1? > Or with the last release, the 0.11.0 ? > > -Matthias > > > > On Wed, Jul 23, 2014 at 9:56 PM, Lucas Holmquist wrote: > > so there is this issue, , about not being able to delete a simplePush installation. > > using the UPS js client, i registered the ?deviceToken? with the push server, but when trying to use CURL or even the JS lib, i was getting a 404, and i noticed that it would never actually hit the server( i was in debug mode in IntelliJ ) > > this was a demo that i had working back in april https://github.com/lholmquist/mobileweek/blob/master/mobileweek-ffos/js/app.js#L17 > > i noticed that when i registered the deviceToken, i was doing a encodeURIComponent before sending it to the UPS. > > i modified the UPS JS client to do it this way, and then when i tried to do the remove, i actually hit the breakpoints i set. but the server could not find the installation doing > > Installation installation = > clientInstallationService.findInstallationForVariantByDeviceToken(variant.getVariantID(), token); > > > I changed the JS client to only do 1 encode instead of 2 but it still couldn?t find the installation. > > I?m not really familiar with JPA and all that, so i don?t know how the query stuff works in this case > > > But i do think we should be encoding the deviceToken( which is the pushEndpointURL ) when registering with the UPS, or else i don?t think we can ever get access to that endpoint > > > On Jul 14, 2014, at 9:52 AM, Lucas Holmquist wrote: > >> >> On Jul 11, 2014, at 6:33 AM, Matthias Wessendorf wrote: >> >>> Hey Luke, >>> >>> I created this JIRA: >>> https://issues.jboss.org/browse/AGPUSH-802 >>> >>> As I plan working on AGPUSH-532 next week, to make sure we have the 'right' model in place for 1.0.0. I think once the server bits are merged, we should address AGPUSH-802 >> >> kk >> >>> >>> -Matthias >>> >>> >>> On Thu, Apr 10, 2014 at 5:22 PM, Lucas Holmquist wrote: >>> so after testing this thing out with encodeURIComponent, the delete does work, however, we need to "double up" the encode. >>> >>> this works: >>> >>> https://gist.github.com/lholmquist/10393357 >>> >>> >>> this doesn't: >>> >>> https://gist.github.com/lholmquist/10393450 >>> >>> >>> >>> On Apr 7, 2014, at 2:09 PM, Lucas Holmquist wrote: >>> >>>> >>>> On Apr 7, 2014, at 12:52 PM, Matthias Wessendorf wrote: >>>> >>>>> Ok, >>>>> >>>>> So as token, we use the endpointURL, and on client we perform the encodeURIComponent() function ? >>>> >>>> i think so( as suggested 2 months ago :) ) i just need to see how this will affect how we store stuff in LS. >>>> >>>> >>>> >>>>> >>>>> -Matthias >>>>> >>>>> On Monday, April 7, 2014, Lucas Holmquist wrote: >>>>> so i went back to look at what i had, >>>>> >>>>> >>>>> i don't think we need to get to complicated here, >>>>> >>>>> reading the spec stuff, and this example >>>>> >>>>> https://wiki.mozilla.org/WebAPI/SimplePush#Client_.28WebApp.29_code >>>>> >>>>> they show sending the pushEndpoint to the "App server", so i think we could just use and keep it simple >>>>> >>>>> it is also recommended that the channelID is never exposed to the application. >>>>> >>>>> >>>>> On Apr 1, 2014, at 3:34 PM, Lucas Holmquist wrote: >>>>> >>>>>> i had something, now i forgot what it was, need to go back and check >>>>>> On Apr 1, 2014, at 3:05 PM, Matthias Wessendorf wrote: >>>>>> >>>>>>> >>>>>>> On Fri, Feb 14, 2014 at 2:06 PM, Lucas Holmquist wrote: >>>>>>> still exploring >>>>>>> >>>>>>> :-) any recent thoughts on 'encodeURIComponent()' ? >>>>>>> >>>>>>> >>>>>>> On Feb 13, 2014, at 3:39 PM, Sebastien Blanc wrote: >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Wed, Feb 12, 2014 at 2:30 PM, Lucas Holmquist wrote: >>>>>>>> i might have a couple thoughts, but i need to try some things out first >>>>>>>> >>>>>>>> Any update on that or does the solution proposed by Matzew (using encodeURIComponent() ) could be enough ? >>>>>>>> >>>>>>>> On Feb 12, 2014, at 3:53 AM, Sebastien Blanc wrote: >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Tue, Feb 11, 2014 at 7:15 PM, Sebastien Blanc wrote: >>>>>>>>> Ok, >>>>>>>>> I've been doing some tests by using the PushEndpoint as device token. For registration it works but I just faced an issue by trying to unregister because the URL for the DELETE looks like : >>>>>>>>> >>>>>>>>> https://judconpush-sblanc.rhcloud.com/rest/registry/device/https://updates.push.services.mozilla.com/update/my_personnal_psuhendpoint_id [ >>>>>>>>> >>>>>>>>> And the REST endpoint get a bit crazy by the extra "/" present in the endpoint URL. Therefore, I think we must just use the last URL fragment as deviceToken. >>>>>>>>> >>>>>>>>> Ok answering to myself ;) That won't work neither since if we do that UPS won't have the compllete push endpoint URL. >>>>>>>>> So how do we deal with that ? >>>>>>>>> >>>>>>>>> >>>>>>>>> On Thu, Feb 6, 2014 at 3:27 PM, Matthias Wessendorf wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Thu, Feb 6, 2014 at 3:11 PM, Sebastien Blanc >>>>> >>>>> >>>>> -- >>>>> Sent from Gmail Mobile >>>>> _______________________________________________ >>>>> aerogear-dev mailing list >>>>> aerogear-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >>> >>> >>> -- >>> Matthias Wessendorf >>> >>> blog: http://matthiaswessendorf.wordpress.com/ >>> sessions: http://www.slideshare.net/mwessendorf >>> twitter: http://twitter.com/mwessendorf >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140723/4d6188cd/attachment.html From mmurray at redhat.com Wed Jul 23 19:18:16 2014 From: mmurray at redhat.com (Michelle Murray) Date: Wed, 23 Jul 2014 19:18:16 -0400 (EDT) Subject: [aerogear-dev] Docs: update on the UPS docs In-Reply-To: References: Message-ID: <771868923.14523103.1406157496965.JavaMail.zimbra@redhat.com> I think Matthias' suggestions for the UPS content look great! I think having the UPS content on one page is ideal. I came up with 4 categories: * UPS Guide, * Tutorials for adding and testing various application variants, * Tutorial for further developing push functionality in applications, * Reference material (APIs). I think the only real difference here from Matthias' plan is that I would separate the existing tutorials into 2 distinct categories. I've included ideas about the content for each of these categories/docs below. I've tried to fill out the table of contents for the docs from what Matthias listed and the docs on the site. As Matthias said, the info in the specs will likely be included in the UPS Guide so they'll become obsolete. Please let me know what you think and how I can help further. Thanks, Michelle Unified Push Server Guide 1. Overview 1.1 About the Unified Push Server [Overview only: What it is, What it consists of, What makes it different from other push servers] 1.2 Use Cases of the Unified Push Server [Who uses it, When to use it, Why use it] 1.3 Useful Terminology [Glossary] 1.4 How the Unified Push Server Works [The details: What is the workflow for Admins and Devs using it? How do apps interact with it; basically setting out the tasks that need to be done and that come in the remaining chps of this guide] 2. Installing the Unified Push Server on JBoss (Wildfly? other non-JBoss servers? make generic server?) [When would choose this option, Components needed] [Steps for installing and running] [Any special JBoss configuration needed or options available] 3. Installing the Unified Push Server on OpenShift [When would choose this option, Components needed] [Steps for installing and running: OpenShift UI, rhc CLI, JBoss Tools OpenShift Tools?] [Any special OpenShift configuration needed or options available] 4. Administering the Unified Push Server Console [Chapter for Admins, common info regardless of underlying UPS hosting sever type] [Overview: What is the console, when to use, who uses] [How to access] [Features: Enroll/remove console users (devs, admins, viewers), ..., (can also complete UPS actions relating to specific apps but see next chp for that info)] [Any console customization? change password, ...] [Additional security?] 5. Configuring and Managing Applications that use the Unified Push Server [Chapter for Devs; Admins can also do the tasks in the console] [Overview of process: register app and variants with server, include server specific info in app, host app for users to install, apps can send automated push notification requests to server using JavaSender API or can use unified push server to send manual push notifications] [How to register app and variants with server, add pointers to any variant prerequisites like needing certificates for Apple, can give more extended info in Tutorials**] [How to configure app source code so as to use server - keep it minimal and focused on which info needed from UPS to be added to app source code, can give more extended info in Tutorials**] [How to send push notification, disable push notifications for selected installs, ...] [For examples of this in action see Tutorials**] 6. More Information [Info on adding and testing push notifications on various Application variants, see Tutorials**] [Info on developing applications that use automated push notifications, see Tutorial"] [Info on push and push server APIs, see blah page for a linked lists of APIs] **Tutorials: Adding and Testing Push Notifications for Applications 1. Introduction [Each variant has different requirements in terms of preconfiguration and where in source code to add push server info] [Tutorials look at each variant and walk through an example of configuring push notifications for each variant] [Assumes push server is running and dev enrolled to use it] 2. ANPs http://aerogear.org/docs/guides/aerogear-push-ios/ 3. GCM http://aerogear.org/docs/guides/aerogear-push-android/ http://aerogear.org/docs/guides/aerogear-push-chrome/ 4. Cordova http://aerogear.org/docs/guides/aerogear-push-cordova-ios/ http://aerogear.org/docs/guides/aerogear-push-cordova-android/ http://aerogear.org/docs/guides/aerogear-cordova/AerogearCordovaPush/ 5. SimplePush http://aerogear.org/docs/guides/aerogear-push-js/ "Tutorial: Developing Push Notification Applications http://aerogear.org/docs/guides/GetStartedwithJavaSender/ Reference: Push APIs JavaSender ...? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140723/cb07eb94/attachment-0001.html From jbalunas at redhat.com Wed Jul 23 20:20:15 2014 From: jbalunas at redhat.com (Jay Balunas) Date: Wed, 23 Jul 2014 20:20:15 -0400 Subject: [aerogear-dev] Docs: update on the UPS docs In-Reply-To: <771868923.14523103.1406157496965.JavaMail.zimbra@redhat.com> References: <771868923.14523103.1406157496965.JavaMail.zimbra@redhat.com> Message-ID: <2BAE779A-BF29-4AD9-9CF9-7D13DB218C3E@redhat.com> Thanks Michelle - this is some good details and suggestions! I like the different categories ideas. I'm sure others will have feedback or additional items as well. On Jul 23, 2014, at 7:18 PM, Michelle Murray wrote: > I think Matthias' suggestions for the UPS content look great! I think having the UPS content on one page is ideal. > > I came up with 4 categories: > * UPS Guide, > * Tutorials for adding and testing various application variants, > * Tutorial for further developing push functionality in applications, > * Reference material (APIs). > > I think the only real difference here from Matthias' plan is that I would separate the existing tutorials into 2 distinct categories. > > I've included ideas about the content for each of these categories/docs below. I've tried to fill out the table of contents for the docs from what Matthias listed and the docs on the site. As Matthias said, the info in the specs will likely be included in the UPS Guide so they'll become obsolete. > > Please let me know what you think and how I can help further. > > Thanks, > Michelle > > > Unified Push Server Guide > > 1. Overview > 1.1 About the Unified Push Server > [Overview only: What it is, What it consists of, What makes it different from other push servers] > 1.2 Use Cases of the Unified Push Server > [Who uses it, When to use it, Why use it] > 1.3 Useful Terminology > [Glossary] > 1.4 How the Unified Push Server Works > [The details: What is the workflow for Admins and Devs using it? How do apps interact with it; basically setting out the tasks that need to be done and that come in the remaining chps of this guide] > > 2. Installing the Unified Push Server on JBoss (Wildfly? other non-JBoss servers? make generic server?) > [When would choose this option, Components needed] > [Steps for installing and running] > [Any special JBoss configuration needed or options available] > > 3. Installing the Unified Push Server on OpenShift > [When would choose this option, Components needed] > [Steps for installing and running: OpenShift UI, rhc CLI, JBoss Tools OpenShift Tools?] > [Any special OpenShift configuration needed or options available] > > 4. Administering the Unified Push Server Console > [Chapter for Admins, common info regardless of underlying UPS hosting sever type] > [Overview: What is the console, when to use, who uses] > [How to access] > [Features: Enroll/remove console users (devs, admins, viewers), ..., (can also complete UPS actions relating to specific apps but see next chp for that info)] > [Any console customization? change password, ...] > [Additional security?] > > 5. Configuring and Managing Applications that use the Unified Push Server > [Chapter for Devs; Admins can also do the tasks in the console] > [Overview of process: register app and variants with server, include server specific info in app, host app for users to install, apps can send automated push notification requests to server using JavaSender API or can use unified push server to send manual push notifications] > [How to register app and variants with server, add pointers to any variant prerequisites like needing certificates for Apple, can give more extended info in Tutorials**] > [How to configure app source code so as to use server - keep it minimal and focused on which info needed from UPS to be added to app source code, can give more extended info in Tutorials**] > [How to send push notification, disable push notifications for selected installs, ...] > [For examples of this in action see Tutorials**] > > 6. More Information > [Info on adding and testing push notifications on various Application variants, see Tutorials**] > [Info on developing applications that use automated push notifications, see Tutorial"] > [Info on push and push server APIs, see blah page for a linked lists of APIs] > > > > **Tutorials: Adding and Testing Push Notifications for Applications > 1. Introduction > [Each variant has different requirements in terms of preconfiguration and where in source code to add push server info] > [Tutorials look at each variant and walk through an example of configuring push notifications for each variant] > [Assumes push server is running and dev enrolled to use it] > > > 2. ANPs > http://aerogear.org/docs/guides/aerogear-push-ios/ > > 3. GCM > http://aerogear.org/docs/guides/aerogear-push-android/ > http://aerogear.org/docs/guides/aerogear-push-chrome/ > > 4. Cordova > http://aerogear.org/docs/guides/aerogear-push-cordova-ios/ > http://aerogear.org/docs/guides/aerogear-push-cordova-android/ > http://aerogear.org/docs/guides/aerogear-cordova/AerogearCordovaPush/ > > 5. SimplePush > http://aerogear.org/docs/guides/aerogear-push-js/ > > > > "Tutorial: Developing Push Notification Applications > http://aerogear.org/docs/guides/GetStartedwithJavaSender/ > > > > Reference: Push APIs > JavaSender > ...? > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140723/24d40ebe/attachment.html From scm.blanc at gmail.com Thu Jul 24 04:28:07 2014 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Thu, 24 Jul 2014 10:28:07 +0200 Subject: [aerogear-dev] Docs: update on the UPS docs In-Reply-To: <771868923.14523103.1406157496965.JavaMail.zimbra@redhat.com> References: <771868923.14523103.1406157496965.JavaMail.zimbra@redhat.com> Message-ID: Hey Michelle ! I like your TOC for the guide. Some comments inline On Thu, Jul 24, 2014 at 1:18 AM, Michelle Murray wrote: > I think Matthias' suggestions for the UPS content look great! I think > having the UPS content on one page is ideal. > > I came up with 4 categories: > * UPS Guide, > * Tutorials for adding and testing various application variants, > * Tutorial for further developing push functionality in applications, > * Reference material (APIs). > > I think the only real difference here from Matthias' plan is that I would > separate the existing tutorials into 2 distinct categories. > > I've included ideas about the content for each of these categories/docs > below. I've tried to fill out the table of contents for the docs from what > Matthias listed and the docs on the site. As Matthias said, the info in the > specs will likely be included in the UPS Guide so they'll become obsolete. > > Please let me know what you think and how I can help further. > > Thanks, > Michelle > > > *Unified Push Server Guide* > > 1. Overview > 1.1 About the Unified Push Server > [Overview only: What it is, What it consists of, What makes it > different from other push servers] > 1.2 Use Cases of the Unified Push Server > [Who uses it, When to use it, Why use it] > 1.3 Useful Terminology > [Glossary] > 1.4 How the Unified Push Server Works > [The details: What is the workflow for Admins and Devs using it? > How do apps interact with it; basically setting out the tasks that need to > be done and that come in the remaining chps of this guide] > > 2. Installing the Unified Push Server on JBoss (Wildfly? other non-JBoss > servers? make generic server?) > [When would choose this option, Components needed] > [Steps for installing and running] > [Any special JBoss configuration needed or options available] > > 3. Installing the Unified Push Server on OpenShift > [When would choose this option, Components needed] > [Steps for installing and running: OpenShift UI, rhc CLI, JBoss > Tools OpenShift Tools?] > [Any special OpenShift configuration needed or options available] > > 4. Administering the Unified Push Server Console > [Chapter for Admins, common info regardless of underlying UPS > hosting sever type] > [Overview: What is the console, when to use, who uses] > [How to access] > [Features: Enroll/remove console users (devs, admins, viewers), > ..., (can also complete UPS actions relating to specific apps but see next > chp for that info)] > [Any console customization? change password, ...] > [Additional security?] > > 5. Configuring and Managing Applications that use the Unified Push Server > [Chapter for Devs; Admins can also do the tasks in the console] > [Overview of process: register app and variants with server, > include server specific info in app, host app for users to install, apps > can send automated push notification requests to server using JavaSender > API or can use unified push server to send manual push notifications] > [How to register app and variants with server, add pointers to any > variant prerequisites like needing certificates for Apple, can give more > extended info in Tutorials**] > [How to configure app source code so as to use server - keep it > minimal and focused on which info needed from UPS to be added to app source > code, can give more extended info in Tutorials**] > Here, I imagine we just point out the registration snippets that are generated ? Do we just focus on the Client Apps or do we mention the Java Sender or see [1] ? > [How to send push notification, disable push notifications for > selected installs, ...] > Here, we explain how to use the "Send Push" screen ? > [For examples of this in action see Tutorials**] > I would add a section about the stats and metrics > > 6. More Information > [Info on adding and testing push notifications on various > Application variants, see Tutorials**] > [Info on developing applications that use automated push > notifications, see Tutorial"] > [Info on push and push server APIs, see blah page for a linked > lists of APIs] > > [1] I know we have a tutorial on the Sender, but maybe it will not hurt to have a small section on how to integrate UPS with your Java EE Backend > > > ***Tutorials: Adding and Testing Push Notifications for Applications* > 1. Introduction > [Each variant has different requirements in terms of > preconfiguration and where in source code to add push server info] > [Tutorials look at each variant and walk through an example of > configuring push notifications for each variant] > [Assumes push server is running and dev enrolled to use it] > > > 2. ANPs > http://aerogear.org/docs/guides/aerogear-push-ios/ > > 3. GCM > http://aerogear.org/docs/guides/aerogear-push-android/ > http://aerogear.org/docs/guides/aerogear-push-chrome/ > > 4. Cordova > http://aerogear.org/docs/guides/aerogear-push-cordova-ios/ > http://aerogear.org/docs/guides/aerogear-push-cordova-android/ > http://aerogear.org/docs/guides/aerogear-cordova/AerogearCordovaPush/ > Like Matthias said, we will have just one single page for that now > > 5. SimplePush > http://aerogear.org/docs/guides/aerogear-push-js/ > > > > *"Tutorial: Developing Push Notification Applications* > http://aerogear.org/docs/guides/GetStartedwithJavaSender/ > > > > *Reference: Push APIs* > JavaSender > ...? > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140724/74126ded/attachment-0001.html From matzew at apache.org Thu Jul 24 05:26:08 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Thu, 24 Jul 2014 11:26:08 +0200 Subject: [aerogear-dev] Docs: update on the UPS docs In-Reply-To: References: Message-ID: Before actually starting with the (initial) rewrite of the UPS guide (as I outlined), I did the re-org of the UPS content. Please review: https://github.com/aerogear/aerogear.org/pull/327 On Mon, Jul 21, 2014 at 5:59 PM, Matthias Wessendorf wrote: > Hi, > > right now we have a lot of different 'documentation files', like the > README, some specs, and guides and tutorials. > > I'd like to restructure that a bit and centralize the documentation a bit. > > On the "push" landing page ([1]), I'd like to change the "Lean More" link > to a new page that has all the UPS centric documentations > > - AeroGear UnifiedPush Server User/Reference Guide > - Tutorials > > > AeroGear > UnifiedPush Server User/Reference Guide > > - Overview > - some generic information > - Installation and configuration > - what's needed (e.g. JBoss and a database) > - Running on OpenShift > - using the UI on OpenShift > - using the rhc command line > - Using the Admin UI > - doing an overhaul of our existing Admin UI guide (e.g. taking new > screenshots and updating based on new UI features) > > The format of the *reference guide* would be similar to the one from > Keycloak ([2]). But... I will continue using asciidoc ;-) > > The README will be extremely quick and simply link to the homepage ;-) > After this *new* reference guide, I think some of the current specs can > be removed, as the *reference guide* hopefully covers all of their > content :-) > > For the RESTful APIs, I have to look what Keycloak did to get something > like: > http://docs.jboss.org/keycloak/docs/1.0-beta-3/rest-api/overview-index.html > > After the work as been completed, I will be revisiting the specs and > evaluate their need ;-) > Tutorials > > This section will contain links to all the different tutorials we have: > > - http://aerogear.org/docs/guides/aerogear-push-ios/ > - http://aerogear.org/docs/guides/aerogear-push-js/ > - http://aerogear.org/docs/guides/aerogear-push-android/ > - http://aerogear.org/docs/guides/aerogear-push-chrome/ > - http://aerogear.org/docs/guides/GetStartedwithJavaSender/ > > For Cordova we will have one single document, instead of three: > > - http://aerogear.org/docs/guides/aerogear-push-cordova-android/ > - http://aerogear.org/docs/guides/aerogear-push-cordova-ios/ > - http://aerogear.org/docs/guides/aerogear-cordova/AerogearCordovaPush/ > > There is already a JIRA for that ([4]). > > To make it more clear (or clean?), I will remove the UPS/Push related docs > from our guides ([3]) and replace all those links by a single link to the > above mentioned new page (also referenced from [1]). > > Greetings, > Matthias > > > > - [1] http://aerogear.org/push/ > - [2] > http://docs.jboss.org/keycloak/docs/1.0-beta-3/userguide/html/index.html > - [3] http://aerogear.org/docs/guides/ > - [4] https://issues.jboss.org/browse/AGPUSH-805 > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140724/e859973a/attachment.html From tkriz at redhat.com Thu Jul 24 06:19:20 2014 From: tkriz at redhat.com (Tadeas Kriz) Date: Thu, 24 Jul 2014 12:19:20 +0200 Subject: [aerogear-dev] Differences between Firefox OS "native" Push lib and AeroGear's Push adapter In-Reply-To: References: <9B70BDB9-4774-4BF0-9FF7-5213185E4F52@redhat.com> <51C9D854-0730-4B2A-9A92-9DC92649947D@redhat.com> <8AEB32A5-0F61-495B-8EA5-767F48312B9C@redhat.com> <3B256910-96B3-4F55-8456-D890F4B37B2B! ! ! @redhat.com> <28EA872A-87E3-4035-9C63-DA04EF034580@redhat.com> Message-ID: <02064329-0F9B-49DC-A5EC-A106001DD51F@redhat.com> ? Tadeas Kriz On 23 Jul 2014, at 09:56 pm, Lucas Holmquist wrote: > > so there is this issue, , about not being able to delete a simplePush installation. > > using the UPS js client, i registered the ?deviceToken? with the push server, but when trying to use CURL or even the JS lib, i was getting a 404, and i noticed that it would never actually hit the server( i was in debug mode in IntelliJ ) > > this was a demo that i had working back in april https://github.com/lholmquist/mobileweek/blob/master/mobileweek-ffos/js/app.js#L17 > > i noticed that when i registered the deviceToken, i was doing a encodeURIComponent before sending it to the UPS. > > i modified the UPS JS client to do it this way, and then when i tried to do the remove, i actually hit the breakpoints i set. but the server could not find the installation doing > > Installation installation = > clientInstallationService.findInstallationForVariantByDeviceToken(variant.getVariantID(), token); > > > I changed the JS client to only do 1 encode instead of 2 but it still couldn?t find the installation. > > I?m not really familiar with JPA and all that, so i don?t know how the query stuff works in this case > > > But i do think we should be encoding the deviceToken( which is the pushEndpointURL ) when registering with the UPS, or else i don?t think we can ever get access to that endpoint > I?d rather not require this. I mean, if there is no other way, then yes, let?s encode, but I can?t see the reason why would that be a problem. Basically, when you put it into the JSON when registering, it?s just a string and string can have any possible character, no matter what. Then the request. When it?s encoded one time, so it can be put into the URL, it should be enough for the server to use it and to search an installation in the database. Is is possible that there are some Hibernate?s restrictions for the ?deviceToken? field? > > On Jul 14, 2014, at 9:52 AM, Lucas Holmquist wrote: > >> >> On Jul 11, 2014, at 6:33 AM, Matthias Wessendorf wrote: >> >>> Hey Luke, >>> >>> I created this JIRA: >>> https://issues.jboss.org/browse/AGPUSH-802 >>> >>> As I plan working on AGPUSH-532 next week, to make sure we have the 'right' model in place for 1.0.0. I think once the server bits are merged, we should address AGPUSH-802 >> >> kk >> >>> >>> -Matthias >>> >>> >>> On Thu, Apr 10, 2014 at 5:22 PM, Lucas Holmquist wrote: >>> so after testing this thing out with encodeURIComponent, the delete does work, however, we need to "double up" the encode. >>> >>> this works: >>> >>> https://gist.github.com/lholmquist/10393357 >>> >>> >>> this doesn't: >>> >>> https://gist.github.com/lholmquist/10393450 >>> >>> >>> >>> On Apr 7, 2014, at 2:09 PM, Lucas Holmquist wrote: >>> >>>> >>>> On Apr 7, 2014, at 12:52 PM, Matthias Wessendorf wrote: >>>> >>>>> Ok, >>>>> >>>>> So as token, we use the endpointURL, and on client we perform the encodeURIComponent() function ? >>>> >>>> i think so( as suggested 2 months ago :) ) i just need to see how this will affect how we store stuff in LS. >>>> >>>> >>>> >>>>> >>>>> -Matthias >>>>> >>>>> On Monday, April 7, 2014, Lucas Holmquist wrote: >>>>> so i went back to look at what i had, >>>>> >>>>> >>>>> i don't think we need to get to complicated here, >>>>> >>>>> reading the spec stuff, and this example >>>>> >>>>> https://wiki.mozilla.org/WebAPI/SimplePush#Client_.28WebApp.29_code >>>>> >>>>> they show sending the pushEndpoint to the "App server", so i think we could just use and keep it simple >>>>> >>>>> it is also recommended that the channelID is never exposed to the application. >>>>> >>>>> >>>>> On Apr 1, 2014, at 3:34 PM, Lucas Holmquist wrote: >>>>> >>>>>> i had something, now i forgot what it was, need to go back and check >>>>>> On Apr 1, 2014, at 3:05 PM, Matthias Wessendorf wrote: >>>>>> >>>>>>> >>>>>>> On Fri, Feb 14, 2014 at 2:06 PM, Lucas Holmquist wrote: >>>>>>> still exploring >>>>>>> >>>>>>> :-) any recent thoughts on 'encodeURIComponent()' ? >>>>>>> >>>>>>> >>>>>>> On Feb 13, 2014, at 3:39 PM, Sebastien Blanc wrote: >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Wed, Feb 12, 2014 at 2:30 PM, Lucas Holmquist wrote: >>>>>>>> i might have a couple thoughts, but i need to try some things out first >>>>>>>> >>>>>>>> Any update on that or does the solution proposed by Matzew (using encodeURIComponent() ) could be enough ? >>>>>>>> >>>>>>>> On Feb 12, 2014, at 3:53 AM, Sebastien Blanc wrote: >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Tue, Feb 11, 2014 at 7:15 PM, Sebastien Blanc wrote: >>>>>>>>> Ok, >>>>>>>>> I've been doing some tests by using the PushEndpoint as device token. For registration it works but I just faced an issue by trying to unregister because the URL for the DELETE looks like : >>>>>>>>> >>>>>>>>> https://judconpush-sblanc.rhcloud.com/rest/registry/device/https://updates.push.services.mozilla.com/update/my_personnal_psuhendpoint_id [ >>>>>>>>> >>>>>>>>> And the REST endpoint get a bit crazy by the extra "/" present in the endpoint URL. Therefore, I think we must just use the last URL fragment as deviceToken. >>>>>>>>> >>>>>>>>> Ok answering to myself ;) That won't work neither since if we do that UPS won't have the compllete push endpoint URL. >>>>>>>>> So how do we deal with that ? >>>>>>>>> >>>>>>>>> >>>>>>>>> On Thu, Feb 6, 2014 at 3:27 PM, Matthias Wessendorf wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Thu, Feb 6, 2014 at 3:11 PM, Sebastien Blanc >>>>> >>>>> >>>>> -- >>>>> Sent from Gmail Mobile >>>>> _______________________________________________ >>>>> aerogear-dev mailing list >>>>> aerogear-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >>> >>> >>> -- >>> Matthias Wessendorf >>> >>> blog: http://matthiaswessendorf.wordpress.com/ >>> sessions: http://www.slideshare.net/mwessendorf >>> twitter: http://twitter.com/mwessendorf >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140724/bb96097d/attachment-0001.html From matzew at apache.org Thu Jul 24 06:24:32 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Thu, 24 Jul 2014 12:24:32 +0200 Subject: [aerogear-dev] Differences between Firefox OS "native" Push lib and AeroGear's Push adapter In-Reply-To: <02064329-0F9B-49DC-A5EC-A106001DD51F@redhat.com> References: <9B70BDB9-4774-4BF0-9FF7-5213185E4F52@redhat.com> <51C9D854-0730-4B2A-9A92-9DC92649947D@redhat.com> <8AEB32A5-0F61-495B-8EA5-767F48312B9C@redhat.com> <28EA872A-87E3-4035-9C63-DA04EF034580@redhat.com> <02064329-0F9B-49DC-A5EC-A106001DD51F@redhat.com> Message-ID: On Thu, Jul 24, 2014 at 12:19 PM, Tadeas Kriz wrote: > > ? > Tadeas Kriz > > On 23 Jul 2014, at 09:56 pm, Lucas Holmquist wrote: > > > so there is this issue, , about not being able to delete a simplePush > installation. > > using the UPS js client, i registered the ?deviceToken? with the push > server, but when trying to use CURL or even the JS lib, i was getting a > 404, and i noticed that it would never actually hit the server( i was in > debug mode in IntelliJ ) > > this was a demo that i had working back in april > https://github.com/lholmquist/mobileweek/blob/master/mobileweek-ffos/js/app.js#L17 > > i noticed that when i registered the deviceToken, i was doing a > encodeURIComponent before sending it to the UPS. > > i modified the UPS JS client to do it this way, and then when i tried to > do the remove, i actually hit the breakpoints i set. but the server could > not find the installation doing > > Installation installation = > > clientInstallationService.findInstallationForVariantByDeviceToken(variant.getVariantID(), > token); > > > I changed the JS client to only do 1 encode instead of 2 but it still > couldn?t find the installation. > > I?m not really familiar with JPA and all that, so i don?t know how the > query stuff works in this case > > > But i do think we should be encoding the deviceToken( which is the > pushEndpointURL ) when registering with the UPS, or else i don?t think we > can ever get access to that endpoint > > > I?d rather not require this. I mean, if there is no other way, then yes, > let?s encode, but I can?t see the reason why would that be a problem. > Basically, when you put it into the JSON when registering, it?s just a > string and string can have any possible character, no matter what. Then the > request. When it?s encoded one time, so it can be put into the URL, it > should be enough for the server to use it and to search an installation in > the database. > > Is is possible that there are some Hibernate?s restrictions for the > ?deviceToken? field? > possible - hadn't had a chance to check that. Note: some of the model changed w/ Beta1 -M > > > On Jul 14, 2014, at 9:52 AM, Lucas Holmquist wrote: > > > On Jul 11, 2014, at 6:33 AM, Matthias Wessendorf > wrote: > > Hey Luke, > > I created this JIRA: > https://issues.jboss.org/browse/AGPUSH-802 > > As I plan working on AGPUSH-532 next week, to make sure we have the > 'right' model in place for 1.0.0. I think once the server bits are merged, > we should address AGPUSH-802 > > > kk > > > -Matthias > > > On Thu, Apr 10, 2014 at 5:22 PM, Lucas Holmquist > wrote: > >> so after testing this thing out with encodeURIComponent, the delete does >> work, however, we need to "double up" the encode. >> >> this works: >> >> https://gist.github.com/lholmquist/10393357 >> >> >> this doesn't: >> >> https://gist.github.com/lholmquist/10393450 >> >> >> >> On Apr 7, 2014, at 2:09 PM, Lucas Holmquist wrote: >> >> >> On Apr 7, 2014, at 12:52 PM, Matthias Wessendorf >> wrote: >> >> Ok, >> >> So as token, we use the endpointURL, and on client we perform the >> encodeURIComponent() function ? >> >> >> i think so( as suggested 2 months ago :) ) i just need to see how this >> will affect how we store stuff in LS. >> >> >> >> >> -Matthias >> >> On Monday, April 7, 2014, Lucas Holmquist wrote: >> >>> so i went back to look at what i had, >>> >>> >>> i don't think we need to get to complicated here, >>> >>> reading the spec stuff, and this example >>> >>> https://wiki.mozilla.org/WebAPI/SimplePush#Client_.28WebApp.29_code >>> >>> they show sending the pushEndpoint to the "App server", so i think we >>> could just use and keep it simple >>> >>> it is also recommended that the channelID is never exposed to the >>> application. >>> >>> >>> On Apr 1, 2014, at 3:34 PM, Lucas Holmquist wrote: >>> >>> i had something, now i forgot what it was, need to go back and check >>> On Apr 1, 2014, at 3:05 PM, Matthias Wessendorf >>> wrote: >>> >>> >>> On Fri, Feb 14, 2014 at 2:06 PM, Lucas Holmquist >>> wrote: >>> >>> still exploring >>> >>> >>> :-) any recent thoughts on 'encodeURIComponent()' ? >>> >>> >>> >>> On Feb 13, 2014, at 3:39 PM, Sebastien Blanc >>> wrote: >>> >>> >>> >>> >>> On Wed, Feb 12, 2014 at 2:30 PM, Lucas Holmquist >>> wrote: >>> >>> i might have a couple thoughts, but i need to try some things out first >>> >>> >>> Any update on that or does the solution proposed by Matzew (using encodeURIComponent() >>> ) could be enough ? >>> >>> >>> On Feb 12, 2014, at 3:53 AM, Sebastien Blanc >>> wrote: >>> >>> >>> >>> >>> On Tue, Feb 11, 2014 at 7:15 PM, Sebastien Blanc >>> wrote: >>> >>> Ok, >>> I've been doing some tests by using the PushEndpoint as device token. >>> For registration it works but I just faced an issue by trying to unregister >>> because the URL for the DELETE looks like : >>> >>> >>> https://judconpush-sblanc.rhcloud.com/rest/registry/device/https://updates.push.services.mozilla.com/update/my_personnal_psuhendpoint_id >>> [ >>> >>> And the REST endpoint get a bit crazy by the extra "/" present in the >>> endpoint URL. Therefore, I think we must just use the last URL fragment as >>> deviceToken. >>> >>> >>> Ok answering to myself ;) That won't work neither since if we do that >>> UPS won't have the compllete push endpoint URL. >>> So how do we deal with that ? >>> >>> >>> >>> On Thu, Feb 6, 2014 at 3:27 PM, Matthias Wessendorf >>> wrote: >>> >>> >>> >>> >>> On Thu, Feb 6, 2014 at 3:11 PM, Sebastien Blanc >>> >>> >> >> -- >> Sent from Gmail Mobile >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140724/1c2f6f9b/attachment.html From matzew at apache.org Thu Jul 24 07:29:12 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Thu, 24 Jul 2014 13:29:12 +0200 Subject: [aerogear-dev] Docs: update on the UPS docs In-Reply-To: References: Message-ID: Here is the TOC that I have in mind (and started to work on): UnifiedPush Server User Guide - Overview - About the UnifiedPush Server - Use-cases and scenarios - Useful Terminology - How the UnifiedPush Server Works - Installation and configuration - The WAR file distribution - setup and configure a database - deploy the WAR files - Running on OpenShift - create an instance using OpenShift's Web UI - create an instance using OpenShift's command line interface - Using the Admin UI - Administering the UnifiedPush Server Console - Configuring and Managing Applications that use the UnifiedPush Server - Preparing mobile devices to be connected with the UnifiedPush Server - Sending Push Notifications - Next steps - TBD: Links to tutorials and specs (some specs might go away) On Thu, Jul 24, 2014 at 11:26 AM, Matthias Wessendorf wrote: > Before actually starting with the (initial) rewrite of the UPS guide (as I > outlined), I did the re-org of the UPS content. > > Please review: > https://github.com/aerogear/aerogear.org/pull/327 > > > > > On Mon, Jul 21, 2014 at 5:59 PM, Matthias Wessendorf > wrote: > >> Hi, >> >> right now we have a lot of different 'documentation files', like the >> README, some specs, and guides and tutorials. >> >> I'd like to restructure that a bit and centralize the documentation a bit. >> >> On the "push" landing page ([1]), I'd like to change the "Lean More" link >> to a new page that has all the UPS centric documentations >> >> - AeroGear UnifiedPush Server User/Reference Guide >> - Tutorials >> >> >> AeroGear >> UnifiedPush Server User/Reference Guide >> >> - Overview >> - some generic information >> - Installation and configuration >> - what's needed (e.g. JBoss and a database) >> - Running on OpenShift >> - using the UI on OpenShift >> - using the rhc command line >> - Using the Admin UI >> - doing an overhaul of our existing Admin UI guide (e.g. taking >> new screenshots and updating based on new UI features) >> >> The format of the *reference guide* would be similar to the one from >> Keycloak ([2]). But... I will continue using asciidoc ;-) >> >> The README will be extremely quick and simply link to the homepage ;-) >> After this *new* reference guide, I think some of the current specs can >> be removed, as the *reference guide* hopefully covers all of their >> content :-) >> >> For the RESTful APIs, I have to look what Keycloak did to get something >> like: >> http://docs.jboss.org/keycloak/docs/1.0-beta-3/rest-api/overview-index.html >> >> After the work as been completed, I will be revisiting the specs and >> evaluate their need ;-) >> Tutorials >> >> This section will contain links to all the different tutorials we have: >> >> - http://aerogear.org/docs/guides/aerogear-push-ios/ >> - http://aerogear.org/docs/guides/aerogear-push-js/ >> - http://aerogear.org/docs/guides/aerogear-push-android/ >> - http://aerogear.org/docs/guides/aerogear-push-chrome/ >> - http://aerogear.org/docs/guides/GetStartedwithJavaSender/ >> >> For Cordova we will have one single document, instead of three: >> >> - http://aerogear.org/docs/guides/aerogear-push-cordova-android/ >> - http://aerogear.org/docs/guides/aerogear-push-cordova-ios/ >> - >> http://aerogear.org/docs/guides/aerogear-cordova/AerogearCordovaPush/ >> >> There is already a JIRA for that ([4]). >> >> To make it more clear (or clean?), I will remove the UPS/Push related >> docs from our guides ([3]) and replace all those links by a single link to >> the above mentioned new page (also referenced from [1]). >> >> Greetings, >> Matthias >> >> >> >> - [1] http://aerogear.org/push/ >> - [2] >> http://docs.jboss.org/keycloak/docs/1.0-beta-3/userguide/html/index.html >> - [3] http://aerogear.org/docs/guides/ >> - [4] https://issues.jboss.org/browse/AGPUSH-805 >> >> >> -- >> Matthias Wessendorf >> >> blog: http://matthiaswessendorf.wordpress.com/ >> sessions: http://www.slideshare.net/mwessendorf >> twitter: http://twitter.com/mwessendorf >> > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140724/cf334e0c/attachment-0001.html From matzew at apache.org Thu Jul 24 07:32:51 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Thu, 24 Jul 2014 13:32:51 +0200 Subject: [aerogear-dev] Docs: update on the UPS docs In-Reply-To: References: Message-ID: update: UnifiedPush Server User Guide - Overview - About the UnifiedPush Server - Use-cases and scenarios - Useful Terminology - How the UnifiedPush Server Works - Installation and configuration - The WAR file distribution - setup and configure a database - deploy the WAR files - Running on OpenShift - create an instance using OpenShift's Web UI - create an instance using OpenShift's command line interface - Using the Admin UI - Administering the UnifiedPush Server Console - Configuring and Managing Applications that use the UnifiedPush Server - Preparing mobile devices to be connected with the UnifiedPush Server - Sending Push Notifications - Preparing backends to send Push Notifications - Next steps - TBD: Links to tutorials and specs (some specs might go away) On Thu, Jul 24, 2014 at 1:29 PM, Matthias Wessendorf wrote: > Here is the TOC that I have in mind (and started to work on): > > UnifiedPush Server User Guide > > - Overview > - About the UnifiedPush Server > - Use-cases and scenarios > - Useful Terminology > - How the UnifiedPush Server Works > - Installation and configuration > - The WAR file distribution > - setup and configure a database > - deploy the WAR files > - Running on OpenShift > - create an instance using OpenShift's Web UI > - create an instance using OpenShift's command line interface > - Using the Admin UI > - Administering the UnifiedPush Server Console > - Configuring and Managing Applications that use the UnifiedPush > Server > - Preparing mobile devices to be connected with the UnifiedPush > Server > - Sending Push Notifications > - Next steps > - TBD: Links to tutorials and specs (some specs might go away) > > > > > > On Thu, Jul 24, 2014 at 11:26 AM, Matthias Wessendorf > wrote: > >> Before actually starting with the (initial) rewrite of the UPS guide (as >> I outlined), I did the re-org of the UPS content. >> >> Please review: >> https://github.com/aerogear/aerogear.org/pull/327 >> >> >> >> >> On Mon, Jul 21, 2014 at 5:59 PM, Matthias Wessendorf >> wrote: >> >>> Hi, >>> >>> right now we have a lot of different 'documentation files', like the >>> README, some specs, and guides and tutorials. >>> >>> I'd like to restructure that a bit and centralize the documentation a >>> bit. >>> >>> On the "push" landing page ([1]), I'd like to change the "Lean More" >>> link to a new page that has all the UPS centric documentations >>> >>> - AeroGear UnifiedPush Server User/Reference Guide >>> - Tutorials >>> >>> >>> AeroGear >>> UnifiedPush Server User/Reference Guide >>> >>> - Overview >>> - some generic information >>> - Installation and configuration >>> - what's needed (e.g. JBoss and a database) >>> - Running on OpenShift >>> - using the UI on OpenShift >>> - using the rhc command line >>> - Using the Admin UI >>> - doing an overhaul of our existing Admin UI guide (e.g. taking >>> new screenshots and updating based on new UI features) >>> >>> The format of the *reference guide* would be similar to the one from >>> Keycloak ([2]). But... I will continue using asciidoc ;-) >>> >>> The README will be extremely quick and simply link to the homepage ;-) >>> After this *new* reference guide, I think some of the current specs can >>> be removed, as the *reference guide* hopefully covers all of their >>> content :-) >>> >>> For the RESTful APIs, I have to look what Keycloak did to get something >>> like: >>> http://docs.jboss.org/keycloak/docs/1.0-beta-3/rest-api/overview-index.html >>> >>> After the work as been completed, I will be revisiting the specs and >>> evaluate their need ;-) >>> >>> Tutorials >>> >>> This section will contain links to all the different tutorials we have: >>> >>> - http://aerogear.org/docs/guides/aerogear-push-ios/ >>> - http://aerogear.org/docs/guides/aerogear-push-js/ >>> - http://aerogear.org/docs/guides/aerogear-push-android/ >>> - http://aerogear.org/docs/guides/aerogear-push-chrome/ >>> - http://aerogear.org/docs/guides/GetStartedwithJavaSender/ >>> >>> For Cordova we will have one single document, instead of three: >>> >>> - http://aerogear.org/docs/guides/aerogear-push-cordova-android/ >>> - http://aerogear.org/docs/guides/aerogear-push-cordova-ios/ >>> - >>> http://aerogear.org/docs/guides/aerogear-cordova/AerogearCordovaPush/ >>> >>> There is already a JIRA for that ([4]). >>> >>> To make it more clear (or clean?), I will remove the UPS/Push related >>> docs from our guides ([3]) and replace all those links by a single link to >>> the above mentioned new page (also referenced from [1]). >>> >>> Greetings, >>> Matthias >>> >>> >>> >>> - [1] http://aerogear.org/push/ >>> - [2] >>> http://docs.jboss.org/keycloak/docs/1.0-beta-3/userguide/html/index.html >>> - [3] http://aerogear.org/docs/guides/ >>> - [4] https://issues.jboss.org/browse/AGPUSH-805 >>> >>> >>> -- >>> Matthias Wessendorf >>> >>> blog: http://matthiaswessendorf.wordpress.com/ >>> sessions: http://www.slideshare.net/mwessendorf >>> twitter: http://twitter.com/mwessendorf >>> >> >> >> >> -- >> Matthias Wessendorf >> >> blog: http://matthiaswessendorf.wordpress.com/ >> sessions: http://www.slideshare.net/mwessendorf >> twitter: http://twitter.com/mwessendorf >> > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140724/fb2beb00/attachment.html From daniel.bevenius at gmail.com Thu Jul 24 08:14:35 2014 From: daniel.bevenius at gmail.com (Daniel Bevenius) Date: Thu, 24 Jul 2014 14:14:35 +0200 Subject: [aerogear-dev] Docs: update on the UPS docs In-Reply-To: References: Message-ID: Looks good! perhaps change: Configuring and Managing Applications that use the UnifiedPush Server -> Configuring and managing applications that use the UnifiedPush Server On 24 July 2014 13:32, Matthias Wessendorf wrote: > update: > > > UnifiedPush Server User Guide > > - Overview > - About the UnifiedPush Server > - Use-cases and scenarios > - Useful Terminology > - How the UnifiedPush Server Works > - Installation and configuration > - The WAR file distribution > - setup and configure a database > - deploy the WAR files > - Running on OpenShift > - create an instance using OpenShift's Web UI > - create an instance using OpenShift's command line interface > - Using the Admin UI > - Administering the UnifiedPush Server Console > - Configuring and Managing Applications that use the UnifiedPush > Server > - Preparing mobile devices to be connected with the UnifiedPush > Server > - Sending Push Notifications > - Preparing backends to send Push Notifications > - Next steps > - TBD: Links to tutorials and specs (some specs might go away) > > > > > > > > On Thu, Jul 24, 2014 at 1:29 PM, Matthias Wessendorf > wrote: > >> Here is the TOC that I have in mind (and started to work on): >> >> UnifiedPush Server User Guide >> >> - Overview >> - About the UnifiedPush Server >> - Use-cases and scenarios >> - Useful Terminology >> - How the UnifiedPush Server Works >> - Installation and configuration >> - The WAR file distribution >> - setup and configure a database >> - deploy the WAR files >> - Running on OpenShift >> - create an instance using OpenShift's Web UI >> - create an instance using OpenShift's command line interface >> - Using the Admin UI >> - Administering the UnifiedPush Server Console >> - Configuring and Managing Applications that use the UnifiedPush >> Server >> - Preparing mobile devices to be connected with the UnifiedPush >> Server >> - Sending Push Notifications >> - Next steps >> - TBD: Links to tutorials and specs (some specs might go away) >> >> >> >> >> >> On Thu, Jul 24, 2014 at 11:26 AM, Matthias Wessendorf >> wrote: >> >>> Before actually starting with the (initial) rewrite of the UPS guide (as >>> I outlined), I did the re-org of the UPS content. >>> >>> Please review: >>> https://github.com/aerogear/aerogear.org/pull/327 >>> >>> >>> >>> >>> On Mon, Jul 21, 2014 at 5:59 PM, Matthias Wessendorf >>> wrote: >>> >>>> Hi, >>>> >>>> right now we have a lot of different 'documentation files', like the >>>> README, some specs, and guides and tutorials. >>>> >>>> I'd like to restructure that a bit and centralize the documentation a >>>> bit. >>>> >>>> On the "push" landing page ([1]), I'd like to change the "Lean More" >>>> link to a new page that has all the UPS centric documentations >>>> >>>> - AeroGear UnifiedPush Server User/Reference Guide >>>> - Tutorials >>>> >>>> >>>> AeroGear >>>> UnifiedPush Server User/Reference Guide >>>> >>>> - Overview >>>> - some generic information >>>> - Installation and configuration >>>> - what's needed (e.g. JBoss and a database) >>>> - Running on OpenShift >>>> - using the UI on OpenShift >>>> - using the rhc command line >>>> - Using the Admin UI >>>> - doing an overhaul of our existing Admin UI guide (e.g. taking >>>> new screenshots and updating based on new UI features) >>>> >>>> The format of the *reference guide* would be similar to the one from >>>> Keycloak ([2]). But... I will continue using asciidoc ;-) >>>> >>>> The README will be extremely quick and simply link to the homepage ;-) >>>> After this *new* reference guide, I think some of the current specs >>>> can be removed, as the *reference guide* hopefully covers all of their >>>> content :-) >>>> >>>> For the RESTful APIs, I have to look what Keycloak did to get something >>>> like: >>>> http://docs.jboss.org/keycloak/docs/1.0-beta-3/rest-api/overview-index.html >>>> >>>> After the work as been completed, I will be revisiting the specs and >>>> evaluate their need ;-) >>>> >>>> Tutorials >>>> >>>> This section will contain links to all the different tutorials we have: >>>> >>>> - http://aerogear.org/docs/guides/aerogear-push-ios/ >>>> - http://aerogear.org/docs/guides/aerogear-push-js/ >>>> - http://aerogear.org/docs/guides/aerogear-push-android/ >>>> - http://aerogear.org/docs/guides/aerogear-push-chrome/ >>>> - http://aerogear.org/docs/guides/GetStartedwithJavaSender/ >>>> >>>> For Cordova we will have one single document, instead of three: >>>> >>>> - http://aerogear.org/docs/guides/aerogear-push-cordova-android/ >>>> - http://aerogear.org/docs/guides/aerogear-push-cordova-ios/ >>>> - >>>> http://aerogear.org/docs/guides/aerogear-cordova/AerogearCordovaPush/ >>>> >>>> There is already a JIRA for that ([4]). >>>> >>>> To make it more clear (or clean?), I will remove the UPS/Push related >>>> docs from our guides ([3]) and replace all those links by a single link to >>>> the above mentioned new page (also referenced from [1]). >>>> >>>> Greetings, >>>> Matthias >>>> >>>> >>>> >>>> - [1] http://aerogear.org/push/ >>>> - [2] >>>> http://docs.jboss.org/keycloak/docs/1.0-beta-3/userguide/html/index.html >>>> - [3] http://aerogear.org/docs/guides/ >>>> - [4] https://issues.jboss.org/browse/AGPUSH-805 >>>> >>>> >>>> -- >>>> Matthias Wessendorf >>>> >>>> blog: http://matthiaswessendorf.wordpress.com/ >>>> sessions: http://www.slideshare.net/mwessendorf >>>> twitter: http://twitter.com/mwessendorf >>>> >>> >>> >>> >>> -- >>> Matthias Wessendorf >>> >>> blog: http://matthiaswessendorf.wordpress.com/ >>> sessions: http://www.slideshare.net/mwessendorf >>> twitter: http://twitter.com/mwessendorf >>> >> >> >> >> -- >> Matthias Wessendorf >> >> blog: http://matthiaswessendorf.wordpress.com/ >> sessions: http://www.slideshare.net/mwessendorf >> twitter: http://twitter.com/mwessendorf >> > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140724/0bd165bc/attachment-0001.html From lholmqui at redhat.com Thu Jul 24 08:41:50 2014 From: lholmqui at redhat.com (Lucas Holmquist) Date: Thu, 24 Jul 2014 08:41:50 -0400 Subject: [aerogear-dev] Differences between Firefox OS "native" Push lib and AeroGear's Push adapter In-Reply-To: <02064329-0F9B-49DC-A5EC-A106001DD51F@redhat.com> References: <9B70BDB9-4774-4BF0-9FF7-5213185E4F52@redhat.com> <51C9D854-0730-4B2A-9A92-9DC92649947D@redhat.com> <8AEB32A5-0F61-495B-8EA5-767F48312B9C@redhat.com> <3B256910-96B3-4F55-8456-D890F4B37B2B! ! ! ! @redhat.com> <28EA872A-87E3-4035-9C63-DA04EF034580@redhat.com> <02064329-0F9B-49DC-A5EC-A106001DD51F@redhat.com> Message-ID: On Jul 24, 2014, at 6:19 AM, Tadeas Kriz wrote: > > ? > Tadeas Kriz > > On 23 Jul 2014, at 09:56 pm, Lucas Holmquist wrote: > >> >> so there is this issue, , about not being able to delete a simplePush installation. >> >> using the UPS js client, i registered the ?deviceToken? with the push server, but when trying to use CURL or even the JS lib, i was getting a 404, and i noticed that it would never actually hit the server( i was in debug mode in IntelliJ ) >> >> this was a demo that i had working back in april https://github.com/lholmquist/mobileweek/blob/master/mobileweek-ffos/js/app.js#L17 >> >> i noticed that when i registered the deviceToken, i was doing a encodeURIComponent before sending it to the UPS. >> >> i modified the UPS JS client to do it this way, and then when i tried to do the remove, i actually hit the breakpoints i set. but the server could not find the installation doing >> >> Installation installation = >> clientInstallationService.findInstallationForVariantByDeviceToken(variant.getVariantID(), token); >> >> >> I changed the JS client to only do 1 encode instead of 2 but it still couldn?t find the installation. >> >> I?m not really familiar with JPA and all that, so i don?t know how the query stuff works in this case >> >> >> But i do think we should be encoding the deviceToken( which is the pushEndpointURL ) when registering with the UPS, or else i don?t think we can ever get access to that endpoint >> > > I?d rather not require this. I mean, if there is no other way, then yes, let?s encode, but I can?t see the reason why would that be a problem. Basically, when you put it into the JSON when registering, it?s just a string and string can have any possible character, no matter what. Then the request. When it?s encoded one time, so it can be put into the URL, it should be enough for the server to use it and to search an installation in the database. The problem is that you are not able to access the endpoint. /shortenedURLForBrevity/http://localhost:7777/simplepush/owejfoiwjfooijf994lkmsf239sflkwekjnkhwf basically, that is the endpoint you need to send a DELETE to. which isn?t possible We could also encode on the server side before storing, and the libs/CURL would need to encode for a DELETE? > > Is is possible that there are some Hibernate?s restrictions for the ?deviceToken? field? > >> >> On Jul 14, 2014, at 9:52 AM, Lucas Holmquist wrote: >> >>> >>> On Jul 11, 2014, at 6:33 AM, Matthias Wessendorf wrote: >>> >>>> Hey Luke, >>>> >>>> I created this JIRA: >>>> https://issues.jboss.org/browse/AGPUSH-802 >>>> >>>> As I plan working on AGPUSH-532 next week, to make sure we have the 'right' model in place for 1.0.0. I think once the server bits are merged, we should address AGPUSH-802 >>> >>> kk >>> >>>> >>>> -Matthias >>>> >>>> >>>> On Thu, Apr 10, 2014 at 5:22 PM, Lucas Holmquist wrote: >>>> so after testing this thing out with encodeURIComponent, the delete does work, however, we need to "double up" the encode. >>>> >>>> this works: >>>> >>>> https://gist.github.com/lholmquist/10393357 >>>> >>>> >>>> this doesn't: >>>> >>>> https://gist.github.com/lholmquist/10393450 >>>> >>>> >>>> >>>> On Apr 7, 2014, at 2:09 PM, Lucas Holmquist wrote: >>>> >>>>> >>>>> On Apr 7, 2014, at 12:52 PM, Matthias Wessendorf wrote: >>>>> >>>>>> Ok, >>>>>> >>>>>> So as token, we use the endpointURL, and on client we perform the encodeURIComponent() function ? >>>>> >>>>> i think so( as suggested 2 months ago :) ) i just need to see how this will affect how we store stuff in LS. >>>>> >>>>> >>>>> >>>>>> >>>>>> -Matthias >>>>>> >>>>>> On Monday, April 7, 2014, Lucas Holmquist wrote: >>>>>> so i went back to look at what i had, >>>>>> >>>>>> >>>>>> i don't think we need to get to complicated here, >>>>>> >>>>>> reading the spec stuff, and this example >>>>>> >>>>>> https://wiki.mozilla.org/WebAPI/SimplePush#Client_.28WebApp.29_code >>>>>> >>>>>> they show sending the pushEndpoint to the "App server", so i think we could just use and keep it simple >>>>>> >>>>>> it is also recommended that the channelID is never exposed to the application. >>>>>> >>>>>> >>>>>> On Apr 1, 2014, at 3:34 PM, Lucas Holmquist wrote: >>>>>> >>>>>>> i had something, now i forgot what it was, need to go back and check >>>>>>> On Apr 1, 2014, at 3:05 PM, Matthias Wessendorf wrote: >>>>>>> >>>>>>>> >>>>>>>> On Fri, Feb 14, 2014 at 2:06 PM, Lucas Holmquist wrote: >>>>>>>> still exploring >>>>>>>> >>>>>>>> :-) any recent thoughts on 'encodeURIComponent()' ? >>>>>>>> >>>>>>>> >>>>>>>> On Feb 13, 2014, at 3:39 PM, Sebastien Blanc wrote: >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Wed, Feb 12, 2014 at 2:30 PM, Lucas Holmquist wrote: >>>>>>>>> i might have a couple thoughts, but i need to try some things out first >>>>>>>>> >>>>>>>>> Any update on that or does the solution proposed by Matzew (using encodeURIComponent() ) could be enough ? >>>>>>>>> >>>>>>>>> On Feb 12, 2014, at 3:53 AM, Sebastien Blanc wrote: >>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Tue, Feb 11, 2014 at 7:15 PM, Sebastien Blanc wrote: >>>>>>>>>> Ok, >>>>>>>>>> I've been doing some tests by using the PushEndpoint as device token. For registration it works but I just faced an issue by trying to unregister because the URL for the DELETE looks like : >>>>>>>>>> >>>>>>>>>> https://judconpush-sblanc.rhcloud.com/rest/registry/device/https://updates.push.services.mozilla.com/update/my_personnal_psuhendpoint_id [ >>>>>>>>>> >>>>>>>>>> And the REST endpoint get a bit crazy by the extra "/" present in the endpoint URL. Therefore, I think we must just use the last URL fragment as deviceToken. >>>>>>>>>> >>>>>>>>>> Ok answering to myself ;) That won't work neither since if we do that UPS won't have the compllete push endpoint URL. >>>>>>>>>> So how do we deal with that ? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Thu, Feb 6, 2014 at 3:27 PM, Matthias Wessendorf wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Thu, Feb 6, 2014 at 3:11 PM, Sebastien Blanc >>>>>> >>>>>> >>>>>> -- >>>>>> Sent from Gmail Mobile >>>>>> _______________________________________________ >>>>>> aerogear-dev mailing list >>>>>> aerogear-dev at lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>> >>>>> _______________________________________________ >>>>> aerogear-dev mailing list >>>>> aerogear-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> >>>> >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> >>>> >>>> >>>> -- >>>> Matthias Wessendorf >>>> >>>> blog: http://matthiaswessendorf.wordpress.com/ >>>> sessions: http://www.slideshare.net/mwessendorf >>>> twitter: http://twitter.com/mwessendorf >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140724/12958e63/attachment-0001.html From matzew at apache.org Thu Jul 24 09:14:32 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Thu, 24 Jul 2014 15:14:32 +0200 Subject: [aerogear-dev] Differences between Firefox OS "native" Push lib and AeroGear's Push adapter In-Reply-To: References: <9B70BDB9-4774-4BF0-9FF7-5213185E4F52@redhat.com> <51C9D854-0730-4B2A-9A92-9DC92649947D@redhat.com> <8AEB32A5-0F61-495B-8EA5-767F48312B9C@redhat.com> <28EA872A-87E3-4035-9C63-DA04EF034580@redhat.com> <02064329-0F9B-49DC-A5EC-A106001DD51F@redhat.com> Message-ID: On Thu, Jul 24, 2014 at 2:41 PM, Lucas Holmquist wrote: > > On Jul 24, 2014, at 6:19 AM, Tadeas Kriz wrote: > > > ? > Tadeas Kriz > > On 23 Jul 2014, at 09:56 pm, Lucas Holmquist wrote: > > > so there is this issue, , about not being able to delete a simplePush > installation. > > using the UPS js client, i registered the ?deviceToken? with the push > server, but when trying to use CURL or even the JS lib, i was getting a > 404, and i noticed that it would never actually hit the server( i was in > debug mode in IntelliJ ) > > this was a demo that i had working back in april > https://github.com/lholmquist/mobileweek/blob/master/mobileweek-ffos/js/app.js#L17 > > i noticed that when i registered the deviceToken, i was doing a > encodeURIComponent before sending it to the UPS. > > i modified the UPS JS client to do it this way, and then when i tried to > do the remove, i actually hit the breakpoints i set. but the server could > not find the installation doing > > Installation installation = > > clientInstallationService.findInstallationForVariantByDeviceToken(variant.getVariantID(), > token); > > > I changed the JS client to only do 1 encode instead of 2 but it still > couldn?t find the installation. > > I?m not really familiar with JPA and all that, so i don?t know how the > query stuff works in this case > > > But i do think we should be encoding the deviceToken( which is the > pushEndpointURL ) when registering with the UPS, or else i don?t think we > can ever get access to that endpoint > > > I?d rather not require this. I mean, if there is no other way, then yes, > let?s encode, but I can?t see the reason why would that be a problem. > Basically, when you put it into the JSON when registering, it?s just a > string and string can have any possible character, no matter what. Then the > request. When it?s encoded one time, so it can be put into the URL, it > should be enough for the server to use it and to search an installation in > the database. > > > The problem is that you are not able to access the endpoint. > > /shortenedURLForBrevity/ > http://localhost:7777/simplepush/owejfoiwjfooijf994lkmsf239sflkwekjnkhwf > > basically, that is the endpoint you need to send a DELETE to. which isn?t > possible > I guess on Android that's never a problem because the endpoint there looks like: /shortenedURLForBrevity/+MY_GCM_TOKEN Passos, can you confirm ? -M > > We could also encode on the server side before storing, and the libs/CURL > would need to encode for a DELETE? > > > Is is possible that there are some Hibernate?s restrictions for the > ?deviceToken? field? > > > On Jul 14, 2014, at 9:52 AM, Lucas Holmquist wrote: > > > On Jul 11, 2014, at 6:33 AM, Matthias Wessendorf > wrote: > > Hey Luke, > > I created this JIRA: > https://issues.jboss.org/browse/AGPUSH-802 > > As I plan working on AGPUSH-532 next week, to make sure we have the > 'right' model in place for 1.0.0. I think once the server bits are merged, > we should address AGPUSH-802 > > > kk > > > -Matthias > > > On Thu, Apr 10, 2014 at 5:22 PM, Lucas Holmquist > wrote: > >> so after testing this thing out with encodeURIComponent, the delete does >> work, however, we need to "double up" the encode. >> >> this works: >> >> https://gist.github.com/lholmquist/10393357 >> >> >> this doesn't: >> >> https://gist.github.com/lholmquist/10393450 >> >> >> >> On Apr 7, 2014, at 2:09 PM, Lucas Holmquist wrote: >> >> >> On Apr 7, 2014, at 12:52 PM, Matthias Wessendorf >> wrote: >> >> Ok, >> >> So as token, we use the endpointURL, and on client we perform the >> encodeURIComponent() function ? >> >> >> i think so( as suggested 2 months ago :) ) i just need to see how this >> will affect how we store stuff in LS. >> >> >> >> >> -Matthias >> >> On Monday, April 7, 2014, Lucas Holmquist wrote: >> >>> so i went back to look at what i had, >>> >>> >>> i don't think we need to get to complicated here, >>> >>> reading the spec stuff, and this example >>> >>> https://wiki.mozilla.org/WebAPI/SimplePush#Client_.28WebApp.29_code >>> >>> they show sending the pushEndpoint to the "App server", so i think we >>> could just use and keep it simple >>> >>> it is also recommended that the channelID is never exposed to the >>> application. >>> >>> >>> On Apr 1, 2014, at 3:34 PM, Lucas Holmquist wrote: >>> >>> i had something, now i forgot what it was, need to go back and check >>> On Apr 1, 2014, at 3:05 PM, Matthias Wessendorf >>> wrote: >>> >>> >>> On Fri, Feb 14, 2014 at 2:06 PM, Lucas Holmquist >>> wrote: >>> >>> still exploring >>> >>> >>> :-) any recent thoughts on 'encodeURIComponent()' ? >>> >>> >>> >>> On Feb 13, 2014, at 3:39 PM, Sebastien Blanc >>> wrote: >>> >>> >>> >>> >>> On Wed, Feb 12, 2014 at 2:30 PM, Lucas Holmquist >>> wrote: >>> >>> i might have a couple thoughts, but i need to try some things out first >>> >>> >>> Any update on that or does the solution proposed by Matzew (using encodeURIComponent() >>> ) could be enough ? >>> >>> >>> On Feb 12, 2014, at 3:53 AM, Sebastien Blanc >>> wrote: >>> >>> >>> >>> >>> On Tue, Feb 11, 2014 at 7:15 PM, Sebastien Blanc >>> wrote: >>> >>> Ok, >>> I've been doing some tests by using the PushEndpoint as device token. >>> For registration it works but I just faced an issue by trying to unregister >>> because the URL for the DELETE looks like : >>> >>> >>> https://judconpush-sblanc.rhcloud.com/rest/registry/device/https://updates.push.services.mozilla.com/update/my_personnal_psuhendpoint_id >>> [ >>> >>> And the REST endpoint get a bit crazy by the extra "/" present in the >>> endpoint URL. Therefore, I think we must just use the last URL fragment as >>> deviceToken. >>> >>> >>> Ok answering to myself ;) That won't work neither since if we do that >>> UPS won't have the compllete push endpoint URL. >>> So how do we deal with that ? >>> >>> >>> >>> On Thu, Feb 6, 2014 at 3:27 PM, Matthias Wessendorf >>> wrote: >>> >>> >>> >>> >>> On Thu, Feb 6, 2014 at 3:11 PM, Sebastien Blanc >>> >>> >> >> -- >> Sent from Gmail Mobile >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140724/c1054f74/attachment-0001.html From lholmqui at redhat.com Thu Jul 24 09:17:09 2014 From: lholmqui at redhat.com (Lucas Holmquist) Date: Thu, 24 Jul 2014 09:17:09 -0400 Subject: [aerogear-dev] Differences between Firefox OS "native" Push lib and AeroGear's Push adapter In-Reply-To: References: <9B70BDB9-4774-4BF0-9FF7-5213185E4F52@redhat.com> <51C9D854-0730-4B2A-9A92-9DC92649947D@redhat.com> <8AEB32A5-0F61-495B-8EA5-767F48312B9C@redhat.com> <28EA872A-87E3-4035-9C63-DA04EF034580@redhat.com> <02064329-0F9B-49DC-A5EC-A106001DD51F@redhat.com> Message-ID: On Jul 24, 2014, at 9:14 AM, Matthias Wessendorf wrote: > > > > On Thu, Jul 24, 2014 at 2:41 PM, Lucas Holmquist wrote: > > On Jul 24, 2014, at 6:19 AM, Tadeas Kriz wrote: > >> >> ? >> Tadeas Kriz >> >> On 23 Jul 2014, at 09:56 pm, Lucas Holmquist wrote: >> >>> >>> so there is this issue, , about not being able to delete a simplePush installation. >>> >>> using the UPS js client, i registered the ?deviceToken? with the push server, but when trying to use CURL or even the JS lib, i was getting a 404, and i noticed that it would never actually hit the server( i was in debug mode in IntelliJ ) >>> >>> this was a demo that i had working back in april https://github.com/lholmquist/mobileweek/blob/master/mobileweek-ffos/js/app.js#L17 >>> >>> i noticed that when i registered the deviceToken, i was doing a encodeURIComponent before sending it to the UPS. >>> >>> i modified the UPS JS client to do it this way, and then when i tried to do the remove, i actually hit the breakpoints i set. but the server could not find the installation doing >>> >>> Installation installation = >>> clientInstallationService.findInstallationForVariantByDeviceToken(variant.getVariantID(), token); >>> >>> >>> I changed the JS client to only do 1 encode instead of 2 but it still couldn?t find the installation. >>> >>> I?m not really familiar with JPA and all that, so i don?t know how the query stuff works in this case >>> >>> >>> But i do think we should be encoding the deviceToken( which is the pushEndpointURL ) when registering with the UPS, or else i don?t think we can ever get access to that endpoint >>> >> >> I?d rather not require this. I mean, if there is no other way, then yes, let?s encode, but I can?t see the reason why would that be a problem. Basically, when you put it into the JSON when registering, it?s just a string and string can have any possible character, no matter what. Then the request. When it?s encoded one time, so it can be put into the URL, it should be enough for the server to use it and to search an installation in the database. > > The problem is that you are not able to access the endpoint. > > /shortenedURLForBrevity/http://localhost:7777/simplepush/owejfoiwjfooijf994lkmsf239sflkwekjnkhwf > > basically, that is the endpoint you need to send a DELETE to. which isn?t possible > > > I guess on Android that's never a problem because the endpoint there looks like: > /shortenedURLForBrevity/+MY_GCM_TOKEN right, same for iOS, it?s just SimplePush that has the issue, since the token is a URL > > > Passos, can you confirm ? > > -M > > > > We could also encode on the server side before storing, and the libs/CURL would need to encode for a DELETE? > >> >> Is is possible that there are some Hibernate?s restrictions for the ?deviceToken? field? >> >>> >>> On Jul 14, 2014, at 9:52 AM, Lucas Holmquist wrote: >>> >>>> >>>> On Jul 11, 2014, at 6:33 AM, Matthias Wessendorf wrote: >>>> >>>>> Hey Luke, >>>>> >>>>> I created this JIRA: >>>>> https://issues.jboss.org/browse/AGPUSH-802 >>>>> >>>>> As I plan working on AGPUSH-532 next week, to make sure we have the 'right' model in place for 1.0.0. I think once the server bits are merged, we should address AGPUSH-802 >>>> >>>> kk >>>> >>>>> >>>>> -Matthias >>>>> >>>>> >>>>> On Thu, Apr 10, 2014 at 5:22 PM, Lucas Holmquist wrote: >>>>> so after testing this thing out with encodeURIComponent, the delete does work, however, we need to "double up" the encode. >>>>> >>>>> this works: >>>>> >>>>> https://gist.github.com/lholmquist/10393357 >>>>> >>>>> >>>>> this doesn't: >>>>> >>>>> https://gist.github.com/lholmquist/10393450 >>>>> >>>>> >>>>> >>>>> On Apr 7, 2014, at 2:09 PM, Lucas Holmquist wrote: >>>>> >>>>>> >>>>>> On Apr 7, 2014, at 12:52 PM, Matthias Wessendorf wrote: >>>>>> >>>>>>> Ok, >>>>>>> >>>>>>> So as token, we use the endpointURL, and on client we perform the encodeURIComponent() function ? >>>>>> >>>>>> i think so( as suggested 2 months ago :) ) i just need to see how this will affect how we store stuff in LS. >>>>>> >>>>>> >>>>>> >>>>>>> >>>>>>> -Matthias >>>>>>> >>>>>>> On Monday, April 7, 2014, Lucas Holmquist wrote: >>>>>>> so i went back to look at what i had, >>>>>>> >>>>>>> >>>>>>> i don't think we need to get to complicated here, >>>>>>> >>>>>>> reading the spec stuff, and this example >>>>>>> >>>>>>> https://wiki.mozilla.org/WebAPI/SimplePush#Client_.28WebApp.29_code >>>>>>> >>>>>>> they show sending the pushEndpoint to the "App server", so i think we could just use and keep it simple >>>>>>> >>>>>>> it is also recommended that the channelID is never exposed to the application. >>>>>>> >>>>>>> >>>>>>> On Apr 1, 2014, at 3:34 PM, Lucas Holmquist wrote: >>>>>>> >>>>>>>> i had something, now i forgot what it was, need to go back and check >>>>>>>> On Apr 1, 2014, at 3:05 PM, Matthias Wessendorf wrote: >>>>>>>> >>>>>>>>> >>>>>>>>> On Fri, Feb 14, 2014 at 2:06 PM, Lucas Holmquist wrote: >>>>>>>>> still exploring >>>>>>>>> >>>>>>>>> :-) any recent thoughts on 'encodeURIComponent()' ? >>>>>>>>> >>>>>>>>> >>>>>>>>> On Feb 13, 2014, at 3:39 PM, Sebastien Blanc wrote: >>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Wed, Feb 12, 2014 at 2:30 PM, Lucas Holmquist wrote: >>>>>>>>>> i might have a couple thoughts, but i need to try some things out first >>>>>>>>>> >>>>>>>>>> Any update on that or does the solution proposed by Matzew (using encodeURIComponent() ) could be enough ? >>>>>>>>>> >>>>>>>>>> On Feb 12, 2014, at 3:53 AM, Sebastien Blanc wrote: >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Tue, Feb 11, 2014 at 7:15 PM, Sebastien Blanc wrote: >>>>>>>>>>> Ok, >>>>>>>>>>> I've been doing some tests by using the PushEndpoint as device token. For registration it works but I just faced an issue by trying to unregister because the URL for the DELETE looks like : >>>>>>>>>>> >>>>>>>>>>> https://judconpush-sblanc.rhcloud.com/rest/registry/device/https://updates.push.services.mozilla.com/update/my_personnal_psuhendpoint_id [ >>>>>>>>>>> >>>>>>>>>>> And the REST endpoint get a bit crazy by the extra "/" present in the endpoint URL. Therefore, I think we must just use the last URL fragment as deviceToken. >>>>>>>>>>> >>>>>>>>>>> Ok answering to myself ;) That won't work neither since if we do that UPS won't have the compllete push endpoint URL. >>>>>>>>>>> So how do we deal with that ? >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Thu, Feb 6, 2014 at 3:27 PM, Matthias Wessendorf wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Thu, Feb 6, 2014 at 3:11 PM, Sebastien Blanc >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Sent from Gmail Mobile >>>>>>> _______________________________________________ >>>>>>> aerogear-dev mailing list >>>>>>> aerogear-dev at lists.jboss.org >>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>> >>>>>> _______________________________________________ >>>>>> aerogear-dev mailing list >>>>>> aerogear-dev at lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>> >>>>> >>>>> _______________________________________________ >>>>> aerogear-dev mailing list >>>>> aerogear-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>> >>>>> >>>>> >>>>> -- >>>>> Matthias Wessendorf >>>>> >>>>> blog: http://matthiaswessendorf.wordpress.com/ >>>>> sessions: http://www.slideshare.net/mwessendorf >>>>> twitter: http://twitter.com/mwessendorf >>>>> _______________________________________________ >>>>> aerogear-dev mailing list >>>>> aerogear-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140724/02388e49/attachment-0001.html From tkriz at redhat.com Thu Jul 24 09:19:48 2014 From: tkriz at redhat.com (Tadeas Kriz) Date: Thu, 24 Jul 2014 15:19:48 +0200 Subject: [aerogear-dev] Differences between Firefox OS "native" Push lib and AeroGear's Push adapter In-Reply-To: References: <9B70BDB9-4774-4BF0-9FF7-5213185E4F52@redhat.com> <51C9D854-0730-4B2A-9A92-9DC92649947D@redhat.com> <8AEB32A5-0F61-495B-8EA5-767F48312B9C@redhat.com> <3B256910-96B3-4F55-8456-D890F4B37B2B! ! ! ! ! @redhat.com> <28EA872A-87E3-4035-9C63-DA04EF034580@redhat.com> <02064329-0F9B-49DC-A5EC-A106001DD51F@redhat.com> Message-ID: ? Tadeas Kriz On 24 Jul 2014, at 02:41 pm, Lucas Holmquist wrote: > > On Jul 24, 2014, at 6:19 AM, Tadeas Kriz wrote: > >> >> ? >> Tadeas Kriz >> >> On 23 Jul 2014, at 09:56 pm, Lucas Holmquist wrote: >> >>> >>> so there is this issue, , about not being able to delete a simplePush installation. >>> >>> using the UPS js client, i registered the ?deviceToken? with the push server, but when trying to use CURL or even the JS lib, i was getting a 404, and i noticed that it would never actually hit the server( i was in debug mode in IntelliJ ) >>> >>> this was a demo that i had working back in april https://github.com/lholmquist/mobileweek/blob/master/mobileweek-ffos/js/app.js#L17 >>> >>> i noticed that when i registered the deviceToken, i was doing a encodeURIComponent before sending it to the UPS. >>> >>> i modified the UPS JS client to do it this way, and then when i tried to do the remove, i actually hit the breakpoints i set. but the server could not find the installation doing >>> >>> Installation installation = >>> clientInstallationService.findInstallationForVariantByDeviceToken(variant.getVariantID(), token); >>> >>> >>> I changed the JS client to only do 1 encode instead of 2 but it still couldn?t find the installation. >>> >>> I?m not really familiar with JPA and all that, so i don?t know how the query stuff works in this case >>> >>> >>> But i do think we should be encoding the deviceToken( which is the pushEndpointURL ) when registering with the UPS, or else i don?t think we can ever get access to that endpoint >>> >> >> I?d rather not require this. I mean, if there is no other way, then yes, let?s encode, but I can?t see the reason why would that be a problem. Basically, when you put it into the JSON when registering, it?s just a string and string can have any possible character, no matter what. Then the request. When it?s encoded one time, so it can be put into the URL, it should be enough for the server to use it and to search an installation in the database. > > The problem is that you are not able to access the endpoint. > > /shortenedURLForBrevity/http://localhost:7777/simplepush/owejfoiwjfooijf994lkmsf239sflkwekjnkhwf > That?s not what I mean. I was saying that we can encode it once (in RestAssured, this even happens automatically) so it will become: /shortenedURLForBrevity/http%3A%2F%2Flocalhost%3A7777%2Fsimplepush%2Fowejfoiwjfooijf994lkmsf239sflkwekjnkhwf which should work just fine. In the endpoint, it should then be decoded back into "http://localhost:7777/simplepush/owejfoiwjfooijf994lkmsf239sflkwekjnkhwf? (which may even happen automatically with RestEasy). This is what?s URLencode is for, to be able to use the string in a url as a path parameter, so we should be able to get this working properly. > basically, that is the endpoint you need to send a DELETE to. which isn?t possible > > We could also encode on the server side before storing, and the libs/CURL would need to encode for a DELETE? > >> >> Is is possible that there are some Hibernate?s restrictions for the ?deviceToken? field? >> >>> >>> On Jul 14, 2014, at 9:52 AM, Lucas Holmquist wrote: >>> >>>> >>>> On Jul 11, 2014, at 6:33 AM, Matthias Wessendorf wrote: >>>> >>>>> Hey Luke, >>>>> >>>>> I created this JIRA: >>>>> https://issues.jboss.org/browse/AGPUSH-802 >>>>> >>>>> As I plan working on AGPUSH-532 next week, to make sure we have the 'right' model in place for 1.0.0. I think once the server bits are merged, we should address AGPUSH-802 >>>> >>>> kk >>>> >>>>> >>>>> -Matthias >>>>> >>>>> >>>>> On Thu, Apr 10, 2014 at 5:22 PM, Lucas Holmquist wrote: >>>>> so after testing this thing out with encodeURIComponent, the delete does work, however, we need to "double up" the encode. >>>>> >>>>> this works: >>>>> >>>>> https://gist.github.com/lholmquist/10393357 >>>>> >>>>> >>>>> this doesn't: >>>>> >>>>> https://gist.github.com/lholmquist/10393450 >>>>> >>>>> >>>>> >>>>> On Apr 7, 2014, at 2:09 PM, Lucas Holmquist wrote: >>>>> >>>>>> >>>>>> On Apr 7, 2014, at 12:52 PM, Matthias Wessendorf wrote: >>>>>> >>>>>>> Ok, >>>>>>> >>>>>>> So as token, we use the endpointURL, and on client we perform the encodeURIComponent() function ? >>>>>> >>>>>> i think so( as suggested 2 months ago :) ) i just need to see how this will affect how we store stuff in LS. >>>>>> >>>>>> >>>>>> >>>>>>> >>>>>>> -Matthias >>>>>>> >>>>>>> On Monday, April 7, 2014, Lucas Holmquist wrote: >>>>>>> so i went back to look at what i had, >>>>>>> >>>>>>> >>>>>>> i don't think we need to get to complicated here, >>>>>>> >>>>>>> reading the spec stuff, and this example >>>>>>> >>>>>>> https://wiki.mozilla.org/WebAPI/SimplePush#Client_.28WebApp.29_code >>>>>>> >>>>>>> they show sending the pushEndpoint to the "App server", so i think we could just use and keep it simple >>>>>>> >>>>>>> it is also recommended that the channelID is never exposed to the application. >>>>>>> >>>>>>> >>>>>>> On Apr 1, 2014, at 3:34 PM, Lucas Holmquist wrote: >>>>>>> >>>>>>>> i had something, now i forgot what it was, need to go back and check >>>>>>>> On Apr 1, 2014, at 3:05 PM, Matthias Wessendorf wrote: >>>>>>>> >>>>>>>>> >>>>>>>>> On Fri, Feb 14, 2014 at 2:06 PM, Lucas Holmquist wrote: >>>>>>>>> still exploring >>>>>>>>> >>>>>>>>> :-) any recent thoughts on 'encodeURIComponent()' ? >>>>>>>>> >>>>>>>>> >>>>>>>>> On Feb 13, 2014, at 3:39 PM, Sebastien Blanc wrote: >>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Wed, Feb 12, 2014 at 2:30 PM, Lucas Holmquist wrote: >>>>>>>>>> i might have a couple thoughts, but i need to try some things out first >>>>>>>>>> >>>>>>>>>> Any update on that or does the solution proposed by Matzew (using encodeURIComponent() ) could be enough ? >>>>>>>>>> >>>>>>>>>> On Feb 12, 2014, at 3:53 AM, Sebastien Blanc wrote: >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Tue, Feb 11, 2014 at 7:15 PM, Sebastien Blanc wrote: >>>>>>>>>>> Ok, >>>>>>>>>>> I've been doing some tests by using the PushEndpoint as device token. For registration it works but I just faced an issue by trying to unregister because the URL for the DELETE looks like : >>>>>>>>>>> >>>>>>>>>>> https://judconpush-sblanc.rhcloud.com/rest/registry/device/https://updates.push.services.mozilla.com/update/my_personnal_psuhendpoint_id [ >>>>>>>>>>> >>>>>>>>>>> And the REST endpoint get a bit crazy by the extra "/" present in the endpoint URL. Therefore, I think we must just use the last URL fragment as deviceToken. >>>>>>>>>>> >>>>>>>>>>> Ok answering to myself ;) That won't work neither since if we do that UPS won't have the compllete push endpoint URL. >>>>>>>>>>> So how do we deal with that ? >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Thu, Feb 6, 2014 at 3:27 PM, Matthias Wessendorf wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Thu, Feb 6, 2014 at 3:11 PM, Sebastien Blanc >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Sent from Gmail Mobile >>>>>>> _______________________________________________ >>>>>>> aerogear-dev mailing list >>>>>>> aerogear-dev at lists.jboss.org >>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>> >>>>>> _______________________________________________ >>>>>> aerogear-dev mailing list >>>>>> aerogear-dev at lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>> >>>>> >>>>> _______________________________________________ >>>>> aerogear-dev mailing list >>>>> aerogear-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>> >>>>> >>>>> >>>>> -- >>>>> Matthias Wessendorf >>>>> >>>>> blog: http://matthiaswessendorf.wordpress.com/ >>>>> sessions: http://www.slideshare.net/mwessendorf >>>>> twitter: http://twitter.com/mwessendorf >>>>> _______________________________________________ >>>>> aerogear-dev mailing list >>>>> aerogear-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140724/76fd88c6/attachment-0001.html From matzew at apache.org Thu Jul 24 09:20:31 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Thu, 24 Jul 2014 15:20:31 +0200 Subject: [aerogear-dev] Differences between Firefox OS "native" Push lib and AeroGear's Push adapter In-Reply-To: References: <9B70BDB9-4774-4BF0-9FF7-5213185E4F52@redhat.com> <51C9D854-0730-4B2A-9A92-9DC92649947D@redhat.com> <8AEB32A5-0F61-495B-8EA5-767F48312B9C@redhat.com> <28EA872A-87E3-4035-9C63-DA04EF034580@redhat.com> <02064329-0F9B-49DC-A5EC-A106001DD51F@redhat.com> Message-ID: On Thu, Jul 24, 2014 at 3:17 PM, Lucas Holmquist wrote: > > On Jul 24, 2014, at 9:14 AM, Matthias Wessendorf > wrote: > > > > > On Thu, Jul 24, 2014 at 2:41 PM, Lucas Holmquist > wrote: > >> >> On Jul 24, 2014, at 6:19 AM, Tadeas Kriz wrote: >> >> >> ? >> Tadeas Kriz >> >> On 23 Jul 2014, at 09:56 pm, Lucas Holmquist >> wrote: >> >> >> so there is this issue, , about not being able to delete a simplePush >> installation. >> >> using the UPS js client, i registered the ?deviceToken? with the push >> server, but when trying to use CURL or even the JS lib, i was getting a >> 404, and i noticed that it would never actually hit the server( i was in >> debug mode in IntelliJ ) >> >> this was a demo that i had working back in april >> https://github.com/lholmquist/mobileweek/blob/master/mobileweek-ffos/js/app.js#L17 >> >> i noticed that when i registered the deviceToken, i was doing a >> encodeURIComponent before sending it to the UPS. >> >> i modified the UPS JS client to do it this way, and then when i tried to >> do the remove, i actually hit the breakpoints i set. but the server could >> not find the installation doing >> >> Installation installation = >> >> clientInstallationService.findInstallationForVariantByDeviceToken(variant.getVariantID(), >> token); >> >> >> I changed the JS client to only do 1 encode instead of 2 but it still >> couldn?t find the installation. >> >> I?m not really familiar with JPA and all that, so i don?t know how the >> query stuff works in this case >> >> >> But i do think we should be encoding the deviceToken( which is the >> pushEndpointURL ) when registering with the UPS, or else i don?t think we >> can ever get access to that endpoint >> >> >> I?d rather not require this. I mean, if there is no other way, then yes, >> let?s encode, but I can?t see the reason why would that be a problem. >> Basically, when you put it into the JSON when registering, it?s just a >> string and string can have any possible character, no matter what. Then the >> request. When it?s encoded one time, so it can be put into the URL, it >> should be enough for the server to use it and to search an installation in >> the database. >> >> >> The problem is that you are not able to access the endpoint. >> >> /shortenedURLForBrevity/ >> http://localhost:7777/simplepush/owejfoiwjfooijf994lkmsf239sflkwekjnkhwf >> >> basically, that is the endpoint you need to send a DELETE to. which >> isn?t possible >> > > > I guess on Android that's never a problem because the endpoint there looks > like: > /shortenedURLForBrevity/+MY_GCM_TOKEN > > > right, same for iOS, it?s just SimplePush that has the issue, since the > token is a URL > I also wonder if our Hibernate layer has issues w/ and URL as the token :) Hadn't had the time to check that yet -M > > > > Passos, can you confirm ? > > -M > > > >> >> We could also encode on the server side before storing, and the >> libs/CURL would need to encode for a DELETE? >> >> >> Is is possible that there are some Hibernate?s restrictions for the >> ?deviceToken? field? >> >> >> On Jul 14, 2014, at 9:52 AM, Lucas Holmquist wrote: >> >> >> On Jul 11, 2014, at 6:33 AM, Matthias Wessendorf >> wrote: >> >> Hey Luke, >> >> I created this JIRA: >> https://issues.jboss.org/browse/AGPUSH-802 >> >> As I plan working on AGPUSH-532 next week, to make sure we have the >> 'right' model in place for 1.0.0. I think once the server bits are merged, >> we should address AGPUSH-802 >> >> >> kk >> >> >> -Matthias >> >> >> On Thu, Apr 10, 2014 at 5:22 PM, Lucas Holmquist >> wrote: >> >>> so after testing this thing out with encodeURIComponent, the delete >>> does work, however, we need to "double up" the encode. >>> >>> this works: >>> >>> https://gist.github.com/lholmquist/10393357 >>> >>> >>> this doesn't: >>> >>> https://gist.github.com/lholmquist/10393450 >>> >>> >>> >>> On Apr 7, 2014, at 2:09 PM, Lucas Holmquist wrote: >>> >>> >>> On Apr 7, 2014, at 12:52 PM, Matthias Wessendorf >>> wrote: >>> >>> Ok, >>> >>> So as token, we use the endpointURL, and on client we perform the >>> encodeURIComponent() function ? >>> >>> >>> i think so( as suggested 2 months ago :) ) i just need to see how >>> this will affect how we store stuff in LS. >>> >>> >>> >>> >>> -Matthias >>> >>> On Monday, April 7, 2014, Lucas Holmquist wrote: >>> >>>> so i went back to look at what i had, >>>> >>>> >>>> i don't think we need to get to complicated here, >>>> >>>> reading the spec stuff, and this example >>>> >>>> https://wiki.mozilla.org/WebAPI/SimplePush#Client_.28WebApp.29_code >>>> >>>> they show sending the pushEndpoint to the "App server", so i think we >>>> could just use and keep it simple >>>> >>>> it is also recommended that the channelID is never exposed to the >>>> application. >>>> >>>> >>>> On Apr 1, 2014, at 3:34 PM, Lucas Holmquist >>>> wrote: >>>> >>>> i had something, now i forgot what it was, need to go back and check >>>> On Apr 1, 2014, at 3:05 PM, Matthias Wessendorf >>>> wrote: >>>> >>>> >>>> On Fri, Feb 14, 2014 at 2:06 PM, Lucas Holmquist >>>> wrote: >>>> >>>> still exploring >>>> >>>> >>>> :-) any recent thoughts on 'encodeURIComponent()' ? >>>> >>>> >>>> >>>> On Feb 13, 2014, at 3:39 PM, Sebastien Blanc >>>> wrote: >>>> >>>> >>>> >>>> >>>> On Wed, Feb 12, 2014 at 2:30 PM, Lucas Holmquist >>>> wrote: >>>> >>>> i might have a couple thoughts, but i need to try some things out first >>>> >>>> >>>> Any update on that or does the solution proposed by Matzew (using encodeURIComponent() >>>> ) could be enough ? >>>> >>>> >>>> On Feb 12, 2014, at 3:53 AM, Sebastien Blanc >>>> wrote: >>>> >>>> >>>> >>>> >>>> On Tue, Feb 11, 2014 at 7:15 PM, Sebastien Blanc >>>> wrote: >>>> >>>> Ok, >>>> I've been doing some tests by using the PushEndpoint as device token. >>>> For registration it works but I just faced an issue by trying to unregister >>>> because the URL for the DELETE looks like : >>>> >>>> >>>> https://judconpush-sblanc.rhcloud.com/rest/registry/device/https://updates.push.services.mozilla.com/update/my_personnal_psuhendpoint_id >>>> [ >>>> >>>> And the REST endpoint get a bit crazy by the extra "/" present in the >>>> endpoint URL. Therefore, I think we must just use the last URL fragment as >>>> deviceToken. >>>> >>>> >>>> Ok answering to myself ;) That won't work neither since if we do that >>>> UPS won't have the compllete push endpoint URL. >>>> So how do we deal with that ? >>>> >>>> >>>> >>>> On Thu, Feb 6, 2014 at 3:27 PM, Matthias Wessendorf >>>> wrote: >>>> >>>> >>>> >>>> >>>> On Thu, Feb 6, 2014 at 3:11 PM, Sebastien Blanc >>>> >>>> >>> >>> -- >>> Sent from Gmail Mobile >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >>> >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >> >> >> >> -- >> Matthias Wessendorf >> >> blog: http://matthiaswessendorf.wordpress.com/ >> sessions: http://www.slideshare.net/mwessendorf >> twitter: http://twitter.com/mwessendorf >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140724/01470a45/attachment-0001.html From matzew at apache.org Thu Jul 24 09:25:50 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Thu, 24 Jul 2014 15:25:50 +0200 Subject: [aerogear-dev] Docs: update on the UPS docs In-Reply-To: References: Message-ID: Thanks Dan! FYI - the draft of the TOC (and soon content) lives in this branch: https://github.com/aerogear/aerogear.org/blob/NewUPS_Guide/docs/unifiedpush/ups_userguide/index.markdown -M On Thu, Jul 24, 2014 at 2:14 PM, Daniel Bevenius wrote: > Looks good! > perhaps change: Configuring and Managing Applications that use the > UnifiedPush Server -> Configuring and managing applications that use the > UnifiedPush Server > > > > On 24 July 2014 13:32, Matthias Wessendorf wrote: > >> update: >> >> >> UnifiedPush Server User Guide >> >> - Overview >> - About the UnifiedPush Server >> - Use-cases and scenarios >> - Useful Terminology >> - How the UnifiedPush Server Works >> - Installation and configuration >> - The WAR file distribution >> - setup and configure a database >> - deploy the WAR files >> - Running on OpenShift >> - create an instance using OpenShift's Web UI >> - create an instance using OpenShift's command line interface >> - Using the Admin UI >> - Administering the UnifiedPush Server Console >> - Configuring and Managing Applications that use the UnifiedPush >> Server >> - Preparing mobile devices to be connected with the UnifiedPush >> Server >> - Sending Push Notifications >> - Preparing backends to send Push Notifications >> - Next steps >> - TBD: Links to tutorials and specs (some specs might go away) >> >> >> >> >> >> >> >> On Thu, Jul 24, 2014 at 1:29 PM, Matthias Wessendorf >> wrote: >> >>> Here is the TOC that I have in mind (and started to work on): >>> >>> UnifiedPush Server User Guide >>> >>> - Overview >>> - About the UnifiedPush Server >>> - Use-cases and scenarios >>> - Useful Terminology >>> - How the UnifiedPush Server Works >>> - Installation and configuration >>> - The WAR file distribution >>> - setup and configure a database >>> - deploy the WAR files >>> - Running on OpenShift >>> - create an instance using OpenShift's Web UI >>> - create an instance using OpenShift's command line interface >>> - Using the Admin UI >>> - Administering the UnifiedPush Server Console >>> - Configuring and Managing Applications that use the UnifiedPush >>> Server >>> - Preparing mobile devices to be connected with the UnifiedPush >>> Server >>> - Sending Push Notifications >>> - Next steps >>> - TBD: Links to tutorials and specs (some specs might go away) >>> >>> >>> >>> >>> >>> On Thu, Jul 24, 2014 at 11:26 AM, Matthias Wessendorf >> > wrote: >>> >>>> Before actually starting with the (initial) rewrite of the UPS guide >>>> (as I outlined), I did the re-org of the UPS content. >>>> >>>> Please review: >>>> https://github.com/aerogear/aerogear.org/pull/327 >>>> >>>> >>>> >>>> >>>> On Mon, Jul 21, 2014 at 5:59 PM, Matthias Wessendorf >>> > wrote: >>>> >>>>> Hi, >>>>> >>>>> right now we have a lot of different 'documentation files', like the >>>>> README, some specs, and guides and tutorials. >>>>> >>>>> I'd like to restructure that a bit and centralize the documentation a >>>>> bit. >>>>> >>>>> On the "push" landing page ([1]), I'd like to change the "Lean More" >>>>> link to a new page that has all the UPS centric documentations >>>>> >>>>> - AeroGear UnifiedPush Server User/Reference Guide >>>>> - Tutorials >>>>> >>>>> >>>>> AeroGear >>>>> UnifiedPush Server User/Reference Guide >>>>> >>>>> - Overview >>>>> - some generic information >>>>> - Installation and configuration >>>>> - what's needed (e.g. JBoss and a database) >>>>> - Running on OpenShift >>>>> - using the UI on OpenShift >>>>> - using the rhc command line >>>>> - Using the Admin UI >>>>> - doing an overhaul of our existing Admin UI guide (e.g. taking >>>>> new screenshots and updating based on new UI features) >>>>> >>>>> The format of the *reference guide* would be similar to the one from >>>>> Keycloak ([2]). But... I will continue using asciidoc ;-) >>>>> >>>>> The README will be extremely quick and simply link to the homepage ;-) >>>>> After this *new* reference guide, I think some of the current specs >>>>> can be removed, as the *reference guide* hopefully covers all of >>>>> their content :-) >>>>> >>>>> For the RESTful APIs, I have to look what Keycloak did to get >>>>> something like: >>>>> http://docs.jboss.org/keycloak/docs/1.0-beta-3/rest-api/overview-index.html >>>>> >>>>> After the work as been completed, I will be revisiting the specs and >>>>> evaluate their need ;-) >>>>> >>>>> Tutorials >>>>> >>>>> This section will contain links to all the different tutorials we have: >>>>> >>>>> - http://aerogear.org/docs/guides/aerogear-push-ios/ >>>>> - http://aerogear.org/docs/guides/aerogear-push-js/ >>>>> - http://aerogear.org/docs/guides/aerogear-push-android/ >>>>> - http://aerogear.org/docs/guides/aerogear-push-chrome/ >>>>> - http://aerogear.org/docs/guides/GetStartedwithJavaSender/ >>>>> >>>>> For Cordova we will have one single document, instead of three: >>>>> >>>>> - http://aerogear.org/docs/guides/aerogear-push-cordova-android/ >>>>> - http://aerogear.org/docs/guides/aerogear-push-cordova-ios/ >>>>> - >>>>> http://aerogear.org/docs/guides/aerogear-cordova/AerogearCordovaPush/ >>>>> >>>>> There is already a JIRA for that ([4]). >>>>> >>>>> To make it more clear (or clean?), I will remove the UPS/Push related >>>>> docs from our guides ([3]) and replace all those links by a single link to >>>>> the above mentioned new page (also referenced from [1]). >>>>> >>>>> Greetings, >>>>> Matthias >>>>> >>>>> >>>>> >>>>> - [1] http://aerogear.org/push/ >>>>> - [2] >>>>> http://docs.jboss.org/keycloak/docs/1.0-beta-3/userguide/html/index.html >>>>> - [3] http://aerogear.org/docs/guides/ >>>>> - [4] https://issues.jboss.org/browse/AGPUSH-805 >>>>> >>>>> >>>>> -- >>>>> Matthias Wessendorf >>>>> >>>>> blog: http://matthiaswessendorf.wordpress.com/ >>>>> sessions: http://www.slideshare.net/mwessendorf >>>>> twitter: http://twitter.com/mwessendorf >>>>> >>>> >>>> >>>> >>>> -- >>>> Matthias Wessendorf >>>> >>>> blog: http://matthiaswessendorf.wordpress.com/ >>>> sessions: http://www.slideshare.net/mwessendorf >>>> twitter: http://twitter.com/mwessendorf >>>> >>> >>> >>> >>> -- >>> Matthias Wessendorf >>> >>> blog: http://matthiaswessendorf.wordpress.com/ >>> sessions: http://www.slideshare.net/mwessendorf >>> twitter: http://twitter.com/mwessendorf >>> >> >> >> >> -- >> Matthias Wessendorf >> >> blog: http://matthiaswessendorf.wordpress.com/ >> sessions: http://www.slideshare.net/mwessendorf >> twitter: http://twitter.com/mwessendorf >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140724/e2819a5f/attachment.html From tkriz at redhat.com Thu Jul 24 09:28:08 2014 From: tkriz at redhat.com (Tadeas Kriz) Date: Thu, 24 Jul 2014 15:28:08 +0200 Subject: [aerogear-dev] Differences between Firefox OS "native" Push lib and AeroGear's Push adapter In-Reply-To: References: <9B70BDB9-4774-4BF0-9FF7-5213185E4F52@redhat.com> <51C9D854-0730-4B2A-9A92-9DC92649947D@redhat.com> <8AEB32A5-0F61-495B-8EA5-767F48312B9C@redhat.com> <28EA872A-87E3-4035-9C63-DA04EF034580! @redhat.com> <02064329-0F9B-49DC-A5EC-A106001DD51F@redhat.com> Message-ID: ? Tadeas Kriz On 24 Jul 2014, at 03:20 pm, Matthias Wessendorf wrote: > > > > On Thu, Jul 24, 2014 at 3:17 PM, Lucas Holmquist wrote: > > On Jul 24, 2014, at 9:14 AM, Matthias Wessendorf wrote: > >> >> >> >> On Thu, Jul 24, 2014 at 2:41 PM, Lucas Holmquist wrote: >> >> On Jul 24, 2014, at 6:19 AM, Tadeas Kriz wrote: >> >>> >>> ? >>> Tadeas Kriz >>> >>> On 23 Jul 2014, at 09:56 pm, Lucas Holmquist wrote: >>> >>>> >>>> so there is this issue, , about not being able to delete a simplePush installation. >>>> >>>> using the UPS js client, i registered the ?deviceToken? with the push server, but when trying to use CURL or even the JS lib, i was getting a 404, and i noticed that it would never actually hit the server( i was in debug mode in IntelliJ ) >>>> >>>> this was a demo that i had working back in april https://github.com/lholmquist/mobileweek/blob/master/mobileweek-ffos/js/app.js#L17 >>>> >>>> i noticed that when i registered the deviceToken, i was doing a encodeURIComponent before sending it to the UPS. >>>> >>>> i modified the UPS JS client to do it this way, and then when i tried to do the remove, i actually hit the breakpoints i set. but the server could not find the installation doing >>>> >>>> Installation installation = >>>> clientInstallationService.findInstallationForVariantByDeviceToken(variant.getVariantID(), token); >>>> >>>> >>>> I changed the JS client to only do 1 encode instead of 2 but it still couldn?t find the installation. >>>> >>>> I?m not really familiar with JPA and all that, so i don?t know how the query stuff works in this case >>>> >>>> >>>> But i do think we should be encoding the deviceToken( which is the pushEndpointURL ) when registering with the UPS, or else i don?t think we can ever get access to that endpoint >>>> >>> >>> I?d rather not require this. I mean, if there is no other way, then yes, let?s encode, but I can?t see the reason why would that be a problem. Basically, when you put it into the JSON when registering, it?s just a string and string can have any possible character, no matter what. Then the request. When it?s encoded one time, so it can be put into the URL, it should be enough for the server to use it and to search an installation in the database. >> >> The problem is that you are not able to access the endpoint. >> >> /shortenedURLForBrevity/http://localhost:7777/simplepush/owejfoiwjfooijf994lkmsf239sflkwekjnkhwf >> >> basically, that is the endpoint you need to send a DELETE to. which isn?t possible >> >> >> I guess on Android that's never a problem because the endpoint there looks like: >> /shortenedURLForBrevity/+MY_GCM_TOKEN > > right, same for iOS, it?s just SimplePush that has the issue, since the token is a URL > > I also wonder if our Hibernate layer has issues w/ and URL as the token :) Hadn't had the time to check that yet > > -M > It should not. For hibernate, it?s just a string like any other. The problem might be in the configuration of JAX.RS/RestEasy. If I?ll have some time today evening, I?ll try to fix it, it should be an easy fix. > >> >> >> Passos, can you confirm ? >> >> -M >> >> >> >> We could also encode on the server side before storing, and the libs/CURL would need to encode for a DELETE? >> >>> >>> Is is possible that there are some Hibernate?s restrictions for the ?deviceToken? field? >>> >>>> >>>> On Jul 14, 2014, at 9:52 AM, Lucas Holmquist wrote: >>>> >>>>> >>>>> On Jul 11, 2014, at 6:33 AM, Matthias Wessendorf wrote: >>>>> >>>>>> Hey Luke, >>>>>> >>>>>> I created this JIRA: >>>>>> https://issues.jboss.org/browse/AGPUSH-802 >>>>>> >>>>>> As I plan working on AGPUSH-532 next week, to make sure we have the 'right' model in place for 1.0.0. I think once the server bits are merged, we should address AGPUSH-802 >>>>> >>>>> kk >>>>> >>>>>> >>>>>> -Matthias >>>>>> >>>>>> >>>>>> On Thu, Apr 10, 2014 at 5:22 PM, Lucas Holmquist wrote: >>>>>> so after testing this thing out with encodeURIComponent, the delete does work, however, we need to "double up" the encode. >>>>>> >>>>>> this works: >>>>>> >>>>>> https://gist.github.com/lholmquist/10393357 >>>>>> >>>>>> >>>>>> this doesn't: >>>>>> >>>>>> https://gist.github.com/lholmquist/10393450 >>>>>> >>>>>> >>>>>> >>>>>> On Apr 7, 2014, at 2:09 PM, Lucas Holmquist wrote: >>>>>> >>>>>>> >>>>>>> On Apr 7, 2014, at 12:52 PM, Matthias Wessendorf wrote: >>>>>>> >>>>>>>> Ok, >>>>>>>> >>>>>>>> So as token, we use the endpointURL, and on client we perform the encodeURIComponent() function ? >>>>>>> >>>>>>> i think so( as suggested 2 months ago :) ) i just need to see how this will affect how we store stuff in LS. >>>>>>> >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> -Matthias >>>>>>>> >>>>>>>> On Monday, April 7, 2014, Lucas Holmquist wrote: >>>>>>>> so i went back to look at what i had, >>>>>>>> >>>>>>>> >>>>>>>> i don't think we need to get to complicated here, >>>>>>>> >>>>>>>> reading the spec stuff, and this example >>>>>>>> >>>>>>>> https://wiki.mozilla.org/WebAPI/SimplePush#Client_.28WebApp.29_code >>>>>>>> >>>>>>>> they show sending the pushEndpoint to the "App server", so i think we could just use and keep it simple >>>>>>>> >>>>>>>> it is also recommended that the channelID is never exposed to the application. >>>>>>>> >>>>>>>> >>>>>>>> On Apr 1, 2014, at 3:34 PM, Lucas Holmquist wrote: >>>>>>>> >>>>>>>>> i had something, now i forgot what it was, need to go back and check >>>>>>>>> On Apr 1, 2014, at 3:05 PM, Matthias Wessendorf wrote: >>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Fri, Feb 14, 2014 at 2:06 PM, Lucas Holmquist wrote: >>>>>>>>>> still exploring >>>>>>>>>> >>>>>>>>>> :-) any recent thoughts on 'encodeURIComponent()' ? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Feb 13, 2014, at 3:39 PM, Sebastien Blanc wrote: >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Wed, Feb 12, 2014 at 2:30 PM, Lucas Holmquist wrote: >>>>>>>>>>> i might have a couple thoughts, but i need to try some things out first >>>>>>>>>>> >>>>>>>>>>> Any update on that or does the solution proposed by Matzew (using encodeURIComponent() ) could be enough ? >>>>>>>>>>> >>>>>>>>>>> On Feb 12, 2014, at 3:53 AM, Sebastien Blanc wrote: >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Tue, Feb 11, 2014 at 7:15 PM, Sebastien Blanc wrote: >>>>>>>>>>>> Ok, >>>>>>>>>>>> I've been doing some tests by using the PushEndpoint as device token. For registration it works but I just faced an issue by trying to unregister because the URL for the DELETE looks like : >>>>>>>>>>>> >>>>>>>>>>>> https://judconpush-sblanc.rhcloud.com/rest/registry/device/https://updates.push.services.mozilla.com/update/my_personnal_psuhendpoint_id [ >>>>>>>>>>>> >>>>>>>>>>>> And the REST endpoint get a bit crazy by the extra "/" present in the endpoint URL. Therefore, I think we must just use the last URL fragment as deviceToken. >>>>>>>>>>>> >>>>>>>>>>>> Ok answering to myself ;) That won't work neither since if we do that UPS won't have the compllete push endpoint URL. >>>>>>>>>>>> So how do we deal with that ? >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Thu, Feb 6, 2014 at 3:27 PM, Matthias Wessendorf wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Thu, Feb 6, 2014 at 3:11 PM, Sebastien Blanc >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Sent from Gmail Mobile >>>>>>>> _______________________________________________ >>>>>>>> aerogear-dev mailing list >>>>>>>> aerogear-dev at lists.jboss.org >>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>> >>>>>>> _______________________________________________ >>>>>>> aerogear-dev mailing list >>>>>>> aerogear-dev at lists.jboss.org >>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> aerogear-dev mailing list >>>>>> aerogear-dev at lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Matthias Wessendorf >>>>>> >>>>>> blog: http://matthiaswessendorf.wordpress.com/ >>>>>> sessions: http://www.slideshare.net/mwessendorf >>>>>> twitter: http://twitter.com/mwessendorf >>>>>> _______________________________________________ >>>>>> aerogear-dev mailing list >>>>>> aerogear-dev at lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>> >>>>> _______________________________________________ >>>>> aerogear-dev mailing list >>>>> aerogear-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> >> -- >> Matthias Wessendorf >> >> blog: http://matthiaswessendorf.wordpress.com/ >> sessions: http://www.slideshare.net/mwessendorf >> twitter: http://twitter.com/mwessendorf >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140724/69fdd348/attachment-0001.html From scm.blanc at gmail.com Thu Jul 24 11:22:07 2014 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Thu, 24 Jul 2014 17:22:07 +0200 Subject: [aerogear-dev] [Vote] Release of UPS 1.0.0.Beta1 In-Reply-To: References: Message-ID: +1 I've deployed the WARs on OpenShift, then tested with the HelloWorld and the Contact App. Everything work as expected ! On Wed, Jul 23, 2014 at 9:01 AM, Matthias Wessendorf wrote: > Good morning folks! > > we are getting closer and closer to our 1.0.0 release! Thank you very > much, guys! > > However, before we are moving towards the 1.0.0.Final community release, > I'd love to get the current work out as 1.0.0.Beta1 > > Note this release contains a ton of work and new features. To name a few > highlights: > > * increased APNs payload (2k) > * iOS8 interactive notification support > * Pagination for analytics > * improved callback for details on actual push delivery > * optimisations and improvements > > Besides these changes, a ton of more work was done by the team: > https://issues.jboss.org/browse/AGPUSH/fixforversion/12323753 > > The staging repository is located here: > > https://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-3598 > > > NOTE: Once this release has been approved the matching tag will be used to > get the OpenShift online bits updated! > > Let me know the results of your testing! > If I hear nothing bad by Friday evening, the release to maven central will > happen on Monday; > > Greetings, > Matthias > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140724/9999469e/attachment.html From scm.blanc at gmail.com Thu Jul 24 11:24:13 2014 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Thu, 24 Jul 2014 17:24:13 +0200 Subject: [aerogear-dev] UPS: Java Sender release In-Reply-To: References: <46E8BE1A-B34A-4729-903B-DD27D70974D1@redhat.com> Message-ID: Tested with the Contact Quickstart + AeroDoc , work as expected ! +1 On Tue, Jul 22, 2014 at 10:31 AM, Matthias Wessendorf wrote: > awesome! > > > On Tue, Jul 22, 2014 at 10:13 AM, Tadeas Kriz wrote: > >> Hey, >> >> it will get tested in the same run as UnifiedPush server using our >> integration tests suite. >> >> ? >> Tadeas Kriz >> >> On 22 Jul 2014, at 10:00 am, Matthias Wessendorf >> wrote: >> >> Hi, >> >> I'd like to release the 0.8.0 version of the java-sender. The staging >> repo is here: >> >> http://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-3597/ >> >> >> Changes since last release: >> * AGPUSH-800 (need to be tested against master of UPS server) >> * AGPUSH-783 >> >> Please test and let me know! >> >> Thanks! >> >> -- >> Matthias Wessendorf >> >> blog: http://matthiaswessendorf.wordpress.com/ >> sessions: http://www.slideshare.net/mwessendorf >> twitter: http://twitter.com/mwessendorf >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140724/c2a25290/attachment.html From corinnekrych at gmail.com Thu Jul 24 11:25:32 2014 From: corinnekrych at gmail.com (Corinne Krych) Date: Thu, 24 Jul 2014 17:25:32 +0200 Subject: [aerogear-dev] [Vote] Release of UPS 1.0.0.Beta1 In-Reply-To: References: Message-ID: <516051AF-3D4F-4416-A0A8-DD42375A431B@gmail.com> +1 Successfully tested interactive notification on iOS8 with dev and prod certificates on iOS8beta4 ++ Corinne On 24 Jul 2014, at 17:22, Sebastien Blanc wrote: > +1 > I've deployed the WARs on OpenShift, then tested with the HelloWorld and the Contact App. > Everything work as expected ! > > > > On Wed, Jul 23, 2014 at 9:01 AM, Matthias Wessendorf wrote: > Good morning folks! > > we are getting closer and closer to our 1.0.0 release! Thank you very much, guys! > > However, before we are moving towards the 1.0.0.Final community release, I'd love to get the current work out as 1.0.0.Beta1 > > Note this release contains a ton of work and new features. To name a few highlights: > > * increased APNs payload (2k) > * iOS8 interactive notification support > * Pagination for analytics > * improved callback for details on actual push delivery > * optimisations and improvements > > Besides these changes, a ton of more work was done by the team: > https://issues.jboss.org/browse/AGPUSH/fixforversion/12323753 > > The staging repository is located here: > https://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-3598 > > > NOTE: Once this release has been approved the matching tag will be used to get the OpenShift online bits updated! > > Let me know the results of your testing! > If I hear nothing bad by Friday evening, the release to maven central will happen on Monday; > > Greetings, > Matthias > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev From corinnekrych at gmail.com Thu Jul 24 11:26:05 2014 From: corinnekrych at gmail.com (Corinne Krych) Date: Thu, 24 Jul 2014 17:26:05 +0200 Subject: [aerogear-dev] UPS: Java Sender release In-Reply-To: References: <46E8BE1A-B34A-4729-903B-DD27D70974D1@redhat.com> Message-ID: +1 tested on AeroDoc on iOS8 ++ Corinne On 24 Jul 2014, at 17:24, Sebastien Blanc wrote: > Tested with the Contact Quickstart + AeroDoc , work as expected ! > +1 > > > > On Tue, Jul 22, 2014 at 10:31 AM, Matthias Wessendorf wrote: > awesome! > > > On Tue, Jul 22, 2014 at 10:13 AM, Tadeas Kriz wrote: > Hey, > > it will get tested in the same run as UnifiedPush server using our integration tests suite. > > ? > Tadeas Kriz > > On 22 Jul 2014, at 10:00 am, Matthias Wessendorf wrote: > >> Hi, >> >> I'd like to release the 0.8.0 version of the java-sender. The staging repo is here: >> http://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-3597/ >> >> >> Changes since last release: >> * AGPUSH-800 (need to be tested against master of UPS server) >> * AGPUSH-783 >> >> Please test and let me know! >> >> Thanks! >> >> -- >> Matthias Wessendorf >> >> blog: http://matthiaswessendorf.wordpress.com/ >> sessions: http://www.slideshare.net/mwessendorf >> twitter: http://twitter.com/mwessendorf >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev From kpiwko at redhat.com Thu Jul 24 11:44:00 2014 From: kpiwko at redhat.com (Karel Piwko) Date: Thu, 24 Jul 2014 15:46:00 +0002 Subject: [aerogear-dev] Differences between Firefox OS "native" Push lib and AeroGear's Push adapter In-Reply-To: References: <9B70BDB9-4774-4BF0-9FF7-5213185E4F52@redhat.com> <51C9D854-0730-4B2A-9A92-9DC92649947D@redhat.com> <8AEB32A5-0F61-495B-8EA5-767F48312B9C@redhat.com> <28EA872A-87E3-4035-9C63-DA04EF034580!@redhat.com> <02064329-0F9B-49DC-A5EC-A106001DD51F@redhat.com> Message-ID: <1406216640.15307.0@smtp.corp.redhat.com> On Thu, Jul 24, 2014 at 3:28 PM, Tadeas Kriz wrote: > > It should not. For hibernate, it?s just a string like any other. > The problem might be in the configuration of JAX.RS/RestEasy. If > I?ll have some time today evening, I?ll try to fix it, it should > be an easy fix. Last famous words? ;-) But I agree. Everything is string and URL encode should happen on client while server should automatically decode and work always with just decoded string. If we need to encode twice, something is wrong. > > From bradrickcarter at gmail.com Thu Jul 24 14:09:21 2014 From: bradrickcarter at gmail.com (bradrickcarter) Date: Thu, 24 Jul 2014 11:09:21 -0700 (PDT) Subject: [aerogear-dev] Issues with Aerogear on Cordova In-Reply-To: References: Message-ID: <1406225361976-8516.post@n5.nabble.com> I'm having a similar issue. First I'd like to said I spent about 3 days trying to get the push plugin to work in my cordova project (pulled out all of my hair!). I finally got it working and I am able to push to iOS and Android. The issue is I can only push messages from the Aerogear Push server on OpenSift. I have tried all day to send a message using the rest end-points with cURL and Ajax. I have no more hair to pull out. I have used the following urls to send and none work; https://push-1127studios.rhcloud.com/ag-push/rest/sender returns - HTTP/1.1 400 Bad Request https://push-1127studios.rhcloud.com/rest/sender returns - HTTP/1.1 404 Not Found I have double checked my applicationID and master secret but nothing is working. Help! please... -- View this message in context: http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-Issues-with-Aerogear-on-Cordova-tp6331p8516.html Sent from the aerogear-dev mailing list archive at Nabble.com. From bradrickcarter at gmail.com Thu Jul 24 14:13:00 2014 From: bradrickcarter at gmail.com (bradrickcarter) Date: Thu, 24 Jul 2014 11:13:00 -0700 (PDT) Subject: [aerogear-dev] push sender rest not working for me Message-ID: <1406225580030-8517.post@n5.nabble.com> First I'd like to say I spent about 3 days trying to get the push plugin to work in my cordova project (pulled out all of my hair!). I finally got it working and I am able to push to iOS and Android. The issue is I can only push messages from the Aerogear Push server on OpenSift. I have tried all day to send a message using the rest end-points with cURL and Ajax. I have no more hair to pull out. I have used the following urls to send and none work; https://push-1127studios.rhcloud.com/ag-push/rest/sender returns - HTTP/1.1 400 Bad Request https://push-1127studios.rhcloud.com/rest/sender returns - HTTP/1.1 404 Not Found I have double checked my applicationID and master secret but nothing is working. Help! please... -- View this message in context: http://aerogear-dev.1069024.n5.nabble.com/push-sender-rest-not-working-for-me-tp8517.html Sent from the aerogear-dev mailing list archive at Nabble.com. From matzew at apache.org Thu Jul 24 14:26:12 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Thu, 24 Jul 2014 20:26:12 +0200 Subject: [aerogear-dev] Issues with Aerogear on Cordova In-Reply-To: <1406225361976-8516.post@n5.nabble.com> References: <1406225361976-8516.post@n5.nabble.com> Message-ID: On Thu, Jul 24, 2014 at 8:09 PM, bradrickcarter wrote: > I'm having a similar issue. First I'd like to said I spent about 3 days > trying to get the push plugin to work in my cordova project (pulled out all > of my hair!). I finally got it working and I am able to push to iOS and > Android. The issue is I can only push messages from the Aerogear Push > server > on OpenSift. I have tried all day to send a message using the rest > end-points with cURL and Ajax. I have no more hair to pull out. > > I have used the following urls to send and none work; > > https://push-1127studios.rhcloud.com/ag-push/rest/sender > returns - HTTP/1.1 400 Bad Request > Can share the CURL that cause the 400 ? I bet there is some tiny error on the actual CURL/JSON > > https://push-1127studios.rhcloud.com/rest/sender > returns - HTTP/1.1 404 Not Found > w/ 0.11.0, we are deploying the UnifiedPush Server to the "ag-push" context, that's a change. > > I have double checked my applicationID and master secret but nothing is > working. > > Help! > please... > > > > -- > View this message in context: > http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-Issues-with-Aerogear-on-Cordova-tp6331p8516.html > Sent from the aerogear-dev mailing list archive at Nabble.com. > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140724/6dcc8ca1/attachment.html From matzew at apache.org Thu Jul 24 14:27:39 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Thu, 24 Jul 2014 20:27:39 +0200 Subject: [aerogear-dev] push sender rest not working for me In-Reply-To: <1406225580030-8517.post@n5.nabble.com> References: <1406225580030-8517.post@n5.nabble.com> Message-ID: On Thu, Jul 24, 2014 at 8:13 PM, bradrickcarter wrote: > First I'd like to say I spent about 3 days trying to get the push plugin to > work in my cordova project (pulled out all of my hair!). I finally got it > working and I am able to push to iOS and Android. The issue is I can only > push messages from the Aerogear Push server on OpenSift. I have tried all > day to send a message using the rest end-points with cURL and Ajax. I have > no more hair to pull out. > > I have used the following urls to send and none work; > > https://push-1127studios.rhcloud.com/ag-push/rest/sender > returns - HTTP/1.1 400 Bad Request > Can share the CURL that cause the 400 ? I bet there is some tiny error on the actual CURL/JSON PS: Does the "Send Push" dialog work? The Server has a little page to actually send messags -M > > https://push-1127studios.rhcloud.com/rest/sender > returns - HTTP/1.1 404 Not Found > > I have double checked my applicationID and master secret but nothing is > working. > > Help! > please... > > > > -- > View this message in context: > http://aerogear-dev.1069024.n5.nabble.com/push-sender-rest-not-working-for-me-tp8517.html > Sent from the aerogear-dev mailing list archive at Nabble.com. > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140724/328e2aba/attachment.html From bradrickcarter at gmail.com Thu Jul 24 14:35:54 2014 From: bradrickcarter at gmail.com (bradrickcarter) Date: Thu, 24 Jul 2014 11:35:54 -0700 (PDT) Subject: [aerogear-dev] push sender rest not working for me In-Reply-To: References: <1406225580030-8517.post@n5.nabble.com> Message-ID: <17B9B0DD-A769-4AA0-9200-DA2AB043ACB0@gmail.com> Hi Matthias, Yes, the "Send Push" dialog works on the server. I had a typo in my url but I am now getting a 401 Unauthorized. curl request below; curl -3 -u "{ffeaec0b-ebc9-48e7-bab7-1cee73d38221}:{34882347-03ed-4561-95b6-6eeedc0adbd6}" -v -H "Accept: application/json" -H "Content-type: application/json" -X POST -d '{"message": {"alert":"This is a test push from cURL","sound":"default","badge":7,"content-available" : true}}' https://push-1127studios.rhcloud.com/ag-push/rest/sender Thank you! On Jul 24, 2014, at 1:28 PM, Matthias Wessendorf [via aerogear-dev] wrote: > > > > On Thu, Jul 24, 2014 at 8:13 PM, bradrickcarter <[hidden email]> wrote: > First I'd like to say I spent about 3 days trying to get the push plugin to > work in my cordova project (pulled out all of my hair!). I finally got it > working and I am able to push to iOS and Android. The issue is I can only > push messages from the Aerogear Push server on OpenSift. I have tried all > day to send a message using the rest end-points with cURL and Ajax. I have > no more hair to pull out. > > I have used the following urls to send and none work; > > https://push-1127studios.rhcloud.com/ag-push/rest/sender > returns - HTTP/1.1 400 Bad Request > > Can share the CURL that cause the 400 ? > I bet there is some tiny error on the actual CURL/JSON > > PS: Does the "Send Push" dialog work? The Server has a little page to actually send messags > > -M > > > https://push-1127studios.rhcloud.com/rest/sender > returns - HTTP/1.1 404 Not Found > > I have double checked my applicationID and master secret but nothing is > working. > > Help! > please... > > > > -- > View this message in context: http://aerogear-dev.1069024.n5.nabble.com/push-sender-rest-not-working-for-me-tp8517.html > Sent from the aerogear-dev mailing list archive at Nabble.com. > _______________________________________________ > aerogear-dev mailing list > [hidden email] > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > > _______________________________________________ > aerogear-dev mailing list > [hidden email] > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > If you reply to this email, your message will be added to the discussion below: > http://aerogear-dev.1069024.n5.nabble.com/push-sender-rest-not-working-for-me-tp8517p8519.html > To unsubscribe from push sender rest not working for me, click here. > NAML -- View this message in context: http://aerogear-dev.1069024.n5.nabble.com/push-sender-rest-not-working-for-me-tp8517p8520.html Sent from the aerogear-dev mailing list archive at Nabble.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140724/cb131493/attachment.html From matzew at apache.org Thu Jul 24 14:39:37 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Thu, 24 Jul 2014 20:39:37 +0200 Subject: [aerogear-dev] push sender rest not working for me In-Reply-To: <17B9B0DD-A769-4AA0-9200-DA2AB043ACB0@gmail.com> References: <1406225580030-8517.post@n5.nabble.com> <17B9B0DD-A769-4AA0-9200-DA2AB043ACB0@gmail.com> Message-ID: You should have received a message :-) here is my curl: curl -3 -u "ffeaec0b-ebc9-48e7-bab7-1cee73d38221:34882347-03ed-4561-95b6-6eeedc0adbd6" -v -H "Accept: application/json" -H "Content-type: application/json" -X POST -d '{"message": {"alert":"This is a test push from cURL","sound":"default","badge":7,"content-available" : true}}' https://push-1127studios.rhcloud.com/ag-push/rest/sender I removed the {} from the applicationID and from the masterSecret as well. I wonder, why did you enter these {} around the credentials ? On Thu, Jul 24, 2014 at 8:35 PM, bradrickcarter wrote: > Hi Matthias, > > Yes, the "Send Push" dialog works on the server. > > I had a typo in my url but I am now getting a 401 Unauthorized. curl > request below; > > curl -3 -u > "{ffeaec0b-ebc9-48e7-bab7-1cee73d38221}:{34882347-03ed-4561-95b6-6eeedc0adbd6}" > -v -H "Accept: application/json" -H "Content-type: application/json" -X > POST -d '{"message": {"alert":"This is a test push from > cURL","sound":"default","badge":7,"content-available" : true}}' > https://push-1127studios.rhcloud.com/ag-push/rest/sender > > > Thank you! > > > On Jul 24, 2014, at 1:28 PM, Matthias Wessendorf [via aerogear-dev] <[hidden > email] > wrote: > > > > > On Thu, Jul 24, 2014 at 8:13 PM, bradrickcarter < href="x-msg://3/user/SendEmail.jtp?type=node&node=8519&i=0" > target="_top" rel="nofollow" link="external">[hidden email]> wrote: > >> First I'd like to say I spent about 3 days trying to get the push plugin >> to >> work in my cordova project (pulled out all of my hair!). I finally got it >> working and I am able to push to iOS and Android. The issue is I can only >> push messages from the Aerogear Push server on OpenSift. I have tried all >> day to send a message using the rest end-points with cURL and Ajax. I have >> no more hair to pull out. >> >> I have used the following urls to send and none work; >> >> https://push-1127studios.rhcloud.com/ag-push/rest/sender >> returns - HTTP/1.1 400 Bad Request >> > > Can share the CURL that cause the 400 ? > I bet there is some tiny error on the actual CURL/JSON > > PS: Does the "Send Push" dialog work? The Server has a little page to > actually send messags > > -M > > >> >> https://push-1127studios.rhcloud.com/rest/sender >> returns - HTTP/1.1 404 Not Found >> >> I have double checked my applicationID and master secret but nothing is >> working. >> >> Help! >> please... >> >> >> >> -- >> View this message in context: >> http://aerogear-dev.1069024.n5.nabble.com/push-sender-rest-not-working-for-me-tp8517.html >> Sent from the aerogear-dev mailing list archive at Nabble.com. >> _______________________________________________ >> aerogear-dev mailing list >> > target="_top" rel="nofollow" link="external">[hidden email] >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > > _______________________________________________ > aerogear-dev mailing list > target="_top" rel="nofollow" link="external">[hidden email] > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > ------------------------------ > If you reply to this email, your message will be added to the discussion > below: > > http://aerogear-dev.1069024.n5.nabble.com/push-sender-rest-not-working-for-me-tp8517p8519.html > To unsubscribe from push sender rest not working for me, click here. > NAML > > > > > ------------------------------ > View this message in context: Re: [aerogear-dev] push sender rest not > working for me > > > Sent from the aerogear-dev mailing list archive > at Nabble.com. > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140724/f19f312f/attachment-0001.html From bradrickcarter at gmail.com Thu Jul 24 14:44:02 2014 From: bradrickcarter at gmail.com (bradrickcarter) Date: Thu, 24 Jul 2014 11:44:02 -0700 (PDT) Subject: [aerogear-dev] push sender rest not working for me In-Reply-To: References: <1406225580030-8517.post@n5.nabble.com> <17B9B0DD-A769-4AA0-9200-DA2AB043ACB0@gmail.com> Message-ID: <1D335542-AD62-42ED-A81E-3931276C81F6@gmail.com> HA! Yes! Thanks! Not sure why i did that. Been up late nights trying to make this work... BTW - can I send a push from a web app using ajax? Thanks! On Jul 24, 2014, at 1:40 PM, Matthias Wessendorf [via aerogear-dev] wrote: > You should have received a message :-) > > > here is my curl: > > curl -3 -u "ffeaec0b-ebc9-48e7-bab7-1cee73d38221:34882347-03ed-4561-95b6-6eeedc0adbd6" -v -H "Accept: application/json" -H "Content-type: application/json" -X POST -d '{"message": {"alert":"This is a test push from cURL","sound":"default","badge":7,"content-available" : true}}' https://push-1127studios.rhcloud.com/ag-push/rest/sender > > > I removed the {} from the applicationID and from the masterSecret as well. > > I wonder, why did you enter these {} around the credentials ? > > > > > > > On Thu, Jul 24, 2014 at 8:35 PM, bradrickcarter <[hidden email]> wrote: > Hi Matthias, > > Yes, the "Send Push" dialog works on the server. > > I had a typo in my url but I am now getting a 401 Unauthorized. curl request below; > > curl -3 -u "{ffeaec0b-ebc9-48e7-bab7-1cee73d38221}:{34882347-03ed-4561-95b6-6eeedc0adbd6}" -v -H "Accept: application/json" -H "Content-type: application/json" -X POST -d '{"message": {"alert":"This is a test push from cURL","sound":"default","badge":7,"content-available" : true}}' https://push-1127studios.rhcloud.com/ag-push/rest/sender > > > Thank you! > > > On Jul 24, 2014, at 1:28 PM, Matthias Wessendorf [via aerogear-dev] <[hidden email]> wrote: > >> >> >> >> On Thu, Jul 24, 2014 at 8:13 PM, bradrickcarter <[hidden email]> wrote: >> First I'd like to say I spent about 3 days trying to get the push plugin to >> work in my cordova project (pulled out all of my hair!). I finally got it >> working and I am able to push to iOS and Android. The issue is I can only >> push messages from the Aerogear Push server on OpenSift. I have tried all >> day to send a message using the rest end-points with cURL and Ajax. I have >> no more hair to pull out. >> >> I have used the following urls to send and none work; >> >> https://push-1127studios.rhcloud.com/ag-push/rest/sender >> returns - HTTP/1.1 400 Bad Request >> >> Can share the CURL that cause the 400 ? >> I bet there is some tiny error on the actual CURL/JSON >> >> PS: Does the "Send Push" dialog work? The Server has a little page to actually send messags >> >> -M >> >> >> https://push-1127studios.rhcloud.com/rest/sender >> returns - HTTP/1.1 404 Not Found >> >> I have double checked my applicationID and master secret but nothing is >> working. >> >> Help! >> please... >> >> >> >> -- >> View this message in context: http://aerogear-dev.1069024.n5.nabble.com/push-sender-rest-not-working-for-me-tp8517.html >> Sent from the aerogear-dev mailing list archive at Nabble.com. >> _______________________________________________ >> aerogear-dev mailing list >> [hidden email] >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> >> -- >> Matthias Wessendorf >> >> blog: http://matthiaswessendorf.wordpress.com/ >> sessions: http://www.slideshare.net/mwessendorf >> twitter: http://twitter.com/mwessendorf >> >> _______________________________________________ >> aerogear-dev mailing list >> [hidden email] >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> If you reply to this email, your message will be added to the discussion below: >> http://aerogear-dev.1069024.n5.nabble.com/push-sender-rest-not-working-for-me-tp8517p8519.html >> To unsubscribe from push sender rest not working for me, click here. >> NAML > > > View this message in context: Re: [aerogear-dev] push sender rest not working for me > > Sent from the aerogear-dev mailing list archive at Nabble.com. > > _______________________________________________ > aerogear-dev mailing list > [hidden email] > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > > _______________________________________________ > aerogear-dev mailing list > [hidden email] > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > If you reply to this email, your message will be added to the discussion below: > http://aerogear-dev.1069024.n5.nabble.com/push-sender-rest-not-working-for-me-tp8517p8521.html > To unsubscribe from push sender rest not working for me, click here. > NAML -- View this message in context: http://aerogear-dev.1069024.n5.nabble.com/push-sender-rest-not-working-for-me-tp8517p8522.html Sent from the aerogear-dev mailing list archive at Nabble.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140724/d0aa983e/attachment.html From matzew at apache.org Thu Jul 24 14:49:44 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Thu, 24 Jul 2014 20:49:44 +0200 Subject: [aerogear-dev] push sender rest not working for me In-Reply-To: <1D335542-AD62-42ED-A81E-3931276C81F6@gmail.com> References: <1406225580030-8517.post@n5.nabble.com> <17B9B0DD-A769-4AA0-9200-DA2AB043ACB0@gmail.com> <1D335542-AD62-42ED-A81E-3931276C81F6@gmail.com> Message-ID: Hello Brad! On Thu, Jul 24, 2014 at 8:44 PM, bradrickcarter wrote: > HA! Yes! Thanks! > > Not sure why i did that. Been up late nights trying to make this work... > the devil is always in the details. sorry for that. Let us know if/how we can improve our getting started experience! > > BTW - can I send a push from a web app using ajax? > well, if the pushAppID/masterSecret is stored somewhere in a web-browser, everyone can read that (view source). I'd send it form a backend. We have libraries for * PHP * node.js * Java Since the endpoints are HTTP/REST, you can use any platform :) Now, using a backend as a "proxy", your web-app can bing the backend, via ajax, like "hey send 'XYZ' push", and the backend than has the credentials and simply delegates the XYZ payload to the UPS. That way pushAppID/masterSecret are not exposed on the "web site" -M > > Thanks! > On Jul 24, 2014, at 1:40 PM, Matthias Wessendorf [via aerogear-dev] <[hidden > email] > wrote: > > You should have received a message :-) > > > here is my curl: > > curl -3 -u > "ffeaec0b-ebc9-48e7-bab7-1cee73d38221:34882347-03ed-4561-95b6-6eeedc0adbd6" > -v -H "Accept: application/json" -H "Content-type: application/json" -X > POST -d '{"message": {"alert":"This is a test push from > cURL","sound":"default","badge":7,"content-available" : true}}' > https://push-1127studios.rhcloud.com/ag-push/rest/sender > > > I removed the {} from the applicationID and from the masterSecret as well. > > I wonder, why did you enter these {} around the credentials ? > > > > > > > On Thu, Jul 24, 2014 at 8:35 PM, bradrickcarter < href="x-msg://5/user/SendEmail.jtp?type=node&node=8521&i=0" > target="_top" rel="nofollow" link="external">[hidden email]> wrote: > >> Hi Matthias, >> >> Yes, the "Send Push" dialog works on the server. >> >> I had a typo in my url but I am now getting a 401 Unauthorized. curl >> request below; >> >> curl -3 -u >> "{ffeaec0b-ebc9-48e7-bab7-1cee73d38221}:{34882347-03ed-4561-95b6-6eeedc0adbd6}" >> -v -H "Accept: application/json" -H "Content-type: application/json" -X >> POST -d '{"message": {"alert":"This is a test push from >> cURL","sound":"default","badge":7,"content-available" : true}}' >> https://push-1127studios.rhcloud.com/ag-push/rest/sender >> >> >> Thank you! >> >> >> On Jul 24, 2014, at 1:28 PM, Matthias Wessendorf [via aerogear-dev] <[hidden >> email] > wrote: >> >> >> >> >> On Thu, Jul 24, 2014 at 8:13 PM, bradrickcarter <x-msg://3/user/SendEmail.jtp?type=node&node=8519&i=0" >> target="_top" rel="nofollow" link="external">[hidden email]> wrote: >> >>> First I'd like to say I spent about 3 days trying to get the push plugin >>> to >>> work in my cordova project (pulled out all of my hair!). I finally got it >>> working and I am able to push to iOS and Android. The issue is I can only >>> push messages from the Aerogear Push server on OpenSift. I have tried all >>> day to send a message using the rest end-points with cURL and Ajax. I >>> have >>> no more hair to pull out. >>> >>> I have used the following urls to send and none work; >>> >>> https://push-1127studios.rhcloud.com/ag-push/rest/sender >>> returns - HTTP/1.1 400 Bad Request >>> >> >> Can share the CURL that cause the 400 ? >> I bet there is some tiny error on the actual CURL/JSON >> >> PS: Does the "Send Push" dialog work? The Server has a little page to >> actually send messags >> >> -M >> >> >>> >>> https://push-1127studios.rhcloud.com/rest/sender >>> returns - HTTP/1.1 404 Not Found >>> >>> I have double checked my applicationID and master secret but nothing is >>> working. >>> >>> Help! >>> please... >>> >>> >>> >>> -- >>> View this message in context: >>> http://aerogear-dev.1069024.n5.nabble.com/push-sender-rest-not-working-for-me-tp8517.html >>> Sent from the aerogear-dev mailing list archive at Nabble.com >>> . >>> _______________________________________________ >>> aerogear-dev mailing list >>> x-msg://3/user/SendEmail.jtp?type=node&node=8519&i=1" >>> target="_top" rel="nofollow" link="external">[hidden email] >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >> >> >> >> -- >> Matthias Wessendorf >> >> blog: http://matthiaswessendorf.wordpress.com/ >> sessions: http://www.slideshare.net/mwessendorf >> twitter: http://twitter.com/mwessendorf >> >> _______________________________________________ >> aerogear-dev mailing list >> x-msg://3/user/SendEmail.jtp?type=node&node=8519&i=2" >> target="_top" rel="nofollow" link="external">[hidden email] >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> ------------------------------ >> If you reply to this email, your message will be added to the >> discussion below: >> >> http://aerogear-dev.1069024.n5.nabble.com/push-sender-rest-not-working-for-me-tp8517p8519.html >> To unsubscribe from push sender rest not working for me, click here. >> NAML >> >> >> >> >> ------------------------------ >> View this message in context: Re: [aerogear-dev] push sender rest not >> working for me >> >> >> Sent from the aerogear-dev mailing list archive >> at Nabble.com. >> >> _______________________________________________ >> aerogear-dev mailing list >> > target="_top" rel="nofollow" link="external">[hidden email] >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > > _______________________________________________ > aerogear-dev mailing list > target="_top" rel="nofollow" link="external">[hidden email] > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > ------------------------------ > If you reply to this email, your message will be added to the discussion > below: > > http://aerogear-dev.1069024.n5.nabble.com/push-sender-rest-not-working-for-me-tp8517p8521.html > To unsubscribe from push sender rest not working for me, click here. > NAML > > > > > ------------------------------ > View this message in context: Re: [aerogear-dev] push sender rest not > working for me > > Sent from the aerogear-dev mailing list archive > at Nabble.com. > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140724/42aea7a4/attachment-0001.html From matzew at apache.org Thu Jul 24 14:53:15 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Thu, 24 Jul 2014 20:53:15 +0200 Subject: [aerogear-dev] Quickstarts 1.0.0.Beta1 release ? In-Reply-To: <1406130081.29031.0@smtp.corp.redhat.com> References: <1406130081.29031.0@smtp.corp.redhat.com> Message-ID: On Wed, Jul 23, 2014 at 5:41 PM, Karel Piwko wrote: > > > On Wed, Jul 23, 2014 at 5:14 PM, Matthias Wessendorf > wrote: > > > > > > > > On Wed, Jul 23, 2014 at 4:59 PM, Sebastien Blanc > > wrote: > >> Sounds good ! No new features planned, > >> I know QE is testing but thier eventual findings could go with Beta2 > >> ? > > I guess that's the plan. We've just started with the latter repository, > some of the fixes were included and overall it does not look bad for > Beta1 :-). > OK, I will tag the repos tomorrow. > > > > > yeah, some fixes already were done for QE findings. Mainly on Cordova > > and its plugin. Makes me wonder, should we roll a new Cordova Plugin > > release ? > > > > -Matthias > > > >> > >> > >> > >> > >> On Wed, Jul 23, 2014 at 4:54 PM, Matthias Wessendorf > >> wrote: > >>> Hi, > >>> > >>> with the upcoming UPS 1.0.0.Beta1 release, I'd also like to have a > >>> release for both quickstarts: > >>> > >>> * https://github.com/aerogear/aerogear-push-helloworld > >>> * https://github.com/aerogear/aerogear-push-quickstarts > >>> > >>> > >>> Basically the idea is to simply create a TAG in GH. In the > >>> announcement of the new server version, we link to the tarball/zip > >>> from github of the quickstart 1.0.0.Beta1 release tag > >>> > >>> Or... is someone planing to add fixes to the quickstarts, this week > >>> ? > >>> > >>> > >>> Thanks, > >>> Matthias > >>> > >>> -- > >>> Matthias Wessendorf > >>> > >>> blog: http://matthiaswessendorf.wordpress.com/ > >>> sessions: http://www.slideshare.net/mwessendorf > >>> twitter: http://twitter.com/mwessendorf > >>> > >>> _______________________________________________ > >>> aerogear-dev mailing list > >>> aerogear-dev at lists.jboss.org > >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev > >> > >> > >> _______________________________________________ > >> aerogear-dev mailing list > >> aerogear-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > > > > -- > > Matthias Wessendorf > > > > blog: http://matthiaswessendorf.wordpress.com/ > > sessions: http://www.slideshare.net/mwessendorf > > twitter: http://twitter.com/mwessendorf > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140724/49ea4fa8/attachment.html From matzew at apache.org Thu Jul 24 14:55:21 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Thu, 24 Jul 2014 20:55:21 +0200 Subject: [aerogear-dev] Quickstarts 1.0.0.Beta1 release ? In-Reply-To: References: Message-ID: On Wed, Jul 23, 2014 at 5:14 PM, Matthias Wessendorf wrote: > > > > On Wed, Jul 23, 2014 at 4:59 PM, Sebastien Blanc > wrote: > >> Sounds good ! No new features planned, >> I know QE is testing but thier eventual findings could go with Beta2 ? >> > > > yeah, some fixes already were done for QE findings. Mainly on Cordova and > its plugin. Makes me wonder, should we roll a new Cordova Plugin release ? > Any thoughts on this ? > > -Matthias > > >> >> >> >> >> On Wed, Jul 23, 2014 at 4:54 PM, Matthias Wessendorf >> wrote: >> >>> Hi, >>> >>> with the upcoming UPS 1.0.0.Beta1 release, I'd also like to have a >>> release for both quickstarts: >>> >>> * https://github.com/aerogear/aerogear-push-helloworld >>> * https://github.com/aerogear/aerogear-push-quickstarts >>> >>> >>> Basically the idea is to simply create a TAG in GH. In the announcement >>> of the new server version, we link to the tarball/zip from github of the >>> quickstart 1.0.0.Beta1 release tag >>> >>> Or... is someone planing to add fixes to the quickstarts, this week ? >>> >>> >>> Thanks, >>> Matthias >>> >>> -- >>> Matthias Wessendorf >>> >>> blog: http://matthiaswessendorf.wordpress.com/ >>> sessions: http://www.slideshare.net/mwessendorf >>> twitter: http://twitter.com/mwessendorf >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140724/3a31a372/attachment.html From bradrickcarter at gmail.com Thu Jul 24 15:00:47 2014 From: bradrickcarter at gmail.com (bradrickcarter) Date: Thu, 24 Jul 2014 12:00:47 -0700 (PDT) Subject: [aerogear-dev] push sender rest not working for me In-Reply-To: References: <1406225580030-8517.post@n5.nabble.com> <17B9B0DD-A769-4AA0-9200-DA2AB043ACB0@gmail.com> <1D335542-AD62-42ED-A81E-3931276C81F6@gmail.com> Message-ID: Where do I find the php library? Thanks On Jul 24, 2014, at 1:50 PM, Matthias Wessendorf [via aerogear-dev] wrote: > Hello Brad! > > > On Thu, Jul 24, 2014 at 8:44 PM, bradrickcarter <[hidden email]> wrote: > HA! Yes! Thanks! > > Not sure why i did that. Been up late nights trying to make this work... > > the devil is always in the details. sorry for that. > > Let us know if/how we can improve our getting started experience! > > > BTW - can I send a push from a web app using ajax? > > well, if the pushAppID/masterSecret is stored somewhere in a web-browser, everyone can read that (view source). > > I'd send it form a backend. We have libraries for > * PHP > * node.js > * Java > Since the endpoints are HTTP/REST, you can use any platform :) > > > Now, using a backend as a "proxy", your web-app can bing the backend, via ajax, like "hey send 'XYZ' push", and the backend than has the credentials and simply delegates the XYZ payload to the UPS. That way pushAppID/masterSecret are not exposed on the "web site" > > -M > > > > > Thanks! > On Jul 24, 2014, at 1:40 PM, Matthias Wessendorf [via aerogear-dev] <[hidden email]> wrote: > >> You should have received a message :-) >> >> >> here is my curl: >> >> curl -3 -u "ffeaec0b-ebc9-48e7-bab7-1cee73d38221:34882347-03ed-4561-95b6-6eeedc0adbd6" -v -H "Accept: application/json" -H "Content-type: application/json" -X POST -d '{"message": {"alert":"This is a test push from cURL","sound":"default","badge":7,"content-available" : true}}' https://push-1127studios.rhcloud.com/ag-push/rest/sender >> >> >> I removed the {} from the applicationID and from the masterSecret as well. >> >> I wonder, why did you enter these {} around the credentials ? >> >> >> >> >> >> >> On Thu, Jul 24, 2014 at 8:35 PM, bradrickcarter <[hidden email]> wrote: >> Hi Matthias, >> >> Yes, the "Send Push" dialog works on the server. >> >> I had a typo in my url but I am now getting a 401 Unauthorized. curl request below; >> >> curl -3 -u "{ffeaec0b-ebc9-48e7-bab7-1cee73d38221}:{34882347-03ed-4561-95b6-6eeedc0adbd6}" -v -H "Accept: application/json" -H "Content-type: application/json" -X POST -d '{"message": {"alert":"This is a test push from cURL","sound":"default","badge":7,"content-available" : true}}' https://push-1127studios.rhcloud.com/ag-push/rest/sender >> >> >> Thank you! >> >> >> On Jul 24, 2014, at 1:28 PM, Matthias Wessendorf [via aerogear-dev] <[hidden email]> wrote: >> >>> >>> >>> >>> On Thu, Jul 24, 2014 at 8:13 PM, bradrickcarter <x-msg://3/user/SendEmail.jtp?type=node&node=8519&i=0" target="_top" rel="nofollow" link="external">[hidden email]> wrote: >>> First I'd like to say I spent about 3 days trying to get the push plugin to >>> work in my cordova project (pulled out all of my hair!). I finally got it >>> working and I am able to push to iOS and Android. The issue is I can only >>> push messages from the Aerogear Push server on OpenSift. I have tried all >>> day to send a message using the rest end-points with cURL and Ajax. I have >>> no more hair to pull out. >>> >>> I have used the following urls to send and none work; >>> >>> https://push-1127studios.rhcloud.com/ag-push/rest/sender >>> returns - HTTP/1.1 400 Bad Request >>> >>> Can share the CURL that cause the 400 ? >>> I bet there is some tiny error on the actual CURL/JSON >>> >>> PS: Does the "Send Push" dialog work? The Server has a little page to actually send messags >>> >>> -M >>> >>> >>> https://push-1127studios.rhcloud.com/rest/sender >>> returns - HTTP/1.1 404 Not Found >>> >>> I have double checked my applicationID and master secret but nothing is >>> working. >>> >>> Help! >>> please... >>> >>> >>> >>> -- >>> View this message in context: http://aerogear-dev.1069024.n5.nabble.com/push-sender-rest-not-working-for-me-tp8517.html >>> Sent from the aerogear-dev mailing list archive at Nabble.com. >>> _______________________________________________ >>> aerogear-dev mailing list >>> x-msg://3/user/SendEmail.jtp?type=node&node=8519&i=1" target="_top" rel="nofollow" link="external">[hidden email] >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >>> >>> >>> -- >>> Matthias Wessendorf >>> >>> blog: http://matthiaswessendorf.wordpress.com/ >>> sessions: http://www.slideshare.net/mwessendorf >>> twitter: http://twitter.com/mwessendorf >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> x-msg://3/user/SendEmail.jtp?type=node&node=8519&i=2" target="_top" rel="nofollow" link="external">[hidden email] >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >>> If you reply to this email, your message will be added to the discussion below: >>> http://aerogear-dev.1069024.n5.nabble.com/push-sender-rest-not-working-for-me-tp8517p8519.html >>> To unsubscribe from push sender rest not working for me, click here. >>> NAML >> >> >> View this message in context: Re: [aerogear-dev] push sender rest not working for me >> >> Sent from the aerogear-dev mailing list archive at Nabble.com. >> >> _______________________________________________ >> aerogear-dev mailing list >> [hidden email] >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> >> -- >> Matthias Wessendorf >> >> blog: http://matthiaswessendorf.wordpress.com/ >> sessions: http://www.slideshare.net/mwessendorf >> twitter: http://twitter.com/mwessendorf >> >> _______________________________________________ >> aerogear-dev mailing list >> [hidden email] >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> If you reply to this email, your message will be added to the discussion below: >> http://aerogear-dev.1069024.n5.nabble.com/push-sender-rest-not-working-for-me-tp8517p8521.html >> To unsubscribe from push sender rest not working for me, click here. >> NAML > > > View this message in context: Re: [aerogear-dev] push sender rest not working for me > Sent from the aerogear-dev mailing list archive at Nabble.com. > > _______________________________________________ > aerogear-dev mailing list > [hidden email] > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > > _______________________________________________ > aerogear-dev mailing list > [hidden email] > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > If you reply to this email, your message will be added to the discussion below: > http://aerogear-dev.1069024.n5.nabble.com/push-sender-rest-not-working-for-me-tp8517p8523.html > To unsubscribe from push sender rest not working for me, click here. > NAML -- View this message in context: http://aerogear-dev.1069024.n5.nabble.com/push-sender-rest-not-working-for-me-tp8517p8526.html Sent from the aerogear-dev mailing list archive at Nabble.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140724/71b6b6c9/attachment-0001.html From edewit at redhat.com Thu Jul 24 15:02:41 2014 From: edewit at redhat.com (Erik Jan de Wit) Date: Thu, 24 Jul 2014 21:02:41 +0200 Subject: [aerogear-dev] push sender rest not working for me In-Reply-To: References: <1406225580030-8517.post@n5.nabble.com> <17B9B0DD-A769-4AA0-9200-DA2AB043ACB0@gmail.com> <1D335542-AD62-42ED-A81E-3931276C81F6@gmail.com> Message-ID: > Where do I find the php library? https://github.com/aerogear/aerogear-unified-push-php-client -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140724/b6aeb2f8/attachment.html From matzew at apache.org Thu Jul 24 15:09:31 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Thu, 24 Jul 2014 21:09:31 +0200 Subject: [aerogear-dev] push sender rest not working for me In-Reply-To: References: <1406225580030-8517.post@n5.nabble.com> <17B9B0DD-A769-4AA0-9200-DA2AB043ACB0@gmail.com> <1D335542-AD62-42ED-A81E-3931276C81F6@gmail.com> Message-ID: On Thursday, July 24, 2014, bradrickcarter wrote: > Where do I find the php library? > > https://github.com/aerogear/aerogear-unified-push-php-client Not sure it's 100% at latest greatest, but should work > Thanks > On Jul 24, 2014, at 1:50 PM, Matthias Wessendorf [via aerogear-dev] <[hidden > email] > wrote: > > Hello Brad! > > > On Thu, Jul 24, 2014 at 8:44 PM, bradrickcarter < href="x-msg://7/user/SendEmail.jtp?type=node&node=8523&i=0" > target="_top" rel="nofollow" link="external">[hidden email]> wrote: > >> HA! Yes! Thanks! >> >> Not sure why i did that. Been up late nights trying to make this work... >> > > the devil is always in the details. sorry for that. > > Let us know if/how we can improve our getting started experience! > > >> >> BTW - can I send a push from a web app using ajax? >> > > well, if the pushAppID/masterSecret is stored somewhere in a web-browser, > everyone can read that (view source). > > I'd send it form a backend. We have libraries for > * PHP > * node.js > * Java > Since the endpoints are HTTP/REST, you can use any platform :) > > > Now, using a backend as a "proxy", your web-app can bing the backend, via > ajax, like "hey send 'XYZ' push", and the backend than has the credentials > and simply delegates the XYZ payload to the UPS. That way > pushAppID/masterSecret are not exposed on the "web site" > > -M > > > > >> >> Thanks! >> On Jul 24, 2014, at 1:40 PM, Matthias Wessendorf [via aerogear-dev] <[hidden >> email] > wrote: >> >> You should have received a message :-) >> >> >> here is my curl: >> >> curl -3 -u >> "ffeaec0b-ebc9-48e7-bab7-1cee73d38221:34882347-03ed-4561-95b6-6eeedc0adbd6" >> -v -H "Accept: application/json" -H "Content-type: application/json" -X >> POST -d '{"message": {"alert":"This is a test push from >> cURL","sound":"default","badge":7,"content-available" : true}}' >> https://push-1127studios.rhcloud.com/ag-push/rest/sender >> >> >> I removed the {} from the applicationID and from the masterSecret as well. >> >> I wonder, why did you enter these {} around the credentials ? >> >> >> >> >> >> >> On Thu, Jul 24, 2014 at 8:35 PM, bradrickcarter <x-msg://5/user/SendEmail.jtp?type=node&node=8521&i=0" >> target="_top" rel="nofollow" link="external">[hidden email]> wrote: >> >>> Hi Matthias, >>> >>> Yes, the "Send Push" dialog works on the server. >>> >>> I had a typo in my url but I am now getting a 401 Unauthorized. curl >>> request below; >>> >>> curl -3 -u >>> "{ffeaec0b-ebc9-48e7-bab7-1cee73d38221}:{34882347-03ed-4561-95b6-6eeedc0adbd6}" >>> -v -H "Accept: application/json" -H "Content-type: application/json" -X >>> POST -d '{"message": {"alert":"This is a test push from >>> cURL","sound":"default","badge":7,"content-available" : true}}' >>> https://push-1127studios.rhcloud.com/ag-push/rest/sender >>> >>> >>> Thank you! >>> >>> >>> On Jul 24, 2014, at 1:28 PM, Matthias Wessendorf [via aerogear-dev] <[hidden >>> email] > wrote: >>> >>> >>> >>> >>> On Thu, Jul 24, 2014 at 8:13 PM, bradrickcarter <>> href="x-msg://3/user/SendEmail.jtp?type=node&amp;amp;node=8519&amp;amp;i=0">x-msg://3/user/SendEmail.jtp?type=node&amp;node=8519&amp;i=0">>> href="x-msg://3/user/SendEmail.jtp?type=node&amp;node=8519&amp;i=0">x-msg://3/user/SendEmail.jtp?type=node&node=8519&i=0" >>> target="_top" rel="nofollow" link="external">[hidden email]> wrote: >>> >>>> First I'd like to say I spent about 3 days trying to get the push >>>> plugin to >>>> work in my cordova project (pulled out all of my hair!). I finally got >>>> it >>>> working and I am able to push to iOS and Android. The issue is I can >>>> only >>>> push messages from the Aerogear Push server on OpenSift. I have tried >>>> all >>>> day to send a message using the rest end-points with cURL and Ajax. I >>>> have >>>> no more hair to pull out. >>>> >>>> I have used the following urls to send and none work; >>>> >>>> https://push-1127studios.rhcloud.com/ag-push/rest/sender >>>> returns - HTTP/1.1 400 Bad Request >>>> >>> >>> Can share the CURL that cause the 400 ? >>> I bet there is some tiny error on the actual CURL/JSON >>> >>> PS: Does the "Send Push" dialog work? The Server has a little page to >>> actually send messags >>> >>> -M >>> >>> >>>> >>>> https://push-1127studios.rhcloud.com/rest/sender >>>> returns - HTTP/1.1 404 Not Found >>>> >>>> I have double checked my applicationID and master secret but nothing is >>>> working. >>>> >>>> Help! >>>> please... >>>> >>>> >>>> >>>> -- >>>> View this message in context: >>>> http://aerogear-dev.1069024.n5.nabble.com/push-sender-rest-not-working-for-me-tp8517.html >>>> Sent from the aerogear-dev mailing list archive at Nabble.com >>>> . >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> >>> href="x-msg://3/user/SendEmail.jtp?type=node&amp;amp;node=8519&amp;amp;i=1">x-msg://3/user/SendEmail.jtp?type=node&amp;node=8519&amp;i=1">>>> href="x-msg://3/user/SendEmail.jtp?type=node&amp;node=8519&amp;i=1">x-msg://3/user/SendEmail.jtp?type=node&node=8519&i=1" >>>> target="_top" rel="nofollow" link="external">[hidden email] >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> >>> >>> >>> >>> -- >>> Matthias Wessendorf >>> >>> blog: http://matthiaswessendorf.wordpress.com/ >>> sessions: http://www.slideshare.net/mwessendorf >>> twitter: http://twitter.com/mwessendorf >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> >> href="x-msg://3/user/SendEmail.jtp?type=node&amp;amp;node=8519&amp;amp;i=2">x-msg://3/user/SendEmail.jtp?type=node&amp;node=8519&amp;i=2">>> href="x-msg://3/user/SendEmail.jtp?type=node&amp;node=8519&amp;i=2">x-msg://3/user/SendEmail.jtp?type=node&node=8519&i=2" >>> target="_top" rel="nofollow" link="external">[hidden email] >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >>> ------------------------------ >>> If you reply to this email, your message will be added to the >>> discussion below: >>> >>> http://aerogear-dev.1069024.n5.nabble.com/push-sender-rest-not-working-for-me-tp8517p8519.html >>> To unsubscribe from push sender rest not working for me, click here. >>> NAML >>> >>> >>> >>> >>> ------------------------------ >>> View this message in context: Re: [aerogear-dev] push sender rest not >>> working for me >>> >>> >>> Sent from the aerogear-dev mailing list archive >>> at Nabble.com >>> . >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> x-msg://5/user/SendEmail.jtp?type=node&node=8521&i=1" >>> target="_top" rel="nofollow" link="external">[hidden email] >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >> >> >> >> -- >> Matthias Wessendorf >> >> blog: http://matthiaswessendorf.wordpress.com/ >> sessions: http://www.slideshare.net/mwessendorf >> twitter: http://twitter.com/mwessendorf >> >> _______________________________________________ >> aerogear-dev mailing list >> x-msg://5/user/SendEmail.jtp?type=node&node=8521&i=2" >> target="_top" rel="nofollow" link="external">[hidden email] >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> ------------------------------ >> If you reply to this email, your message will be added to the >> discussion below: >> >> http://aerogear-dev.1069024.n5.nabble.com/push-sender-rest-not-working-for-me-tp8517p8521.html >> To unsubscribe from push sender rest not working for me, click here. >> NAML >> >> >> >> >> ------------------------------ >> View this message in context: Re: [aerogear-dev] push sender rest not >> working for me >> >> Sent from the aerogear-dev mailing list archive >> at Nabble.com. >> >> _______________________________________________ >> aerogear-dev mailing list >> > target="_top" rel="nofollow" link="external">[hidden email] >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > > _______________________________________________ > aerogear-dev mailing list > target="_top" rel="nofollow" link="external">[hidden email] > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > ------------------------------ > If you reply to this email, your message will be added to the discussion > below: > > http://aerogear-dev.1069024.n5.nabble.com/push-sender-rest-not-working-for-me-tp8517p8523.html > To unsubscribe from push sender rest not working for me, click here. > NAML > > > > > ------------------------------ > View this message in context: Re: [aerogear-dev] push sender rest not > working for me > > Sent from the aerogear-dev mailing list archive > at Nabble.com. > -- Sent from Gmail Mobile -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140724/5ce5ee7b/attachment-0001.html From scm.blanc at gmail.com Thu Jul 24 15:34:31 2014 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Thu, 24 Jul 2014 21:34:31 +0200 Subject: [aerogear-dev] Quickstarts 1.0.0.Beta1 release ? In-Reply-To: References: Message-ID: I would vote for a new release, I testes the HelloWorld and the Contact Quickstart with the master repo of the plugin and all work fine. On Thu, Jul 24, 2014 at 8:55 PM, Matthias Wessendorf wrote: > > > > On Wed, Jul 23, 2014 at 5:14 PM, Matthias Wessendorf > wrote: > >> >> >> >> On Wed, Jul 23, 2014 at 4:59 PM, Sebastien Blanc >> wrote: >> >>> Sounds good ! No new features planned, >>> I know QE is testing but thier eventual findings could go with Beta2 ? >>> >> >> >> yeah, some fixes already were done for QE findings. Mainly on Cordova and >> its plugin. Makes me wonder, should we roll a new Cordova Plugin release ? >> > > Any thoughts on this ? > > > > >> >> -Matthias >> >> >>> >>> >>> >>> >>> On Wed, Jul 23, 2014 at 4:54 PM, Matthias Wessendorf >> > wrote: >>> >>>> Hi, >>>> >>>> with the upcoming UPS 1.0.0.Beta1 release, I'd also like to have a >>>> release for both quickstarts: >>>> >>>> * https://github.com/aerogear/aerogear-push-helloworld >>>> * https://github.com/aerogear/aerogear-push-quickstarts >>>> >>>> >>>> Basically the idea is to simply create a TAG in GH. In the announcement >>>> of the new server version, we link to the tarball/zip from github of the >>>> quickstart 1.0.0.Beta1 release tag >>>> >>>> Or... is someone planing to add fixes to the quickstarts, this week ? >>>> >>>> >>>> Thanks, >>>> Matthias >>>> >>>> -- >>>> Matthias Wessendorf >>>> >>>> blog: http://matthiaswessendorf.wordpress.com/ >>>> sessions: http://www.slideshare.net/mwessendorf >>>> twitter: http://twitter.com/mwessendorf >>>> >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> >>> >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >> >> >> >> -- >> Matthias Wessendorf >> >> blog: http://matthiaswessendorf.wordpress.com/ >> sessions: http://www.slideshare.net/mwessendorf >> twitter: http://twitter.com/mwessendorf >> > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140724/4e729dc5/attachment.html From scm.blanc at gmail.com Thu Jul 24 15:39:44 2014 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Thu, 24 Jul 2014 21:39:44 +0200 Subject: [aerogear-dev] push sender rest not working for me In-Reply-To: References: <1406225580030-8517.post@n5.nabble.com> <17B9B0DD-A769-4AA0-9200-DA2AB043ACB0@gmail.com> Message-ID: On Thu, Jul 24, 2014 at 8:39 PM, Matthias Wessendorf wrote: > You should have received a message :-) > > > here is my curl: > > curl -3 -u > "ffeaec0b-ebc9-48e7-bab7-1cee73d38221:34882347-03ed-4561-95b6-6eeedc0adbd6" > -v -H "Accept: application/json" -H "Content-type: application/json" -X > POST -d '{"message": {"alert":"This is a test push from > cURL","sound":"default","badge":7,"content-available" : true}}' > https://push-1127studios.rhcloud.com/ag-push/rest/sender > > > I removed the {} from the applicationID and from the masterSecret as well. > > I wonder, why did you enter these {} around the credentials ? > Probably because of this doc http://aerogear.org/docs/specs/aerogear-push-messages/ that shows the {} It is at least the third time someone get hit by this , I think we should remove it, it's confusing. > > > > > > On Thu, Jul 24, 2014 at 8:35 PM, bradrickcarter > wrote: > >> Hi Matthias, >> >> Yes, the "Send Push" dialog works on the server. >> >> I had a typo in my url but I am now getting a 401 Unauthorized. curl >> request below; >> >> curl -3 -u >> "{ffeaec0b-ebc9-48e7-bab7-1cee73d38221}:{34882347-03ed-4561-95b6-6eeedc0adbd6}" >> -v -H "Accept: application/json" -H "Content-type: application/json" -X >> POST -d '{"message": {"alert":"This is a test push from >> cURL","sound":"default","badge":7,"content-available" : true}}' >> https://push-1127studios.rhcloud.com/ag-push/rest/sender >> >> >> Thank you! >> >> >> On Jul 24, 2014, at 1:28 PM, Matthias Wessendorf [via aerogear-dev] <[hidden >> email] > wrote: >> >> >> >> >> On Thu, Jul 24, 2014 at 8:13 PM, bradrickcarter <> href="x-msg://3/user/SendEmail.jtp?type=node&node=8519&i=0" >> target="_top" rel="nofollow" link="external">[hidden email]> wrote: >> >>> First I'd like to say I spent about 3 days trying to get the push plugin >>> to >>> work in my cordova project (pulled out all of my hair!). I finally got it >>> working and I am able to push to iOS and Android. The issue is I can only >>> push messages from the Aerogear Push server on OpenSift. I have tried all >>> day to send a message using the rest end-points with cURL and Ajax. I >>> have >>> no more hair to pull out. >>> >>> I have used the following urls to send and none work; >>> >>> https://push-1127studios.rhcloud.com/ag-push/rest/sender >>> returns - HTTP/1.1 400 Bad Request >>> >> >> Can share the CURL that cause the 400 ? >> I bet there is some tiny error on the actual CURL/JSON >> >> PS: Does the "Send Push" dialog work? The Server has a little page to >> actually send messags >> >> -M >> >> >>> >>> https://push-1127studios.rhcloud.com/rest/sender >>> returns - HTTP/1.1 404 Not Found >>> >>> I have double checked my applicationID and master secret but nothing is >>> working. >>> >>> Help! >>> please... >>> >>> >>> >>> -- >>> View this message in context: >>> http://aerogear-dev.1069024.n5.nabble.com/push-sender-rest-not-working-for-me-tp8517.html >>> Sent from the aerogear-dev mailing list archive at Nabble.com. >>> _______________________________________________ >>> aerogear-dev mailing list >>> >> target="_top" rel="nofollow" link="external">[hidden email] >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >> >> >> >> -- >> Matthias Wessendorf >> >> blog: http://matthiaswessendorf.wordpress.com/ >> sessions: http://www.slideshare.net/mwessendorf >> twitter: http://twitter.com/mwessendorf >> >> _______________________________________________ >> aerogear-dev mailing list >> > target="_top" rel="nofollow" link="external">[hidden email] >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> ------------------------------ >> If you reply to this email, your message will be added to the >> discussion below: >> >> http://aerogear-dev.1069024.n5.nabble.com/push-sender-rest-not-working-for-me-tp8517p8519.html >> To unsubscribe from push sender rest not working for me, click here. >> NAML >> >> >> >> >> ------------------------------ >> View this message in context: Re: [aerogear-dev] push sender rest not >> working for me >> >> >> Sent from the aerogear-dev mailing list archive >> at Nabble.com. >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140724/70785afa/attachment-0001.html From matzew at apache.org Thu Jul 24 15:40:47 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Thu, 24 Jul 2014 21:40:47 +0200 Subject: [aerogear-dev] Quickstarts 1.0.0.Beta1 release ? In-Reply-To: References: Message-ID: On Thursday, July 24, 2014, Sebastien Blanc wrote: > I would vote for a new release, I testes the HelloWorld and the Contact > Quickstart with the master repo of the plugin and all work fine. > That's great to hear! +1 here too > > > On Thu, Jul 24, 2014 at 8:55 PM, Matthias Wessendorf > wrote: > >> >> >> >> On Wed, Jul 23, 2014 at 5:14 PM, Matthias Wessendorf > > wrote: >> >>> >>> >>> >>> On Wed, Jul 23, 2014 at 4:59 PM, Sebastien Blanc >> > wrote: >>> >>>> Sounds good ! No new features planned, >>>> I know QE is testing but thier eventual findings could go with Beta2 ? >>>> >>> >>> >>> yeah, some fixes already were done for QE findings. Mainly on Cordova >>> and its plugin. Makes me wonder, should we roll a new Cordova Plugin >>> release ? >>> >> >> Any thoughts on this ? >> >> >> >> >>> >>> -Matthias >>> >>> >>>> >>>> >>>> >>>> >>>> On Wed, Jul 23, 2014 at 4:54 PM, Matthias Wessendorf < >>>> matzew at apache.org > >>>> wrote: >>>> >>>>> Hi, >>>>> >>>>> with the upcoming UPS 1.0.0.Beta1 release, I'd also like to have a >>>>> release for both quickstarts: >>>>> >>>>> * https://github.com/aerogear/aerogear-push-helloworld >>>>> * https://github.com/aerogear/aerogear-push-quickstarts >>>>> >>>>> >>>>> Basically the idea is to simply create a TAG in GH. In the >>>>> announcement of the new server version, we link to the tarball/zip from >>>>> github of the quickstart 1.0.0.Beta1 release tag >>>>> >>>>> Or... is someone planing to add fixes to the quickstarts, this week ? >>>>> >>>>> >>>>> Thanks, >>>>> Matthias >>>>> >>>>> -- >>>>> Matthias Wessendorf >>>>> >>>>> blog: http://matthiaswessendorf.wordpress.com/ >>>>> sessions: http://www.slideshare.net/mwessendorf >>>>> twitter: http://twitter.com/mwessendorf >>>>> >>>>> _______________________________________________ >>>>> aerogear-dev mailing list >>>>> aerogear-dev at lists.jboss.org >>>>> >>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>> >>>> >>>> >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev at lists.jboss.org >>>> >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> >>> >>> >>> >>> -- >>> Matthias Wessendorf >>> >>> blog: http://matthiaswessendorf.wordpress.com/ >>> sessions: http://www.slideshare.net/mwessendorf >>> twitter: http://twitter.com/mwessendorf >>> >> >> >> >> -- >> Matthias Wessendorf >> >> blog: http://matthiaswessendorf.wordpress.com/ >> sessions: http://www.slideshare.net/mwessendorf >> twitter: http://twitter.com/mwessendorf >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > -- Sent from Gmail Mobile -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140724/db24c610/attachment.html From matzew at apache.org Thu Jul 24 15:42:07 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Thu, 24 Jul 2014 21:42:07 +0200 Subject: [aerogear-dev] push sender rest not working for me In-Reply-To: References: <1406225580030-8517.post@n5.nabble.com> <17B9B0DD-A769-4AA0-9200-DA2AB043ACB0@gmail.com> Message-ID: As I do an overhaul on the docs, I will get to the specs too. :-) Good catch! On Thursday, July 24, 2014, Sebastien Blanc wrote: > > > > On Thu, Jul 24, 2014 at 8:39 PM, Matthias Wessendorf > wrote: > >> You should have received a message :-) >> >> >> here is my curl: >> >> curl -3 -u >> "ffeaec0b-ebc9-48e7-bab7-1cee73d38221:34882347-03ed-4561-95b6-6eeedc0adbd6" >> -v -H "Accept: application/json" -H "Content-type: application/json" -X >> POST -d '{"message": {"alert":"This is a test push from >> cURL","sound":"default","badge":7,"content-available" : true}}' >> https://push-1127studios.rhcloud.com/ag-push/rest/sender >> >> >> I removed the {} from the applicationID and from the masterSecret as well. >> >> I wonder, why did you enter these {} around the credentials ? >> > Probably because of this doc > http://aerogear.org/docs/specs/aerogear-push-messages/ that shows the {} > It is at least the third time someone get hit by this , I think we should > remove it, it's confusing. > > >> >> >> >> >> >> On Thu, Jul 24, 2014 at 8:35 PM, bradrickcarter > > wrote: >> >>> Hi Matthias, >>> >>> Yes, the "Send Push" dialog works on the server. >>> >>> I had a typo in my url but I am now getting a 401 Unauthorized. curl >>> request below; >>> >>> curl -3 -u >>> "{ffeaec0b-ebc9-48e7-bab7-1cee73d38221}:{34882347-03ed-4561-95b6-6eeedc0adbd6}" >>> -v -H "Accept: application/json" -H "Content-type: application/json" -X >>> POST -d '{"message": {"alert":"This is a test push from >>> cURL","sound":"default","badge":7,"content-available" : true}}' >>> https://push-1127studios.rhcloud.com/ag-push/rest/sender >>> >>> >>> Thank you! >>> >>> >>> On Jul 24, 2014, at 1:28 PM, Matthias Wessendorf [via aerogear-dev] <[hidden >>> email] > wrote: >>> >>> >>> >>> >>> On Thu, Jul 24, 2014 at 8:13 PM, bradrickcarter <>> href="x-msg://3/user/SendEmail.jtp?type=node&node=8519&i=0" >>> target="_top" rel="nofollow" link="external">[hidden email]> wrote: >>> >>>> First I'd like to say I spent about 3 days trying to get the push >>>> plugin to >>>> work in my cordova project (pulled out all of my hair!). I finally got >>>> it >>>> working and I am able to push to iOS and Android. The issue is I can >>>> only >>>> push messages from the Aerogear Push server on OpenSift. I have tried >>>> all >>>> day to send a message using the rest end-points with cURL and Ajax. I >>>> have >>>> no more hair to pull out. >>>> >>>> I have used the following urls to send and none work; >>>> >>>> https://push-1127studios.rhcloud.com/ag-push/rest/sender >>>> returns - HTTP/1.1 400 Bad Request >>>> >>> >>> Can share the CURL that cause the 400 ? >>> I bet there is some tiny error on the actual CURL/JSON >>> >>> PS: Does the "Send Push" dialog work? The Server has a little page to >>> actually send messags >>> >>> -M >>> >>> >>>> >>>> https://push-1127studios.rhcloud.com/rest/sender >>>> returns - HTTP/1.1 404 Not Found >>>> >>>> I have double checked my applicationID and master secret but nothing is >>>> working. >>>> >>>> Help! >>>> please... >>>> >>>> >>>> >>>> -- >>>> View this message in context: >>>> http://aerogear-dev.1069024.n5.nabble.com/push-sender-rest-not-working-for-me-tp8517.html >>>> Sent from the aerogear-dev mailing list archive at Nabble.com. >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> >>> target="_top" rel="nofollow" link="external">[hidden email] >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> >>> >>> >>> >>> -- >>> Matthias Wessendorf >>> >>> blog: http://matthiaswessendorf.wordpress.com/ >>> sessions: http://www.slideshare.net/mwessendorf >>> twitter: http://twitter.com/mwessendorf >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> >> target="_top" rel="nofollow" link="external">[hidden email] >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >>> ------------------------------ >>> If you reply to this email, your message will be added to the >>> discussion below: >>> >>> http://aerogear-dev.1069024.n5.nabble.com/push-sender-rest-not-working-for-me-tp8517p8519.html >>> To unsubscribe from push sender rest not working for me, click here. >>> NAML >>> >>> >>> >>> >>> ------------------------------ >>> View this message in context: Re: [aerogear-dev] push sender rest not >>> working for me >>> >>> >>> Sent from the aerogear-dev mailing list archive >>> at Nabble.com. >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >> >> >> >> -- >> Matthias Wessendorf >> >> blog: http://matthiaswessendorf.wordpress.com/ >> sessions: http://www.slideshare.net/mwessendorf >> twitter: http://twitter.com/mwessendorf >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > -- Sent from Gmail Mobile -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140724/f1bcc0d2/attachment-0001.html From bradrickcarter at gmail.com Thu Jul 24 16:01:53 2014 From: bradrickcarter at gmail.com (bradrickcarter) Date: Thu, 24 Jul 2014 13:01:53 -0700 (PDT) Subject: [aerogear-dev] push sender rest not working for me In-Reply-To: References: <1406225580030-8517.post@n5.nabble.com> <17B9B0DD-A769-4AA0-9200-DA2AB043ACB0@gmail.com> Message-ID: BTW - you asked why I put brackets around the credentials, its in your docs. it may be common knowledge not to do that but I was having such a hard time making it work I thought I would follow the docs to a T. http://aerogear.org/docs/specs/aerogear-push-messages/ curl -3 -u "{PushApplicationID}:{MasterSecret}" -v -H "Accept: application/json" -H "Content-type: application/json" -X POST -d '{ "variants" : ["c3f0a94f-48de-4b77-a08e-68114460857e", "444939cd-ae63-4ce1-96a4-de74b77e3737" ....], "alias" : ["user at account.com", "someone at aerogear.org", ....], "categories" : ["someCategory", "otherCategory"], "deviceType" : ["iPad", "AndroidTablet"], "ttl" : 3600, "message": { "alert":"HELLO!", "sound":"default", "badge":7, "content-available" : true, "someKey":"some value", "anotherCustomKey":"some other value" }, "simple-push": "version=123" }' https://SERVER:PORT/CONTEXT/rest/sender On Jul 24, 2014, at 1:40 PM, Matthias Wessendorf [via aerogear-dev] wrote: > You should have received a message :-) > > > here is my curl: > > curl -3 -u "ffeaec0b-ebc9-48e7-bab7-1cee73d38221:34882347-03ed-4561-95b6-6eeedc0adbd6" -v -H "Accept: application/json" -H "Content-type: application/json" -X POST -d '{"message": {"alert":"This is a test push from cURL","sound":"default","badge":7,"content-available" : true}}' https://push-1127studios.rhcloud.com/ag-push/rest/sender > > > I removed the {} from the applicationID and from the masterSecret as well. > > I wonder, why did you enter these {} around the credentials ? > > > > > > > On Thu, Jul 24, 2014 at 8:35 PM, bradrickcarter <[hidden email]> wrote: > Hi Matthias, > > Yes, the "Send Push" dialog works on the server. > > I had a typo in my url but I am now getting a 401 Unauthorized. curl request below; > > curl -3 -u "{ffeaec0b-ebc9-48e7-bab7-1cee73d38221}:{34882347-03ed-4561-95b6-6eeedc0adbd6}" -v -H "Accept: application/json" -H "Content-type: application/json" -X POST -d '{"message": {"alert":"This is a test push from cURL","sound":"default","badge":7,"content-available" : true}}' https://push-1127studios.rhcloud.com/ag-push/rest/sender > > > Thank you! > > > On Jul 24, 2014, at 1:28 PM, Matthias Wessendorf [via aerogear-dev] <[hidden email]> wrote: > >> >> >> >> On Thu, Jul 24, 2014 at 8:13 PM, bradrickcarter <[hidden email]> wrote: >> First I'd like to say I spent about 3 days trying to get the push plugin to >> work in my cordova project (pulled out all of my hair!). I finally got it >> working and I am able to push to iOS and Android. The issue is I can only >> push messages from the Aerogear Push server on OpenSift. I have tried all >> day to send a message using the rest end-points with cURL and Ajax. I have >> no more hair to pull out. >> >> I have used the following urls to send and none work; >> >> https://push-1127studios.rhcloud.com/ag-push/rest/sender >> returns - HTTP/1.1 400 Bad Request >> >> Can share the CURL that cause the 400 ? >> I bet there is some tiny error on the actual CURL/JSON >> >> PS: Does the "Send Push" dialog work? The Server has a little page to actually send messags >> >> -M >> >> >> https://push-1127studios.rhcloud.com/rest/sender >> returns - HTTP/1.1 404 Not Found >> >> I have double checked my applicationID and master secret but nothing is >> working. >> >> Help! >> please... >> >> >> >> -- >> View this message in context: http://aerogear-dev.1069024.n5.nabble.com/push-sender-rest-not-working-for-me-tp8517.html >> Sent from the aerogear-dev mailing list archive at Nabble.com. >> _______________________________________________ >> aerogear-dev mailing list >> [hidden email] >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> >> -- >> Matthias Wessendorf >> >> blog: http://matthiaswessendorf.wordpress.com/ >> sessions: http://www.slideshare.net/mwessendorf >> twitter: http://twitter.com/mwessendorf >> >> _______________________________________________ >> aerogear-dev mailing list >> [hidden email] >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> If you reply to this email, your message will be added to the discussion below: >> http://aerogear-dev.1069024.n5.nabble.com/push-sender-rest-not-working-for-me-tp8517p8519.html >> To unsubscribe from push sender rest not working for me, click here. >> NAML > > > View this message in context: Re: [aerogear-dev] push sender rest not working for me > > Sent from the aerogear-dev mailing list archive at Nabble.com. > > _______________________________________________ > aerogear-dev mailing list > [hidden email] > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > > _______________________________________________ > aerogear-dev mailing list > [hidden email] > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > If you reply to this email, your message will be added to the discussion below: > http://aerogear-dev.1069024.n5.nabble.com/push-sender-rest-not-working-for-me-tp8517p8521.html > To unsubscribe from push sender rest not working for me, click here. > NAML -- View this message in context: http://aerogear-dev.1069024.n5.nabble.com/push-sender-rest-not-working-for-me-tp8517p8533.html Sent from the aerogear-dev mailing list archive at Nabble.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140724/d2f1c57d/attachment.html From edewit at redhat.com Thu Jul 24 16:15:32 2014 From: edewit at redhat.com (Erik Jan de Wit) Date: Thu, 24 Jul 2014 22:15:32 +0200 Subject: [aerogear-dev] Quickstarts 1.0.0.Beta1 release ? In-Reply-To: References: Message-ID: <6DD0A928-89A9-4722-BFC3-9322A3FABF51@redhat.com> > yeah, some fixes already were done for QE findings. Mainly on Cordova and its plugin. Makes me wonder, should we roll a new Cordova Plugin release ? > > Any thoughts on this ? > Uhmm?. am I right that the issues we want to base a release on are these: https://issues.jboss.org/browse/AGCORDOVA-22?jql=project%20%3D%20AGCORDOVA%20AND%20fixVersion%20%3D%20push-0.7.0%20ORDER%20BY%20updated%20DESC%2C%20priority%20DESC%2C%20created%20ASC -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140724/9a268f91/attachment-0001.html From matzew at apache.org Thu Jul 24 16:26:36 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Thu, 24 Jul 2014 22:26:36 +0200 Subject: [aerogear-dev] Quickstarts 1.0.0.Beta1 release ? In-Reply-To: <6DD0A928-89A9-4722-BFC3-9322A3FABF51@redhat.com> References: <6DD0A928-89A9-4722-BFC3-9322A3FABF51@redhat.com> Message-ID: On Thu, Jul 24, 2014 at 10:15 PM, Erik Jan de Wit wrote: > yeah, some fixes already were done for QE findings. Mainly on Cordova and >> its plugin. Makes me wonder, should we roll a new Cordova Plugin release ? >> > > Any thoughts on this ? > > > Uhmm?. am I right that the issues we want to base a release on are these: > > > https://issues.jboss.org/browse/AGCORDOVA-22?jql=project%20%3D%20AGCORDOVA%20AND%20fixVersion%20%3D%20push-0.7.0%20ORDER%20BY%20updated%20DESC%2C%20priority%20DESC%2C%20created%20ASC > > Oh, :) I had the impression it was way more :) But yeah, if you are interested in doing a 0.7.0 now, let's do it. If you prefer waiting a bit longer, that's perfectly fine as well -Matthias > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140724/406c3b18/attachment.html From daniel at passos.me Thu Jul 24 17:38:26 2014 From: daniel at passos.me (Daniel Passos) Date: Thu, 24 Jul 2014 18:38:26 -0300 Subject: [aerogear-dev] Modularizing the Android Library In-Reply-To: <4E71A4E1-4E3F-4A89-B8F1-65D0003B4A9B@gmail.com> References: <5317317F.1010209@redhat.com> <20140306143829.65e1e4aa@kapy-ntb-x220> <20140508192800.GB69433@abstractj.org> <4CD71A7A-EDE1-4648-AB3E-E4DDB383D824@gmail.com> <4E71A4E1-4E3F-4A89-B8F1-65D0003B4A9B@gmail.com> Message-ID: On Tue, Jul 22, 2014 at 11:20 AM, Corinne Krych wrote: > > On 22 Jul 2014, at 16:12, Daniel Passos wrote: > > > Hey Guys, > > > > Summers and I started working on agdroid modules and remove some cyclic > dependencies. So we plan to split the agdroid on these modules: > > > > ? aerogear-android-core > > ? aerogear-android-pipe > > ? aerogear-android-auth > > ? aerogear-android-autz > > ? aerogear-android-store (with option security dependecy to use > EncryptedStores) > > ? aerogear-android-security > > ? aerogear-android-push > > ? aerogear-android-push-ups > > what will be the difference between push and push-ups? > Push for the commons classes, interfaces and helpers used in all implementations and ups is an implementation to register/receive message from UPS. > > > ? aerogear-android-offline > > -- Passos > > ? > > > > > > On Fri, May 9, 2014 at 3:55 AM, Corinne Krych > wrote: > > Oops > > [2] https://issues.jboss.org/browse/AGIOS-187 > > > > On 09 May 2014, at 08:52, Corinne Krych wrote: > > > > > [2] https://issues.jboss.org/browse/AGIOS-192 > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140724/e26baddf/attachment.html From daniel at passos.me Thu Jul 24 17:47:12 2014 From: daniel at passos.me (Daniel Passos) Date: Thu, 24 Jul 2014 18:47:12 -0300 Subject: [aerogear-dev] Modularizing the Android Library In-Reply-To: <20140722150611.GA58163@abstractj.org> References: <5317317F.1010209@redhat.com> <20140306143829.65e1e4aa@kapy-ntb-x220> <20140508192800.GB69433@abstractj.org> <4CD71A7A-EDE1-4648-AB3E-E4DDB383D824@gmail.com> <20140722150611.GA58163@abstractj.org> Message-ID: Hi Bruno, aerogear-android-security for now is only to all around KeyServices, like PassPhrase and KeyStore. I'm not sure if Auth and Authz will be used together. The fact is today the implementation is not following the same contracts, so that's the reason why we decided to split that. -- Passos On Tue, Jul 22, 2014 at 12:06 PM, Bruno Oliveira wrote: > Passos, what does aerogear-android-security stands for? Do we really > need the authz module? My question is due to the fact that mostly it > will be together with auth module, but I could be wrong. > > On 2014-07-22, Daniel Passos wrote: > > Hey Guys, > > > > Summers and I started working on agdroid modules and remove some cyclic > > dependencies. So we plan to split the agdroid on these modules: > > > > - aerogear-android-core > > - aerogear-android-pipe > > - aerogear-android-auth > > - aerogear-android-autz > > - aerogear-android-store (with option security dependecy to use > > EncryptedStores) > > - aerogear-android-security > > - aerogear-android-push > > - aerogear-android-push-ups > > - aerogear-android-offline > > > > -- Passos > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140724/6afc435e/attachment.html From daniel at passos.me Thu Jul 24 18:11:59 2014 From: daniel at passos.me (Daniel Passos) Date: Thu, 24 Jul 2014 19:11:59 -0300 Subject: [aerogear-dev] Android Registrations In-Reply-To: <53C7E324.4000700@redhat.com> References: <53C68EAA.3070909@redhat.com> <20140717130048.GA71531@abstractj.org> <53C7E324.4000700@redhat.com> Message-ID: Hi Guys, Here is an example Library: https://github.com/danielpassos/aerogear-android-offline/commit/e89e242dd2231359a8f82477279f9a7cf5bdf59b Usage: https://github.com/danielpassos/aerogear-android-offline-demo/commit/e24962d25db0563f7033d8a704e2987b85e2fd04 -- Passos On Thu, Jul 17, 2014 at 11:52 AM, Summers Pittman wrote: > On 07/17/2014 09:00 AM, Bruno Oliveira wrote: > > Good morning Summers, make sure to assign that Jira for you, please. The > > gist for an Android outsider like me seems ok, but I would like to see > > these changes in at your fork for more context. > > > > Do you have any pointers? > No it is written in Java. > > Right now I am more interested in discussion around the direction of the > changes (in the TODO comments) before I spend a few weeks of time and > get a HUGE PR build up. As such all the implementation is "throw new > NotImplementedException()". But, since it seems like it will help, I > will grab the JIRA ball and link to the gist as well as my current > working repo. > > > > > On 2014-07-16, Summers Pittman wrote: > >> We've mentioned moving from the factory/producer/headache pattern that > >> we currently use (Pipeline, etc) to something more fluent and more > >> maintainable. See this JIRA : > https://issues.jboss.org/browse/AGDROID-259 > >> > >> To that end I've stubbed out some classes and made a strawman set of > >> unit tests for Pipeline : > >> https://gist.github.com/secondsun/8478a5f0527fc97b2456 > >> > >> In the comments of some of the tests I've added questions for the > >> implementation portion of Registrations. > >> > >> The ultimate goal is to make the factories and feature classes(Pipe, > >> AuthModule, etc) flexible enough that circular dependencies can be > >> broken and 1) modularization can happen and 2) feature additions can be > >> quicker and change fewer stable APIs. > >> > >> Comments, questions, and tomatoes are welcome. > >> > >> -- > >> Summers Pittman > >>>> Phone:404 941 4698 > >>>> Java is my crack. > >> _______________________________________________ > >> aerogear-dev mailing list > >> aerogear-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > -- > > > > abstractj > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > -- > Summers Pittman > >>Phone:404 941 4698 > >>Java is my crack. > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140724/6a06d6e0/attachment-0001.html From daniel at passos.me Thu Jul 24 18:13:36 2014 From: daniel at passos.me (Daniel Passos) Date: Thu, 24 Jul 2014 19:13:36 -0300 Subject: [aerogear-dev] [Android] UnifiedPush Registration as a separate module ? In-Reply-To: <8375DB00-7E0D-412C-8A6C-432C4513222E@redhat.com> References: <8375DB00-7E0D-412C-8A6C-432C4513222E@redhat.com> Message-ID: Hey Sebi, We'll do that for 2.0 ;) -- Passos On Wed, Jul 16, 2014 at 2:05 PM, Lucas Holmquist wrote: > the same will probably happen with iOS when adding in safari push > On Jul 16, 2014, at 12:53 PM, Sebastien Blanc wrote: > > Hi ! > This is just an idea (for later/future) I had when I looked at the Amazon > Device Messaging bits (the GCM variant from Amazon). > > Basically it's just Java/Android code : > https://developer.amazon.com/public/apis/engage/device-messaging/tech-docs/04-integrating-your-app-with-adm > > But when we will implement the UPS Amazon library there will be some > duplication (basically the UPS registration process). > > It would be nice if this was extracted into a small module (i.e : > android-unifiedpush-registration) that could be used by the "pure" android > bits (i.e : android-unifiedpush-gcm) and by the Amazon bits > (android-unifiedpush-adm) and maybe later by other system based on Android > but using their own Push infra. > > wdyt ? > > Sebi > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140724/9e3af15f/attachment.html From daniel at passos.me Thu Jul 24 18:27:56 2014 From: daniel at passos.me (Daniel Passos) Date: Thu, 24 Jul 2014 19:27:56 -0300 Subject: [aerogear-dev] News from iOS Modules front In-Reply-To: <78957F0D-27BC-49B8-9F47-5905FA3F55A7@gmail.com> References: <78957F0D-27BC-49B8-9F47-5905FA3F55A7@gmail.com> Message-ID: On Fri, Jul 11, 2014 at 6:20 PM, Corinne Krych wrote: > Hello Guys, > > Last Tuesday during our (favourite) iOS meeting [1] [2] we talked about > modularization. We agreed with Android team modularization is scheduled for > 2.0. > > For iOS we have several actions: > > 1. rename existing repos (too bad we don?t follow well Android convention) > ? aerogear-ios-crypto > ? aerogear-ios-push (thanks passos for the suggestion) > ? aerogear-ios-otp > ? aerogear-ios-xcode-template > ? aerogear-ios-cookbook > > Since we?re talking about renaming, what about dropping ?arerogear? for > the repo name? all those repos belong to aerogear organization anyway. > Maybe removing the aerogear part will stress more the small libraries > aspect. Maybe sth we already discussed but can?t remember/find it. wdyt? > -9001 for dropping ?arerogear? for the repo name > 2. Pipe and Store deprecated. All aerogear-ios we?ll stick to 1.7 version > and will be marked deprecated. > But ?. don?t be scared new modules will replace them: > > ? aerogear-ios-http : Lightweight lib around NSURLSession to ease HTTP > calls with pluggable request and response Serializers. Very very Draft > version [3] with some cookbook recipe [4]. With this module we will work > directly with NSURLSession (iOS foundation networking) instead of using > AFNetworking. Sure Andrea will like it: no dependency :) > ? aerogear-ios-oauth2 : dependent on aerogear-ios-http, bring all the good > stuff like AccountManager, OAuth2 extensible adapters, fluid http post/get > ... > ? aerogear-ios-storage usage of incrementalStorage to plug into Core Data > Very nice! > Those modules will be written in Swift code. We?ll test them both in iOS7 > and iOS8. > Sorry but It's not clear for me. We'll not support Objective-C for that? Or will support both? > 3. Cookbook recipes rpo > ? tag our repo 1.7: we didn?t have a tag strategy for cookbook demos but > with the move from 1.X to 2.) I think we should > * Swift demo naming convention add ?-swift? for Swift version like we did > [5]. We should also append ?-objc? to other recipes to be consistent. > > 4. Differentiate Swift vs Objective-C libs > How to differenctiate Swift code. Specially for aerogear-ios-push which > will be declined in 2 versions? One suggestion from Matthias was to have 2 > separate branches. > master -> objc-c > until iOS8 is released and stable. > I?m +1 with that idea. > Agreed with that for now Let me know if you have suggestions/objections. When we reach an agreement, > I?ll create associated JIRA. > > ++ > Corinne > > [1] http://oksoclap.com/p/aerogear_ios_meeting_01072014 > [2] > http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2014/aerogear.2014-07-08-11.42.txt > [3] https://github.com/corinnekrych/aerogear-ios-http > [4] https://github.com/corinnekrych/Weather > [5] > https://github.com/aerogear/aerogear-push-helloworld/tree/master/ios-swift -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140724/d336d764/attachment.html From matzew at apache.org Fri Jul 25 02:04:27 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Fri, 25 Jul 2014 08:04:27 +0200 Subject: [aerogear-dev] Android Registrations In-Reply-To: <53C68EAA.3070909@redhat.com> References: <53C68EAA.3070909@redhat.com> Message-ID: On Wed, Jul 16, 2014 at 4:39 PM, Summers Pittman wrote: > We've mentioned moving from the factory/producer/headache pattern that > we currently use (Pipeline, etc) to something more fluent and more > maintainable. See this JIRA : https://issues.jboss.org/browse/AGDROID-259 > > To that end I've stubbed out some classes and made a strawman set of > unit tests for Pipeline : > https://gist.github.com/secondsun/8478a5f0527fc97b2456 that reads pretty nice! .withUrl(url).module(basicModule).forClass(Data.class); like it! > > > In the comments of some of the tests I've added questions for the > implementation portion of Registrations. > > The ultimate goal is to make the factories and feature classes(Pipe, > AuthModule, etc) flexible enough that circular dependencies can be > broken and 1) modularization can happen and 2) feature additions can be > quicker and change fewer stable APIs. > > Comments, questions, and tomatoes are welcome. > > -- > Summers Pittman > >>Phone:404 941 4698 > >>Java is my crack. > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140725/5e8d668b/attachment.html From cvasilak at gmail.com Fri Jul 25 02:55:30 2014 From: cvasilak at gmail.com (Christos Vasilakis) Date: Fri, 25 Jul 2014 09:55:30 +0300 Subject: [aerogear-dev] News from iOS Modules front In-Reply-To: References: <78957F0D-27BC-49B8-9F47-5905FA3F55A7@gmail.com> Message-ID: Thanks for your feedback Passos, On Jul 25, 2014, at 1:27 AM, Daniel Passos wrote: > On Fri, Jul 11, 2014 at 6:20 PM, Corinne Krych wrote: > Hello Guys, > > Last Tuesday during our (favourite) iOS meeting [1] [2] we talked about modularization. We agreed with Android team modularization is scheduled for 2.0. > > For iOS we have several actions: > > 1. rename existing repos (too bad we don?t follow well Android convention) > ? aerogear-ios-crypto > ? aerogear-ios-push (thanks passos for the suggestion) > ? aerogear-ios-otp > ? aerogear-ios-xcode-template > ? aerogear-ios-cookbook > > Since we?re talking about renaming, what about dropping ?arerogear? for the repo name? all those repos belong to aerogear organization anyway. Maybe removing the aerogear part will stress more the small libraries aspect. Maybe sth we already discussed but can?t remember/find it. wdyt? > > -9001 for dropping ?arerogear? for the repo name > > 2. Pipe and Store deprecated. All aerogear-ios we?ll stick to 1.7 version and will be marked deprecated. > But ?. don?t be scared new modules will replace them: > > ? aerogear-ios-http : Lightweight lib around NSURLSession to ease HTTP calls with pluggable request and response Serializers. Very very Draft version [3] with some cookbook recipe [4]. With this module we will work directly with NSURLSession (iOS foundation networking) instead of using AFNetworking. Sure Andrea will like it: no dependency :) > ? aerogear-ios-oauth2 : dependent on aerogear-ios-http, bring all the good stuff like AccountManager, OAuth2 extensible adapters, fluid http post/get ... > ? aerogear-ios-storage usage of incrementalStorage to plug into Core Data > > Very nice! > > Those modules will be written in Swift code. We?ll test them both in iOS7 and iOS8. > Sorry but It's not clear for me. We'll not support Objective-C for that? Or will support both? we will _aim_ to support objc-c apps that will try to use our fwks written in Swift. Although there is some great interoperability between the two languages, there are things that need be taken into account when obj-c code accesses swift code (and vice versa) (more information can be found here [1]) Our belief, is that any _new_ fwk is about to head start today, its can be based on Swift. At the end as Apple has stated: {quote} Swift is ready to use today, in brand new apps or alongside your proven Objective-C code. We have big plans for the Swift language, including improvements to syntax, and powerful new features.? {quote} Thanks, Christos [1] https://developer.apple.com/library/prerelease/ios/documentation/Swift/Conceptual/BuildingCocoaApps/MixandMatch.html#//apple_ref/doc/uid/TP40014216-CH10-XID_74 > > 3. Cookbook recipes rpo > ? tag our repo 1.7: we didn?t have a tag strategy for cookbook demos but with the move from 1.X to 2.) I think we should > * Swift demo naming convention add ?-swift? for Swift version like we did [5]. We should also append ?-objc? to other recipes to be consistent. > > 4. Differentiate Swift vs Objective-C libs > How to differenctiate Swift code. Specially for aerogear-ios-push which will be declined in 2 versions? One suggestion from Matthias was to have 2 separate branches. > master -> objc-c > until iOS8 is released and stable. > I?m +1 with that idea. > > Agreed with that for now > > Let me know if you have suggestions/objections. When we reach an agreement, I?ll create associated JIRA. > > ++ > Corinne > > [1] http://oksoclap.com/p/aerogear_ios_meeting_01072014 > [2] http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2014/aerogear.2014-07-08-11.42.txt > [3] https://github.com/corinnekrych/aerogear-ios-http > [4] https://github.com/corinnekrych/Weather > [5] https://github.com/aerogear/aerogear-push-helloworld/tree/master/ios-swift > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140725/9ed63dab/attachment-0001.html From matzew at apache.org Fri Jul 25 03:09:37 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Fri, 25 Jul 2014 09:09:37 +0200 Subject: [aerogear-dev] Modularizing the Android Library In-Reply-To: References: <5317317F.1010209@redhat.com> <20140306143829.65e1e4aa@kapy-ntb-x220> <20140508192800.GB69433@abstractj.org> <4CD71A7A-EDE1-4648-AB3E-E4DDB383D824@gmail.com> Message-ID: On Tue, Jul 22, 2014 at 4:12 PM, Daniel Passos wrote: > Hey Guys, > > Summers and I started working on agdroid modules and remove some cyclic > dependencies. So we plan to split the agdroid on these modules: > > - aerogear-android-core > - aerogear-android-pipe > - aerogear-android-auth > - aerogear-android-autz > - aerogear-android-store (with option security dependecy to use > EncryptedStores) > - aerogear-android-security > - aerogear-android-push > > is that for, SimplePush (I think summers did a poc there) and straight GCM ? > > - aerogear-android-push-ups > - aerogear-android-offline > > -- Passos > ? > > > On Fri, May 9, 2014 at 3:55 AM, Corinne Krych > wrote: > >> Oops >> [2] https://issues.jboss.org/browse/AGIOS-187 >> >> On 09 May 2014, at 08:52, Corinne Krych wrote: >> >> > [2] https://issues.jboss.org/browse/AGIOS-192 >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140725/657bc407/attachment.html From matzew at apache.org Fri Jul 25 03:13:52 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Fri, 25 Jul 2014 09:13:52 +0200 Subject: [aerogear-dev] News from iOS Modules front In-Reply-To: <78957F0D-27BC-49B8-9F47-5905FA3F55A7@gmail.com> References: <78957F0D-27BC-49B8-9F47-5905FA3F55A7@gmail.com> Message-ID: On Fri, Jul 11, 2014 at 11:20 PM, Corinne Krych wrote: > Hello Guys, > > Last Tuesday during our (favourite) iOS meeting [1] [2] we talked about > modularization. We agreed with Android team modularization is scheduled for > 2.0. > > For iOS we have several actions: > > 1. rename existing repos (too bad we don?t follow well Android convention) > ? aerogear-ios-crypto > ? aerogear-ios-push (thanks passos for the suggestion) > ? aerogear-ios-otp > ? aerogear-ios-xcode-template > ? aerogear-ios-cookbook > > Since we?re talking about renaming, what about dropping ?arerogear? for > the repo name? +1 makes sense > all those repos belong to aerogear organization anyway. Maybe removing the > aerogear part will stress more the small libraries aspect. Maybe sth we > already discussed but can?t remember/find it. wdyt? > > 2. Pipe and Store deprecated. All aerogear-ios we?ll stick to 1.7 version > and will be marked deprecated. > But ?. don?t be scared new modules will replace them: > > ? aerogear-ios-http : Lightweight lib around NSURLSession to ease HTTP > calls with pluggable request and response Serializers. Very very Draft > version [3] with some cookbook recipe [4]. With this module we will work > directly with NSURLSession (iOS foundation networking) instead of using > AFNetworking. Sure Andrea will like it: no dependency :) > ? aerogear-ios-oauth2 : dependent on aerogear-ios-http, bring all the good > stuff like AccountManager, OAuth2 extensible adapters, fluid http post/get > ... > ? aerogear-ios-storage usage of incrementalStorage to plug into Core Data > +1 all of that sounds awesome! > > Those modules will be written in Swift code. We?ll test them both in iOS7 > and iOS8. > +1 on Swift! > > 3. Cookbook recipes rpo > ? tag our repo 1.7: we didn?t have a tag strategy for cookbook demos but > with the move from 1.X to 2.) I think we should > * Swift demo naming convention add ?-swift? for Swift version like we did > [5]. We should also append ?-objc? to other recipes to be consistent. > yeah > > 4. Differentiate Swift vs Objective-C libs > How to differenctiate Swift code. Specially for aerogear-ios-push which > will be declined in 2 versions? One suggestion from Matthias was to have 2 > separate branches. > master -> objc-c > until iOS8 is released and stable. > I?m +1 with that idea. > yeah, let's have ObjC on master now; The master can, later this year, contain the Swift lib, and we move ObjC to be deprecated as soon as we do have iOS8 (~September) > > Let me know if you have suggestions/objections. When we reach an > agreement, I?ll create associated JIRA. > > ++ > Corinne > > [1] http://oksoclap.com/p/aerogear_ios_meeting_01072014 > [2] > http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2014/aerogear.2014-07-08-11.42.txt > [3] https://github.com/corinnekrych/aerogear-ios-http > [4] https://github.com/corinnekrych/Weather > [5] > https://github.com/aerogear/aerogear-push-helloworld/tree/master/ios-swift > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140725/816c4d15/attachment.html From corinnekrych at gmail.com Fri Jul 25 03:37:44 2014 From: corinnekrych at gmail.com (Corinne Krych) Date: Fri, 25 Jul 2014 09:37:44 +0200 Subject: [aerogear-dev] News from iOS Modules front In-Reply-To: References: <78957F0D-27BC-49B8-9F47-5905FA3F55A7@gmail.com> Message-ID: On 25 Jul 2014, at 09:13, Matthias Wessendorf wrote: > > > > On Fri, Jul 11, 2014 at 11:20 PM, Corinne Krych wrote: > Hello Guys, > > Last Tuesday during our (favourite) iOS meeting [1] [2] we talked about modularization. We agreed with Android team modularization is scheduled for 2.0. > > For iOS we have several actions: > > 1. rename existing repos (too bad we don?t follow well Android convention) > ? aerogear-ios-crypto > ? aerogear-ios-push (thanks passos for the suggestion) > ? aerogear-ios-otp > ? aerogear-ios-xcode-template > ? aerogear-ios-cookbook > > Since we?re talking about renaming, what about dropping ?arerogear? for the repo name? > > +1 makes sense It looks like we don?t have the same view here. Obviously if we go renaming we will have to change all the repos. With or without, coonsistency is key. My main motivation for dropping aerogear prefex was that ag is already present in the name of the organisation. Besides as we go with fine grained modularisation, our libs can be used independently, the naming without prefix is to enforce that. @passos and all others guys not in favor for dropping prefix, may I ask why? > > all those repos belong to aerogear organization anyway. Maybe removing the aerogear part will stress more the small libraries aspect. Maybe sth we already discussed but can?t remember/find it. wdyt? > > 2. Pipe and Store deprecated. All aerogear-ios we?ll stick to 1.7 version and will be marked deprecated. > But ?. don?t be scared new modules will replace them: > > ? aerogear-ios-http : Lightweight lib around NSURLSession to ease HTTP calls with pluggable request and response Serializers. Very very Draft version [3] with some cookbook recipe [4]. With this module we will work directly with NSURLSession (iOS foundation networking) instead of using AFNetworking. Sure Andrea will like it: no dependency :) > ? aerogear-ios-oauth2 : dependent on aerogear-ios-http, bring all the good stuff like AccountManager, OAuth2 extensible adapters, fluid http post/get ... > ? aerogear-ios-storage usage of incrementalStorage to plug into Core Data > > > +1 all of that sounds awesome! > > > Those modules will be written in Swift code. We?ll test them both in iOS7 and iOS8. > > +1 on Swift! > > > 3. Cookbook recipes rpo > ? tag our repo 1.7: we didn?t have a tag strategy for cookbook demos but with the move from 1.X to 2.) I think we should > * Swift demo naming convention add ?-swift? for Swift version like we did [5]. We should also append ?-objc? to other recipes to be consistent. > > yeah > > > 4. Differentiate Swift vs Objective-C libs > How to differenctiate Swift code. Specially for aerogear-ios-push which will be declined in 2 versions? One suggestion from Matthias was to have 2 separate branches. > master -> objc-c > until iOS8 is released and stable. > I?m +1 with that idea. > > yeah, let's have ObjC on master now; > The master can, later this year, contain the Swift lib, and we move ObjC to be deprecated as soon as we do have iOS8 (~September) > > > Let me know if you have suggestions/objections. When we reach an agreement, I?ll create associated JIRA. > > ++ > Corinne > > [1] http://oksoclap.com/p/aerogear_ios_meeting_01072014 > [2] http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2014/aerogear.2014-07-08-11.42.txt > [3] https://github.com/corinnekrych/aerogear-ios-http > [4] https://github.com/corinnekrych/Weather > [5] https://github.com/aerogear/aerogear-push-helloworld/tree/master/ios-swift > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev From daniel.bevenius at gmail.com Fri Jul 25 03:41:11 2014 From: daniel.bevenius at gmail.com (Daniel Bevenius) Date: Fri, 25 Jul 2014 09:41:11 +0200 Subject: [aerogear-dev] News from iOS Modules front In-Reply-To: References: <78957F0D-27BC-49B8-9F47-5905FA3F55A7@gmail.com> Message-ID: >Since we?re talking about renaming, what about dropping ?arerogear? for the repo name? +1 on dropping the aerogear prefix on the repos. On 25 July 2014 09:37, Corinne Krych wrote: > > On 25 Jul 2014, at 09:13, Matthias Wessendorf wrote: > > > > > > > > > On Fri, Jul 11, 2014 at 11:20 PM, Corinne Krych > wrote: > > Hello Guys, > > > > Last Tuesday during our (favourite) iOS meeting [1] [2] we talked about > modularization. We agreed with Android team modularization is scheduled for > 2.0. > > > > For iOS we have several actions: > > > > 1. rename existing repos (too bad we don?t follow well Android > convention) > > ? aerogear-ios-crypto > > ? aerogear-ios-push (thanks passos for the suggestion) > > ? aerogear-ios-otp > > ? aerogear-ios-xcode-template > > ? aerogear-ios-cookbook > > > > Since we?re talking about renaming, what about dropping ?arerogear? for > the repo name? > > > > +1 makes sense > > > It looks like we don?t have the same view here. Obviously if we go > renaming we will have to change all the repos. With or without, > coonsistency is key. > > My main motivation for dropping aerogear prefex was that ag is already > present in the name of the organisation. Besides as we go with fine grained > modularisation, our libs can be used independently, the naming without > prefix is to enforce that. > > @passos and all others guys not in favor for dropping prefix, may I ask > why? > > > > > > all those repos belong to aerogear organization anyway. Maybe removing > the aerogear part will stress more the small libraries aspect. Maybe sth we > already discussed but can?t remember/find it. wdyt? > > > > 2. Pipe and Store deprecated. All aerogear-ios we?ll stick to 1.7 > version and will be marked deprecated. > > But ?. don?t be scared new modules will replace them: > > > > ? aerogear-ios-http : Lightweight lib around NSURLSession to ease HTTP > calls with pluggable request and response Serializers. Very very Draft > version [3] with some cookbook recipe [4]. With this module we will work > directly with NSURLSession (iOS foundation networking) instead of using > AFNetworking. Sure Andrea will like it: no dependency :) > > ? aerogear-ios-oauth2 : dependent on aerogear-ios-http, bring all the > good stuff like AccountManager, OAuth2 extensible adapters, fluid http > post/get ... > > ? aerogear-ios-storage usage of incrementalStorage to plug into Core Data > > > > > > +1 all of that sounds awesome! > > > > > > Those modules will be written in Swift code. We?ll test them both in > iOS7 and iOS8. > > > > +1 on Swift! > > > > > > 3. Cookbook recipes rpo > > ? tag our repo 1.7: we didn?t have a tag strategy for cookbook demos but > with the move from 1.X to 2.) I think we should > > * Swift demo naming convention add ?-swift? for Swift version like we > did [5]. We should also append ?-objc? to other recipes to be consistent. > > > > yeah > > > > > > 4. Differentiate Swift vs Objective-C libs > > How to differenctiate Swift code. Specially for aerogear-ios-push which > will be declined in 2 versions? One suggestion from Matthias was to have 2 > separate branches. > > master -> objc-c > > until iOS8 is released and stable. > > I?m +1 with that idea. > > > > yeah, let's have ObjC on master now; > > The master can, later this year, contain the Swift lib, and we move ObjC > to be deprecated as soon as we do have iOS8 (~September) > > > > > > Let me know if you have suggestions/objections. When we reach an > agreement, I?ll create associated JIRA. > > > > ++ > > Corinne > > > > [1] http://oksoclap.com/p/aerogear_ios_meeting_01072014 > > [2] > http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2014/aerogear.2014-07-08-11.42.txt > > [3] https://github.com/corinnekrych/aerogear-ios-http > > [4] https://github.com/corinnekrych/Weather > > [5] > https://github.com/aerogear/aerogear-push-helloworld/tree/master/ios-swift > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > > > > -- > > Matthias Wessendorf > > > > blog: http://matthiaswessendorf.wordpress.com/ > > sessions: http://www.slideshare.net/mwessendorf > > twitter: http://twitter.com/mwessendorf > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140725/94208d01/attachment-0001.html From scm.blanc at gmail.com Fri Jul 25 03:46:12 2014 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Fri, 25 Jul 2014 09:46:12 +0200 Subject: [aerogear-dev] News from iOS Modules front In-Reply-To: References: <78957F0D-27BC-49B8-9F47-5905FA3F55A7@gmail.com> Message-ID: On Fri, Jul 25, 2014 at 9:37 AM, Corinne Krych wrote: > > On 25 Jul 2014, at 09:13, Matthias Wessendorf wrote: > > > > > > > > > On Fri, Jul 11, 2014 at 11:20 PM, Corinne Krych > wrote: > > Hello Guys, > > > > Last Tuesday during our (favourite) iOS meeting [1] [2] we talked about > modularization. We agreed with Android team modularization is scheduled for > 2.0. > > > > For iOS we have several actions: > > > > 1. rename existing repos (too bad we don?t follow well Android > convention) > > ? aerogear-ios-crypto > > ? aerogear-ios-push (thanks passos for the suggestion) > > ? aerogear-ios-otp > > ? aerogear-ios-xcode-template > > ? aerogear-ios-cookbook > > > > Since we?re talking about renaming, what about dropping ?arerogear? for > the repo name? > > > > +1 makes sense > > > It looks like we don?t have the same view here. Obviously if we go > renaming we will have to change all the repos. With or without, > coonsistency is key. > > My main motivation for dropping aerogear prefex was that ag is already > present in the name of the organisation. Besides as we go with fine grained > modularisation, our libs can be used independently, the naming without > prefix is to enforce that. > > @passos and all others guys not in favor for dropping prefix, may I ask > why? > If we put GH and organization appart, will the name "AeroGear" appears anywhere in the lib name/pod when someone install it through cocoapods ? > > > > > > all those repos belong to aerogear organization anyway. Maybe removing > the aerogear part will stress more the small libraries aspect. Maybe sth we > already discussed but can?t remember/find it. wdyt? > > > > 2. Pipe and Store deprecated. All aerogear-ios we?ll stick to 1.7 > version and will be marked deprecated. > > But ?. don?t be scared new modules will replace them: > > > > ? aerogear-ios-http : Lightweight lib around NSURLSession to ease HTTP > calls with pluggable request and response Serializers. Very very Draft > version [3] with some cookbook recipe [4]. With this module we will work > directly with NSURLSession (iOS foundation networking) instead of using > AFNetworking. Sure Andrea will like it: no dependency :) > > ? aerogear-ios-oauth2 : dependent on aerogear-ios-http, bring all the > good stuff like AccountManager, OAuth2 extensible adapters, fluid http > post/get ... > > ? aerogear-ios-storage usage of incrementalStorage to plug into Core Data > > > > > > +1 all of that sounds awesome! > > > > > > Those modules will be written in Swift code. We?ll test them both in > iOS7 and iOS8. > > > > +1 on Swift! > > > > > > 3. Cookbook recipes rpo > > ? tag our repo 1.7: we didn?t have a tag strategy for cookbook demos but > with the move from 1.X to 2.) I think we should > > * Swift demo naming convention add ?-swift? for Swift version like we > did [5]. We should also append ?-objc? to other recipes to be consistent. > > > > yeah > > > > > > 4. Differentiate Swift vs Objective-C libs > > How to differenctiate Swift code. Specially for aerogear-ios-push which > will be declined in 2 versions? One suggestion from Matthias was to have 2 > separate branches. > > master -> objc-c > > until iOS8 is released and stable. > > I?m +1 with that idea. > > > > yeah, let's have ObjC on master now; > > The master can, later this year, contain the Swift lib, and we move ObjC > to be deprecated as soon as we do have iOS8 (~September) > > > > > > Let me know if you have suggestions/objections. When we reach an > agreement, I?ll create associated JIRA. > > > > ++ > > Corinne > > > > [1] http://oksoclap.com/p/aerogear_ios_meeting_01072014 > > [2] > http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2014/aerogear.2014-07-08-11.42.txt > > [3] https://github.com/corinnekrych/aerogear-ios-http > > [4] https://github.com/corinnekrych/Weather > > [5] > https://github.com/aerogear/aerogear-push-helloworld/tree/master/ios-swift > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > > > > -- > > Matthias Wessendorf > > > > blog: http://matthiaswessendorf.wordpress.com/ > > sessions: http://www.slideshare.net/mwessendorf > > twitter: http://twitter.com/mwessendorf > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140725/3041c635/attachment.html From corinnekrych at gmail.com Fri Jul 25 03:50:14 2014 From: corinnekrych at gmail.com (Corinne Krych) Date: Fri, 25 Jul 2014 09:50:14 +0200 Subject: [aerogear-dev] News from iOS Modules front In-Reply-To: References: <78957F0D-27BC-49B8-9F47-5905FA3F55A7@gmail.com> Message-ID: <96E5A52E-9917-4AFA-81C1-464D036DABD5@gmail.com> On 25 Jul 2014, at 09:46, Sebastien Blanc wrote: > > > > On Fri, Jul 25, 2014 at 9:37 AM, Corinne Krych wrote: > > On 25 Jul 2014, at 09:13, Matthias Wessendorf wrote: > > > > > > > > > On Fri, Jul 11, 2014 at 11:20 PM, Corinne Krych wrote: > > Hello Guys, > > > > Last Tuesday during our (favourite) iOS meeting [1] [2] we talked about modularization. We agreed with Android team modularization is scheduled for 2.0. > > > > For iOS we have several actions: > > > > 1. rename existing repos (too bad we don?t follow well Android convention) > > ? aerogear-ios-crypto > > ? aerogear-ios-push (thanks passos for the suggestion) > > ? aerogear-ios-otp > > ? aerogear-ios-xcode-template > > ? aerogear-ios-cookbook > > > > Since we?re talking about renaming, what about dropping ?arerogear? for the repo name? > > > > +1 makes sense > > > It looks like we don?t have the same view here. Obviously if we go renaming we will have to change all the repos. With or without, coonsistency is key. > > My main motivation for dropping aerogear prefex was that ag is already present in the name of the organisation. Besides as we go with fine grained modularisation, our libs can be used independently, the naming without prefix is to enforce that. > > @passos and all others guys not in favor for dropping prefix, may I ask why? > > If we put GH and organization appart, will the name "AeroGear" appears anywhere in the lib name/pod when someone install it through cocoapods ? > Yeap we?ll keep aerogear as a prefix for cocoapods https://github.com/aerogear/aerogear-otp-ios/blob/master/AeroGear-OTP.podspec#L18 Good question: What about the other modules? > > > > > > all those repos belong to aerogear organization anyway. Maybe removing the aerogear part will stress more the small libraries aspect. Maybe sth we already discussed but can?t remember/find it. wdyt? > > > > 2. Pipe and Store deprecated. All aerogear-ios we?ll stick to 1.7 version and will be marked deprecated. > > But ?. don?t be scared new modules will replace them: > > > > ? aerogear-ios-http : Lightweight lib around NSURLSession to ease HTTP calls with pluggable request and response Serializers. Very very Draft version [3] with some cookbook recipe [4]. With this module we will work directly with NSURLSession (iOS foundation networking) instead of using AFNetworking. Sure Andrea will like it: no dependency :) > > ? aerogear-ios-oauth2 : dependent on aerogear-ios-http, bring all the good stuff like AccountManager, OAuth2 extensible adapters, fluid http post/get ... > > ? aerogear-ios-storage usage of incrementalStorage to plug into Core Data > > > > > > +1 all of that sounds awesome! > > > > > > Those modules will be written in Swift code. We?ll test them both in iOS7 and iOS8. > > > > +1 on Swift! > > > > > > 3. Cookbook recipes rpo > > ? tag our repo 1.7: we didn?t have a tag strategy for cookbook demos but with the move from 1.X to 2.) I think we should > > * Swift demo naming convention add ?-swift? for Swift version like we did [5]. We should also append ?-objc? to other recipes to be consistent. > > > > yeah > > > > > > 4. Differentiate Swift vs Objective-C libs > > How to differenctiate Swift code. Specially for aerogear-ios-push which will be declined in 2 versions? One suggestion from Matthias was to have 2 separate branches. > > master -> objc-c > > until iOS8 is released and stable. > > I?m +1 with that idea. > > > > yeah, let's have ObjC on master now; > > The master can, later this year, contain the Swift lib, and we move ObjC to be deprecated as soon as we do have iOS8 (~September) > > > > > > Let me know if you have suggestions/objections. When we reach an agreement, I?ll create associated JIRA. > > > > ++ > > Corinne > > > > [1] http://oksoclap.com/p/aerogear_ios_meeting_01072014 > > [2] http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2014/aerogear.2014-07-08-11.42.txt > > [3] https://github.com/corinnekrych/aerogear-ios-http > > [4] https://github.com/corinnekrych/Weather > > [5] https://github.com/aerogear/aerogear-push-helloworld/tree/master/ios-swift > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > > > > -- > > Matthias Wessendorf > > > > blog: http://matthiaswessendorf.wordpress.com/ > > sessions: http://www.slideshare.net/mwessendorf > > twitter: http://twitter.com/mwessendorf > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev From tkriz at redhat.com Fri Jul 25 04:32:04 2014 From: tkriz at redhat.com (Tadeas Kriz) Date: Fri, 25 Jul 2014 10:32:04 +0200 Subject: [aerogear-dev] Differences between Firefox OS "native" Push lib and AeroGear's Push adapter In-Reply-To: <1406216640.15307.0@smtp.corp.redhat.com> References: <9B70BDB9-4774-4BF0-9FF7-5213185E4F52@redhat.com> <51C9D854-0730-4B2A-9A92-9DC92649947D@redhat.com> <8AEB32A5-0F61-495B-8EA5-767F48312B9C@redhat.com> <28EA872A-87E3-4035-9C63-DA04EF034580! !@redhat.com> <02064329-0F9B-49DC-A5EC-A106001DD51F@redhat.com> <1406216640.15307.0@smtp.corp.redhat.com> Message-ID: <1E3E76E8-60D7-4BF3-9B95-6C58F4DC9286@redhat.com> ? Tadeas Kriz On 24 Jul 2014, at 05:44 pm, Karel Piwko wrote: > On Thu, Jul 24, 2014 at 3:28 PM, Tadeas Kriz wrote: >> >> It should not. For hibernate, it?s just a string like any other. >> The problem might be in the configuration of JAX.RS/RestEasy. If >> I?ll have some time today evening, I?ll try to fix it, it should >> be an easy fix. > > Last famous words? ;-) > I shall never say ?an easy fix? again. > But I agree. Everything is string and URL encode should happen on > client while server should automatically decode and work always with > just decoded string. If we need to encode twice, something is wrong. > Anyway, the 400 Bad request response is made by the tomcat itself, disallowing the use of %2F as a path parameter. This will probably apply on other web containers. Possible solutions with their disadvantages: 1. well-documented double-encoding of the URL (might be confusing) 2. use @QueryParam instead of @PathParam (breaks the api consistence, as every other call would still use @PathParam) 3. allow @QueryParam (again, breaks the api consistence, but only for the SimplePush) 4. find another encoding (Base64 for URL = URLEncode then Base64 encode) 5. don?t use the url as a deviceToken (might not comply with Mozzila?s SimplePush specs) What do you think guys? >> >> > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev From bruno at abstractj.org Fri Jul 25 04:33:24 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Fri, 25 Jul 2014 05:33:24 -0300 Subject: [aerogear-dev] AeroGear Crypto Java 0.1.4 Staged In-Reply-To: References: <20140722104220.GA42479@abstractj.org> Message-ID: <20140725083324.GC25297@abstractj.org> AG Crypto was released on nexus, now is just the matter of wait for the sync with Maven Central. On 2014-07-22, Matthias Wessendorf wrote: > +1 on this release! > > (have tested and build the tag) > > -M > > > On Tue, Jul 22, 2014 at 12:42 PM, Bruno Oliveira > wrote: > > > Good morning peeps, > > > > AeroGear Crypto 0.1.4 was staged today for testing at > > > > https://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-3599 > > . > > The major changes relates to PKCS validation, borrowed from AG > > Security > > -- > > > > abstractj > > PGP: 0x84DC9914 > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -- abstractj PGP: 0x84DC9914 From matzew at apache.org Fri Jul 25 04:56:47 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Fri, 25 Jul 2014 10:56:47 +0200 Subject: [aerogear-dev] AeroGear Crypto Java 0.1.4 Staged In-Reply-To: <20140725083324.GC25297@abstractj.org> References: <20140722104220.GA42479@abstractj.org> <20140725083324.GC25297@abstractj.org> Message-ID: yay! On Fri, Jul 25, 2014 at 10:33 AM, Bruno Oliveira wrote: > AG Crypto was released on nexus, now is just the matter of wait for the > sync with Maven Central. > > On 2014-07-22, Matthias Wessendorf wrote: > > +1 on this release! > > > > (have tested and build the tag) > > > > -M > > > > > > On Tue, Jul 22, 2014 at 12:42 PM, Bruno Oliveira > > wrote: > > > > > Good morning peeps, > > > > > > AeroGear Crypto 0.1.4 was staged today for testing at > > > > > > > https://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-3599 > > > . > > > The major changes relates to PKCS validation, borrowed from AG > > > Security > > > -- > > > > > > abstractj > > > PGP: 0x84DC9914 > > > _______________________________________________ > > > aerogear-dev mailing list > > > aerogear-dev at lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > > > > > > > -- > > Matthias Wessendorf > > > > blog: http://matthiaswessendorf.wordpress.com/ > > sessions: http://www.slideshare.net/mwessendorf > > twitter: http://twitter.com/mwessendorf > > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > -- > > abstractj > PGP: 0x84DC9914 > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140725/163a0a24/attachment.html From matzew at apache.org Fri Jul 25 04:58:24 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Fri, 25 Jul 2014 10:58:24 +0200 Subject: [aerogear-dev] News from iOS Modules front In-Reply-To: <96E5A52E-9917-4AFA-81C1-464D036DABD5@gmail.com> References: <78957F0D-27BC-49B8-9F47-5905FA3F55A7@gmail.com> <96E5A52E-9917-4AFA-81C1-464D036DABD5@gmail.com> Message-ID: On Fri, Jul 25, 2014 at 9:50 AM, Corinne Krych wrote: > > On 25 Jul 2014, at 09:46, Sebastien Blanc wrote: > > > > > > > > > On Fri, Jul 25, 2014 at 9:37 AM, Corinne Krych > wrote: > > > > On 25 Jul 2014, at 09:13, Matthias Wessendorf wrote: > > > > > > > > > > > > > > On Fri, Jul 11, 2014 at 11:20 PM, Corinne Krych < > corinnekrych at gmail.com> wrote: > > > Hello Guys, > > > > > > Last Tuesday during our (favourite) iOS meeting [1] [2] we talked > about modularization. We agreed with Android team modularization is > scheduled for 2.0. > > > > > > For iOS we have several actions: > > > > > > 1. rename existing repos (too bad we don?t follow well Android > convention) > > > ? aerogear-ios-crypto > > > ? aerogear-ios-push (thanks passos for the suggestion) > > > ? aerogear-ios-otp > > > ? aerogear-ios-xcode-template > > > ? aerogear-ios-cookbook > > > > > > Since we?re talking about renaming, what about dropping ?arerogear? > for the repo name? > > > > > > +1 makes sense > > > > > > It looks like we don?t have the same view here. Obviously if we go > renaming we will have to change all the repos. With or without, > coonsistency is key. > > > > My main motivation for dropping aerogear prefex was that ag is already > present in the name of the organisation. Besides as we go with fine grained > modularisation, our libs can be used independently, the naming without > prefix is to enforce that. > > > > @passos and all others guys not in favor for dropping prefix, may I ask > why? > > > > If we put GH and organization appart, will the name "AeroGear" appears > anywhere in the lib name/pod when someone install it through cocoapods ? > > > > Yeap we?ll keep aerogear as a prefix for cocoapods > > https://github.com/aerogear/aerogear-otp-ios/blob/master/AeroGear-OTP.podspec#L18 > > Good question: What about the other modules? > hrm, yeah .... I am bit concerned there.... perhaps.... not sure, keep the aerogear ? but yeah it feels duplicated ... > > > > > > > > > > > all those repos belong to aerogear organization anyway. Maybe removing > the aerogear part will stress more the small libraries aspect. Maybe sth we > already discussed but can?t remember/find it. wdyt? > > > > > > 2. Pipe and Store deprecated. All aerogear-ios we?ll stick to 1.7 > version and will be marked deprecated. > > > But ?. don?t be scared new modules will replace them: > > > > > > ? aerogear-ios-http : Lightweight lib around NSURLSession to ease HTTP > calls with pluggable request and response Serializers. Very very Draft > version [3] with some cookbook recipe [4]. With this module we will work > directly with NSURLSession (iOS foundation networking) instead of using > AFNetworking. Sure Andrea will like it: no dependency :) > > > ? aerogear-ios-oauth2 : dependent on aerogear-ios-http, bring all the > good stuff like AccountManager, OAuth2 extensible adapters, fluid http > post/get ... > > > ? aerogear-ios-storage usage of incrementalStorage to plug into Core > Data > > > > > > > > > +1 all of that sounds awesome! > > > > > > > > > Those modules will be written in Swift code. We?ll test them both in > iOS7 and iOS8. > > > > > > +1 on Swift! > > > > > > > > > 3. Cookbook recipes rpo > > > ? tag our repo 1.7: we didn?t have a tag strategy for cookbook demos > but with the move from 1.X to 2.) I think we should > > > * Swift demo naming convention add ?-swift? for Swift version like we > did [5]. We should also append ?-objc? to other recipes to be consistent. > > > > > > yeah > > > > > > > > > 4. Differentiate Swift vs Objective-C libs > > > How to differenctiate Swift code. Specially for aerogear-ios-push > which will be declined in 2 versions? One suggestion from Matthias was to > have 2 separate branches. > > > master -> objc-c > > > until iOS8 is released and stable. > > > I?m +1 with that idea. > > > > > > yeah, let's have ObjC on master now; > > > The master can, later this year, contain the Swift lib, and we move > ObjC to be deprecated as soon as we do have iOS8 (~September) > > > > > > > > > Let me know if you have suggestions/objections. When we reach an > agreement, I?ll create associated JIRA. > > > > > > ++ > > > Corinne > > > > > > [1] http://oksoclap.com/p/aerogear_ios_meeting_01072014 > > > [2] > http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2014/aerogear.2014-07-08-11.42.txt > > > [3] https://github.com/corinnekrych/aerogear-ios-http > > > [4] https://github.com/corinnekrych/Weather > > > [5] > https://github.com/aerogear/aerogear-push-helloworld/tree/master/ios-swift > > > _______________________________________________ > > > aerogear-dev mailing list > > > aerogear-dev at lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > > > > > > > > -- > > > Matthias Wessendorf > > > > > > blog: http://matthiaswessendorf.wordpress.com/ > > > sessions: http://www.slideshare.net/mwessendorf > > > twitter: http://twitter.com/mwessendorf > > > _______________________________________________ > > > aerogear-dev mailing list > > > aerogear-dev at lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140725/87af2aec/attachment.html From daniel.bevenius at gmail.com Fri Jul 25 05:04:31 2014 From: daniel.bevenius at gmail.com (Daniel Bevenius) Date: Fri, 25 Jul 2014 11:04:31 +0200 Subject: [aerogear-dev] Differences between Firefox OS "native" Push lib and AeroGear's Push adapter In-Reply-To: <1E3E76E8-60D7-4BF3-9B95-6C58F4DC9286@redhat.com> References: <9B70BDB9-4774-4BF0-9FF7-5213185E4F52@redhat.com> <51C9D854-0730-4B2A-9A92-9DC92649947D@redhat.com> <8AEB32A5-0F61-495B-8EA5-767F48312B9C@redhat.com> <02064329-0F9B-49DC-A5EC-A106001DD51F@redhat.com> <1406216640.15307.0@smtp.corp.redhat.com> <1E3E76E8-60D7-4BF3-9B95-6C58F4DC9286@redhat.com> Message-ID: >5. don?t use the url as a deviceToken (might not comply with Mozzila?s SimplePush specs) The deviceToken is an UPS concept and there is nothing in the SimplePush spec which is violated in this case. I'm not sure about what the best option is for UPS thought. Would a regex in for the @Path annotation work perhaps, something like: @DELETE @Path("{token, .+}") public Response unregisterInstallations( On 25 July 2014 10:32, Tadeas Kriz wrote: > > ? > Tadeas Kriz > > On 24 Jul 2014, at 05:44 pm, Karel Piwko wrote: > > > On Thu, Jul 24, 2014 at 3:28 PM, Tadeas Kriz wrote: > >> > >> It should not. For hibernate, it?s just a string like any other. > >> The problem might be in the configuration of JAX.RS/RestEasy. If > >> I?ll have some time today evening, I?ll try to fix it, it should > >> be an easy fix. > > > > Last famous words? ;-) > > > > I shall never say ?an easy fix? again. > > > But I agree. Everything is string and URL encode should happen on > > client while server should automatically decode and work always with > > just decoded string. If we need to encode twice, something is wrong. > > > > Anyway, the 400 Bad request response is made by the tomcat itself, > disallowing the use of %2F as a path parameter. This will probably apply on > other web containers. > > Possible solutions with their disadvantages: > > 1. well-documented double-encoding of the URL (might be confusing) > 2. use @QueryParam instead of @PathParam (breaks the api consistence, as > every other call would still use @PathParam) > 3. allow @QueryParam (again, breaks the api consistence, but only for the > SimplePush) > 4. find another encoding (Base64 for URL = URLEncode then Base64 encode) > 5. don?t use the url as a deviceToken (might not comply with Mozzila?s > SimplePush specs) > > What do you think guys? > > >> > >> > > > > > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140725/a398e9f9/attachment-0001.html From matzew at apache.org Fri Jul 25 05:15:39 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Fri, 25 Jul 2014 11:15:39 +0200 Subject: [aerogear-dev] Differences between Firefox OS "native" Push lib and AeroGear's Push adapter In-Reply-To: <1E3E76E8-60D7-4BF3-9B95-6C58F4DC9286@redhat.com> References: <9B70BDB9-4774-4BF0-9FF7-5213185E4F52@redhat.com> <51C9D854-0730-4B2A-9A92-9DC92649947D@redhat.com> <8AEB32A5-0F61-495B-8EA5-767F48312B9C@redhat.com> <02064329-0F9B-49DC-A5EC-A106001DD51F@redhat.com> <1406216640.15307.0@smtp.corp.redhat.com> <1E3E76E8-60D7-4BF3-9B95-6C58F4DC9286@redhat.com> Message-ID: On Fri, Jul 25, 2014 at 10:32 AM, Tadeas Kriz wrote: > > ? > Tadeas Kriz > > On 24 Jul 2014, at 05:44 pm, Karel Piwko wrote: > > > On Thu, Jul 24, 2014 at 3:28 PM, Tadeas Kriz wrote: > >> > >> It should not. For hibernate, it?s just a string like any other. > >> The problem might be in the configuration of JAX.RS/RestEasy. If > >> I?ll have some time today evening, I?ll try to fix it, it should > >> be an easy fix. > > > > Last famous words? ;-) > > > > I shall never say ?an easy fix? again. > > > But I agree. Everything is string and URL encode should happen on > > client while server should automatically decode and work always with > > just decoded string. If we need to encode twice, something is wrong. > > > > Anyway, the 400 Bad request response is made by the tomcat itself, > disallowing the use of %2F as a path parameter. This will probably apply on > other web containers. > > Possible solutions with their disadvantages: > > 1. well-documented double-encoding of the URL (might be confusing) > well, yeah :) that would be my choice; even if it sucks > 2. use @QueryParam instead of @PathParam (breaks the api consistence, as > every other call would still use @PathParam) > 3. allow @QueryParam (again, breaks the api consistence, but only for the > SimplePush) > -1 on any API chagne > 4. find another encoding (Base64 for URL = URLEncode then Base64 encode) > not sure > 5. don?t use the url as a deviceToken (might not comply with Mozzila?s > SimplePush specs) > does dan's regex work (for all platforms), I'd vote for that, otherwise option 1 -M > > What do you think guys? > > >> > >> > > > > > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140725/2a1084e6/attachment.html From tkriz at redhat.com Fri Jul 25 06:25:43 2014 From: tkriz at redhat.com (Tadeas Kriz) Date: Fri, 25 Jul 2014 12:25:43 +0200 Subject: [aerogear-dev] Differences between Firefox OS "native" Push lib and AeroGear's Push adapter In-Reply-To: References: <9B70BDB9-4774-4BF0-9FF7-5213185E4F52@redhat.com> <51C9D854-0730-4B2A-9A92-9DC92649947D@redhat.com> <8AEB32A5-0F61-495B-8EA5-767F48312B9C@redhat.com> <02064329-0F9B-49DC-A5EC-A106001DD51F@redhat.com> <1406216640.15307.0@smtp.corp.redhat.com> <1E3E76E8-60D7-4BF3-9B95-6C58F4DC9286@redhat.com> Message-ID: <919B56C2-8E6D-4CD8-A620-F9839E013685@redhat.com> ? Tadeas Kriz On 25 Jul 2014, at 11:04 am, Daniel Bevenius wrote: > >5. don?t use the url as a deviceToken (might not comply with Mozzila?s SimplePush specs) > The deviceToken is an UPS concept and there is nothing in the SimplePush spec which is violated in this case. > I thought that deviceTokens were changed from a generated value to the URL just to comply with Mozzila?s SimplePush specs. Matzew, why was the generated token removed then? > I'm not sure about what the best option is for UPS thought. Would a regex in for the @Path annotation work perhaps, something like: > > @DELETE > @Path("{token, .+}") > public Response unregisterInstallations( > What do you mean by that regex? The problem is simply the ?%2F? in the token (which is an URLencoded simplepush url) and it?s being revoked long before it hits the RestEasy (which does the routing according to what?s in the @Path). > > On 25 July 2014 10:32, Tadeas Kriz wrote: > > ? > Tadeas Kriz > > On 24 Jul 2014, at 05:44 pm, Karel Piwko wrote: > > > On Thu, Jul 24, 2014 at 3:28 PM, Tadeas Kriz wrote: > >> > >> It should not. For hibernate, it?s just a string like any other. > >> The problem might be in the configuration of JAX.RS/RestEasy. If > >> I?ll have some time today evening, I?ll try to fix it, it should > >> be an easy fix. > > > > Last famous words? ;-) > > > > I shall never say ?an easy fix? again. > > > But I agree. Everything is string and URL encode should happen on > > client while server should automatically decode and work always with > > just decoded string. If we need to encode twice, something is wrong. > > > > Anyway, the 400 Bad request response is made by the tomcat itself, disallowing the use of %2F as a path parameter. This will probably apply on other web containers. > > Possible solutions with their disadvantages: > > 1. well-documented double-encoding of the URL (might be confusing) > 2. use @QueryParam instead of @PathParam (breaks the api consistence, as every other call would still use @PathParam) > 3. allow @QueryParam (again, breaks the api consistence, but only for the SimplePush) > 4. find another encoding (Base64 for URL = URLEncode then Base64 encode) > 5. don?t use the url as a deviceToken (might not comply with Mozzila?s SimplePush specs) > > What do you think guys? > > >> > >> > > > > > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140725/dde13562/attachment.html From daniel.bevenius at gmail.com Fri Jul 25 06:38:40 2014 From: daniel.bevenius at gmail.com (Daniel Bevenius) Date: Fri, 25 Jul 2014 12:38:40 +0200 Subject: [aerogear-dev] Differences between Firefox OS "native" Push lib and AeroGear's Push adapter In-Reply-To: <919B56C2-8E6D-4CD8-A620-F9839E013685@redhat.com> References: <9B70BDB9-4774-4BF0-9FF7-5213185E4F52@redhat.com> <51C9D854-0730-4B2A-9A92-9DC92649947D@redhat.com> <8AEB32A5-0F61-495B-8EA5-767F48312B9C@redhat.com> <02064329-0F9B-49DC-A5EC-A106001DD51F@redhat.com> <1406216640.15307.0@smtp.corp.redhat.com> <1E3E76E8-60D7-4BF3-9B95-6C58F4DC9286@redhat.com> <919B56C2-8E6D-4CD8-A620-F9839E013685@redhat.com> Message-ID: >What do you mean by that regex? That the JAXRS implementation should not disallow as '/' in the path. >The problem is simply the ?%2F? in the token (which is an URLencoded simplepush url) and it?s being revoked long before it hits the RestEasy (which does the routing according to what?s in the @Path). I guess I don't understand why this would be revoked by anything before it hits the JAXRS implementation, but if that is the case you are right and adding this would not help. On 25 July 2014 12:25, Tadeas Kriz wrote: > > ? > Tadeas Kriz > > On 25 Jul 2014, at 11:04 am, Daniel Bevenius > wrote: > > >5. don?t use the url as a deviceToken (might not comply with Mozzila?s > SimplePush specs) > The deviceToken is an UPS concept and there is nothing in the SimplePush > spec which is violated in this case. > > I thought that deviceTokens were changed from a generated value to the URL > just to comply with Mozzila?s SimplePush specs. Matzew, why was the > generated token removed then? > > I'm not sure about what the best option is for UPS thought. Would a regex > in for the @Path annotation work perhaps, something like: > > @DELETE > @Path("{token, .+}") > public Response unregisterInstallations( > > > What do you mean by that regex? The problem is simply the ?%2F? in the > token (which is an URLencoded simplepush url) and it?s being revoked long > before it hits the RestEasy (which does the routing according to what?s in > the @Path). > > > On 25 July 2014 10:32, Tadeas Kriz wrote: > >> >> ? >> Tadeas Kriz >> >> On 24 Jul 2014, at 05:44 pm, Karel Piwko wrote: >> >> > On Thu, Jul 24, 2014 at 3:28 PM, Tadeas Kriz wrote: >> >> >> >> It should not. For hibernate, it?s just a string like any other. >> >> The problem might be in the configuration of JAX.RS/RestEasy >> . If >> >> I?ll have some time today evening, I?ll try to fix it, it should >> >> be an easy fix. >> > >> > Last famous words? ;-) >> > >> >> I shall never say ?an easy fix? again. >> >> > But I agree. Everything is string and URL encode should happen on >> > client while server should automatically decode and work always with >> > just decoded string. If we need to encode twice, something is wrong. >> > >> >> Anyway, the 400 Bad request response is made by the tomcat itself, >> disallowing the use of %2F as a path parameter. This will probably apply on >> other web containers. >> >> Possible solutions with their disadvantages: >> >> 1. well-documented double-encoding of the URL (might be confusing) >> 2. use @QueryParam instead of @PathParam (breaks the api consistence, as >> every other call would still use @PathParam) >> 3. allow @QueryParam (again, breaks the api consistence, but only for the >> SimplePush) >> 4. find another encoding (Base64 for URL = URLEncode then Base64 encode) >> 5. don?t use the url as a deviceToken (might not comply with Mozzila?s >> SimplePush specs) >> >> What do you think guys? >> >> >> >> >> >> > >> > >> > _______________________________________________ >> > aerogear-dev mailing list >> > aerogear-dev at lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140725/5f4158c5/attachment-0001.html From tkriz at redhat.com Fri Jul 25 06:55:01 2014 From: tkriz at redhat.com (Tadeas Kriz) Date: Fri, 25 Jul 2014 12:55:01 +0200 Subject: [aerogear-dev] Differences between Firefox OS "native" Push lib and AeroGear's Push adapter In-Reply-To: References: <9B70BDB9-4774-4BF0-9FF7-5213185E4F52@redhat.com> <51C9D854-0730-4B2A-9A92-9DC92649947D@redhat.com> <8AEB32A5-0F61-495B-8EA5-767F48312B9C@redhat.com> <02064329-0F9B-49DC-A5EC-A106001DD51F! @redhat.com> <1406216640.15307.0@smtp.corp.redhat.com> <1E3E76E8-60D7-4BF3-9B95-6C58F4DC9286@redhat.com> <919B56C2-8E6D-4CD8-A620-F9839E013685@redhat.com> Message-ID: ? Tadeas Kriz On 25 Jul 2014, at 12:38 pm, Daniel Bevenius wrote: > >What do you mean by that regex? > That the JAXRS implementation should not disallow as '/' in the path. Well, if it was like: ``` DELETE /rest/registry/installation/http://localhost:8321/asdasd ``` and the token you showed would match all the characters (which means that the `String token` would become `http://localhost:8321/asdasd` in the endpoint method), it might work, although I?m not sure if this is the best solution ?on the market?. > > >The problem is simply the ?%2F? in the token (which is an URLencoded simplepush url) and it?s being revoked long before it hits the RestEasy (which does the routing according to what?s in the @Path). > I guess I don't understand why this would be revoked by anything before it hits the JAXRS implementation, but if that is the case you are right and adding this would not help. > This was a solution for a security hole. As I understand it, on linux, scripts cannot tell difference between ?/? and ?%2F? and because of that, it?s forbidden to use as a path parameter (at least on Tomcat). > > > > > > On 25 July 2014 12:25, Tadeas Kriz wrote: > > ? > Tadeas Kriz > > On 25 Jul 2014, at 11:04 am, Daniel Bevenius wrote: > >> >5. don?t use the url as a deviceToken (might not comply with Mozzila?s SimplePush specs) >> The deviceToken is an UPS concept and there is nothing in the SimplePush spec which is violated in this case. >> > > I thought that deviceTokens were changed from a generated value to the URL just to comply with Mozzila?s SimplePush specs. Matzew, why was the generated token removed then? > >> I'm not sure about what the best option is for UPS thought. Would a regex in for the @Path annotation work perhaps, something like: >> >> @DELETE >> @Path("{token, .+}") >> public Response unregisterInstallations( >> > > What do you mean by that regex? The problem is simply the ?%2F? in the token (which is an URLencoded simplepush url) and it?s being revoked long before it hits the RestEasy (which does the routing according to what?s in the @Path). > >> >> On 25 July 2014 10:32, Tadeas Kriz wrote: >> >> ? >> Tadeas Kriz >> >> On 24 Jul 2014, at 05:44 pm, Karel Piwko wrote: >> >> > On Thu, Jul 24, 2014 at 3:28 PM, Tadeas Kriz wrote: >> >> >> >> It should not. For hibernate, it?s just a string like any other. >> >> The problem might be in the configuration of JAX.RS/RestEasy. If >> >> I?ll have some time today evening, I?ll try to fix it, it should >> >> be an easy fix. >> > >> > Last famous words? ;-) >> > >> >> I shall never say ?an easy fix? again. >> >> > But I agree. Everything is string and URL encode should happen on >> > client while server should automatically decode and work always with >> > just decoded string. If we need to encode twice, something is wrong. >> > >> >> Anyway, the 400 Bad request response is made by the tomcat itself, disallowing the use of %2F as a path parameter. This will probably apply on other web containers. >> >> Possible solutions with their disadvantages: >> >> 1. well-documented double-encoding of the URL (might be confusing) >> 2. use @QueryParam instead of @PathParam (breaks the api consistence, as every other call would still use @PathParam) >> 3. allow @QueryParam (again, breaks the api consistence, but only for the SimplePush) >> 4. find another encoding (Base64 for URL = URLEncode then Base64 encode) >> 5. don?t use the url as a deviceToken (might not comply with Mozzila?s SimplePush specs) >> >> What do you think guys? >> >> >> >> >> >> > >> > >> > _______________________________________________ >> > aerogear-dev mailing list >> > aerogear-dev at lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140725/a54e1b79/attachment.html From matzew at apache.org Fri Jul 25 07:04:35 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Fri, 25 Jul 2014 13:04:35 +0200 Subject: [aerogear-dev] Differences between Firefox OS "native" Push lib and AeroGear's Push adapter In-Reply-To: <919B56C2-8E6D-4CD8-A620-F9839E013685@redhat.com> References: <9B70BDB9-4774-4BF0-9FF7-5213185E4F52@redhat.com> <51C9D854-0730-4B2A-9A92-9DC92649947D@redhat.com> <8AEB32A5-0F61-495B-8EA5-767F48312B9C@redhat.com> <02064329-0F9B-49DC-A5EC-A106001DD51F@redhat.com> <1406216640.15307.0@smtp.corp.redhat.com> <1E3E76E8-60D7-4BF3-9B95-6C58F4DC9286@redhat.com> <919B56C2-8E6D-4CD8-A620-F9839E013685@redhat.com> Message-ID: On Fri, Jul 25, 2014 at 12:25 PM, Tadeas Kriz wrote: > > ? > Tadeas Kriz > > On 25 Jul 2014, at 11:04 am, Daniel Bevenius > wrote: > > >5. don?t use the url as a deviceToken (might not comply with Mozzila?s > SimplePush specs) > The deviceToken is an UPS concept and there is nothing in the SimplePush > spec which is violated in this case. > > I thought that deviceTokens were changed from a generated value to the URL > just to comply with Mozzila?s SimplePush specs. > Nope > Matzew, why was the generated token removed then? > It was the channelID before - but that should not be exposed. In GCM devices are identified via registrationID In APNs devices are identified va deviceToken (both are somewhat the same - but different names) In SimplePush devices are identifeid v/ the URL of the pushEndpoint (a backend uses that endpoint to notify _THAT_ client, regardless of how many channels it has subscribed) So, that lead us to make the change (see history of this threa) -M > > I'm not sure about what the best option is for UPS thought. Would a regex > in for the @Path annotation work perhaps, something like: > > @DELETE > @Path("{token, .+}") > public Response unregisterInstallations( > > > What do you mean by that regex? The problem is simply the ?%2F? in the > token (which is an URLencoded simplepush url) and it?s being revoked long > before it hits the RestEasy (which does the routing according to what?s in > the @Path). > > > On 25 July 2014 10:32, Tadeas Kriz wrote: > >> >> ? >> Tadeas Kriz >> >> On 24 Jul 2014, at 05:44 pm, Karel Piwko wrote: >> >> > On Thu, Jul 24, 2014 at 3:28 PM, Tadeas Kriz wrote: >> >> >> >> It should not. For hibernate, it?s just a string like any other. >> >> The problem might be in the configuration of JAX.RS/RestEasy >> . If >> >> I?ll have some time today evening, I?ll try to fix it, it should >> >> be an easy fix. >> > >> > Last famous words? ;-) >> > >> >> I shall never say ?an easy fix? again. >> >> > But I agree. Everything is string and URL encode should happen on >> > client while server should automatically decode and work always with >> > just decoded string. If we need to encode twice, something is wrong. >> > >> >> Anyway, the 400 Bad request response is made by the tomcat itself, >> disallowing the use of %2F as a path parameter. This will probably apply on >> other web containers. >> >> Possible solutions with their disadvantages: >> >> 1. well-documented double-encoding of the URL (might be confusing) >> 2. use @QueryParam instead of @PathParam (breaks the api consistence, as >> every other call would still use @PathParam) >> 3. allow @QueryParam (again, breaks the api consistence, but only for the >> SimplePush) >> 4. find another encoding (Base64 for URL = URLEncode then Base64 encode) >> 5. don?t use the url as a deviceToken (might not comply with Mozzila?s >> SimplePush specs) >> >> What do you think guys? >> >> >> >> >> >> > >> > >> > _______________________________________________ >> > aerogear-dev mailing list >> > aerogear-dev at lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140725/d5bb7310/attachment-0001.html From daniel.bevenius at gmail.com Fri Jul 25 07:09:53 2014 From: daniel.bevenius at gmail.com (Daniel Bevenius) Date: Fri, 25 Jul 2014 13:09:53 +0200 Subject: [aerogear-dev] Differences between Firefox OS "native" Push lib and AeroGear's Push adapter In-Reply-To: References: <9B70BDB9-4774-4BF0-9FF7-5213185E4F52@redhat.com> <51C9D854-0730-4B2A-9A92-9DC92649947D@redhat.com> <8AEB32A5-0F61-495B-8EA5-767F48312B9C@redhat.com> <1406216640.15307.0@smtp.corp.redhat.com> <1E3E76E8-60D7-4BF3-9B95-6C58F4DC9286@redhat.com> <919B56C2-8E6D-4CD8-A620-F9839E013685@redhat.com> Message-ID: > it might work, although I?m not sure if this is the best solution ?on the market?. It may not be the best solution and feel free to ignore it. On 25 July 2014 12:55, Tadeas Kriz wrote: > > ? > Tadeas Kriz > > On 25 Jul 2014, at 12:38 pm, Daniel Bevenius > wrote: > > >What do you mean by that regex? > That the JAXRS implementation should not disallow as '/' in the path. > > > Well, if it was like: > > ``` > DELETE /rest/registry/installation/http://localhost:8321/asdasd > ``` > > and the token you showed would match all the characters (which means that > the `String token` would become `http://localhost:8321/asdasd` in the > endpoint method), it might work, although I?m not sure if this is the best > solution ?on the market?. > > > >The problem is simply the ?%2F? in the token (which is an URLencoded > simplepush url) and it?s being revoked long before it hits the RestEasy > (which does the routing according to what?s in the @Path). > I guess I don't understand why this would be revoked by anything before it > hits the JAXRS implementation, but if that is the case you are right and > adding this would not help. > > > This was a solution for a security hole. As I understand it, on linux, > scripts cannot tell difference between ?/? and ?%2F? and because of that, > it?s forbidden to use as a path parameter (at least on Tomcat). > > > > > > > On 25 July 2014 12:25, Tadeas Kriz wrote: > >> >> ? >> Tadeas Kriz >> >> On 25 Jul 2014, at 11:04 am, Daniel Bevenius >> wrote: >> >> >5. don?t use the url as a deviceToken (might not comply with Mozzila?s >> SimplePush specs) >> The deviceToken is an UPS concept and there is nothing in the SimplePush >> spec which is violated in this case. >> >> I thought that deviceTokens were changed from a generated value to the >> URL just to comply with Mozzila?s SimplePush specs. Matzew, why was the >> generated token removed then? >> >> I'm not sure about what the best option is for UPS thought. Would a regex >> in for the @Path annotation work perhaps, something like: >> >> @DELETE >> @Path("{token, .+}") >> public Response unregisterInstallations( >> >> >> What do you mean by that regex? The problem is simply the ?%2F? in the >> token (which is an URLencoded simplepush url) and it?s being revoked long >> before it hits the RestEasy (which does the routing according to what?s in >> the @Path). >> >> >> On 25 July 2014 10:32, Tadeas Kriz wrote: >> >>> >>> ? >>> Tadeas Kriz >>> >>> On 24 Jul 2014, at 05:44 pm, Karel Piwko wrote: >>> >>> > On Thu, Jul 24, 2014 at 3:28 PM, Tadeas Kriz wrote: >>> >> >>> >> It should not. For hibernate, it?s just a string like any other. >>> >> The problem might be in the configuration of JAX.RS/RestEasy >>> . If >>> >> I?ll have some time today evening, I?ll try to fix it, it should >>> >> be an easy fix. >>> > >>> > Last famous words? ;-) >>> > >>> >>> I shall never say ?an easy fix? again. >>> >>> > But I agree. Everything is string and URL encode should happen on >>> > client while server should automatically decode and work always with >>> > just decoded string. If we need to encode twice, something is wrong. >>> > >>> >>> Anyway, the 400 Bad request response is made by the tomcat itself, >>> disallowing the use of %2F as a path parameter. This will probably apply on >>> other web containers. >>> >>> Possible solutions with their disadvantages: >>> >>> 1. well-documented double-encoding of the URL (might be confusing) >>> 2. use @QueryParam instead of @PathParam (breaks the api consistence, as >>> every other call would still use @PathParam) >>> 3. allow @QueryParam (again, breaks the api consistence, but only for >>> the SimplePush) >>> 4. find another encoding (Base64 for URL = URLEncode then Base64 encode) >>> 5. don?t use the url as a deviceToken (might not comply with Mozzila?s >>> SimplePush specs) >>> >>> What do you think guys? >>> >>> >> >>> >> >>> > >>> > >>> > _______________________________________________ >>> > aerogear-dev mailing list >>> > aerogear-dev at lists.jboss.org >>> > https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140725/abeda02c/attachment.html From tkriz at redhat.com Fri Jul 25 07:32:32 2014 From: tkriz at redhat.com (Tadeas Kriz) Date: Fri, 25 Jul 2014 13:32:32 +0200 Subject: [aerogear-dev] Differences between Firefox OS "native" Push lib and AeroGear's Push adapter In-Reply-To: References: <9B70BDB9-4774-4BF0-9FF7-5213185E4F52@redhat.com> <51C9D854-0730-4B2A-9A92-9DC92649947D@redhat.com> <8AEB32A5-0F61-495B-8EA5-767F48312B9C@redhat.com> <1406216640.15307.0@smtp.corp.redhat.com> <1E3E76E8-60D7-4BF3-9B95-6C58F4DC9286@redhat.com> <919B56C2-8E6D-4CD8-A620-F9839E013685@redhat.com> Message-ID: ? Tadeas Kriz On 25 Jul 2014, at 01:09 pm, Daniel Bevenius wrote: > > it might work, although I?m not sure if this is the best solution ?on the market?. > It may not be the best solution and feel free to ignore it. > I?d love to test it first. My only concern is whether or not might it be a security issue. I think that?s something that Bruno might know. > > > > On 25 July 2014 12:55, Tadeas Kriz wrote: > > ? > Tadeas Kriz > > On 25 Jul 2014, at 12:38 pm, Daniel Bevenius wrote: > >> >What do you mean by that regex? >> That the JAXRS implementation should not disallow as '/' in the path. > > Well, if it was like: > > ``` > DELETE /rest/registry/installation/http://localhost:8321/asdasd > ``` > > and the token you showed would match all the characters (which means that the `String token` would become `http://localhost:8321/asdasd` in the endpoint method), it might work, although I?m not sure if this is the best solution ?on the market?. > >> >> >The problem is simply the ?%2F? in the token (which is an URLencoded simplepush url) and it?s being revoked long before it hits the RestEasy (which does the routing according to what?s in the @Path). >> I guess I don't understand why this would be revoked by anything before it hits the JAXRS implementation, but if that is the case you are right and adding this would not help. >> > > This was a solution for a security hole. As I understand it, on linux, scripts cannot tell difference between ?/? and ?%2F? and because of that, it?s forbidden to use as a path parameter (at least on Tomcat). > >> >> >> >> >> >> On 25 July 2014 12:25, Tadeas Kriz wrote: >> >> ? >> Tadeas Kriz >> >> On 25 Jul 2014, at 11:04 am, Daniel Bevenius wrote: >> >>> >5. don?t use the url as a deviceToken (might not comply with Mozzila?s SimplePush specs) >>> The deviceToken is an UPS concept and there is nothing in the SimplePush spec which is violated in this case. >>> >> >> I thought that deviceTokens were changed from a generated value to the URL just to comply with Mozzila?s SimplePush specs. Matzew, why was the generated token removed then? >> >>> I'm not sure about what the best option is for UPS thought. Would a regex in for the @Path annotation work perhaps, something like: >>> >>> @DELETE >>> @Path("{token, .+}") >>> public Response unregisterInstallations( >>> >> >> What do you mean by that regex? The problem is simply the ?%2F? in the token (which is an URLencoded simplepush url) and it?s being revoked long before it hits the RestEasy (which does the routing according to what?s in the @Path). >> >>> >>> On 25 July 2014 10:32, Tadeas Kriz wrote: >>> >>> ? >>> Tadeas Kriz >>> >>> On 24 Jul 2014, at 05:44 pm, Karel Piwko wrote: >>> >>> > On Thu, Jul 24, 2014 at 3:28 PM, Tadeas Kriz wrote: >>> >> >>> >> It should not. For hibernate, it?s just a string like any other. >>> >> The problem might be in the configuration of JAX.RS/RestEasy. If >>> >> I?ll have some time today evening, I?ll try to fix it, it should >>> >> be an easy fix. >>> > >>> > Last famous words? ;-) >>> > >>> >>> I shall never say ?an easy fix? again. >>> >>> > But I agree. Everything is string and URL encode should happen on >>> > client while server should automatically decode and work always with >>> > just decoded string. If we need to encode twice, something is wrong. >>> > >>> >>> Anyway, the 400 Bad request response is made by the tomcat itself, disallowing the use of %2F as a path parameter. This will probably apply on other web containers. >>> >>> Possible solutions with their disadvantages: >>> >>> 1. well-documented double-encoding of the URL (might be confusing) >>> 2. use @QueryParam instead of @PathParam (breaks the api consistence, as every other call would still use @PathParam) >>> 3. allow @QueryParam (again, breaks the api consistence, but only for the SimplePush) >>> 4. find another encoding (Base64 for URL = URLEncode then Base64 encode) >>> 5. don?t use the url as a deviceToken (might not comply with Mozzila?s SimplePush specs) >>> >>> What do you think guys? >>> >>> >> >>> >> >>> > >>> > >>> > _______________________________________________ >>> > aerogear-dev mailing list >>> > aerogear-dev at lists.jboss.org >>> > https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140725/9e2bb5d5/attachment-0001.html From tkriz at redhat.com Fri Jul 25 07:44:34 2014 From: tkriz at redhat.com (Tadeas Kriz) Date: Fri, 25 Jul 2014 13:44:34 +0200 Subject: [aerogear-dev] [Vote] Release of UPS 1.0.0.Beta1 In-Reply-To: <516051AF-3D4F-4416-A0A8-DD42375A431B@gmail.com> References: <516051AF-3D4F-4416-A0A8-DD42375A431B@gmail.com> Message-ID: <15898286-33BA-487D-821A-6D11946008C2@redhat.com> I?ve run integration tests against the staging repository and the only concern seems to be the unregistration of a simplepush variant we?ve already been discussing. +1 on the release! Good job! ? Tadeas Kriz On 24 Jul 2014, at 05:25 pm, Corinne Krych wrote: > +1 > Successfully tested interactive notification on iOS8 with dev and prod certificates on iOS8beta4 > > ++ > Corinne > On 24 Jul 2014, at 17:22, Sebastien Blanc wrote: > >> +1 >> I've deployed the WARs on OpenShift, then tested with the HelloWorld and the Contact App. >> Everything work as expected ! >> >> >> >> On Wed, Jul 23, 2014 at 9:01 AM, Matthias Wessendorf wrote: >> Good morning folks! >> >> we are getting closer and closer to our 1.0.0 release! Thank you very much, guys! >> >> However, before we are moving towards the 1.0.0.Final community release, I'd love to get the current work out as 1.0.0.Beta1 >> >> Note this release contains a ton of work and new features. To name a few highlights: >> >> * increased APNs payload (2k) >> * iOS8 interactive notification support >> * Pagination for analytics >> * improved callback for details on actual push delivery >> * optimisations and improvements >> >> Besides these changes, a ton of more work was done by the team: >> https://issues.jboss.org/browse/AGPUSH/fixforversion/12323753 >> >> The staging repository is located here: >> https://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-3598 >> >> >> NOTE: Once this release has been approved the matching tag will be used to get the OpenShift online bits updated! >> >> Let me know the results of your testing! >> If I hear nothing bad by Friday evening, the release to maven central will happen on Monday; >> >> Greetings, >> Matthias >> >> >> >> -- >> Matthias Wessendorf >> >> blog: http://matthiaswessendorf.wordpress.com/ >> sessions: http://www.slideshare.net/mwessendorf >> twitter: http://twitter.com/mwessendorf >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev From qmx at qmx.me Fri Jul 25 08:04:09 2014 From: qmx at qmx.me (Douglas Campos) Date: Fri, 25 Jul 2014 09:04:09 -0300 Subject: [aerogear-dev] News from iOS Modules front In-Reply-To: <78957F0D-27BC-49B8-9F47-5905FA3F55A7@gmail.com> References: <78957F0D-27BC-49B8-9F47-5905FA3F55A7@gmail.com> Message-ID: <20140725120409.GA79892@darkstar.local> On Fri, Jul 11, 2014 at 11:20:08PM +0200, Corinne Krych wrote: > Since we?re talking about renaming, what about dropping ?arerogear? > for the repo name? all those repos belong to aerogear organization > anyway. Maybe removing the aerogear part will stress more the small > libraries aspect. Maybe sth we already discussed but can?t > remember/find it. wdyt? -1 Rationale: the organization namespace only exists on github - when you clone the projects you'll end up with a ton of folders with loose naming - so having the prefix keeps it organized on disk + gives us a nice boost for the 'aerogear' brand. I can say that here where I have a bazillion of opensource projects, it's nice to have all aerogear stuff properly sorted - less cognitive load for contributors. -- qmx From matzew at apache.org Fri Jul 25 08:17:19 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Fri, 25 Jul 2014 14:17:19 +0200 Subject: [aerogear-dev] News from iOS Modules front In-Reply-To: <20140725120409.GA79892@darkstar.local> References: <78957F0D-27BC-49B8-9F47-5905FA3F55A7@gmail.com> <20140725120409.GA79892@darkstar.local> Message-ID: On Fri, Jul 25, 2014 at 2:04 PM, Douglas Campos wrote: > On Fri, Jul 11, 2014 at 11:20:08PM +0200, Corinne Krych wrote: > > Since we?re talking about renaming, what about dropping ?arerogear? > > for the repo name? all those repos belong to aerogear organization > > anyway. Maybe removing the aerogear part will stress more the small > > libraries aspect. Maybe sth we already discussed but can?t > > remember/find it. wdyt? > -1 > > Rationale: the organization namespace only exists on github - when you > clone the projects you'll end up with a ton of folders with loose > naming - so having the prefix keeps it organized on disk + gives us a > nice boost for the 'aerogear' brand. > yeah :-) ok, let's keep the 'aerogear' :-) > > I can say that here where I have a bazillion of opensource projects, > it's nice to have all aerogear stuff properly sorted - less cognitive > load for contributors. > > -- > qmx > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140725/8d0d6cf6/attachment.html From corinnekrych at gmail.com Fri Jul 25 08:29:21 2014 From: corinnekrych at gmail.com (Corinne Krych) Date: Fri, 25 Jul 2014 14:29:21 +0200 Subject: [aerogear-dev] News from iOS Modules front In-Reply-To: <20140725120409.GA79892@darkstar.local> References: <78957F0D-27BC-49B8-9F47-5905FA3F55A7@gmail.com> <20140725120409.GA79892@darkstar.local> Message-ID: On 25 Jul 2014, at 14:04, Douglas Campos wrote: > On Fri, Jul 11, 2014 at 11:20:08PM +0200, Corinne Krych wrote: >> Since we?re talking about renaming, what about dropping ?arerogear? >> for the repo name? all those repos belong to aerogear organization >> anyway. Maybe removing the aerogear part will stress more the small >> libraries aspect. Maybe sth we already discussed but can?t >> remember/find it. wdyt? > -1 > > Rationale: the organization namespace only exists on github - when you > clone the projects you'll end up with a ton of folders with loose > naming - so having the prefix keeps it organized on disk + gives us a > nice boost for the 'aerogear' brand. > > I can say that here where I have a bazillion of opensource projects, > it's nice to have all aerogear stuff properly sorted - less cognitive > load for contributors. > Oki. we stick to ag prefix. no rush on that. > -- > qmx > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev From kpiwko at redhat.com Fri Jul 25 08:49:05 2014 From: kpiwko at redhat.com (Karel Piwko) Date: Fri, 25 Jul 2014 12:51:05 +0002 Subject: [aerogear-dev] Differences between Firefox OS "native" Push lib and AeroGear's Push adapter In-Reply-To: References: <9B70BDB9-4774-4BF0-9FF7-5213185E4F52@redhat.com> <51C9D854-0730-4B2A-9A92-9DC92649947D@redhat.com> <8AEB32A5-0F61-495B-8EA5-767F48312B9C@redhat.com> <02064329-0F9B-49DC-A5EC-A106001DD51F@redhat.com> <1406216640.15307.0@smtp.corp.redhat.com> <1E3E76E8-60D7-4BF3-9B95-6C58F4DC9286@redhat.com> <919B56C2-8E6D-4CD8-A620-F9839E013685@redhat.com> Message-ID: <1406292545.14163.0@smtp.corp.redhat.com> Long term, we want an implementation that works on all servers. If some of them reject path params with '/', we need to token encode it somehow. According to https://wiki.mozilla.org/WebAPI/SimplePush/Protocol , EndpointURL should be exposed to application. Which does not mean that it must be exposed to via UPS, right? As UPS is *THE* application to which EndpointURL is exposed to. UPS can translate {deviceToken} to EndpointURL. We just need a way how to generate unique {deviceToken} on client. Would UUID work? EndpointURL can become part of JSON [1]. Such change would mean that clients can't use SP server directly but have to go through UPS. This makes more sense then current setup to me. Karel [1] https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/jaxrs/src/main/java/org/jboss/aerogear/unifiedpush/rest/registry/installations/InstallationRegistrationEndpoint.java#L74 On Fri, Jul 25, 2014 at 1:04 PM, Matthias Wessendorf wrote: > > > > On Fri, Jul 25, 2014 at 12:25 PM, Tadeas Kriz > wrote: >> >> ? >> Tadeas Kriz >> >> On 25 Jul 2014, at 11:04 am, Daniel Bevenius >> wrote: >> >>> >5. don?t use the url as a deviceToken (might not comply with >>> Mozzila?s SimplePush specs) >>> The deviceToken is an UPS concept and there is nothing in the >>> SimplePush spec which is violated in this case. >>> >> I thought that deviceTokens were changed from a generated value to >> the URL just to comply with Mozzila?s SimplePush specs. > > Nope > >> Matzew, why was the generated token removed then? > > It was the channelID before - but that should not be exposed. > In GCM devices are identified via registrationID > In APNs devices are identified va deviceToken > (both are somewhat the same - but different names) > > In SimplePush devices are identifeid v/ the URL of the pushEndpoint > (a backend uses that endpoint to notify _THAT_ client, regardless of > how many channels it has subscribed) > > So, that lead us to make the change (see history of this threa) > > -M > > > >> >>> I'm not sure about what the best option is for UPS thought. Would a >>> regex in for the @Path annotation work perhaps, something like: >>> >>> @DELETE >>> @Path("{token, .+}") >>> public Response unregisterInstallations( >>> >> >> What do you mean by that regex? The problem is simply the ?%2F? >> in the token (which is an URLencoded simplepush url) and it?s >> being revoked long before it hits the RestEasy (which does the >> routing according to what?s in the @Path). >> >>> >>> On 25 July 2014 10:32, Tadeas Kriz wrote: >>>> >>>> ? >>>> Tadeas Kriz >>>> >>>> On 24 Jul 2014, at 05:44 pm, Karel Piwko wrote: >>>> >>>> > On Thu, Jul 24, 2014 at 3:28 PM, Tadeas Kriz >>>> wrote: >>>> >> >>>> >> It should not. For hibernate, it?s just a string like any >>>> other. >>>> >> The problem might be in the configuration of JAX.RS/RestEasy. If >>>> >> I?ll have some time today evening, I?ll try to fix it, it >>>> should >>>> >> be an easy fix. >>>> > >>>> > Last famous words? ;-) >>>> > >>>> >>>> I shall never say ?an easy fix? again. >>>> >>>> > But I agree. Everything is string and URL encode should happen on >>>> > client while server should automatically decode and work always >>>> with >>>> > just decoded string. If we need to encode twice, something is >>>> wrong. >>>> > >>>> >>>> Anyway, the 400 Bad request response is made by the tomcat itself, >>>> disallowing the use of %2F as a path parameter. This will probably >>>> apply on other web containers. >>>> >>>> Possible solutions with their disadvantages: >>>> >>>> 1. well-documented double-encoding of the URL (might be confusing) >>>> 2. use @QueryParam instead of @PathParam (breaks the api >>>> consistence, as every other call would still use @PathParam) >>>> 3. allow @QueryParam (again, breaks the api consistence, but only >>>> for the SimplePush) >>>> 4. find another encoding (Base64 for URL = URLEncode then Base64 >>>> encode) >>>> 5. don?t use the url as a deviceToken (might not comply with >>>> Mozzila?s SimplePush specs) >>>> >>>> What do you think guys? >>>> >>>> >> >>>> >> >>>> > >>>> > >>>> > _______________________________________________ >>>> > aerogear-dev mailing list >>>> > aerogear-dev at lists.jboss.org >>>> > https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> >>>> >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf From tkriz at redhat.com Fri Jul 25 08:53:31 2014 From: tkriz at redhat.com (Tadeas Kriz) Date: Fri, 25 Jul 2014 14:53:31 +0200 Subject: [aerogear-dev] Differences between Firefox OS "native" Push lib and AeroGear's Push adapter In-Reply-To: <1406292545.14163.0@smtp.corp.redhat.com> References: <9B70BDB9-4774-4BF0-9FF7-5213185E4F52@redhat.com> <51C9D854-0730-4B2A-9A92-9DC92649947D@redhat.com> <8AEB32A5-0F61-495B-8EA5-767F48312B9C@redhat.com> <02064329-0F9B-49DC-A5EC-A106001DD51F! @redhat.com> <1406216640.15307.0@smtp.corp.redhat.com> <1E3E76E8-60D7-4BF3-9B95-6C58F4DC9286@redhat.com> <919B56C2-8E6D-4CD8-A620-F9839E013685@redhat.com> <1406292545.14163.0@smtp.corp.redhat.com> Message-ID: I believe that?s how it was before the change, am I right? I think that the proposed solution, to switch back to generated tokens might be the most stable a way to go. ? Tadeas Kriz On 25 Jul 2014, at 02:49 pm, Karel Piwko wrote: > Long term, we want an implementation that works on all servers. If some > of them reject path params with '/', we need to token encode it somehow. > > According to https://wiki.mozilla.org/WebAPI/SimplePush/Protocol , > EndpointURL should be exposed to application. Which does not mean that > it must be exposed to via UPS, right? As UPS is *THE* application to > which EndpointURL is exposed to. > > UPS can translate {deviceToken} to EndpointURL. We just need a way how > to generate unique {deviceToken} on client. Would UUID work? > EndpointURL can become part of JSON [1]. > > Such change would mean that clients can't use SP server directly but > have to go through UPS. This makes more sense then current setup to me. > > Karel > > [1] > https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/jaxrs/src/main/java/org/jboss/aerogear/unifiedpush/rest/registry/installations/InstallationRegistrationEndpoint.java#L74 > > On Fri, Jul 25, 2014 at 1:04 PM, Matthias Wessendorf > wrote: >> >> >> >> On Fri, Jul 25, 2014 at 12:25 PM, Tadeas Kriz >> wrote: >>> >>> ? >>> Tadeas Kriz >>> >>> On 25 Jul 2014, at 11:04 am, Daniel Bevenius >>> wrote: >>> >>>>> 5. don?t use the url as a deviceToken (might not comply with >>>> Mozzila?s SimplePush specs) >>>> The deviceToken is an UPS concept and there is nothing in the >>>> SimplePush spec which is violated in this case. >>>> >>> I thought that deviceTokens were changed from a generated value to >>> the URL just to comply with Mozzila?s SimplePush specs. >> >> Nope >> >>> Matzew, why was the generated token removed then? >> >> It was the channelID before - but that should not be exposed. >> In GCM devices are identified via registrationID >> In APNs devices are identified va deviceToken >> (both are somewhat the same - but different names) >> >> In SimplePush devices are identifeid v/ the URL of the pushEndpoint >> (a backend uses that endpoint to notify _THAT_ client, regardless of >> how many channels it has subscribed) >> >> So, that lead us to make the change (see history of this threa) >> >> -M >> >> >> >>> >>>> I'm not sure about what the best option is for UPS thought. Would a >>>> regex in for the @Path annotation work perhaps, something like: >>>> >>>> @DELETE >>>> @Path("{token, .+}") >>>> public Response unregisterInstallations( >>>> >>> >>> What do you mean by that regex? The problem is simply the ?%2F? >>> in the token (which is an URLencoded simplepush url) and it?s >>> being revoked long before it hits the RestEasy (which does the >>> routing according to what?s in the @Path). >>> >>>> >>>> On 25 July 2014 10:32, Tadeas Kriz wrote: >>>>> >>>>> ? >>>>> Tadeas Kriz >>>>> >>>>> On 24 Jul 2014, at 05:44 pm, Karel Piwko wrote: >>>>> >>>>>> On Thu, Jul 24, 2014 at 3:28 PM, Tadeas Kriz >>>>> wrote: >>>>>>> >>>>>>> It should not. For hibernate, it?s just a string like any >>>>> other. >>>>>>> The problem might be in the configuration of JAX.RS/RestEasy. If >>>>>>> I?ll have some time today evening, I?ll try to fix it, it >>>>> should >>>>>>> be an easy fix. >>>>>> >>>>>> Last famous words? ;-) >>>>>> >>>>> >>>>> I shall never say ?an easy fix? again. >>>>> >>>>>> But I agree. Everything is string and URL encode should happen on >>>>>> client while server should automatically decode and work always >>>>> with >>>>>> just decoded string. If we need to encode twice, something is >>>>> wrong. >>>>>> >>>>> >>>>> Anyway, the 400 Bad request response is made by the tomcat itself, >>>>> disallowing the use of %2F as a path parameter. This will probably >>>>> apply on other web containers. >>>>> >>>>> Possible solutions with their disadvantages: >>>>> >>>>> 1. well-documented double-encoding of the URL (might be confusing) >>>>> 2. use @QueryParam instead of @PathParam (breaks the api >>>>> consistence, as every other call would still use @PathParam) >>>>> 3. allow @QueryParam (again, breaks the api consistence, but only >>>>> for the SimplePush) >>>>> 4. find another encoding (Base64 for URL = URLEncode then Base64 >>>>> encode) >>>>> 5. don?t use the url as a deviceToken (might not comply with >>>>> Mozzila?s SimplePush specs) >>>>> >>>>> What do you think guys? >>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> aerogear-dev mailing list >>>>>> aerogear-dev at lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>> >>>>> >>>>> _______________________________________________ >>>>> aerogear-dev mailing list >>>>> aerogear-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> >> -- >> Matthias Wessendorf >> >> blog: http://matthiaswessendorf.wordpress.com/ >> sessions: http://www.slideshare.net/mwessendorf >> twitter: http://twitter.com/mwessendorf > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev From matzew at apache.org Fri Jul 25 08:56:26 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Fri, 25 Jul 2014 14:56:26 +0200 Subject: [aerogear-dev] Differences between Firefox OS "native" Push lib and AeroGear's Push adapter In-Reply-To: <1406292545.14163.0@smtp.corp.redhat.com> References: <9B70BDB9-4774-4BF0-9FF7-5213185E4F52@redhat.com> <51C9D854-0730-4B2A-9A92-9DC92649947D@redhat.com> <8AEB32A5-0F61-495B-8EA5-767F48312B9C@redhat.com> <02064329-0F9B-49DC-A5EC-A106001DD51F@redhat.com> <1406216640.15307.0@smtp.corp.redhat.com> <1E3E76E8-60D7-4BF3-9B95-6C58F4DC9286@redhat.com> <919B56C2-8E6D-4CD8-A620-F9839E013685@redhat.com> <1406292545.14163.0@smtp.corp.redhat.com> Message-ID: On Fri, Jul 25, 2014 at 2:49 PM, Karel Piwko wrote: > Long term, we want an implementation that works on all servers. If some > of them reject path params with '/', we need to token encode it somehow. > > According to https://wiki.mozilla.org/WebAPI/SimplePush/Protocol , > EndpointURL should be exposed to application. Which does not mean that > it must be exposed to via UPS, right? It is not really exposed via UPS... > As UPS is *THE* application to > which EndpointURL is exposed to. > right, that's why we store it there :) In order to have the UPS trigger the updates (using the URL) > > UPS can translate {deviceToken} to EndpointURL. We just need a way how > to generate unique {deviceToken} on client. that would be our own layer on-top, which is a no-go > Would UUID work? > EndpointURL can become part of JSON [1]. > it was there as "simplePushEndpoint", but for stated reasons it's now the deviceToken that has the URL value > > Such change would mean that clients can't use SP server directly but > have to go through UPS. This makes more sense then current setup to me. > not really > > Karel > > [1] > > https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/jaxrs/src/main/java/org/jboss/aerogear/unifiedpush/rest/registry/installations/InstallationRegistrationEndpoint.java#L74 > > On Fri, Jul 25, 2014 at 1:04 PM, Matthias Wessendorf > wrote: > > > > > > > > On Fri, Jul 25, 2014 at 12:25 PM, Tadeas Kriz > > wrote: > >> > >> ? > >> Tadeas Kriz > >> > >> On 25 Jul 2014, at 11:04 am, Daniel Bevenius > >> wrote: > >> > >>> >5. don?t use the url as a deviceToken (might not comply with > >>> Mozzila?s SimplePush specs) > >>> The deviceToken is an UPS concept and there is nothing in the > >>> SimplePush spec which is violated in this case. > >>> > >> I thought that deviceTokens were changed from a generated value to > >> the URL just to comply with Mozzila?s SimplePush specs. > > > > Nope > > > >> Matzew, why was the generated token removed then? > > > > It was the channelID before - but that should not be exposed. > > In GCM devices are identified via registrationID > > In APNs devices are identified va deviceToken > > (both are somewhat the same - but different names) > > > > In SimplePush devices are identifeid v/ the URL of the pushEndpoint > > (a backend uses that endpoint to notify _THAT_ client, regardless of > > how many channels it has subscribed) > > > > So, that lead us to make the change (see history of this threa) > > > > -M > > > > > > > >> > >>> I'm not sure about what the best option is for UPS thought. Would a > >>> regex in for the @Path annotation work perhaps, something like: > >>> > >>> @DELETE > >>> @Path("{token, .+}") > >>> public Response unregisterInstallations( > >>> > >> > >> What do you mean by that regex? The problem is simply the ?%2F? > >> in the token (which is an URLencoded simplepush url) and it?s > >> being revoked long before it hits the RestEasy (which does the > >> routing according to what?s in the @Path). > >> > >>> > >>> On 25 July 2014 10:32, Tadeas Kriz wrote: > >>>> > >>>> ? > >>>> Tadeas Kriz > >>>> > >>>> On 24 Jul 2014, at 05:44 pm, Karel Piwko wrote: > >>>> > >>>> > On Thu, Jul 24, 2014 at 3:28 PM, Tadeas Kriz > >>>> wrote: > >>>> >> > >>>> >> It should not. For hibernate, it?s just a string like any > >>>> other. > >>>> >> The problem might be in the configuration of JAX.RS/RestEasy. If > >>>> >> I?ll have some time today evening, I?ll try to fix it, it > >>>> should > >>>> >> be an easy fix. > >>>> > > >>>> > Last famous words? ;-) > >>>> > > >>>> > >>>> I shall never say ?an easy fix? again. > >>>> > >>>> > But I agree. Everything is string and URL encode should happen on > >>>> > client while server should automatically decode and work always > >>>> with > >>>> > just decoded string. If we need to encode twice, something is > >>>> wrong. > >>>> > > >>>> > >>>> Anyway, the 400 Bad request response is made by the tomcat itself, > >>>> disallowing the use of %2F as a path parameter. This will probably > >>>> apply on other web containers. > >>>> > >>>> Possible solutions with their disadvantages: > >>>> > >>>> 1. well-documented double-encoding of the URL (might be confusing) > >>>> 2. use @QueryParam instead of @PathParam (breaks the api > >>>> consistence, as every other call would still use @PathParam) > >>>> 3. allow @QueryParam (again, breaks the api consistence, but only > >>>> for the SimplePush) > >>>> 4. find another encoding (Base64 for URL = URLEncode then Base64 > >>>> encode) > >>>> 5. don?t use the url as a deviceToken (might not comply with > >>>> Mozzila?s SimplePush specs) > >>>> > >>>> What do you think guys? > >>>> > >>>> >> > >>>> >> > >>>> > > >>>> > > >>>> > _______________________________________________ > >>>> > aerogear-dev mailing list > >>>> > aerogear-dev at lists.jboss.org > >>>> > https://lists.jboss.org/mailman/listinfo/aerogear-dev > >>>> > >>>> > >>>> _______________________________________________ > >>>> aerogear-dev mailing list > >>>> aerogear-dev at lists.jboss.org > >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev > >>> > >>> _______________________________________________ > >>> aerogear-dev mailing list > >>> aerogear-dev at lists.jboss.org > >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev > >> > >> > >> _______________________________________________ > >> aerogear-dev mailing list > >> aerogear-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > > > > -- > > Matthias Wessendorf > > > > blog: http://matthiaswessendorf.wordpress.com/ > > sessions: http://www.slideshare.net/mwessendorf > > twitter: http://twitter.com/mwessendorf > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140725/422703ca/attachment.html From kpiwko at redhat.com Fri Jul 25 09:06:08 2014 From: kpiwko at redhat.com (Karel Piwko) Date: Fri, 25 Jul 2014 13:08:08 +0002 Subject: [aerogear-dev] Differences between Firefox OS "native" Push lib and AeroGear's Push adapter In-Reply-To: References: <9B70BDB9-4774-4BF0-9FF7-5213185E4F52@redhat.com> <51C9D854-0730-4B2A-9A92-9DC92649947D@redhat.com> <8AEB32A5-0F61-495B-8EA5-767F48312B9C@redhat.com> <02064329-0F9B-49DC-A5EC-A106001DD51F@redhat.com> <1406216640.15307.0@smtp.corp.redhat.com> <1E3E76E8-60D7-4BF3-9B95-6C58F4DC9286@redhat.com> <919B56C2-8E6D-4CD8-A620-F9839E013685@redhat.com> <1406292545.14163.0@smtp.corp.redhat.com> Message-ID: <1406293568.14163.1@smtp.corp.redhat.com> On Fri, Jul 25, 2014 at 2:56 PM, Matthias Wessendorf wrote: > >> UPS can translate {deviceToken} to EndpointURL. We just need a way >> how >> to generate unique {deviceToken} on client. > > that would be our own layer on-top, which is a no-go why? it would be there anyway. Imagine that your UPS is running on exposed URL which is a gateway to your internal network. SP URL is valid only in that internal network, not visible from outside world at all. So, using UPS is the only way to send the message to that URL. > > >> Would UUID work? >> EndpointURL can become part of JSON [1]. > > it was there as "simplePushEndpoint", but for stated reasons it's now > the deviceToken that has the URL value > > >> >> Such change would mean that clients can't use SP server directly but >> have to go through UPS. This makes more sense then current setup to >> me. > > not really See reason stated above. > >> >> Karel >> >> [1] >> https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/jaxrs/src/main/java/org/jboss/aerogear/unifiedpush/rest/registry/installations/InstallationRegistrationEndpoint.java#L74 >> >> On Fri, Jul 25, 2014 at 1:04 PM, Matthias Wessendorf >> wrote: >> > >> > >> > >> > On Fri, Jul 25, 2014 at 12:25 PM, Tadeas Kriz >> > wrote: >> >> >> >> ? >> >> Tadeas Kriz >> >> >> >> On 25 Jul 2014, at 11:04 am, Daniel Bevenius >> >> wrote: >> >> >> >>> >5. don?t use the url as a deviceToken (might not comply with >> >>> Mozzila?s SimplePush specs) >> >>> The deviceToken is an UPS concept and there is nothing in the >> >>> SimplePush spec which is violated in this case. >> >>> >> >> I thought that deviceTokens were changed from a generated value to >> >> the URL just to comply with Mozzila?s SimplePush specs. >> > >> > Nope >> > >> >> Matzew, why was the generated token removed then? >> > >> > It was the channelID before - but that should not be exposed. >> > In GCM devices are identified via registrationID >> > In APNs devices are identified va deviceToken >> > (both are somewhat the same - but different names) >> > >> > In SimplePush devices are identifeid v/ the URL of the pushEndpoint >> > (a backend uses that endpoint to notify _THAT_ client, regardless >> of >> > how many channels it has subscribed) >> > >> > So, that lead us to make the change (see history of this threa) >> > >> > -M >> > >> > >> > >> >> >> >>> I'm not sure about what the best option is for UPS thought. >> Would a >> >>> regex in for the @Path annotation work perhaps, something like: >> >>> >> >>> @DELETE >> >>> @Path("{token, .+}") >> >>> public Response unregisterInstallations( >> >>> >> >> >> >> What do you mean by that regex? The problem is simply the >> ?%2F? >> >> in the token (which is an URLencoded simplepush url) and it?s >> >> being revoked long before it hits the RestEasy (which does the >> >> routing according to what?s in the @Path). >> >> >> >>> >> >>> On 25 July 2014 10:32, Tadeas Kriz wrote: >> >>>> >> >>>> ? >> >>>> Tadeas Kriz >> >>>> >> >>>> On 24 Jul 2014, at 05:44 pm, Karel Piwko >> wrote: >> >>>> >> >>>> > On Thu, Jul 24, 2014 at 3:28 PM, Tadeas Kriz >> >> >>>> wrote: >> >>>> >> >> >>>> >> It should not. For hibernate, it?s just a string like any >> >>>> other. >> >>>> >> The problem might be in the configuration of >> JAX.RS/RestEasy. If >> >>>> >> I?ll have some time today evening, I?ll try to fix it, it >> >>>> should >> >>>> >> be an easy fix. >> >>>> > >> >>>> > Last famous words? ;-) >> >>>> > >> >>>> >> >>>> I shall never say ?an easy fix? again. >> >>>> >> >>>> > But I agree. Everything is string and URL encode should >> happen on >> >>>> > client while server should automatically decode and work >> always >> >>>> with >> >>>> > just decoded string. If we need to encode twice, something is >> >>>> wrong. >> >>>> > >> >>>> >> >>>> Anyway, the 400 Bad request response is made by the tomcat >> itself, >> >>>> disallowing the use of %2F as a path parameter. This will >> probably >> >>>> apply on other web containers. >> >>>> >> >>>> Possible solutions with their disadvantages: >> >>>> >> >>>> 1. well-documented double-encoding of the URL (might be >> confusing) >> >>>> 2. use @QueryParam instead of @PathParam (breaks the api >> >>>> consistence, as every other call would still use @PathParam) >> >>>> 3. allow @QueryParam (again, breaks the api consistence, but >> only >> >>>> for the SimplePush) >> >>>> 4. find another encoding (Base64 for URL = URLEncode then Base64 >> >>>> encode) >> >>>> 5. don?t use the url as a deviceToken (might not comply with >> >>>> Mozzila?s SimplePush specs) >> >>>> >> >>>> What do you think guys? >> >>>> >> >>>> >> >> >>>> >> >> >>>> > >> >>>> > >> >>>> > _______________________________________________ >> >>>> > aerogear-dev mailing list >> >>>> > aerogear-dev at lists.jboss.org >> >>>> > https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >>>> >> >>>> >> >>>> _______________________________________________ >> >>>> aerogear-dev mailing list >> >>>> aerogear-dev at lists.jboss.org >> >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >>> >> >>> _______________________________________________ >> >>> aerogear-dev mailing list >> >>> aerogear-dev at lists.jboss.org >> >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> >> >> >> _______________________________________________ >> >> aerogear-dev mailing list >> >> aerogear-dev at lists.jboss.org >> >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > >> > >> > >> > -- >> > Matthias Wessendorf >> > >> > blog: http://matthiaswessendorf.wordpress.com/ >> > sessions: http://www.slideshare.net/mwessendorf >> > twitter: http://twitter.com/mwessendorf >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf From matzew at apache.org Fri Jul 25 09:19:02 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Fri, 25 Jul 2014 15:19:02 +0200 Subject: [aerogear-dev] Differences between Firefox OS "native" Push lib and AeroGear's Push adapter In-Reply-To: <1406293568.14163.1@smtp.corp.redhat.com> References: <9B70BDB9-4774-4BF0-9FF7-5213185E4F52@redhat.com> <51C9D854-0730-4B2A-9A92-9DC92649947D@redhat.com> <8AEB32A5-0F61-495B-8EA5-767F48312B9C@redhat.com> <02064329-0F9B-49DC-A5EC-A106001DD51F@redhat.com> <1406216640.15307.0@smtp.corp.redhat.com> <1E3E76E8-60D7-4BF3-9B95-6C58F4DC9286@redhat.com> <919B56C2-8E6D-4CD8-A620-F9839E013685@redhat.com> <1406292545.14163.0@smtp.corp.redhat.com> <1406293568.14163.1@smtp.corp.redhat.com> Message-ID: On Fri, Jul 25, 2014 at 3:06 PM, Karel Piwko wrote: > On Fri, Jul 25, 2014 at 2:56 PM, Matthias Wessendorf > wrote: > > > >> UPS can translate {deviceToken} to EndpointURL. We just need a way > >> how > >> to generate unique {deviceToken} on client. > > > > that would be our own layer on-top, which is a no-go > > why? it would be there anyway. Imagine that your UPS is running on > exposed URL which is a gateway to your internal network. SP URL is > valid only in that internal network, not visible from outside world at > all. > > So, using UPS is the only way to send the message to that URL. > Hrm... let's see if I am following you. Let's try: If the UPS has a mapping between "magic_UUID" and endpointURL, that means the client layer (e.g. UPS.js) has to store this UUID somewhere, for unregistration. Instead of having the UPS generating the UUID, it could be generated by the UPS.js, and its JS callback would/could return it (so that the JS app has it handy for later unregister). That would mean the JS client would sending down the same JSON as before, right ? deviceToken: client_side_generated_UUID, pushEndpoint: someURL Did I get it ? > > > > > > >> Would UUID work? > >> EndpointURL can become part of JSON [1]. > > > > it was there as "simplePushEndpoint", but for stated reasons it's now > > the deviceToken that has the URL value > > > > > >> > >> Such change would mean that clients can't use SP server directly but > >> have to go through UPS. This makes more sense then current setup to > >> me. > > > > not really > > See reason stated above. > > > >> > >> Karel > >> > >> [1] > >> > https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/jaxrs/src/main/java/org/jboss/aerogear/unifiedpush/rest/registry/installations/InstallationRegistrationEndpoint.java#L74 > >> > >> On Fri, Jul 25, 2014 at 1:04 PM, Matthias Wessendorf > >> wrote: > >> > > >> > > >> > > >> > On Fri, Jul 25, 2014 at 12:25 PM, Tadeas Kriz > >> > wrote: > >> >> > >> >> ? > >> >> Tadeas Kriz > >> >> > >> >> On 25 Jul 2014, at 11:04 am, Daniel Bevenius > >> >> wrote: > >> >> > >> >>> >5. don?t use the url as a deviceToken (might not comply with > >> >>> Mozzila?s SimplePush specs) > >> >>> The deviceToken is an UPS concept and there is nothing in the > >> >>> SimplePush spec which is violated in this case. > >> >>> > >> >> I thought that deviceTokens were changed from a generated value to > >> >> the URL just to comply with Mozzila?s SimplePush specs. > >> > > >> > Nope > >> > > >> >> Matzew, why was the generated token removed then? > >> > > >> > It was the channelID before - but that should not be exposed. > >> > In GCM devices are identified via registrationID > >> > In APNs devices are identified va deviceToken > >> > (both are somewhat the same - but different names) > >> > > >> > In SimplePush devices are identifeid v/ the URL of the pushEndpoint > >> > (a backend uses that endpoint to notify _THAT_ client, regardless > >> of > >> > how many channels it has subscribed) > >> > > >> > So, that lead us to make the change (see history of this threa) > >> > > >> > -M > >> > > >> > > >> > > >> >> > >> >>> I'm not sure about what the best option is for UPS thought. > >> Would a > >> >>> regex in for the @Path annotation work perhaps, something like: > >> >>> > >> >>> @DELETE > >> >>> @Path("{token, .+}") > >> >>> public Response unregisterInstallations( > >> >>> > >> >> > >> >> What do you mean by that regex? The problem is simply the > >> ?%2F? > >> >> in the token (which is an URLencoded simplepush url) and it?s > >> >> being revoked long before it hits the RestEasy (which does the > >> >> routing according to what?s in the @Path). > >> >> > >> >>> > >> >>> On 25 July 2014 10:32, Tadeas Kriz wrote: > >> >>>> > >> >>>> ? > >> >>>> Tadeas Kriz > >> >>>> > >> >>>> On 24 Jul 2014, at 05:44 pm, Karel Piwko > >> wrote: > >> >>>> > >> >>>> > On Thu, Jul 24, 2014 at 3:28 PM, Tadeas Kriz > >> > >> >>>> wrote: > >> >>>> >> > >> >>>> >> It should not. For hibernate, it?s just a string like any > >> >>>> other. > >> >>>> >> The problem might be in the configuration of > >> JAX.RS/RestEasy. If > >> >>>> >> I?ll have some time today evening, I?ll try to fix it, it > >> >>>> should > >> >>>> >> be an easy fix. > >> >>>> > > >> >>>> > Last famous words? ;-) > >> >>>> > > >> >>>> > >> >>>> I shall never say ?an easy fix? again. > >> >>>> > >> >>>> > But I agree. Everything is string and URL encode should > >> happen on > >> >>>> > client while server should automatically decode and work > >> always > >> >>>> with > >> >>>> > just decoded string. If we need to encode twice, something is > >> >>>> wrong. > >> >>>> > > >> >>>> > >> >>>> Anyway, the 400 Bad request response is made by the tomcat > >> itself, > >> >>>> disallowing the use of %2F as a path parameter. This will > >> probably > >> >>>> apply on other web containers. > >> >>>> > >> >>>> Possible solutions with their disadvantages: > >> >>>> > >> >>>> 1. well-documented double-encoding of the URL (might be > >> confusing) > >> >>>> 2. use @QueryParam instead of @PathParam (breaks the api > >> >>>> consistence, as every other call would still use @PathParam) > >> >>>> 3. allow @QueryParam (again, breaks the api consistence, but > >> only > >> >>>> for the SimplePush) > >> >>>> 4. find another encoding (Base64 for URL = URLEncode then Base64 > >> >>>> encode) > >> >>>> 5. don?t use the url as a deviceToken (might not comply with > >> >>>> Mozzila?s SimplePush specs) > >> >>>> > >> >>>> What do you think guys? > >> >>>> > >> >>>> >> > >> >>>> >> > >> >>>> > > >> >>>> > > >> >>>> > _______________________________________________ > >> >>>> > aerogear-dev mailing list > >> >>>> > aerogear-dev at lists.jboss.org > >> >>>> > https://lists.jboss.org/mailman/listinfo/aerogear-dev > >> >>>> > >> >>>> > >> >>>> _______________________________________________ > >> >>>> aerogear-dev mailing list > >> >>>> aerogear-dev at lists.jboss.org > >> >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev > >> >>> > >> >>> _______________________________________________ > >> >>> aerogear-dev mailing list > >> >>> aerogear-dev at lists.jboss.org > >> >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev > >> >> > >> >> > >> >> _______________________________________________ > >> >> aerogear-dev mailing list > >> >> aerogear-dev at lists.jboss.org > >> >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > >> > > >> > > >> > > >> > -- > >> > Matthias Wessendorf > >> > > >> > blog: http://matthiaswessendorf.wordpress.com/ > >> > sessions: http://www.slideshare.net/mwessendorf > >> > twitter: http://twitter.com/mwessendorf > >> > >> > >> _______________________________________________ > >> aerogear-dev mailing list > >> aerogear-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > > > > -- > > Matthias Wessendorf > > > > blog: http://matthiaswessendorf.wordpress.com/ > > sessions: http://www.slideshare.net/mwessendorf > > twitter: http://twitter.com/mwessendorf > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140725/a8064497/attachment.html From bruno at abstractj.org Fri Jul 25 09:33:27 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Fri, 25 Jul 2014 10:33:27 -0300 Subject: [aerogear-dev] Differences between Firefox OS "native" Push lib and AeroGear's Push adapter In-Reply-To: References: <1406216640.15307.0@smtp.corp.redhat.com> <1E3E76E8-60D7-4BF3-9B95-6C58F4DC9286@redhat.com> <919B56C2-8E6D-4CD8-A620-F9839E013685@redhat.com> Message-ID: <20140725133326.GA14148@abstractj.org> Hi Tadeas, you are correct. Apache web server disallow %2F or %5C due to security concerns. There are several alternatives, most of them workarouds, some people double encode it, others replace / by _ back and forth or some people disable it like: AllowEncodedSlashes On I hope it helps, otherwise let me know how I can help. On 2014-07-25, Tadeas Kriz wrote: > > ? > Tadeas Kriz > > On 25 Jul 2014, at 01:09 pm, Daniel Bevenius wrote: > > > > it might work, although I?m not sure if this is the best solution ?on the market?. > > It may not be the best solution and feel free to ignore it. > > > > I?d love to test it first. My only concern is whether or not might it be a security issue. I think that?s something that Bruno might know. > > > > > > > > > On 25 July 2014 12:55, Tadeas Kriz wrote: > > > > ? > > Tadeas Kriz > > > > On 25 Jul 2014, at 12:38 pm, Daniel Bevenius wrote: > > > >> >What do you mean by that regex? > >> That the JAXRS implementation should not disallow as '/' in the path. > > > > Well, if it was like: > > > > ``` > > DELETE /rest/registry/installation/http://localhost:8321/asdasd > > ``` > > > > and the token you showed would match all the characters (which means that the `String token` would become `http://localhost:8321/asdasd` in the endpoint method), it might work, although I?m not sure if this is the best solution ?on the market?. > > > >> > >> >The problem is simply the ?%2F? in the token (which is an URLencoded simplepush url) and it?s being revoked long before it hits the RestEasy (which does the routing according to what?s in the @Path). > >> I guess I don't understand why this would be revoked by anything before it hits the JAXRS implementation, but if that is the case you are right and adding this would not help. > >> > > > > This was a solution for a security hole. As I understand it, on linux, scripts cannot tell difference between ?/? and ?%2F? and because of that, it?s forbidden to use as a path parameter (at least on Tomcat). > > > >> > >> > >> > >> > >> > >> On 25 July 2014 12:25, Tadeas Kriz wrote: > >> > >> ? > >> Tadeas Kriz > >> > >> On 25 Jul 2014, at 11:04 am, Daniel Bevenius wrote: > >> > >>> >5. don?t use the url as a deviceToken (might not comply with Mozzila?s SimplePush specs) > >>> The deviceToken is an UPS concept and there is nothing in the SimplePush spec which is violated in this case. > >>> > >> > >> I thought that deviceTokens were changed from a generated value to the URL just to comply with Mozzila?s SimplePush specs. Matzew, why was the generated token removed then? > >> > >>> I'm not sure about what the best option is for UPS thought. Would a regex in for the @Path annotation work perhaps, something like: > >>> > >>> @DELETE > >>> @Path("{token, .+}") > >>> public Response unregisterInstallations( > >>> > >> > >> What do you mean by that regex? The problem is simply the ?%2F? in the token (which is an URLencoded simplepush url) and it?s being revoked long before it hits the RestEasy (which does the routing according to what?s in the @Path). > >> > >>> > >>> On 25 July 2014 10:32, Tadeas Kriz wrote: > >>> > >>> ? > >>> Tadeas Kriz > >>> > >>> On 24 Jul 2014, at 05:44 pm, Karel Piwko wrote: > >>> > >>> > On Thu, Jul 24, 2014 at 3:28 PM, Tadeas Kriz wrote: > >>> >> > >>> >> It should not. For hibernate, it?s just a string like any other. > >>> >> The problem might be in the configuration of JAX.RS/RestEasy. If > >>> >> I?ll have some time today evening, I?ll try to fix it, it should > >>> >> be an easy fix. > >>> > > >>> > Last famous words? ;-) > >>> > > >>> > >>> I shall never say ?an easy fix? again. > >>> > >>> > But I agree. Everything is string and URL encode should happen on > >>> > client while server should automatically decode and work always with > >>> > just decoded string. If we need to encode twice, something is wrong. > >>> > > >>> > >>> Anyway, the 400 Bad request response is made by the tomcat itself, disallowing the use of %2F as a path parameter. This will probably apply on other web containers. > >>> > >>> Possible solutions with their disadvantages: > >>> > >>> 1. well-documented double-encoding of the URL (might be confusing) > >>> 2. use @QueryParam instead of @PathParam (breaks the api consistence, as every other call would still use @PathParam) > >>> 3. allow @QueryParam (again, breaks the api consistence, but only for the SimplePush) > >>> 4. find another encoding (Base64 for URL = URLEncode then Base64 encode) > >>> 5. don?t use the url as a deviceToken (might not comply with Mozzila?s SimplePush specs) > >>> > >>> What do you think guys? > >>> > >>> >> > >>> >> > >>> > > >>> > > >>> > _______________________________________________ > >>> > aerogear-dev mailing list > >>> > aerogear-dev at lists.jboss.org > >>> > https://lists.jboss.org/mailman/listinfo/aerogear-dev > >>> > >>> > >>> _______________________________________________ > >>> aerogear-dev mailing list > >>> aerogear-dev at lists.jboss.org > >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev > >>> > >>> _______________________________________________ > >>> aerogear-dev mailing list > >>> aerogear-dev at lists.jboss.org > >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev > >> > >> > >> _______________________________________________ > >> aerogear-dev mailing list > >> aerogear-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > >> > >> _______________________________________________ > >> aerogear-dev mailing list > >> aerogear-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- abstractj PGP: 0x84DC9914 From matzew at apache.org Fri Jul 25 09:38:50 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Fri, 25 Jul 2014 15:38:50 +0200 Subject: [aerogear-dev] Differences between Firefox OS "native" Push lib and AeroGear's Push adapter In-Reply-To: <20140725133326.GA14148@abstractj.org> References: <1406216640.15307.0@smtp.corp.redhat.com> <1E3E76E8-60D7-4BF3-9B95-6C58F4DC9286@redhat.com> <919B56C2-8E6D-4CD8-A620-F9839E013685@redhat.com> <20140725133326.GA14148@abstractj.org> Message-ID: On Fri, Jul 25, 2014 at 3:33 PM, Bruno Oliveira wrote: > Hi Tadeas, you are correct. Apache web server disallow %2F or %5C > due to security concerns. There are several alternatives, most of them > workarouds, some people double encode it, others replace / by _ back and > forth or some people disable it like: > > > AllowEncodedSlashes On > > so, looks like it was a stupid idea to use the pushEndpoint as the 'deviceToken'. Perhaps we should make UPS.js generate a UUID and use that as deviceToken and send the pushEndpoint as part of the JSON, similar to like we did before. (But before we were using the SimplePush channelID as the deviceToken, which is clearly a no-go) > > I hope it helps, otherwise let me know how I can help. > > On 2014-07-25, Tadeas Kriz wrote: > > > > ? > > Tadeas Kriz > > > > On 25 Jul 2014, at 01:09 pm, Daniel Bevenius > wrote: > > > > > > it might work, although I?m not sure if this is the best solution > ?on the market?. > > > It may not be the best solution and feel free to ignore it. > > > > > > > I?d love to test it first. My only concern is whether or not might it be > a security issue. I think that?s something that Bruno might know. > > > > > > > > > > > > > > On 25 July 2014 12:55, Tadeas Kriz wrote: > > > > > > ? > > > Tadeas Kriz > > > > > > On 25 Jul 2014, at 12:38 pm, Daniel Bevenius < > daniel.bevenius at gmail.com> wrote: > > > > > >> >What do you mean by that regex? > > >> That the JAXRS implementation should not disallow as '/' in the path. > > > > > > Well, if it was like: > > > > > > ``` > > > DELETE /rest/registry/installation/http://localhost:8321/asdasd > > > ``` > > > > > > and the token you showed would match all the characters (which means > that the `String token` would become `http://localhost:8321/asdasd` in > the endpoint method), it might work, although I?m not sure if this is the > best solution ?on the market?. > > > > > >> > > >> >The problem is simply the ?%2F? in the token (which is an URLencoded > simplepush url) and it?s being revoked long before it hits the RestEasy > (which does the routing according to what?s in the @Path). > > >> I guess I don't understand why this would be revoked by anything > before it hits the JAXRS implementation, but if that is the case you are > right and adding this would not help. > > >> > > > > > > This was a solution for a security hole. As I understand it, on linux, > scripts cannot tell difference between ?/? and ?%2F? and because of that, > it?s forbidden to use as a path parameter (at least on Tomcat). > > > > > >> > > >> > > >> > > >> > > >> > > >> On 25 July 2014 12:25, Tadeas Kriz wrote: > > >> > > >> ? > > >> Tadeas Kriz > > >> > > >> On 25 Jul 2014, at 11:04 am, Daniel Bevenius < > daniel.bevenius at gmail.com> wrote: > > >> > > >>> >5. don?t use the url as a deviceToken (might not comply with > Mozzila?s SimplePush specs) > > >>> The deviceToken is an UPS concept and there is nothing in the > SimplePush spec which is violated in this case. > > >>> > > >> > > >> I thought that deviceTokens were changed from a generated value to > the URL just to comply with Mozzila?s SimplePush specs. Matzew, why was the > generated token removed then? > > >> > > >>> I'm not sure about what the best option is for UPS thought. Would a > regex in for the @Path annotation work perhaps, something like: > > >>> > > >>> @DELETE > > >>> @Path("{token, .+}") > > >>> public Response unregisterInstallations( > > >>> > > >> > > >> What do you mean by that regex? The problem is simply the ?%2F? in > the token (which is an URLencoded simplepush url) and it?s being revoked > long before it hits the RestEasy (which does the routing according to > what?s in the @Path). > > >> > > >>> > > >>> On 25 July 2014 10:32, Tadeas Kriz wrote: > > >>> > > >>> ? > > >>> Tadeas Kriz > > >>> > > >>> On 24 Jul 2014, at 05:44 pm, Karel Piwko wrote: > > >>> > > >>> > On Thu, Jul 24, 2014 at 3:28 PM, Tadeas Kriz > wrote: > > >>> >> > > >>> >> It should not. For hibernate, it?s just a string like any other. > > >>> >> The problem might be in the configuration of JAX.RS/RestEasy. If > > >>> >> I?ll have some time today evening, I?ll try to fix it, it should > > >>> >> be an easy fix. > > >>> > > > >>> > Last famous words? ;-) > > >>> > > > >>> > > >>> I shall never say ?an easy fix? again. > > >>> > > >>> > But I agree. Everything is string and URL encode should happen on > > >>> > client while server should automatically decode and work always > with > > >>> > just decoded string. If we need to encode twice, something is > wrong. > > >>> > > > >>> > > >>> Anyway, the 400 Bad request response is made by the tomcat itself, > disallowing the use of %2F as a path parameter. This will probably apply on > other web containers. > > >>> > > >>> Possible solutions with their disadvantages: > > >>> > > >>> 1. well-documented double-encoding of the URL (might be confusing) > > >>> 2. use @QueryParam instead of @PathParam (breaks the api > consistence, as every other call would still use @PathParam) > > >>> 3. allow @QueryParam (again, breaks the api consistence, but only > for the SimplePush) > > >>> 4. find another encoding (Base64 for URL = URLEncode then Base64 > encode) > > >>> 5. don?t use the url as a deviceToken (might not comply with > Mozzila?s SimplePush specs) > > >>> > > >>> What do you think guys? > > >>> > > >>> >> > > >>> >> > > >>> > > > >>> > > > >>> > _______________________________________________ > > >>> > aerogear-dev mailing list > > >>> > aerogear-dev at lists.jboss.org > > >>> > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > >>> > > >>> > > >>> _______________________________________________ > > >>> aerogear-dev mailing list > > >>> aerogear-dev at lists.jboss.org > > >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > >>> > > >>> _______________________________________________ > > >>> aerogear-dev mailing list > > >>> aerogear-dev at lists.jboss.org > > >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > >> > > >> > > >> _______________________________________________ > > >> aerogear-dev mailing list > > >> aerogear-dev at lists.jboss.org > > >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > >> > > >> _______________________________________________ > > >> aerogear-dev mailing list > > >> aerogear-dev at lists.jboss.org > > >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > > > > > _______________________________________________ > > > aerogear-dev mailing list > > > aerogear-dev at lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > > _______________________________________________ > > > aerogear-dev mailing list > > > aerogear-dev at lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > -- > > abstractj > PGP: 0x84DC9914 > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140725/c1d1685b/attachment.html From daniel at passos.me Fri Jul 25 09:47:10 2014 From: daniel at passos.me (Daniel Passos) Date: Fri, 25 Jul 2014 10:47:10 -0300 Subject: [aerogear-dev] Modularizing the Android Library In-Reply-To: References: <5317317F.1010209@redhat.com> <20140306143829.65e1e4aa@kapy-ntb-x220> <20140508192800.GB69433@abstractj.org> <4CD71A7A-EDE1-4648-AB3E-E4DDB383D824@gmail.com> Message-ID: On Fri, Jul 25, 2014 at 4:09 AM, Matthias Wessendorf wrote: > > > On Tue, Jul 22, 2014 at 4:12 PM, Daniel Passos wrote: > >> Hey Guys, >> >> Summers and I started working on agdroid modules and remove some cyclic >> dependencies. So we plan to split the agdroid on these modules: >> >> - aerogear-android-core >> - aerogear-android-pipe >> - aerogear-android-auth >> - aerogear-android-autz >> - aerogear-android-store (with option security dependecy to use >> EncryptedStores) >> - aerogear-android-security >> - aerogear-android-push >> >> is that for, SimplePush (I think summers did a poc there) and straight > GCM ? > No. I explained that in my last email. For simple-push we'll create a new one like *-simplepush or *-sp. > >> - aerogear-android-push-ups >> - aerogear-android-offline >> >> -- Passos >> ? >> >> >> On Fri, May 9, 2014 at 3:55 AM, Corinne Krych >> wrote: >> >>> Oops >>> [2] https://issues.jboss.org/browse/AGIOS-187 >>> >>> On 09 May 2014, at 08:52, Corinne Krych wrote: >>> >>> > [2] https://issues.jboss.org/browse/AGIOS-192 >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140725/9dbfb759/attachment-0001.html From matzew at apache.org Fri Jul 25 10:02:56 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Fri, 25 Jul 2014 16:02:56 +0200 Subject: [aerogear-dev] Modularizing the Android Library In-Reply-To: References: <5317317F.1010209@redhat.com> <20140306143829.65e1e4aa@kapy-ntb-x220> <20140508192800.GB69433@abstractj.org> <4CD71A7A-EDE1-4648-AB3E-E4DDB383D824@gmail.com> Message-ID: On Fri, Jul 25, 2014 at 3:47 PM, Daniel Passos wrote: > On Fri, Jul 25, 2014 at 4:09 AM, Matthias Wessendorf > wrote: >> >> >> On Tue, Jul 22, 2014 at 4:12 PM, Daniel Passos wrote: >> >>> Hey Guys, >>> >>> Summers and I started working on agdroid modules and remove some cyclic >>> dependencies. So we plan to split the agdroid on these modules: >>> >>> - aerogear-android-core >>> - aerogear-android-pipe >>> - aerogear-android-auth >>> - aerogear-android-autz >>> - aerogear-android-store (with option security dependecy to use >>> EncryptedStores) >>> - aerogear-android-security >>> - aerogear-android-push >>> >>> is that for, SimplePush (I think summers did a poc there) and straight >> GCM ? >> > > No. I explained that in my last email. For simple-push we'll create a new > one like *-simplepush or *-sp. > perfect > >>> - aerogear-android-push-ups >>> - aerogear-android-offline >>> >>> -- Passos >>> ? >>> >>> >>> On Fri, May 9, 2014 at 3:55 AM, Corinne Krych >>> wrote: >>> >>>> Oops >>>> [2] https://issues.jboss.org/browse/AGIOS-187 >>>> >>>> On 09 May 2014, at 08:52, Corinne Krych wrote: >>>> >>>> > [2] https://issues.jboss.org/browse/AGIOS-192 >>> >>> > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140725/64ea2583/attachment.html From bruno at abstractj.org Fri Jul 25 10:11:14 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Fri, 25 Jul 2014 11:11:14 -0300 Subject: [aerogear-dev] News from iOS Modules front In-Reply-To: <96E5A52E-9917-4AFA-81C1-464D036DABD5@gmail.com> References: <78957F0D-27BC-49B8-9F47-5905FA3F55A7@gmail.com> <96E5A52E-9917-4AFA-81C1-464D036DABD5@gmail.com> Message-ID: <20140725141114.GB14148@abstractj.org> Hi Corinne, I'm not against removing the prefix, but to keep the consistency, if the remove is called potatos-iOS, it must have the same name on Cocoapods. We discussed this during the F2F about getting rid of the prefix, but I'm not sure what has changed now to other team members. Regarding the argument of keeping it organized, that's not valid to me, is always possible to create a folder with all the projects inside. But if most of the team disagree, seems like our suggestion during the meeting is not valid anymore. On 2014-07-25, Corinne Krych wrote: > > On 25 Jul 2014, at 09:46, Sebastien Blanc wrote: > > > > > > > > > On Fri, Jul 25, 2014 at 9:37 AM, Corinne Krych wrote: > > > > On 25 Jul 2014, at 09:13, Matthias Wessendorf wrote: > > > > > > > > > > > > > > On Fri, Jul 11, 2014 at 11:20 PM, Corinne Krych wrote: > > > Hello Guys, > > > > > > Last Tuesday during our (favourite) iOS meeting [1] [2] we talked about modularization. We agreed with Android team modularization is scheduled for 2.0. > > > > > > For iOS we have several actions: > > > > > > 1. rename existing repos (too bad we don?t follow well Android convention) > > > ? aerogear-ios-crypto > > > ? aerogear-ios-push (thanks passos for the suggestion) > > > ? aerogear-ios-otp > > > ? aerogear-ios-xcode-template > > > ? aerogear-ios-cookbook > > > > > > Since we?re talking about renaming, what about dropping ?arerogear? for the repo name? > > > > > > +1 makes sense > > > > > > It looks like we don?t have the same view here. Obviously if we go renaming we will have to change all the repos. With or without, coonsistency is key. > > > > My main motivation for dropping aerogear prefex was that ag is already present in the name of the organisation. Besides as we go with fine grained modularisation, our libs can be used independently, the naming without prefix is to enforce that. > > > > @passos and all others guys not in favor for dropping prefix, may I ask why? > > > > If we put GH and organization appart, will the name "AeroGear" appears anywhere in the lib name/pod when someone install it through cocoapods ? > > > > Yeap we?ll keep aerogear as a prefix for cocoapods > https://github.com/aerogear/aerogear-otp-ios/blob/master/AeroGear-OTP.podspec#L18 > > Good question: What about the other modules? > > > > > > > > > > > all those repos belong to aerogear organization anyway. Maybe removing the aerogear part will stress more the small libraries aspect. Maybe sth we already discussed but can?t remember/find it. wdyt? > > > > > > 2. Pipe and Store deprecated. All aerogear-ios we?ll stick to 1.7 version and will be marked deprecated. > > > But ?. don?t be scared new modules will replace them: > > > > > > ? aerogear-ios-http : Lightweight lib around NSURLSession to ease HTTP calls with pluggable request and response Serializers. Very very Draft version [3] with some cookbook recipe [4]. With this module we will work directly with NSURLSession (iOS foundation networking) instead of using AFNetworking. Sure Andrea will like it: no dependency :) > > > ? aerogear-ios-oauth2 : dependent on aerogear-ios-http, bring all the good stuff like AccountManager, OAuth2 extensible adapters, fluid http post/get ... > > > ? aerogear-ios-storage usage of incrementalStorage to plug into Core Data > > > > > > > > > +1 all of that sounds awesome! > > > > > > > > > Those modules will be written in Swift code. We?ll test them both in iOS7 and iOS8. > > > > > > +1 on Swift! > > > > > > > > > 3. Cookbook recipes rpo > > > ? tag our repo 1.7: we didn?t have a tag strategy for cookbook demos but with the move from 1.X to 2.) I think we should > > > * Swift demo naming convention add ?-swift? for Swift version like we did [5]. We should also append ?-objc? to other recipes to be consistent. > > > > > > yeah > > > > > > > > > 4. Differentiate Swift vs Objective-C libs > > > How to differenctiate Swift code. Specially for aerogear-ios-push which will be declined in 2 versions? One suggestion from Matthias was to have 2 separate branches. > > > master -> objc-c > > > until iOS8 is released and stable. > > > I?m +1 with that idea. > > > > > > yeah, let's have ObjC on master now; > > > The master can, later this year, contain the Swift lib, and we move ObjC to be deprecated as soon as we do have iOS8 (~September) > > > > > > > > > Let me know if you have suggestions/objections. When we reach an agreement, I?ll create associated JIRA. > > > > > > ++ > > > Corinne > > > > > > [1] http://oksoclap.com/p/aerogear_ios_meeting_01072014 > > > [2] http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2014/aerogear.2014-07-08-11.42.txt > > > [3] https://github.com/corinnekrych/aerogear-ios-http > > > [4] https://github.com/corinnekrych/Weather > > > [5] https://github.com/aerogear/aerogear-push-helloworld/tree/master/ios-swift > > > _______________________________________________ > > > aerogear-dev mailing list > > > aerogear-dev at lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > > > > > > > > -- > > > Matthias Wessendorf > > > > > > blog: http://matthiaswessendorf.wordpress.com/ > > > sessions: http://www.slideshare.net/mwessendorf > > > twitter: http://twitter.com/mwessendorf > > > _______________________________________________ > > > aerogear-dev mailing list > > > aerogear-dev at lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -- abstractj PGP: 0x84DC9914 From lholmqui at redhat.com Fri Jul 25 10:16:55 2014 From: lholmqui at redhat.com (Lucas Holmquist) Date: Fri, 25 Jul 2014 10:16:55 -0400 Subject: [aerogear-dev] Differences between Firefox OS "native" Push lib and AeroGear's Push adapter In-Reply-To: References: <1406216640.15307.0@smtp.corp.redhat.com> <1E3E76E8-60D7-4BF3-9B95-6C58F4DC9286@redhat.com> <919B56C2-8E6D-4CD8-A620-F9839E013685@redhat.com> <20140725133326.GA14148@abstractj.org> Message-ID: On Jul 25, 2014, at 9:38 AM, Matthias Wessendorf wrote: > > > > On Fri, Jul 25, 2014 at 3:33 PM, Bruno Oliveira wrote: > Hi Tadeas, you are correct. Apache web server disallow %2F or %5C > due to security concerns. There are several alternatives, most of them > workarouds, some people double encode it, others replace / by _ back and > forth or some people disable it like: > > > AllowEncodedSlashes On > > > so, looks like it was a stupid idea to use the pushEndpoint as the 'deviceToken'. > > Perhaps we should make UPS.js generate a UUID and use that as deviceToken and send the pushEndpoint as part of the JSON, similar to like we did before. > (But before we were using the SimplePush channelID as the deviceToken, which is clearly a no-go) i?ll need to look into this more, but i sort of like the fact that the UPS.js is somewhat stateless and doesn?t care about SimplePush, since it is also used for GCM for Chrome > > > I hope it helps, otherwise let me know how I can help. > > On 2014-07-25, Tadeas Kriz wrote: > > > > ? > > Tadeas Kriz > > > > On 25 Jul 2014, at 01:09 pm, Daniel Bevenius wrote: > > > > > > it might work, although I?m not sure if this is the best solution ?on the market?. > > > It may not be the best solution and feel free to ignore it. > > > > > > > I?d love to test it first. My only concern is whether or not might it be a security issue. I think that?s something that Bruno might know. > > > > > > > > > > > > > > On 25 July 2014 12:55, Tadeas Kriz wrote: > > > > > > ? > > > Tadeas Kriz > > > > > > On 25 Jul 2014, at 12:38 pm, Daniel Bevenius wrote: > > > > > >> >What do you mean by that regex? > > >> That the JAXRS implementation should not disallow as '/' in the path. > > > > > > Well, if it was like: > > > > > > ``` > > > DELETE /rest/registry/installation/http://localhost:8321/asdasd > > > ``` > > > > > > and the token you showed would match all the characters (which means that the `String token` would become `http://localhost:8321/asdasd` in the endpoint method), it might work, although I?m not sure if this is the best solution ?on the market?. > > > > > >> > > >> >The problem is simply the ?%2F? in the token (which is an URLencoded simplepush url) and it?s being revoked long before it hits the RestEasy (which does the routing according to what?s in the @Path). > > >> I guess I don't understand why this would be revoked by anything before it hits the JAXRS implementation, but if that is the case you are right and adding this would not help. > > >> > > > > > > This was a solution for a security hole. As I understand it, on linux, scripts cannot tell difference between ?/? and ?%2F? and because of that, it?s forbidden to use as a path parameter (at least on Tomcat). > > > > > >> > > >> > > >> > > >> > > >> > > >> On 25 July 2014 12:25, Tadeas Kriz wrote: > > >> > > >> ? > > >> Tadeas Kriz > > >> > > >> On 25 Jul 2014, at 11:04 am, Daniel Bevenius wrote: > > >> > > >>> >5. don?t use the url as a deviceToken (might not comply with Mozzila?s SimplePush specs) > > >>> The deviceToken is an UPS concept and there is nothing in the SimplePush spec which is violated in this case. > > >>> > > >> > > >> I thought that deviceTokens were changed from a generated value to the URL just to comply with Mozzila?s SimplePush specs. Matzew, why was the generated token removed then? > > >> > > >>> I'm not sure about what the best option is for UPS thought. Would a regex in for the @Path annotation work perhaps, something like: > > >>> > > >>> @DELETE > > >>> @Path("{token, .+}") > > >>> public Response unregisterInstallations( > > >>> > > >> > > >> What do you mean by that regex? The problem is simply the ?%2F? in the token (which is an URLencoded simplepush url) and it?s being revoked long before it hits the RestEasy (which does the routing according to what?s in the @Path). > > >> > > >>> > > >>> On 25 July 2014 10:32, Tadeas Kriz wrote: > > >>> > > >>> ? > > >>> Tadeas Kriz > > >>> > > >>> On 24 Jul 2014, at 05:44 pm, Karel Piwko wrote: > > >>> > > >>> > On Thu, Jul 24, 2014 at 3:28 PM, Tadeas Kriz wrote: > > >>> >> > > >>> >> It should not. For hibernate, it?s just a string like any other. > > >>> >> The problem might be in the configuration of JAX.RS/RestEasy. If > > >>> >> I?ll have some time today evening, I?ll try to fix it, it should > > >>> >> be an easy fix. > > >>> > > > >>> > Last famous words? ;-) > > >>> > > > >>> > > >>> I shall never say ?an easy fix? again. > > >>> > > >>> > But I agree. Everything is string and URL encode should happen on > > >>> > client while server should automatically decode and work always with > > >>> > just decoded string. If we need to encode twice, something is wrong. > > >>> > > > >>> > > >>> Anyway, the 400 Bad request response is made by the tomcat itself, disallowing the use of %2F as a path parameter. This will probably apply on other web containers. > > >>> > > >>> Possible solutions with their disadvantages: > > >>> > > >>> 1. well-documented double-encoding of the URL (might be confusing) > > >>> 2. use @QueryParam instead of @PathParam (breaks the api consistence, as every other call would still use @PathParam) > > >>> 3. allow @QueryParam (again, breaks the api consistence, but only for the SimplePush) > > >>> 4. find another encoding (Base64 for URL = URLEncode then Base64 encode) > > >>> 5. don?t use the url as a deviceToken (might not comply with Mozzila?s SimplePush specs) > > >>> > > >>> What do you think guys? > > >>> > > >>> >> > > >>> >> > > >>> > > > >>> > > > >>> > _______________________________________________ > > >>> > aerogear-dev mailing list > > >>> > aerogear-dev at lists.jboss.org > > >>> > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > >>> > > >>> > > >>> _______________________________________________ > > >>> aerogear-dev mailing list > > >>> aerogear-dev at lists.jboss.org > > >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > >>> > > >>> _______________________________________________ > > >>> aerogear-dev mailing list > > >>> aerogear-dev at lists.jboss.org > > >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > >> > > >> > > >> _______________________________________________ > > >> aerogear-dev mailing list > > >> aerogear-dev at lists.jboss.org > > >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > >> > > >> _______________________________________________ > > >> aerogear-dev mailing list > > >> aerogear-dev at lists.jboss.org > > >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > > > > > _______________________________________________ > > > aerogear-dev mailing list > > > aerogear-dev at lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > > _______________________________________________ > > > aerogear-dev mailing list > > > aerogear-dev at lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > -- > > abstractj > PGP: 0x84DC9914 > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140725/442871bb/attachment-0001.html From matzew at apache.org Fri Jul 25 10:22:04 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Fri, 25 Jul 2014 16:22:04 +0200 Subject: [aerogear-dev] News from iOS Modules front In-Reply-To: <20140725141114.GB14148@abstractj.org> References: <78957F0D-27BC-49B8-9F47-5905FA3F55A7@gmail.com> <96E5A52E-9917-4AFA-81C1-464D036DABD5@gmail.com> <20140725141114.GB14148@abstractj.org> Message-ID: On Fri, Jul 25, 2014 at 4:11 PM, Bruno Oliveira wrote: > Hi Corinne, > > I'm not against removing the prefix, but to keep the consistency, if the > remove is called potatos-iOS, it must have the same name on Cocoapods. > > We discussed this during the F2F about getting rid of the prefix, but I'm > not > sure what has changed now to other team members. Regarding the argument > of keeping it organized, that's not valid to me, is always possible to > create a > folder with all the projects inside. > > But if most of the team disagree, seems like our suggestion during the > meeting is not valid anymore. > * gh/ag/ag-foo -> feels redundant, so gh/ag/foo does make sense, yeah ** forks... there is still the "forked from gh/ag/foo" * on java, we have APIs and JAR names, I'd think the aerogear name is still visible there. the jar for "gh/ag/foo", could still be named aearogear-foo-1.0.0 (including the o.j.a packages) * On JS we have namesspaces on the API (e.g. AG.Notifier) - on iOS we have classes (AGBlah) And I now recall Bruno's original point: making it more interesting to others, hence droppoing the name. Even if the get rid of the ag-foo, and name if "foo", its fineprint does not take away the aerogear brand. -Matthias > > > On 2014-07-25, Corinne Krych wrote: > > > > On 25 Jul 2014, at 09:46, Sebastien Blanc wrote: > > > > > > > > > > > > > > On Fri, Jul 25, 2014 at 9:37 AM, Corinne Krych > wrote: > > > > > > On 25 Jul 2014, at 09:13, Matthias Wessendorf > wrote: > > > > > > > > > > > > > > > > > > > On Fri, Jul 11, 2014 at 11:20 PM, Corinne Krych < > corinnekrych at gmail.com> wrote: > > > > Hello Guys, > > > > > > > > Last Tuesday during our (favourite) iOS meeting [1] [2] we talked > about modularization. We agreed with Android team modularization is > scheduled for 2.0. > > > > > > > > For iOS we have several actions: > > > > > > > > 1. rename existing repos (too bad we don?t follow well Android > convention) > > > > ? aerogear-ios-crypto > > > > ? aerogear-ios-push (thanks passos for the suggestion) > > > > ? aerogear-ios-otp > > > > ? aerogear-ios-xcode-template > > > > ? aerogear-ios-cookbook > > > > > > > > Since we?re talking about renaming, what about dropping ?arerogear? > for the repo name? > > > > > > > > +1 makes sense > > > > > > > > > It looks like we don?t have the same view here. Obviously if we go > renaming we will have to change all the repos. With or without, > coonsistency is key. > > > > > > My main motivation for dropping aerogear prefex was that ag is already > present in the name of the organisation. Besides as we go with fine grained > modularisation, our libs can be used independently, the naming without > prefix is to enforce that. > > > > > > @passos and all others guys not in favor for dropping prefix, may I > ask why? > > > > > > If we put GH and organization appart, will the name "AeroGear" appears > anywhere in the lib name/pod when someone install it through cocoapods ? > > > > > > > Yeap we?ll keep aerogear as a prefix for cocoapods > > > https://github.com/aerogear/aerogear-otp-ios/blob/master/AeroGear-OTP.podspec#L18 > > > > Good question: What about the other modules? > > > > > > > > > > > > > > > > all those repos belong to aerogear organization anyway. Maybe > removing the aerogear part will stress more the small libraries aspect. > Maybe sth we already discussed but can?t remember/find it. wdyt? > > > > > > > > 2. Pipe and Store deprecated. All aerogear-ios we?ll stick to 1.7 > version and will be marked deprecated. > > > > But ?. don?t be scared new modules will replace them: > > > > > > > > ? aerogear-ios-http : Lightweight lib around NSURLSession to ease > HTTP calls with pluggable request and response Serializers. Very very Draft > version [3] with some cookbook recipe [4]. With this module we will work > directly with NSURLSession (iOS foundation networking) instead of using > AFNetworking. Sure Andrea will like it: no dependency :) > > > > ? aerogear-ios-oauth2 : dependent on aerogear-ios-http, bring all > the good stuff like AccountManager, OAuth2 extensible adapters, fluid http > post/get ... > > > > ? aerogear-ios-storage usage of incrementalStorage to plug into Core > Data > > > > > > > > > > > > +1 all of that sounds awesome! > > > > > > > > > > > > Those modules will be written in Swift code. We?ll test them both in > iOS7 and iOS8. > > > > > > > > +1 on Swift! > > > > > > > > > > > > 3. Cookbook recipes rpo > > > > ? tag our repo 1.7: we didn?t have a tag strategy for cookbook demos > but with the move from 1.X to 2.) I think we should > > > > * Swift demo naming convention add ?-swift? for Swift version like > we did [5]. We should also append ?-objc? to other recipes to be consistent. > > > > > > > > yeah > > > > > > > > > > > > 4. Differentiate Swift vs Objective-C libs > > > > How to differenctiate Swift code. Specially for aerogear-ios-push > which will be declined in 2 versions? One suggestion from Matthias was to > have 2 separate branches. > > > > master -> objc-c > > > > until iOS8 is released and stable. > > > > I?m +1 with that idea. > > > > > > > > yeah, let's have ObjC on master now; > > > > The master can, later this year, contain the Swift lib, and we move > ObjC to be deprecated as soon as we do have iOS8 (~September) > > > > > > > > > > > > Let me know if you have suggestions/objections. When we reach an > agreement, I?ll create associated JIRA. > > > > > > > > ++ > > > > Corinne > > > > > > > > [1] http://oksoclap.com/p/aerogear_ios_meeting_01072014 > > > > [2] > http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2014/aerogear.2014-07-08-11.42.txt > > > > [3] https://github.com/corinnekrych/aerogear-ios-http > > > > [4] https://github.com/corinnekrych/Weather > > > > [5] > https://github.com/aerogear/aerogear-push-helloworld/tree/master/ios-swift > > > > _______________________________________________ > > > > aerogear-dev mailing list > > > > aerogear-dev at lists.jboss.org > > > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > > > > > > > > > > > > -- > > > > Matthias Wessendorf > > > > > > > > blog: http://matthiaswessendorf.wordpress.com/ > > > > sessions: http://www.slideshare.net/mwessendorf > > > > twitter: http://twitter.com/mwessendorf > > > > _______________________________________________ > > > > aerogear-dev mailing list > > > > aerogear-dev at lists.jboss.org > > > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > > > > > _______________________________________________ > > > aerogear-dev mailing list > > > aerogear-dev at lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > > _______________________________________________ > > > aerogear-dev mailing list > > > aerogear-dev at lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > -- > > abstractj > PGP: 0x84DC9914 > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140725/a46d0162/attachment.html From matzew at apache.org Fri Jul 25 10:29:10 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Fri, 25 Jul 2014 16:29:10 +0200 Subject: [aerogear-dev] Differences between Firefox OS "native" Push lib and AeroGear's Push adapter In-Reply-To: References: <1406216640.15307.0@smtp.corp.redhat.com> <1E3E76E8-60D7-4BF3-9B95-6C58F4DC9286@redhat.com> <919B56C2-8E6D-4CD8-A620-F9839E013685@redhat.com> <20140725133326.GA14148@abstractj.org> Message-ID: On Fri, Jul 25, 2014 at 4:16 PM, Lucas Holmquist wrote: > > On Jul 25, 2014, at 9:38 AM, Matthias Wessendorf > wrote: > > > > > On Fri, Jul 25, 2014 at 3:33 PM, Bruno Oliveira > wrote: > >> Hi Tadeas, you are correct. Apache web server disallow %2F or %5C >> due to security concerns. There are several alternatives, most of them >> workarouds, some people double encode it, others replace / by _ back and >> forth or some people disable it like: >> >> >> AllowEncodedSlashes On >> >> > > so, looks like it was a stupid idea to use the pushEndpoint as the > 'deviceToken'. > > Perhaps we should make UPS.js generate a UUID and use that as deviceToken > and send the pushEndpoint as part of the JSON, similar to like we did > before. > (But before we were using the SimplePush channelID as the deviceToken, > which is clearly a no-go) > > > i?ll need to look into this more, but i sort of like the fact that the > UPS.js is somewhat stateless and doesn?t care about SimplePush, since it > is also used for GCM for Chrome > I can see that - but ... thinking... I'd also like to get rid of returning any payload from the registration endpoint. I think some of the simplifications in simplepush are part of the issue. not sure I like it, but it's just different :) > > > >> >> I hope it helps, otherwise let me know how I can help. >> >> On 2014-07-25, Tadeas Kriz wrote: >> > >> > ? >> > Tadeas Kriz >> > >> > On 25 Jul 2014, at 01:09 pm, Daniel Bevenius >> wrote: >> > >> > > > it might work, although I?m not sure if this is the best solution >> ?on the market?. >> > > It may not be the best solution and feel free to ignore it. >> > > >> > >> > I?d love to test it first. My only concern is whether or not might it >> be a security issue. I think that?s something that Bruno might know. >> > >> > > >> > > >> > > >> > > On 25 July 2014 12:55, Tadeas Kriz wrote: >> > > >> > > ? >> > > Tadeas Kriz >> > > >> > > On 25 Jul 2014, at 12:38 pm, Daniel Bevenius < >> daniel.bevenius at gmail.com> wrote: >> > > >> > >> >What do you mean by that regex? >> > >> That the JAXRS implementation should not disallow as '/' in the path. >> > > >> > > Well, if it was like: >> > > >> > > ``` >> > > DELETE /rest/registry/installation/http://localhost:8321/asdasd >> > > ``` >> > > >> > > and the token you showed would match all the characters (which means >> that the `String token` would become `http://localhost:8321/asdasd` >> in the endpoint method), it might work, >> although I?m not sure if this is the best solution ?on the market?. >> > > >> > >> >> > >> >The problem is simply the ?%2F? in the token (which is an >> URLencoded simplepush url) and it?s being revoked long before it hits the >> RestEasy (which does the routing according to what?s in the @Path). >> > >> I guess I don't understand why this would be revoked by anything >> before it hits the JAXRS implementation, but if that is the case you are >> right and adding this would not help. >> > >> >> > > >> > > This was a solution for a security hole. As I understand it, on >> linux, scripts cannot tell difference between ?/? and ?%2F? and because of >> that, it?s forbidden to use as a path parameter (at least on Tomcat). >> > > >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> On 25 July 2014 12:25, Tadeas Kriz wrote: >> > >> >> > >> ? >> > >> Tadeas Kriz >> > >> >> > >> On 25 Jul 2014, at 11:04 am, Daniel Bevenius < >> daniel.bevenius at gmail.com> wrote: >> > >> >> > >>> >5. don?t use the url as a deviceToken (might not comply with >> Mozzila?s SimplePush specs) >> > >>> The deviceToken is an UPS concept and there is nothing in the >> SimplePush spec which is violated in this case. >> > >>> >> > >> >> > >> I thought that deviceTokens were changed from a generated value to >> the URL just to comply with Mozzila?s SimplePush specs. Matzew, why was the >> generated token removed then? >> > >> >> > >>> I'm not sure about what the best option is for UPS thought. Would a >> regex in for the @Path annotation work perhaps, something like: >> > >>> >> > >>> @DELETE >> > >>> @Path("{token, .+}") >> > >>> public Response unregisterInstallations( >> > >>> >> > >> >> > >> What do you mean by that regex? The problem is simply the ?%2F? in >> the token (which is an URLencoded simplepush url) and it?s being revoked >> long before it hits the RestEasy (which does the routing according to >> what?s in the @Path). >> > >> >> > >>> >> > >>> On 25 July 2014 10:32, Tadeas Kriz wrote: >> > >>> >> > >>> ? >> > >>> Tadeas Kriz >> > >>> >> > >>> On 24 Jul 2014, at 05:44 pm, Karel Piwko wrote: >> > >>> >> > >>> > On Thu, Jul 24, 2014 at 3:28 PM, Tadeas Kriz >> wrote: >> > >>> >> >> > >>> >> It should not. For hibernate, it?s just a string like any other. >> > >>> >> The problem might be in the configuration of JAX.RS/RestEasy >> . If >> > >>> >> I?ll have some time today evening, I?ll try to fix it, it should >> > >>> >> be an easy fix. >> > >>> > >> > >>> > Last famous words? ;-) >> > >>> > >> > >>> >> > >>> I shall never say ?an easy fix? again. >> > >>> >> > >>> > But I agree. Everything is string and URL encode should happen on >> > >>> > client while server should automatically decode and work always >> with >> > >>> > just decoded string. If we need to encode twice, something is >> wrong. >> > >>> > >> > >>> >> > >>> Anyway, the 400 Bad request response is made by the tomcat itself, >> disallowing the use of %2F as a path parameter. This will probably apply on >> other web containers. >> > >>> >> > >>> Possible solutions with their disadvantages: >> > >>> >> > >>> 1. well-documented double-encoding of the URL (might be confusing) >> > >>> 2. use @QueryParam instead of @PathParam (breaks the api >> consistence, as every other call would still use @PathParam) >> > >>> 3. allow @QueryParam (again, breaks the api consistence, but only >> for the SimplePush) >> > >>> 4. find another encoding (Base64 for URL = URLEncode then Base64 >> encode) >> > >>> 5. don?t use the url as a deviceToken (might not comply with >> Mozzila?s SimplePush specs) >> > >>> >> > >>> What do you think guys? >> > >>> >> > >>> >> >> > >>> >> >> > >>> > >> > >>> > >> > >>> > _______________________________________________ >> > >>> > aerogear-dev mailing list >> > >>> > aerogear-dev at lists.jboss.org >> > >>> > https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > >>> >> > >>> >> > >>> _______________________________________________ >> > >>> aerogear-dev mailing list >> > >>> aerogear-dev at lists.jboss.org >> > >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > >>> >> > >>> _______________________________________________ >> > >>> aerogear-dev mailing list >> > >>> aerogear-dev at lists.jboss.org >> > >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > >> >> > >> >> > >> _______________________________________________ >> > >> aerogear-dev mailing list >> > >> aerogear-dev at lists.jboss.org >> > >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > >> >> > >> _______________________________________________ >> > >> aerogear-dev mailing list >> > >> aerogear-dev at lists.jboss.org >> > >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > >> > > >> > > _______________________________________________ >> > > aerogear-dev mailing list >> > > aerogear-dev at lists.jboss.org >> > > https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > >> > > _______________________________________________ >> > > aerogear-dev mailing list >> > > aerogear-dev at lists.jboss.org >> > > https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > >> >> -- >> >> abstractj >> PGP: 0x84DC9914 >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140725/ea4a2f3b/attachment-0001.html From tkriz at redhat.com Fri Jul 25 10:33:54 2014 From: tkriz at redhat.com (Tadeas Kriz) Date: Fri, 25 Jul 2014 16:33:54 +0200 Subject: [aerogear-dev] Differences between Firefox OS "native" Push lib and AeroGear's Push adapter In-Reply-To: <20140725133326.GA14148@abstractj.org> References: <1406216640.15307.0@smtp.corp.redhat.com> <1E3E76E8-60D7-4BF3-9B95-6C58F4DC9286@redhat.com> <919B56C2-8E6D-4CD8-A620-F9839E013685@redhat.com> <20140725133326.GA14148@abstractj.org> Message-ID: ? Tadeas Kriz On 25 Jul 2014, at 03:33 pm, Bruno Oliveira wrote: > Hi Tadeas, you are correct. Apache web server disallow %2F or %5C > due to security concerns. There are several alternatives, most of them > workarouds, some people double encode it, others replace / by _ back and > forth or some people disable it like: > > > AllowEncodedSlashes On > > > I hope it helps, otherwise let me know how I can help. > Thanks, this is what I?ve found yesterday while researching this. The ?allowencodedslashes? just opens the security hole, doesn?t it? Anyway, what I meant was if it would be a possible security issue, if we could get it working without the encoded URL at all. Like Daniel propsed, to use the `.*` regex to match everything beneath the `/installation/` so the actual request would look like that? ``` DELETE /rest/registry/installation/http://localhost:8321/asdasdasdasd ``` Thanks. > On 2014-07-25, Tadeas Kriz wrote: >> >> ? >> Tadeas Kriz >> >> On 25 Jul 2014, at 01:09 pm, Daniel Bevenius wrote: >> >>>> it might work, although I?m not sure if this is the best solution ?on the market?. >>> It may not be the best solution and feel free to ignore it. >>> >> >> I?d love to test it first. My only concern is whether or not might it be a security issue. I think that?s something that Bruno might know. >> >>> >>> >>> >>> On 25 July 2014 12:55, Tadeas Kriz wrote: >>> >>> ? >>> Tadeas Kriz >>> >>> On 25 Jul 2014, at 12:38 pm, Daniel Bevenius wrote: >>> >>>>> What do you mean by that regex? >>>> That the JAXRS implementation should not disallow as '/' in the path. >>> >>> Well, if it was like: >>> >>> ``` >>> DELETE /rest/registry/installation/http://localhost:8321/asdasd >>> ``` >>> >>> and the token you showed would match all the characters (which means that the `String token` would become `http://localhost:8321/asdasd` in the endpoint method), it might work, although I?m not sure if this is the best solution ?on the market?. >>> >>>> >>>>> The problem is simply the ?%2F? in the token (which is an URLencoded simplepush url) and it?s being revoked long before it hits the RestEasy (which does the routing according to what?s in the @Path). >>>> I guess I don't understand why this would be revoked by anything before it hits the JAXRS implementation, but if that is the case you are right and adding this would not help. >>>> >>> >>> This was a solution for a security hole. As I understand it, on linux, scripts cannot tell difference between ?/? and ?%2F? and because of that, it?s forbidden to use as a path parameter (at least on Tomcat). >>> >>>> >>>> >>>> >>>> >>>> >>>> On 25 July 2014 12:25, Tadeas Kriz wrote: >>>> >>>> ? >>>> Tadeas Kriz >>>> >>>> On 25 Jul 2014, at 11:04 am, Daniel Bevenius wrote: >>>> >>>>>> 5. don?t use the url as a deviceToken (might not comply with Mozzila?s SimplePush specs) >>>>> The deviceToken is an UPS concept and there is nothing in the SimplePush spec which is violated in this case. >>>>> >>>> >>>> I thought that deviceTokens were changed from a generated value to the URL just to comply with Mozzila?s SimplePush specs. Matzew, why was the generated token removed then? >>>> >>>>> I'm not sure about what the best option is for UPS thought. Would a regex in for the @Path annotation work perhaps, something like: >>>>> >>>>> @DELETE >>>>> @Path("{token, .+}") >>>>> public Response unregisterInstallations( >>>>> >>>> >>>> What do you mean by that regex? The problem is simply the ?%2F? in the token (which is an URLencoded simplepush url) and it?s being revoked long before it hits the RestEasy (which does the routing according to what?s in the @Path). >>>> >>>>> >>>>> On 25 July 2014 10:32, Tadeas Kriz wrote: >>>>> >>>>> ? >>>>> Tadeas Kriz >>>>> >>>>> On 24 Jul 2014, at 05:44 pm, Karel Piwko wrote: >>>>> >>>>>> On Thu, Jul 24, 2014 at 3:28 PM, Tadeas Kriz wrote: >>>>>>> >>>>>>> It should not. For hibernate, it?s just a string like any other. >>>>>>> The problem might be in the configuration of JAX.RS/RestEasy. If >>>>>>> I?ll have some time today evening, I?ll try to fix it, it should >>>>>>> be an easy fix. >>>>>> >>>>>> Last famous words? ;-) >>>>>> >>>>> >>>>> I shall never say ?an easy fix? again. >>>>> >>>>>> But I agree. Everything is string and URL encode should happen on >>>>>> client while server should automatically decode and work always with >>>>>> just decoded string. If we need to encode twice, something is wrong. >>>>>> >>>>> >>>>> Anyway, the 400 Bad request response is made by the tomcat itself, disallowing the use of %2F as a path parameter. This will probably apply on other web containers. >>>>> >>>>> Possible solutions with their disadvantages: >>>>> >>>>> 1. well-documented double-encoding of the URL (might be confusing) >>>>> 2. use @QueryParam instead of @PathParam (breaks the api consistence, as every other call would still use @PathParam) >>>>> 3. allow @QueryParam (again, breaks the api consistence, but only for the SimplePush) >>>>> 4. find another encoding (Base64 for URL = URLEncode then Base64 encode) >>>>> 5. don?t use the url as a deviceToken (might not comply with Mozzila?s SimplePush specs) >>>>> >>>>> What do you think guys? >>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> aerogear-dev mailing list >>>>>> aerogear-dev at lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>> >>>>> >>>>> _______________________________________________ >>>>> aerogear-dev mailing list >>>>> aerogear-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>> >>>>> _______________________________________________ >>>>> aerogear-dev mailing list >>>>> aerogear-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> >>>> >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > -- > > abstractj > PGP: 0x84DC9914 From bruno at abstractj.org Fri Jul 25 10:53:44 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Fri, 25 Jul 2014 11:53:44 -0300 Subject: [aerogear-dev] Modularizing the Android Library In-Reply-To: References: <5317317F.1010209@redhat.com> <20140306143829.65e1e4aa@kapy-ntb-x220> <20140508192800.GB69433@abstractj.org> <4CD71A7A-EDE1-4648-AB3E-E4DDB383D824@gmail.com> <20140722150611.GA58163@abstractj.org> Message-ID: <20140725145344.GC14148@abstractj.org> My suggestion is to make a module with just "android-auth", because split it without knowing if it's necessary is not a good idea. And about android-security being used for services, that makes sense. On 2014-07-24, Daniel Passos wrote: > Hi Bruno, > > aerogear-android-security for now is only to all around KeyServices, like > PassPhrase and KeyStore. > > I'm not sure if Auth and Authz will be used together. The fact is today the > implementation is not following the same contracts, so that's the reason > why we decided to split that. > > -- Passos > > On Tue, Jul 22, 2014 at 12:06 PM, Bruno Oliveira > wrote: > > > Passos, what does aerogear-android-security stands for? Do we really > > need the authz module? My question is due to the fact that mostly it > > will be together with auth module, but I could be wrong. > > > > On 2014-07-22, Daniel Passos wrote: > > > Hey Guys, > > > > > > Summers and I started working on agdroid modules and remove some cyclic > > > dependencies. So we plan to split the agdroid on these modules: > > > > > > - aerogear-android-core > > > - aerogear-android-pipe > > > - aerogear-android-auth > > > - aerogear-android-autz > > > - aerogear-android-store (with option security dependecy to use > > > EncryptedStores) > > > - aerogear-android-security > > > - aerogear-android-push > > > - aerogear-android-push-ups > > > - aerogear-android-offline > > > > > > -- Passos > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -- abstractj PGP: 0x84DC9914 From lholmqui at redhat.com Fri Jul 25 12:02:07 2014 From: lholmqui at redhat.com (Lucas Holmquist) Date: Fri, 25 Jul 2014 12:02:07 -0400 Subject: [aerogear-dev] Differences between Firefox OS "native" Push lib and AeroGear's Push adapter In-Reply-To: References: <1406216640.15307.0@smtp.corp.redhat.com> <1E3E76E8-60D7-4BF3-9B95-6C58F4DC9286@redhat.com> <919B56C2-8E6D-4CD8-A620-F9839E013685@redhat.com> <20140725133326.GA14148@abstractj.org> Message-ID: <6C0C1654-0D6A-424D-8A26-609BCEBA00A6@redhat.com> On Jul 25, 2014, at 10:29 AM, Matthias Wessendorf wrote: > > > > On Fri, Jul 25, 2014 at 4:16 PM, Lucas Holmquist wrote: > > On Jul 25, 2014, at 9:38 AM, Matthias Wessendorf wrote: > >> >> >> >> On Fri, Jul 25, 2014 at 3:33 PM, Bruno Oliveira wrote: >> Hi Tadeas, you are correct. Apache web server disallow %2F or %5C >> due to security concerns. There are several alternatives, most of them >> workarouds, some people double encode it, others replace / by _ back and >> forth or some people disable it like: >> >> >> AllowEncodedSlashes On >> >> >> so, looks like it was a stupid idea to use the pushEndpoint as the 'deviceToken'. >> >> Perhaps we should make UPS.js generate a UUID and use that as deviceToken and send the pushEndpoint as part of the JSON, similar to like we did before. >> (But before we were using the SimplePush channelID as the deviceToken, which is clearly a no-go) > > i?ll need to look into this more, but i sort of like the fact that the UPS.js is somewhat stateless and doesn?t care about SimplePush, since it is also used for GCM for Chrome > > > I can see that - but ... thinking... I'd also like to get rid of returning any payload from the registration endpoint. I think some of the simplifications in simplepush are part of the issue. not sure didn?t realize anything is sent back, in our examples, using UPS.js, we don?t do anything with the returned value > > I like it, but it's just different :) > >> >> >> I hope it helps, otherwise let me know how I can help. >> >> On 2014-07-25, Tadeas Kriz wrote: >> > >> > ? >> > Tadeas Kriz >> > >> > On 25 Jul 2014, at 01:09 pm, Daniel Bevenius wrote: >> > >> > > > it might work, although I?m not sure if this is the best solution ?on the market?. >> > > It may not be the best solution and feel free to ignore it. >> > > >> > >> > I?d love to test it first. My only concern is whether or not might it be a security issue. I think that?s something that Bruno might know. >> > >> > > >> > > >> > > >> > > On 25 July 2014 12:55, Tadeas Kriz wrote: >> > > >> > > ? >> > > Tadeas Kriz >> > > >> > > On 25 Jul 2014, at 12:38 pm, Daniel Bevenius wrote: >> > > >> > >> >What do you mean by that regex? >> > >> That the JAXRS implementation should not disallow as '/' in the path. >> > > >> > > Well, if it was like: >> > > >> > > ``` >> > > DELETE /rest/registry/installation/http://localhost:8321/asdasd >> > > ``` >> > > >> > > and the token you showed would match all the characters (which means that the `String token` would become `http://localhost:8321/asdasd` in the endpoint method), it might work, although I?m not sure if this is the best solution ?on the market?. >> > > >> > >> >> > >> >The problem is simply the ?%2F? in the token (which is an URLencoded simplepush url) and it?s being revoked long before it hits the RestEasy (which does the routing according to what?s in the @Path). >> > >> I guess I don't understand why this would be revoked by anything before it hits the JAXRS implementation, but if that is the case you are right and adding this would not help. >> > >> >> > > >> > > This was a solution for a security hole. As I understand it, on linux, scripts cannot tell difference between ?/? and ?%2F? and because of that, it?s forbidden to use as a path parameter (at least on Tomcat). >> > > >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> On 25 July 2014 12:25, Tadeas Kriz wrote: >> > >> >> > >> ? >> > >> Tadeas Kriz >> > >> >> > >> On 25 Jul 2014, at 11:04 am, Daniel Bevenius wrote: >> > >> >> > >>> >5. don?t use the url as a deviceToken (might not comply with Mozzila?s SimplePush specs) >> > >>> The deviceToken is an UPS concept and there is nothing in the SimplePush spec which is violated in this case. >> > >>> >> > >> >> > >> I thought that deviceTokens were changed from a generated value to the URL just to comply with Mozzila?s SimplePush specs. Matzew, why was the generated token removed then? >> > >> >> > >>> I'm not sure about what the best option is for UPS thought. Would a regex in for the @Path annotation work perhaps, something like: >> > >>> >> > >>> @DELETE >> > >>> @Path("{token, .+}") >> > >>> public Response unregisterInstallations( >> > >>> >> > >> >> > >> What do you mean by that regex? The problem is simply the ?%2F? in the token (which is an URLencoded simplepush url) and it?s being revoked long before it hits the RestEasy (which does the routing according to what?s in the @Path). >> > >> >> > >>> >> > >>> On 25 July 2014 10:32, Tadeas Kriz wrote: >> > >>> >> > >>> ? >> > >>> Tadeas Kriz >> > >>> >> > >>> On 24 Jul 2014, at 05:44 pm, Karel Piwko wrote: >> > >>> >> > >>> > On Thu, Jul 24, 2014 at 3:28 PM, Tadeas Kriz wrote: >> > >>> >> >> > >>> >> It should not. For hibernate, it?s just a string like any other. >> > >>> >> The problem might be in the configuration of JAX.RS/RestEasy. If >> > >>> >> I?ll have some time today evening, I?ll try to fix it, it should >> > >>> >> be an easy fix. >> > >>> > >> > >>> > Last famous words? ;-) >> > >>> > >> > >>> >> > >>> I shall never say ?an easy fix? again. >> > >>> >> > >>> > But I agree. Everything is string and URL encode should happen on >> > >>> > client while server should automatically decode and work always with >> > >>> > just decoded string. If we need to encode twice, something is wrong. >> > >>> > >> > >>> >> > >>> Anyway, the 400 Bad request response is made by the tomcat itself, disallowing the use of %2F as a path parameter. This will probably apply on other web containers. >> > >>> >> > >>> Possible solutions with their disadvantages: >> > >>> >> > >>> 1. well-documented double-encoding of the URL (might be confusing) >> > >>> 2. use @QueryParam instead of @PathParam (breaks the api consistence, as every other call would still use @PathParam) >> > >>> 3. allow @QueryParam (again, breaks the api consistence, but only for the SimplePush) >> > >>> 4. find another encoding (Base64 for URL = URLEncode then Base64 encode) >> > >>> 5. don?t use the url as a deviceToken (might not comply with Mozzila?s SimplePush specs) >> > >>> >> > >>> What do you think guys? >> > >>> >> > >>> >> >> > >>> >> >> > >>> > >> > >>> > >> > >>> > _______________________________________________ >> > >>> > aerogear-dev mailing list >> > >>> > aerogear-dev at lists.jboss.org >> > >>> > https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > >>> >> > >>> >> > >>> _______________________________________________ >> > >>> aerogear-dev mailing list >> > >>> aerogear-dev at lists.jboss.org >> > >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > >>> >> > >>> _______________________________________________ >> > >>> aerogear-dev mailing list >> > >>> aerogear-dev at lists.jboss.org >> > >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > >> >> > >> >> > >> _______________________________________________ >> > >> aerogear-dev mailing list >> > >> aerogear-dev at lists.jboss.org >> > >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > >> >> > >> _______________________________________________ >> > >> aerogear-dev mailing list >> > >> aerogear-dev at lists.jboss.org >> > >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > >> > > >> > > _______________________________________________ >> > > aerogear-dev mailing list >> > > aerogear-dev at lists.jboss.org >> > > https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > >> > > _______________________________________________ >> > > aerogear-dev mailing list >> > > aerogear-dev at lists.jboss.org >> > > https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > >> >> -- >> >> abstractj >> PGP: 0x84DC9914 >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> >> -- >> Matthias Wessendorf >> >> blog: http://matthiaswessendorf.wordpress.com/ >> sessions: http://www.slideshare.net/mwessendorf >> twitter: http://twitter.com/mwessendorf >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140725/e4e2db60/attachment-0001.html From supittma at redhat.com Fri Jul 25 12:07:14 2014 From: supittma at redhat.com (Summers Pittman) Date: Fri, 25 Jul 2014 12:07:14 -0400 Subject: [aerogear-dev] Modularizing the Android Library In-Reply-To: <20140722150611.GA58163@abstractj.org> References: <5317317F.1010209@redhat.com> <20140306143829.65e1e4aa@kapy-ntb-x220> <20140508192800.GB69433@abstractj.org> <4CD71A7A-EDE1-4648-AB3E-E4DDB383D824@gmail.com> <20140722150611.GA58163@abstractj.org> Message-ID: <53D280B2.4070100@redhat.com> On 07/22/2014 11:06 AM, Bruno Oliveira wrote: > Passos, what does aerogear-android-security stands for? Do we really > need the authz module? My question is due to the fact that mostly it > will be together with auth module, but I could be wrong. You are wrong :) In general Auth module consumes a username and password and manages a session. Authz fetches and consumers tokens and manages them through a android.app.Service service. > > On 2014-07-22, Daniel Passos wrote: >> Hey Guys, >> >> Summers and I started working on agdroid modules and remove some cyclic >> dependencies. So we plan to split the agdroid on these modules: >> >> - aerogear-android-core >> - aerogear-android-pipe >> - aerogear-android-auth >> - aerogear-android-autz >> - aerogear-android-store (with option security dependecy to use >> EncryptedStores) >> - aerogear-android-security >> - aerogear-android-push >> - aerogear-android-push-ups >> - aerogear-android-offline >> >> -- Passos >> ? >> >> >> On Fri, May 9, 2014 at 3:55 AM, Corinne Krych >> wrote: >> >>> Oops >>> [2] https://issues.jboss.org/browse/AGIOS-187 >>> >>> On 09 May 2014, at 08:52, Corinne Krych wrote: >>> >>>> [2] https://issues.jboss.org/browse/AGIOS-192 >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > -- > > abstractj > PGP: 0x84DC9914 > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -- Summers Pittman >>Phone:404 941 4698 >>Java is my crack. From matzew at apache.org Fri Jul 25 12:44:07 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Fri, 25 Jul 2014 18:44:07 +0200 Subject: [aerogear-dev] Differences between Firefox OS "native" Push lib and AeroGear's Push adapter In-Reply-To: <6C0C1654-0D6A-424D-8A26-609BCEBA00A6@redhat.com> References: <1406216640.15307.0@smtp.corp.redhat.com> <1E3E76E8-60D7-4BF3-9B95-6C58F4DC9286@redhat.com> <919B56C2-8E6D-4CD8-A620-F9839E013685@redhat.com> <20140725133326.GA14148@abstractj.org> <6C0C1654-0D6A-424D-8A26-609BCEBA00A6@redhat.com> Message-ID: On Friday, July 25, 2014, Lucas Holmquist wrote: > > On Jul 25, 2014, at 10:29 AM, Matthias Wessendorf > wrote: > > > > > On Fri, Jul 25, 2014 at 4:16 PM, Lucas Holmquist > wrote: > >> >> On Jul 25, 2014, at 9:38 AM, Matthias Wessendorf > > wrote: >> >> >> >> >> On Fri, Jul 25, 2014 at 3:33 PM, Bruno Oliveira > > wrote: >> >>> Hi Tadeas, you are correct. Apache web server disallow %2F or %5C >>> due to security concerns. There are several alternatives, most of them >>> workarouds, some people double encode it, others replace / by _ back and >>> forth or some people disable it like: >>> >>> >>> AllowEncodedSlashes On >>> >>> >> >> so, looks like it was a stupid idea to use the pushEndpoint as the >> 'deviceToken'. >> >> Perhaps we should make UPS.js generate a UUID and use that as deviceToken >> and send the pushEndpoint as part of the JSON, similar to like we did >> before. >> (But before we were using the SimplePush channelID as the deviceToken, >> which is clearly a no-go) >> >> >> i?ll need to look into this more, but i sort of like the fact that the >> UPS.js is somewhat stateless and doesn?t care about SimplePush, since it >> is also used for GCM for Chrome >> > > > I can see that - but ... thinking... I'd also like to get rid of returning > any payload from the registration endpoint. I think some of the > simplifications in simplepush are part of the issue. not sure > > didn?t realize anything is sent back, in our examples, using UPS.js, we > don?t do anything with the returned value > Yep, dont rely on it > > > > I like it, but it's just different :) > >> >> >> >>> >>> I hope it helps, otherwise let me know how I can help. >>> >>> On 2014-07-25, Tadeas Kriz wrote: >>> > >>> > ? >>> > Tadeas Kriz >>> > >>> > On 25 Jul 2014, at 01:09 pm, Daniel Bevenius < >>> daniel.bevenius at gmail.com >>> > wrote: >>> > >>> > > > it might work, although I?m not sure if this is the best solution >>> ?on the market?. >>> > > It may not be the best solution and feel free to ignore it. >>> > > >>> > >>> > I?d love to test it first. My only concern is whether or not might it >>> be a security issue. I think that?s something that Bruno might know. >>> > >>> > > >>> > > >>> > > >>> > > On 25 July 2014 12:55, Tadeas Kriz >> > wrote: >>> > > >>> > > ? >>> > > Tadeas Kriz >>> > > >>> > > On 25 Jul 2014, at 12:38 pm, Daniel Bevenius < >>> daniel.bevenius at gmail.com >>> > wrote: >>> > > >>> > >> >What do you mean by that regex? >>> > >> That the JAXRS implementation should not disallow as '/' in the >>> path. >>> > > >>> > > Well, if it was like: >>> > > >>> > > ``` >>> > > DELETE /rest/registry/installation/http://localhost:8321/asdasd >>> > > ``` >>> > > >>> > > and the token you showed would match all the characters (which means >>> that the `String token` would become `http://localhost:8321/asdasd` >>> in the endpoint method), it might work, >>> although I?m not sure if this is the best solution ?on the market?. >>> > > >>> > >> >>> > >> >The problem is simply the ?%2F? in the token (which is an >>> URLencoded simplepush url) and it?s being revoked long before it hits the >>> RestEasy (which does the routing according to what?s in the @Path). >>> > >> I guess I don't understand why this would be revoked by anything >>> before it hits the JAXRS implementation, but if that is the case you are >>> right and adding this would not help. >>> > >> >>> > > >>> > > This was a solution for a security hole. As I understand it, on >>> linux, scripts cannot tell difference between ?/? and ?%2F? and because of >>> that, it?s forbidden to use as a path parameter (at least on Tomcat). >>> > > >>> > >> >>> > >> >>> > >> >>> > >> >>> > >> >>> > >> On 25 July 2014 12:25, Tadeas Kriz >> > wrote: >>> > >> >>> > >> ? >>> > >> Tadeas Kriz >>> > >> >>> > >> On 25 Jul 2014, at 11:04 am, Daniel Bevenius < >>> daniel.bevenius at gmail.com >>> > wrote: >>> > >> >>> > >>> >5. don?t use the url as a deviceToken (might not comply with >>> Mozzila?s SimplePush specs) >>> > >>> The deviceToken is an UPS concept and there is nothing in the >>> SimplePush spec which is violated in this case. >>> > >>> >>> > >> >>> > >> I thought that deviceTokens were changed from a generated value to >>> the URL just to comply with Mozzila?s SimplePush specs. Matzew, why was the >>> generated token removed then? >>> > >> >>> > >>> I'm not sure about what the best option is for UPS thought. Would >>> a regex in for the @Path annotation work perhaps, something like: >>> > >>> >>> > >>> @DELETE >>> > >>> @Path("{token, .+}") >>> > >>> public Response unregisterInstallations( >>> > >>> >>> > >> >>> > >> What do you mean by that regex? The problem is simply the ?%2F? in >>> the token (which is an URLencoded simplepush url) and it?s being revoked >>> long before it hits the RestEasy (which does the routing according to >>> what?s in the @Path). >>> > >> >>> > >>> >>> > >>> On 25 July 2014 10:32, Tadeas Kriz >> > wrote: >>> > >>> >>> > >>> ? >>> > >>> Tadeas Kriz >>> > >>> >>> > >>> On 24 Jul 2014, at 05:44 pm, Karel Piwko >> > wrote: >>> > >>> >>> > >>> > On Thu, Jul 24, 2014 at 3:28 PM, Tadeas Kriz >> > wrote: >>> > >>> >> >>> > >>> >> It should not. For hibernate, it?s just a string like any other. >>> > >>> >> The problem might be in the configuration of JAX.RS/RestEasy >>> . If >>> > >>> >> I?ll have some time today evening, I?ll try to fix it, it should >>> > >>> >> be an easy fix. >>> > >>> > >>> > >>> > Last famous words? ;-) >>> > >>> > >>> > >>> >>> > >>> I shall never say ?an easy fix? again. >>> > >>> >>> > >>> > But I agree. Everything is string and URL encode should happen on >>> > >>> > client while server should automatically decode and work always >>> with >>> > >>> > just decoded string. If we need to encode twice, something is >>> wrong. >>> > >>> > >>> > >>> >>> > >>> Anyway, the 400 Bad request response is made by the tomcat itself, >>> disallowing the use of %2F as a path parameter. This will probably apply on >>> other web containers. >>> > >>> >>> > >>> Possible solutions with their disadvantages: >>> > >>> >>> > >>> 1. well-documented double-encoding of the URL (might be confusing) >>> > >>> 2. use @QueryParam instead of @PathParam (breaks the api >>> consistence, as every other call would still use @PathParam) >>> > >>> 3. allow @QueryParam (again, breaks the api consistence, but only >>> for the SimplePush) >>> > >>> 4. find another encoding (Base64 for URL = URLEncode then Base64 >>> encode) >>> > >>> 5. don?t use the url as a deviceToken (might not comply with >>> Mozzila?s SimplePush specs) >>> > >>> >>> > >>> What do you think guys? >>> > >>> >>> > >>> >> >>> > >>> >> >>> > >>> > >>> > >>> > >>> > >>> > _______________________________________________ >>> > >>> > aerogear-dev mailing list >>> > >>> > aerogear-dev at lists.jboss.org >>> >>> > >>> > https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> > >>> >>> > >>> >>> > >>> _______________________________________________ >>> > >>> aerogear-dev mailing list >>> > >>> aerogear-dev at lists.jboss.org >>> >>> > >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> > >>> >>> > >>> _______________________________________________ >>> > >>> aerogear-dev mailing list >>> > >>> aerogear-dev at lists.jboss.org >>> >>> > >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> > >> >>> > >> >>> > >> _______________________________________________ >>> > >> aerogear-dev mailing list >>> > >> aerogear-dev at lists.jboss.org >>> >>> > >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> > >> >>> > >> _______________________________________________ >>> > >> aerogear-dev mailing list >>> > >> aerogear-dev at lists.jboss.org >>> >>> > >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> > > >>> > > >>> > > _______________________________________________ >>> > > aerogear-dev mailing list >>> > > aerogear-dev at lists.jboss.org >>> >>> > > https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> > > >>> > > _______________________________________________ >>> > > aerogear-dev mailing list >>> > > aerogear-dev at lists.jboss.org >>> >>> > > https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> > >>> >>> -- >>> >>> abstractj >>> PGP: 0x84DC9914 >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >> >> >> >> -- >> Matthias Wessendorf >> >> blog: http://matthiaswessendorf.wordpress.com/ >> sessions: http://www.slideshare.net/mwessendorf >> twitter: http://twitter.com/mwessendorf >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > -- Sent from Gmail Mobile -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140725/0cd50549/attachment-0001.html From bruno at abstractj.org Fri Jul 25 13:02:13 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Fri, 25 Jul 2014 14:02:13 -0300 Subject: [aerogear-dev] Differences between Firefox OS "native" Push lib and AeroGear's Push adapter In-Reply-To: References: <1406216640.15307.0@smtp.corp.redhat.com> <1E3E76E8-60D7-4BF3-9B95-6C58F4DC9286@redhat.com> <919B56C2-8E6D-4CD8-A620-F9839E013685@redhat.com> <20140725133326.GA14148@abstractj.org> Message-ID: <20140725170212.GA26186@abstractj.org> On 2014-07-25, Tadeas Kriz wrote: > > ? > Tadeas Kriz > > On 25 Jul 2014, at 03:33 pm, Bruno Oliveira wrote: > > > Hi Tadeas, you are correct. Apache web server disallow %2F or %5C > > due to security concerns. There are several alternatives, most of them > > workarouds, some people double encode it, others replace / by _ back and > > forth or some people disable it like: > > > > > > AllowEncodedSlashes On > > > > > > I hope it helps, otherwise let me know how I can help. > > > > Thanks, this is what I?ve found yesterday while researching this. The ?allowencodedslashes? just opens the security hole, doesn?t it? Anyway, what I meant was if it would be a possible security issue, if we could get it working without the encoded URL at all. Like Daniel propsed, to use the `.*` regex to match everything beneath the `/installation/` so the actual request would look like that? +1 > > ``` > DELETE /rest/registry/installation/http://localhost:8321/asdasdasdasd > ``` > > Thanks. > > > On 2014-07-25, Tadeas Kriz wrote: > >> > >> ? > >> Tadeas Kriz > >> > >> On 25 Jul 2014, at 01:09 pm, Daniel Bevenius wrote: > >> > >>>> it might work, although I?m not sure if this is the best solution ?on the market?. > >>> It may not be the best solution and feel free to ignore it. > >>> > >> > >> I?d love to test it first. My only concern is whether or not might it be a security issue. I think that?s something that Bruno might know. > >> > >>> > >>> > >>> > >>> On 25 July 2014 12:55, Tadeas Kriz wrote: > >>> > >>> ? > >>> Tadeas Kriz > >>> > >>> On 25 Jul 2014, at 12:38 pm, Daniel Bevenius wrote: > >>> > >>>>> What do you mean by that regex? > >>>> That the JAXRS implementation should not disallow as '/' in the path. > >>> > >>> Well, if it was like: > >>> > >>> ``` > >>> DELETE /rest/registry/installation/http://localhost:8321/asdasd > >>> ``` > >>> > >>> and the token you showed would match all the characters (which means that the `String token` would become `http://localhost:8321/asdasd` in the endpoint method), it might work, although I?m not sure if this is the best solution ?on the market?. > >>> > >>>> > >>>>> The problem is simply the ?%2F? in the token (which is an URLencoded simplepush url) and it?s being revoked long before it hits the RestEasy (which does the routing according to what?s in the @Path). > >>>> I guess I don't understand why this would be revoked by anything before it hits the JAXRS implementation, but if that is the case you are right and adding this would not help. > >>>> > >>> > >>> This was a solution for a security hole. As I understand it, on linux, scripts cannot tell difference between ?/? and ?%2F? and because of that, it?s forbidden to use as a path parameter (at least on Tomcat). > >>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> On 25 July 2014 12:25, Tadeas Kriz wrote: > >>>> > >>>> ? > >>>> Tadeas Kriz > >>>> > >>>> On 25 Jul 2014, at 11:04 am, Daniel Bevenius wrote: > >>>> > >>>>>> 5. don?t use the url as a deviceToken (might not comply with Mozzila?s SimplePush specs) > >>>>> The deviceToken is an UPS concept and there is nothing in the SimplePush spec which is violated in this case. > >>>>> > >>>> > >>>> I thought that deviceTokens were changed from a generated value to the URL just to comply with Mozzila?s SimplePush specs. Matzew, why was the generated token removed then? > >>>> > >>>>> I'm not sure about what the best option is for UPS thought. Would a regex in for the @Path annotation work perhaps, something like: > >>>>> > >>>>> @DELETE > >>>>> @Path("{token, .+}") > >>>>> public Response unregisterInstallations( > >>>>> > >>>> > >>>> What do you mean by that regex? The problem is simply the ?%2F? in the token (which is an URLencoded simplepush url) and it?s being revoked long before it hits the RestEasy (which does the routing according to what?s in the @Path). > >>>> > >>>>> > >>>>> On 25 July 2014 10:32, Tadeas Kriz wrote: > >>>>> > >>>>> ? > >>>>> Tadeas Kriz > >>>>> > >>>>> On 24 Jul 2014, at 05:44 pm, Karel Piwko wrote: > >>>>> > >>>>>> On Thu, Jul 24, 2014 at 3:28 PM, Tadeas Kriz wrote: > >>>>>>> > >>>>>>> It should not. For hibernate, it?s just a string like any other. > >>>>>>> The problem might be in the configuration of JAX.RS/RestEasy. If > >>>>>>> I?ll have some time today evening, I?ll try to fix it, it should > >>>>>>> be an easy fix. > >>>>>> > >>>>>> Last famous words? ;-) > >>>>>> > >>>>> > >>>>> I shall never say ?an easy fix? again. > >>>>> > >>>>>> But I agree. Everything is string and URL encode should happen on > >>>>>> client while server should automatically decode and work always with > >>>>>> just decoded string. If we need to encode twice, something is wrong. > >>>>>> > >>>>> > >>>>> Anyway, the 400 Bad request response is made by the tomcat itself, disallowing the use of %2F as a path parameter. This will probably apply on other web containers. > >>>>> > >>>>> Possible solutions with their disadvantages: > >>>>> > >>>>> 1. well-documented double-encoding of the URL (might be confusing) > >>>>> 2. use @QueryParam instead of @PathParam (breaks the api consistence, as every other call would still use @PathParam) > >>>>> 3. allow @QueryParam (again, breaks the api consistence, but only for the SimplePush) > >>>>> 4. find another encoding (Base64 for URL = URLEncode then Base64 encode) > >>>>> 5. don?t use the url as a deviceToken (might not comply with Mozzila?s SimplePush specs) > >>>>> > >>>>> What do you think guys? > >>>>> > >>>>>>> > >>>>>>> > >>>>>> > >>>>>> > >>>>>> _______________________________________________ > >>>>>> aerogear-dev mailing list > >>>>>> aerogear-dev at lists.jboss.org > >>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev > >>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> aerogear-dev mailing list > >>>>> aerogear-dev at lists.jboss.org > >>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev > >>>>> > >>>>> _______________________________________________ > >>>>> aerogear-dev mailing list > >>>>> aerogear-dev at lists.jboss.org > >>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev > >>>> > >>>> > >>>> _______________________________________________ > >>>> aerogear-dev mailing list > >>>> aerogear-dev at lists.jboss.org > >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev > >>>> > >>>> _______________________________________________ > >>>> aerogear-dev mailing list > >>>> aerogear-dev at lists.jboss.org > >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev > >>> > >>> > >>> _______________________________________________ > >>> aerogear-dev mailing list > >>> aerogear-dev at lists.jboss.org > >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev > >>> > >>> _______________________________________________ > >>> aerogear-dev mailing list > >>> aerogear-dev at lists.jboss.org > >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev > >> > > > > -- > > > > abstractj > > PGP: 0x84DC9914 > -- abstractj PGP: 0x84DC9914 From bruno at abstractj.org Fri Jul 25 13:03:53 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Fri, 25 Jul 2014 14:03:53 -0300 Subject: [aerogear-dev] UPS build Message-ID: <20140725170351.GB26186@abstractj.org> Guys, is just me or the UPS build became crazily slow? -- abstractj PGP: 0x84DC9914 From lukas.fryc at gmail.com Fri Jul 25 13:13:36 2014 From: lukas.fryc at gmail.com (=?UTF-8?B?THVrw6HFoSBGcnnEjQ==?=) Date: Fri, 25 Jul 2014 19:13:36 +0200 Subject: [aerogear-dev] UPS build In-Reply-To: <20140725170351.GB26186@abstractj.org> References: <20140725170351.GB26186@abstractj.org> Message-ID: That's probably because we have added a step to clean admin-ui resources during ups-console by default, https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/servers/ups-server/pom.xml#L352 It cleans all the caches, so that the build will download everything from scratch. I admit I don't remember the details of the issue that forced us to do so, but here is a way around: https://github.com/aerogear/aerogear-unifiedpush-server#developing-and-releasing-ui ~ Lukas On Fri, Jul 25, 2014 at 7:03 PM, Bruno Oliveira wrote: > Guys, is just me or the UPS build became crazily slow? > > -- > > abstractj > PGP: 0x84DC9914 > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140725/f7f86ce4/attachment.html From lukas.fryc at gmail.com Fri Jul 25 13:14:34 2014 From: lukas.fryc at gmail.com (=?UTF-8?B?THVrw6HFoSBGcnnEjQ==?=) Date: Fri, 25 Jul 2014 19:14:34 +0200 Subject: [aerogear-dev] UPS build In-Reply-To: References: <20140725170351.GB26186@abstractj.org> Message-ID: Actually I should have linked this one: https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/servers/ups-server/pom.xml#L268 On Fri, Jul 25, 2014 at 7:13 PM, Luk?? Fry? wrote: > That's probably because we have added a step to clean admin-ui resources > during ups-console by default, > > > https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/servers/ups-server/pom.xml#L352 > > It cleans all the caches, so that the build will download everything from > scratch. > > > I admit I don't remember the details of the issue that forced us to do so, > but here is a way around: > > > https://github.com/aerogear/aerogear-unifiedpush-server#developing-and-releasing-ui > > ~ Lukas > > > On Fri, Jul 25, 2014 at 7:03 PM, Bruno Oliveira > wrote: > >> Guys, is just me or the UPS build became crazily slow? >> >> -- >> >> abstractj >> PGP: 0x84DC9914 >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140725/daeac165/attachment.html From bruno at abstractj.org Fri Jul 25 13:16:12 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Fri, 25 Jul 2014 14:16:12 -0300 Subject: [aerogear-dev] Modularizing the Android Library In-Reply-To: <53D280B2.4070100@redhat.com> References: <5317317F.1010209@redhat.com> <20140306143829.65e1e4aa@kapy-ntb-x220> <20140508192800.GB69433@abstractj.org> <4CD71A7A-EDE1-4648-AB3E-E4DDB383D824@gmail.com> <20140722150611.GA58163@abstractj.org> <53D280B2.4070100@redhat.com> Message-ID: <20140725171611.GC26186@abstractj.org> On 2014-07-25, Summers Pittman wrote: > On 07/22/2014 11:06 AM, Bruno Oliveira wrote: > > Passos, what does aerogear-android-security stands for? Do we really > > need the authz module? My question is due to the fact that mostly it > > will be together with auth module, but I could be wrong. > You are wrong :) Do you have authorization without authentication? Or authentication with no authorization? > > In general > > Auth module consumes a username and password and manages a session. > Authz fetches and consumers tokens and manages them through a > android.app.Service service. > > > > On 2014-07-22, Daniel Passos wrote: > >> Hey Guys, > >> > >> Summers and I started working on agdroid modules and remove some cyclic > >> dependencies. So we plan to split the agdroid on these modules: > >> > >> - aerogear-android-core > >> - aerogear-android-pipe > >> - aerogear-android-auth > >> - aerogear-android-autz > >> - aerogear-android-store (with option security dependecy to use > >> EncryptedStores) > >> - aerogear-android-security > >> - aerogear-android-push > >> - aerogear-android-push-ups > >> - aerogear-android-offline > >> > >> -- Passos > >> ? > >> > >> > >> On Fri, May 9, 2014 at 3:55 AM, Corinne Krych > >> wrote: > >> > >>> Oops > >>> [2] https://issues.jboss.org/browse/AGIOS-187 > >>> > >>> On 09 May 2014, at 08:52, Corinne Krych wrote: > >>> > >>>> [2] https://issues.jboss.org/browse/AGIOS-192 > >>> _______________________________________________ > >>> aerogear-dev mailing list > >>> aerogear-dev at lists.jboss.org > >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev > >>> > >> _______________________________________________ > >> aerogear-dev mailing list > >> aerogear-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > -- > > > > abstractj > > PGP: 0x84DC9914 > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > -- > Summers Pittman > >>Phone:404 941 4698 > >>Java is my crack. > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -- abstractj PGP: 0x84DC9914 From lholmqui at redhat.com Fri Jul 25 13:18:47 2014 From: lholmqui at redhat.com (Lucas Holmquist) Date: Fri, 25 Jul 2014 13:18:47 -0400 Subject: [aerogear-dev] Modularizing the Android Library In-Reply-To: <20140725171611.GC26186@abstractj.org> References: <5317317F.1010209@redhat.com> <20140306143829.65e1e4aa@kapy-ntb-x220> <20140508192800.GB69433@abstractj.org> <4CD71A7A-EDE1-4648-AB3E-E4DDB383D824@gmail.com> <20140722150611.GA58163@abstractj.org> <53D280B2.4070100@redhat.com> <20140725171611.GC26186@abstractj.org> Message-ID: On Jul 25, 2014, at 1:16 PM, Bruno Oliveira wrote: > On 2014-07-25, Summers Pittman wrote: >> On 07/22/2014 11:06 AM, Bruno Oliveira wrote: >>> Passos, what does aerogear-android-security stands for? Do we really >>> need the authz module? My question is due to the fact that mostly it >>> will be together with auth module, but I could be wrong. >> You are wrong :) > > Do you have authorization without authentication? Or authentication with > no authorization? We have this in our JS lib, the Authenitcation module, just does the login/logout/enroll and the Authz module doesn?t rely on it, but connects to 3rd party OAuth2( the current adapter ) providers > >> >> In general >> >> Auth module consumes a username and password and manages a session. >> Authz fetches and consumers tokens and manages them through a >> android.app.Service service. >>> >>> On 2014-07-22, Daniel Passos wrote: >>>> Hey Guys, >>>> >>>> Summers and I started working on agdroid modules and remove some cyclic >>>> dependencies. So we plan to split the agdroid on these modules: >>>> >>>> - aerogear-android-core >>>> - aerogear-android-pipe >>>> - aerogear-android-auth >>>> - aerogear-android-autz >>>> - aerogear-android-store (with option security dependecy to use >>>> EncryptedStores) >>>> - aerogear-android-security >>>> - aerogear-android-push >>>> - aerogear-android-push-ups >>>> - aerogear-android-offline >>>> >>>> -- Passos >>>> ? >>>> >>>> >>>> On Fri, May 9, 2014 at 3:55 AM, Corinne Krych >>>> wrote: >>>> >>>>> Oops >>>>> [2] https://issues.jboss.org/browse/AGIOS-187 >>>>> >>>>> On 09 May 2014, at 08:52, Corinne Krych wrote: >>>>> >>>>>> [2] https://issues.jboss.org/browse/AGIOS-192 >>>>> _______________________________________________ >>>>> aerogear-dev mailing list >>>>> aerogear-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>> >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >>> -- >>> >>> abstractj >>> PGP: 0x84DC9914 >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> -- >> Summers Pittman >>>> Phone:404 941 4698 >>>> Java is my crack. >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > -- > > abstractj > PGP: 0x84DC9914 > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140725/0b63a3a5/attachment-0001.html From bruno at abstractj.org Fri Jul 25 13:25:52 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Fri, 25 Jul 2014 14:25:52 -0300 Subject: [aerogear-dev] Modularizing the Android Library In-Reply-To: References: <20140306143829.65e1e4aa@kapy-ntb-x220> <20140508192800.GB69433@abstractj.org> <4CD71A7A-EDE1-4648-AB3E-E4DDB383D824@gmail.com> <20140722150611.GA58163@abstractj.org> <53D280B2.4070100@redhat.com> <20140725171611.GC26186@abstractj.org> Message-ID: <20140725172551.GD26186@abstractj.org> On 2014-07-25, Lucas Holmquist wrote: > > On Jul 25, 2014, at 1:16 PM, Bruno Oliveira wrote: > > > On 2014-07-25, Summers Pittman wrote: > >> On 07/22/2014 11:06 AM, Bruno Oliveira wrote: > >>> Passos, what does aerogear-android-security stands for? Do we really > >>> need the authz module? My question is due to the fact that mostly it > >>> will be together with auth module, but I could be wrong. > >> You are wrong :) > > > > Do you have authorization without authentication? Or authentication with > > no authorization? > > We have this in our JS lib, the Authenitcation module, just does the login/logout/enroll > > and the Authz module doesn?t rely on it, but connects to 3rd party OAuth2( the current adapter ) providers If it connects using a Token from a 3rd party service, is because it's based on some credential. So, I assume that you have authentication AND authorization, there's no magic ;) Either way, name it to whatever you guys think is the best. > > > > > >> > >> In general > >> > >> Auth module consumes a username and password and manages a session. > >> Authz fetches and consumers tokens and manages them through a > >> android.app.Service service. > >>> > >>> On 2014-07-22, Daniel Passos wrote: > >>>> Hey Guys, > >>>> > >>>> Summers and I started working on agdroid modules and remove some cyclic > >>>> dependencies. So we plan to split the agdroid on these modules: > >>>> > >>>> - aerogear-android-core > >>>> - aerogear-android-pipe > >>>> - aerogear-android-auth > >>>> - aerogear-android-autz > >>>> - aerogear-android-store (with option security dependecy to use > >>>> EncryptedStores) > >>>> - aerogear-android-security > >>>> - aerogear-android-push > >>>> - aerogear-android-push-ups > >>>> - aerogear-android-offline > >>>> > >>>> -- Passos > >>>> ? > >>>> > >>>> > >>>> On Fri, May 9, 2014 at 3:55 AM, Corinne Krych > >>>> wrote: > >>>> > >>>>> Oops > >>>>> [2] https://issues.jboss.org/browse/AGIOS-187 > >>>>> > >>>>> On 09 May 2014, at 08:52, Corinne Krych wrote: > >>>>> > >>>>>> [2] https://issues.jboss.org/browse/AGIOS-192 > >>>>> _______________________________________________ > >>>>> aerogear-dev mailing list > >>>>> aerogear-dev at lists.jboss.org > >>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev > >>>>> > >>>> _______________________________________________ > >>>> aerogear-dev mailing list > >>>> aerogear-dev at lists.jboss.org > >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev > >>> > >>> -- > >>> > >>> abstractj > >>> PGP: 0x84DC9914 > >>> _______________________________________________ > >>> aerogear-dev mailing list > >>> aerogear-dev at lists.jboss.org > >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev > >> > >> > >> -- > >> Summers Pittman > >>>> Phone:404 941 4698 > >>>> Java is my crack. > >> > >> _______________________________________________ > >> aerogear-dev mailing list > >> aerogear-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > -- > > > > abstractj > > PGP: 0x84DC9914 > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -- abstractj PGP: 0x84DC9914 From bruno at abstractj.org Fri Jul 25 13:28:11 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Fri, 25 Jul 2014 14:28:11 -0300 Subject: [aerogear-dev] UPS build In-Reply-To: References: <20140725170351.GB26186@abstractj.org> Message-ID: <20140725172811.GE26186@abstractj.org> Np, thank you. On 2014-07-25, Luk?? Fry? wrote: > Actually I should have linked this one: > > https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/servers/ups-server/pom.xml#L268 > > > On Fri, Jul 25, 2014 at 7:13 PM, Luk?? Fry? wrote: > > > That's probably because we have added a step to clean admin-ui resources > > during ups-console by default, > > > > > > https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/servers/ups-server/pom.xml#L352 > > > > It cleans all the caches, so that the build will download everything from > > scratch. > > > > > > I admit I don't remember the details of the issue that forced us to do so, > > but here is a way around: > > > > > > https://github.com/aerogear/aerogear-unifiedpush-server#developing-and-releasing-ui > > > > ~ Lukas > > > > > > On Fri, Jul 25, 2014 at 7:03 PM, Bruno Oliveira > > wrote: > > > >> Guys, is just me or the UPS build became crazily slow? > >> > >> -- > >> > >> abstractj > >> PGP: 0x84DC9914 > >> _______________________________________________ > >> aerogear-dev mailing list > >> aerogear-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > >> > > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -- abstractj PGP: 0x84DC9914 From lholmqui at redhat.com Fri Jul 25 14:36:36 2014 From: lholmqui at redhat.com (Lucas Holmquist) Date: Fri, 25 Jul 2014 14:36:36 -0400 Subject: [aerogear-dev] Modularizing the Android Library In-Reply-To: <20140725172551.GD26186@abstractj.org> References: <20140306143829.65e1e4aa@kapy-ntb-x220> <20140508192800.GB69433@abstractj.org> <4CD71A7A-EDE1-4648-AB3E-E4DDB383D824@gmail.com> <20140722150611.GA58163@abstractj.org> <53D280B2.4070100@redhat.com> <20140725171611.GC26186@abstractj.org> <20140725172551.GD26186@abstractj.org> Message-ID: On Jul 25, 2014, at 1:25 PM, Bruno Oliveira wrote: > On 2014-07-25, Lucas Holmquist wrote: >> >> On Jul 25, 2014, at 1:16 PM, Bruno Oliveira wrote: >> >>> On 2014-07-25, Summers Pittman wrote: >>>> On 07/22/2014 11:06 AM, Bruno Oliveira wrote: >>>>> Passos, what does aerogear-android-security stands for? Do we really >>>>> need the authz module? My question is due to the fact that mostly it >>>>> will be together with auth module, but I could be wrong. >>>> You are wrong :) >>> >>> Do you have authorization without authentication? Or authentication with >>> no authorization? >> >> We have this in our JS lib, the Authenitcation module, just does the login/logout/enroll >> >> and the Authz module doesn?t rely on it, but connects to 3rd party OAuth2( the current adapter ) providers > > If it connects using a Token from a 3rd party service, is because it's based on some credential. So, > I assume that you have authentication AND authorization, there's no magic ;) > > Either way, name it to whatever you guys think is the best. yea, the names can be confusing here :). we should rename to ?CoolSuperAwesomeThing? and ?bob? :) > >> >> >>> >>>> >>>> In general >>>> >>>> Auth module consumes a username and password and manages a session. >>>> Authz fetches and consumers tokens and manages them through a >>>> android.app.Service service. >>>>> >>>>> On 2014-07-22, Daniel Passos wrote: >>>>>> Hey Guys, >>>>>> >>>>>> Summers and I started working on agdroid modules and remove some cyclic >>>>>> dependencies. So we plan to split the agdroid on these modules: >>>>>> >>>>>> - aerogear-android-core >>>>>> - aerogear-android-pipe >>>>>> - aerogear-android-auth >>>>>> - aerogear-android-autz >>>>>> - aerogear-android-store (with option security dependecy to use >>>>>> EncryptedStores) >>>>>> - aerogear-android-security >>>>>> - aerogear-android-push >>>>>> - aerogear-android-push-ups >>>>>> - aerogear-android-offline >>>>>> >>>>>> -- Passos >>>>>> ? >>>>>> >>>>>> >>>>>> On Fri, May 9, 2014 at 3:55 AM, Corinne Krych >>>>>> wrote: >>>>>> >>>>>>> Oops >>>>>>> [2] https://issues.jboss.org/browse/AGIOS-187 >>>>>>> >>>>>>> On 09 May 2014, at 08:52, Corinne Krych wrote: >>>>>>> >>>>>>>> [2] https://issues.jboss.org/browse/AGIOS-192 >>>>>>> _______________________________________________ >>>>>>> aerogear-dev mailing list >>>>>>> aerogear-dev at lists.jboss.org >>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>> >>>>>> _______________________________________________ >>>>>> aerogear-dev mailing list >>>>>> aerogear-dev at lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>> >>>>> -- >>>>> >>>>> abstractj >>>>> PGP: 0x84DC9914 >>>>> _______________________________________________ >>>>> aerogear-dev mailing list >>>>> aerogear-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> >>>> >>>> -- >>>> Summers Pittman >>>>>> Phone:404 941 4698 >>>>>> Java is my crack. >>>> >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >>> -- >>> >>> abstractj >>> PGP: 0x84DC9914 >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > -- > > abstractj > PGP: 0x84DC9914 > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140725/b769672a/attachment.html From bruno at abstractj.org Fri Jul 25 15:01:00 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Fri, 25 Jul 2014 16:01:00 -0300 Subject: [aerogear-dev] Modularizing the Android Library In-Reply-To: References: <20140508192800.GB69433@abstractj.org> <4CD71A7A-EDE1-4648-AB3E-E4DDB383D824@gmail.com> <20140722150611.GA58163@abstractj.org> <53D280B2.4070100@redhat.com> <20140725171611.GC26186@abstractj.org> <20140725172551.GD26186@abstractj.org> Message-ID: <20140725190100.GA1461@abstractj.org> On 2014-07-25, Lucas Holmquist wrote: > > On Jul 25, 2014, at 1:25 PM, Bruno Oliveira wrote: > > > On 2014-07-25, Lucas Holmquist wrote: > >> > >> On Jul 25, 2014, at 1:16 PM, Bruno Oliveira wrote: > >> > >>> On 2014-07-25, Summers Pittman wrote: > >>>> On 07/22/2014 11:06 AM, Bruno Oliveira wrote: > >>>>> Passos, what does aerogear-android-security stands for? Do we really > >>>>> need the authz module? My question is due to the fact that mostly it > >>>>> will be together with auth module, but I could be wrong. > >>>> You are wrong :) > >>> > >>> Do you have authorization without authentication? Or authentication with > >>> no authorization? > >> > >> We have this in our JS lib, the Authenitcation module, just does the login/logout/enroll > >> > >> and the Authz module doesn?t rely on it, but connects to 3rd party OAuth2( the current adapter ) providers > > > > If it connects using a Token from a 3rd party service, is because it's based on some credential. So, > > I assume that you have authentication AND authorization, there's no magic ;) > > > > Either way, name it to whatever you guys think is the best. > > yea, the names can be confusing here :). we should rename to ?CoolSuperAwesomeThing? and ?bob? :) As long as you do at your own repository, I'm ok. Meanwhile let's not mix the concept of OAuth2 with authorization only. > > > > >> > >> > >>> > >>>> > >>>> In general > >>>> > >>>> Auth module consumes a username and password and manages a session. > >>>> Authz fetches and consumers tokens and manages them through a > >>>> android.app.Service service. > >>>>> > >>>>> On 2014-07-22, Daniel Passos wrote: > >>>>>> Hey Guys, > >>>>>> > >>>>>> Summers and I started working on agdroid modules and remove some cyclic > >>>>>> dependencies. So we plan to split the agdroid on these modules: > >>>>>> > >>>>>> - aerogear-android-core > >>>>>> - aerogear-android-pipe > >>>>>> - aerogear-android-auth > >>>>>> - aerogear-android-autz > >>>>>> - aerogear-android-store (with option security dependecy to use > >>>>>> EncryptedStores) > >>>>>> - aerogear-android-security > >>>>>> - aerogear-android-push > >>>>>> - aerogear-android-push-ups > >>>>>> - aerogear-android-offline > >>>>>> > >>>>>> -- Passos > >>>>>> ? > >>>>>> > >>>>>> > >>>>>> On Fri, May 9, 2014 at 3:55 AM, Corinne Krych > >>>>>> wrote: > >>>>>> > >>>>>>> Oops > >>>>>>> [2] https://issues.jboss.org/browse/AGIOS-187 > >>>>>>> > >>>>>>> On 09 May 2014, at 08:52, Corinne Krych wrote: > >>>>>>> > >>>>>>>> [2] https://issues.jboss.org/browse/AGIOS-192 > >>>>>>> _______________________________________________ > >>>>>>> aerogear-dev mailing list > >>>>>>> aerogear-dev at lists.jboss.org > >>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev > >>>>>>> > >>>>>> _______________________________________________ > >>>>>> aerogear-dev mailing list > >>>>>> aerogear-dev at lists.jboss.org > >>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev > >>>>> > >>>>> -- > >>>>> > >>>>> abstractj > >>>>> PGP: 0x84DC9914 > >>>>> _______________________________________________ > >>>>> aerogear-dev mailing list > >>>>> aerogear-dev at lists.jboss.org > >>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev > >>>> > >>>> > >>>> -- > >>>> Summers Pittman > >>>>>> Phone:404 941 4698 > >>>>>> Java is my crack. > >>>> > >>>> _______________________________________________ > >>>> aerogear-dev mailing list > >>>> aerogear-dev at lists.jboss.org > >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev > >>> > >>> -- > >>> > >>> abstractj > >>> PGP: 0x84DC9914 > >>> _______________________________________________ > >>> aerogear-dev mailing list > >>> aerogear-dev at lists.jboss.org > >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev > >> > > > >> _______________________________________________ > >> aerogear-dev mailing list > >> aerogear-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > > -- > > > > abstractj > > PGP: 0x84DC9914 > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -- abstractj PGP: 0x84DC9914 From lholmqui at redhat.com Fri Jul 25 15:13:08 2014 From: lholmqui at redhat.com (Lucas Holmquist) Date: Fri, 25 Jul 2014 15:13:08 -0400 Subject: [aerogear-dev] Github releases Message-ID: <40EEC57B-3CE7-40C8-B361-9A613DD1DB8C@redhat.com> Hi all, yup, sending this on a Friday, at 3pm EST. while going over some of the JS push tutorial docs, i found that the links to the AG JS lib were point to somewhat older releases. While we could try to remember to update these docs after every release, i propose we use githubs really neat ?release? button. Basically, we would still tag our releases normally, and after we push those up, we can press the ?Draft a New Release? button. This allows us to choose an existing tag, but some release notes in, and also mark as a pre-release but the best part, is that we can now link to the ?latest? release in our docs This is the link created: https://github.com/aerogear/aerogear-js-dist/releases/latest this will link to: https://github.com/aerogear/aerogear-js/releases/tag/1.5.1 wdyt? -Luke -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140725/1ff6fbdf/attachment.html From bruno at abstractj.org Fri Jul 25 15:59:22 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Fri, 25 Jul 2014 12:59:22 -0700 (PDT) Subject: [aerogear-dev] Github releases In-Reply-To: <40EEC57B-3CE7-40C8-B361-9A613DD1DB8C@redhat.com> References: <40EEC57B-3CE7-40C8-B361-9A613DD1DB8C@redhat.com> Message-ID: <1406318362296.eec005@Nodemailer> +1? abstractj PGP: 0x84DC9914 On Fri, Jul 25, 2014 at 4:13 PM, Lucas Holmquist wrote: > Hi all, > yup, sending this on a Friday, at 3pm EST. > while going over some of the JS push tutorial docs, i found that the links to the AG JS lib were point to somewhat older releases. While we could try to remember to update these docs after every release, i propose we use githubs really neat ?release? button. > Basically, we would still tag our releases normally, and after we push those up, we can press the ?Draft a New Release? button. > This allows us to choose an existing tag, but some release notes in, and also mark as a pre-release > but the best part, is that we can now link to the ?latest? release in our docs > This is the link created: https://github.com/aerogear/aerogear-js-dist/releases/latest > this will link to: https://github.com/aerogear/aerogear-js/releases/tag/1.5.1 > wdyt? > -Luke -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140725/e9b73772/attachment.html From daniel.bevenius at gmail.com Sat Jul 26 00:23:50 2014 From: daniel.bevenius at gmail.com (Daniel Bevenius) Date: Sat, 26 Jul 2014 06:23:50 +0200 Subject: [aerogear-dev] Github releases In-Reply-To: <1406318362296.eec005@Nodemailer> References: <40EEC57B-3CE7-40C8-B361-9A613DD1DB8C@redhat.com> <1406318362296.eec005@Nodemailer> Message-ID: +1 Sounds good On 25 July 2014 21:59, Bruno Oliveira wrote: > +1 > ? > abstractj > PGP: 0x84DC9914 > > > On Fri, Jul 25, 2014 at 4:13 PM, Lucas Holmquist > wrote: > >> Hi all, >> >> yup, sending this on a Friday, at 3pm EST. >> >> while going over some of the JS push tutorial docs, i found that the >> links to the AG JS lib were point to somewhat older releases. While we >> could try to remember to update these docs after every release, i propose >> we use githubs really neat ?release? button. >> >> Basically, we would still tag our releases normally, and after we push >> those up, we can press the ?Draft a New Release? button. >> >> This allows us to choose an existing tag, but some release notes in, and >> also mark as a pre-release >> >> but the best part, is that we can now link to the ?latest? release in >> our docs >> >> This is the link created: >> https://github.com/aerogear/aerogear-js-dist/releases/latest >> >> >> this will link to: >> https://github.com/aerogear/aerogear-js/releases/tag/1.5.1 >> >> >> >> wdyt? >> >> >> -Luke >> > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140726/8c9abf76/attachment.html From corinnekrych at gmail.com Sat Jul 26 00:45:05 2014 From: corinnekrych at gmail.com (Corinne Krych) Date: Sat, 26 Jul 2014 06:45:05 +0200 Subject: [aerogear-dev] Modularizing the Android Library In-Reply-To: <20140725190100.GA1461@abstractj.org> References: <20140508192800.GB69433@abstractj.org> <4CD71A7A-EDE1-4648-AB3E-E4DDB383D824@gmail.com> <20140722150611.GA58163@abstractj.org> <53D280B2.4070100@redhat.com> <20140725171611.GC26186@abstractj.org> <20140725172551.GD26186@abstractj.org> <20140725190100.GA1461@abstractj.org> Message-ID: For iOS, we plan to have: - (aerogear)-ios-http ?> pipe revisited - (aerogear)-ios-oauth2 ?> I prefer to opt for a specific name, if later on we need oauth1a we?ll create another module and extract common part in a oauth module - we?ll have another module for auth with digest (we haven?t decided yet in the name) See [1] for a more complete list ++ Corinne [1] http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-News-from-iOS-Modules-front-td8382.html On 25 Jul 2014, at 21:01, Bruno Oliveira wrote: > On 2014-07-25, Lucas Holmquist wrote: >> >> On Jul 25, 2014, at 1:25 PM, Bruno Oliveira wrote: >> >>> On 2014-07-25, Lucas Holmquist wrote: >>>> >>>> On Jul 25, 2014, at 1:16 PM, Bruno Oliveira wrote: >>>> >>>>> On 2014-07-25, Summers Pittman wrote: >>>>>> On 07/22/2014 11:06 AM, Bruno Oliveira wrote: >>>>>>> Passos, what does aerogear-android-security stands for? Do we really >>>>>>> need the authz module? My question is due to the fact that mostly it >>>>>>> will be together with auth module, but I could be wrong. >>>>>> You are wrong :) >>>>> >>>>> Do you have authorization without authentication? Or authentication with >>>>> no authorization? >>>> >>>> We have this in our JS lib, the Authenitcation module, just does the login/logout/enroll >>>> >>>> and the Authz module doesn?t rely on it, but connects to 3rd party OAuth2( the current adapter ) providers >>> >>> If it connects using a Token from a 3rd party service, is because it's based on some credential. So, >>> I assume that you have authentication AND authorization, there's no magic ;) >>> >>> Either way, name it to whatever you guys think is the best. >> >> yea, the names can be confusing here :). we should rename to ?CoolSuperAwesomeThing? and ?bob? :) > > As long as you do at your own repository, I'm ok. Meanwhile let's not > mix the concept of OAuth2 with authorization only. > >> >>> >>>> >>>> >>>>> >>>>>> >>>>>> In general >>>>>> >>>>>> Auth module consumes a username and password and manages a session. >>>>>> Authz fetches and consumers tokens and manages them through a >>>>>> android.app.Service service. >>>>>>> >>>>>>> On 2014-07-22, Daniel Passos wrote: >>>>>>>> Hey Guys, >>>>>>>> >>>>>>>> Summers and I started working on agdroid modules and remove some cyclic >>>>>>>> dependencies. So we plan to split the agdroid on these modules: >>>>>>>> >>>>>>>> - aerogear-android-core >>>>>>>> - aerogear-android-pipe >>>>>>>> - aerogear-android-auth >>>>>>>> - aerogear-android-autz >>>>>>>> - aerogear-android-store (with option security dependecy to use >>>>>>>> EncryptedStores) >>>>>>>> - aerogear-android-security >>>>>>>> - aerogear-android-push >>>>>>>> - aerogear-android-push-ups >>>>>>>> - aerogear-android-offline >>>>>>>> >>>>>>>> -- Passos >>>>>>>> ? >>>>>>>> >>>>>>>> >>>>>>>> On Fri, May 9, 2014 at 3:55 AM, Corinne Krych >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Oops >>>>>>>>> [2] https://issues.jboss.org/browse/AGIOS-187 >>>>>>>>> >>>>>>>>> On 09 May 2014, at 08:52, Corinne Krych wrote: >>>>>>>>> >>>>>>>>>> [2] https://issues.jboss.org/browse/AGIOS-192 >>>>>>>>> _______________________________________________ >>>>>>>>> aerogear-dev mailing list >>>>>>>>> aerogear-dev at lists.jboss.org >>>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> aerogear-dev mailing list >>>>>>>> aerogear-dev at lists.jboss.org >>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>> >>>>>>> -- >>>>>>> >>>>>>> abstractj >>>>>>> PGP: 0x84DC9914 >>>>>>> _______________________________________________ >>>>>>> aerogear-dev mailing list >>>>>>> aerogear-dev at lists.jboss.org >>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>> >>>>>> >>>>>> -- >>>>>> Summers Pittman >>>>>>>> Phone:404 941 4698 >>>>>>>> Java is my crack. >>>>>> >>>>>> _______________________________________________ >>>>>> aerogear-dev mailing list >>>>>> aerogear-dev at lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>> >>>>> -- >>>>> >>>>> abstractj >>>>> PGP: 0x84DC9914 >>>>> _______________________________________________ >>>>> aerogear-dev mailing list >>>>> aerogear-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> >>> >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >>> >>> -- >>> >>> abstractj >>> PGP: 0x84DC9914 >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > -- > > abstractj > PGP: 0x84DC9914 > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev From corinnekrych at gmail.com Sat Jul 26 00:47:08 2014 From: corinnekrych at gmail.com (Corinne Krych) Date: Sat, 26 Jul 2014 06:47:08 +0200 Subject: [aerogear-dev] Github releases In-Reply-To: References: <40EEC57B-3CE7-40C8-B361-9A613DD1DB8C@redhat.com> <1406318362296.eec005@Nodemailer> Message-ID: <9F4B74D2-6B5F-403A-88F0-18EC9F107A80@gmail.com> That is neat indeed ++ Corinne On 26 Jul 2014, at 06:23, Daniel Bevenius wrote: > +1 Sounds good > > > On 25 July 2014 21:59, Bruno Oliveira wrote: > +1 > ? > abstractj > PGP: 0x84DC9914 > > > On Fri, Jul 25, 2014 at 4:13 PM, Lucas Holmquist wrote: > > Hi all, > > > yup, sending this on a Friday, at 3pm EST. > > while going over some of the JS push tutorial docs, i found that the links to the AG JS lib were point to somewhat older releases. While we could try to remember to update these docs after every release, i propose we use githubs really neat ?release? button. > > Basically, we would still tag our releases normally, and after we push those up, we can press the ?Draft a New Release? button. > > This allows us to choose an existing tag, but some release notes in, and also mark as a pre-release > > but the best part, is that we can now link to the ?latest? release in our docs > > This is the link created: https://github.com/aerogear/aerogear-js-dist/releases/latest > > > this will link to: https://github.com/aerogear/aerogear-js/releases/tag/1.5.1 > > > > wdyt? > > > -Luke > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev From cvasilak at gmail.com Sat Jul 26 01:23:28 2014 From: cvasilak at gmail.com (Christos Vasilakis) Date: Sat, 26 Jul 2014 08:23:28 +0300 Subject: [aerogear-dev] Github releases In-Reply-To: References: <40EEC57B-3CE7-40C8-B361-9A613DD1DB8C@redhat.com> <1406318362296.eec005@Nodemailer> Message-ID: <58E31E77-6266-425A-BA5D-9C8263932AD0@gmail.com> +9001 helpful indeed - Christos > On 26 ???? 2014, at 7:23 ?.?., Daniel Bevenius wrote: > > +1 Sounds good > > >> On 25 July 2014 21:59, Bruno Oliveira wrote: >> +1 >> ? >> abstractj >> PGP: 0x84DC9914 >> >> >>> On Fri, Jul 25, 2014 at 4:13 PM, Lucas Holmquist wrote: >>> Hi all, >>> >>> >>> yup, sending this on a Friday, at 3pm EST. >>> >>> while going over some of the JS push tutorial docs, i found that the links to the AG JS lib were point to somewhat older releases. While we could try to remember to update these docs after every release, i propose we use githubs really neat ?release? button. >>> >>> Basically, we would still tag our releases normally, and after we push those up, we can press the ?Draft a New Release? button. >>> >>> This allows us to choose an existing tag, but some release notes in, and also mark as a pre-release >>> >>> but the best part, is that we can now link to the ?latest? release in our docs >>> >>> This is the link created: https://github.com/aerogear/aerogear-js-dist/releases/latest >>> >>> >>> this will link to: https://github.com/aerogear/aerogear-js/releases/tag/1.5.1 >>> >>> >>> >>> wdyt? >>> >>> >>> -Luke >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140726/4f89e3c2/attachment-0001.html From matzew at apache.org Sat Jul 26 04:50:27 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Sat, 26 Jul 2014 10:50:27 +0200 Subject: [aerogear-dev] Github releases In-Reply-To: <40EEC57B-3CE7-40C8-B361-9A613DD1DB8C@redhat.com> References: <40EEC57B-3CE7-40C8-B361-9A613DD1DB8C@redhat.com> Message-ID: Yeah, I saw that too, it's nice a feature they have +1 on using that (versus specific tags/versions) -Matthias On Fri, Jul 25, 2014 at 9:13 PM, Lucas Holmquist wrote: > Hi all, > > yup, sending this on a Friday, at 3pm EST. > > while going over some of the JS push tutorial docs, i found that the links > to the AG JS lib were point to somewhat older releases. While we could try > to remember to update these docs after every release, i propose we use > githubs really neat ?release? button. > > Basically, we would still tag our releases normally, and after we push > those up, we can press the ?Draft a New Release? button. > > This allows us to choose an existing tag, but some release notes in, and > also mark as a pre-release > > but the best part, is that we can now link to the ?latest? release in our > docs > > This is the link created: > https://github.com/aerogear/aerogear-js-dist/releases/latest > > > this will link to: > https://github.com/aerogear/aerogear-js/releases/tag/1.5.1 > > > > wdyt? > > > -Luke > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140726/ba69585e/attachment.html From daniel at passos.me Sat Jul 26 09:36:44 2014 From: daniel at passos.me (Daniel Passos) Date: Sat, 26 Jul 2014 10:36:44 -0300 Subject: [aerogear-dev] Github releases In-Reply-To: References: <40EEC57B-3CE7-40C8-B361-9A613DD1DB8C@redhat.com> Message-ID: +1 On Sat, Jul 26, 2014 at 5:50 AM, Matthias Wessendorf wrote: > Yeah, I saw that too, it's nice a feature they have > > > +1 on using that (versus specific tags/versions) > > -Matthias > > > On Fri, Jul 25, 2014 at 9:13 PM, Lucas Holmquist > wrote: > >> Hi all, >> >> yup, sending this on a Friday, at 3pm EST. >> >> while going over some of the JS push tutorial docs, i found that the >> links to the AG JS lib were point to somewhat older releases. While we >> could try to remember to update these docs after every release, i propose >> we use githubs really neat ?release? button. >> >> Basically, we would still tag our releases normally, and after we push >> those up, we can press the ?Draft a New Release? button. >> >> This allows us to choose an existing tag, but some release notes in, and >> also mark as a pre-release >> >> but the best part, is that we can now link to the ?latest? release in >> our docs >> >> This is the link created: >> https://github.com/aerogear/aerogear-js-dist/releases/latest >> >> >> this will link to: >> https://github.com/aerogear/aerogear-js/releases/tag/1.5.1 >> >> >> >> wdyt? >> >> >> -Luke >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140726/5a7dd7c4/attachment.html From qmx at qmx.me Sat Jul 26 23:03:16 2014 From: qmx at qmx.me (Douglas Campos) Date: Sun, 27 Jul 2014 00:03:16 -0300 Subject: [aerogear-dev] Github releases In-Reply-To: <40EEC57B-3CE7-40C8-B361-9A613DD1DB8C@redhat.com> References: <40EEC57B-3CE7-40C8-B361-9A613DD1DB8C@redhat.com> Message-ID: <20140727030316.GD79892@darkstar.local> +3.14159 -- qmx From daniel.bevenius at gmail.com Sun Jul 27 11:40:17 2014 From: daniel.bevenius at gmail.com (Daniel Bevenius) Date: Sun, 27 Jul 2014 17:40:17 +0200 Subject: [aerogear-dev] Team meeting Message-ID: Agenda: http://oksoclap.com/p/aerogear-team-mgt-20140728 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140727/d0043b30/attachment.html From matzew at apache.org Mon Jul 28 03:07:24 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Mon, 28 Jul 2014 09:07:24 +0200 Subject: [aerogear-dev] [Vote] Release of UPS 1.0.0.Beta1 In-Reply-To: <15898286-33BA-487D-821A-6D11946008C2@redhat.com> References: <516051AF-3D4F-4416-A0A8-DD42375A431B@gmail.com> <15898286-33BA-487D-821A-6D11946008C2@redhat.com> Message-ID: Hi, thanks for voting/testing, guys! I have clicked the magic button on nexus. This release will be on Maven Central soon -Matthias On Fri, Jul 25, 2014 at 1:44 PM, Tadeas Kriz wrote: > I?ve run integration tests against the staging repository and the only > concern seems to be the unregistration of a simplepush variant we?ve > already been discussing. > > +1 on the release! Good job! > > ? > Tadeas Kriz > > On 24 Jul 2014, at 05:25 pm, Corinne Krych wrote: > > > +1 > > Successfully tested interactive notification on iOS8 with dev and prod > certificates on iOS8beta4 > > > > ++ > > Corinne > > On 24 Jul 2014, at 17:22, Sebastien Blanc wrote: > > > >> +1 > >> I've deployed the WARs on OpenShift, then tested with the HelloWorld > and the Contact App. > >> Everything work as expected ! > >> > >> > >> > >> On Wed, Jul 23, 2014 at 9:01 AM, Matthias Wessendorf > wrote: > >> Good morning folks! > >> > >> we are getting closer and closer to our 1.0.0 release! Thank you very > much, guys! > >> > >> However, before we are moving towards the 1.0.0.Final community > release, I'd love to get the current work out as 1.0.0.Beta1 > >> > >> Note this release contains a ton of work and new features. To name a > few highlights: > >> > >> * increased APNs payload (2k) > >> * iOS8 interactive notification support > >> * Pagination for analytics > >> * improved callback for details on actual push delivery > >> * optimisations and improvements > >> > >> Besides these changes, a ton of more work was done by the team: > >> https://issues.jboss.org/browse/AGPUSH/fixforversion/12323753 > >> > >> The staging repository is located here: > >> > https://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-3598 > >> > >> > >> NOTE: Once this release has been approved the matching tag will be used > to get the OpenShift online bits updated! > >> > >> Let me know the results of your testing! > >> If I hear nothing bad by Friday evening, the release to maven central > will happen on Monday; > >> > >> Greetings, > >> Matthias > >> > >> > >> > >> -- > >> Matthias Wessendorf > >> > >> blog: http://matthiaswessendorf.wordpress.com/ > >> sessions: http://www.slideshare.net/mwessendorf > >> twitter: http://twitter.com/mwessendorf > >> > >> _______________________________________________ > >> aerogear-dev mailing list > >> aerogear-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > >> > >> _______________________________________________ > >> aerogear-dev mailing list > >> aerogear-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140728/b9dd1303/attachment.html From matzew at apache.org Mon Jul 28 03:07:54 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Mon, 28 Jul 2014 09:07:54 +0200 Subject: [aerogear-dev] UPS: Java Sender release In-Reply-To: References: <46E8BE1A-B34A-4729-903B-DD27D70974D1@redhat.com> Message-ID: Hi, thanks for voting/testing, guys! I have clicked the magic button on nexus. This release will be on Maven Central soon -Matthias On Thu, Jul 24, 2014 at 5:26 PM, Corinne Krych wrote: > +1 tested on AeroDoc on iOS8 > > ++ > Corinne > On 24 Jul 2014, at 17:24, Sebastien Blanc wrote: > > > Tested with the Contact Quickstart + AeroDoc , work as expected ! > > +1 > > > > > > > > On Tue, Jul 22, 2014 at 10:31 AM, Matthias Wessendorf > wrote: > > awesome! > > > > > > On Tue, Jul 22, 2014 at 10:13 AM, Tadeas Kriz wrote: > > Hey, > > > > it will get tested in the same run as UnifiedPush server using our > integration tests suite. > > > > ? > > Tadeas Kriz > > > > On 22 Jul 2014, at 10:00 am, Matthias Wessendorf > wrote: > > > >> Hi, > >> > >> I'd like to release the 0.8.0 version of the java-sender. The staging > repo is here: > >> > http://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-3597/ > >> > >> > >> Changes since last release: > >> * AGPUSH-800 (need to be tested against master of UPS server) > >> * AGPUSH-783 > >> > >> Please test and let me know! > >> > >> Thanks! > >> > >> -- > >> Matthias Wessendorf > >> > >> blog: http://matthiaswessendorf.wordpress.com/ > >> sessions: http://www.slideshare.net/mwessendorf > >> twitter: http://twitter.com/mwessendorf > >> _______________________________________________ > >> aerogear-dev mailing list > >> aerogear-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > > > > -- > > Matthias Wessendorf > > > > blog: http://matthiaswessendorf.wordpress.com/ > > sessions: http://www.slideshare.net/mwessendorf > > twitter: http://twitter.com/mwessendorf > > > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140728/cd569271/attachment-0001.html From kpiwko at redhat.com Mon Jul 28 03:35:21 2014 From: kpiwko at redhat.com (Karel Piwko) Date: Mon, 28 Jul 2014 07:37:21 +0002 Subject: [aerogear-dev] Differences between Firefox OS "native" Push lib and AeroGear's Push adapter In-Reply-To: References: <9B70BDB9-4774-4BF0-9FF7-5213185E4F52@redhat.com> <51C9D854-0730-4B2A-9A92-9DC92649947D@redhat.com> <8AEB32A5-0F61-495B-8EA5-767F48312B9C@redhat.com> <02064329-0F9B-49DC-A5EC-A106001DD51F@redhat.com> <1406216640.15307.0@smtp.corp.redhat.com> <1E3E76E8-60D7-4BF3-9B95-6C58F4DC9286@redhat.com> <919B56C2-8E6D-4CD8-A620-F9839E013685@redhat.com> <1406292545.14163.0@smtp.corp.redhat.com> <1406293568.14163.1@smtp.corp.redhat.com> Message-ID: <1406532921.14163.2@smtp.corp.redhat.com> Yes, that was it. And you're right, it indeed makes better sense to generate UUID by client, not by server. Karel On Fri, Jul 25, 2014 at 3:19 PM, Matthias Wessendorf wrote: > > > > On Fri, Jul 25, 2014 at 3:06 PM, Karel Piwko > wrote: >> On Fri, Jul 25, 2014 at 2:56 PM, Matthias Wessendorf >> wrote: >> > >> >> UPS can translate {deviceToken} to EndpointURL. We just need a way >> >> how >> >> to generate unique {deviceToken} on client. >> > >> > that would be our own layer on-top, which is a no-go >> >> why? it would be there anyway. Imagine that your UPS is running on >> exposed URL which is a gateway to your internal network. SP URL is >> valid only in that internal network, not visible from outside world >> at >> all. >> >> So, using UPS is the only way to send the message to that URL. > > Hrm... let's see if I am following you. Let's try: > > If the UPS has a mapping between "magic_UUID" and endpointURL, that > means the client layer (e.g. UPS.js) has to store this UUID > somewhere, for unregistration. > > Instead of having the UPS generating the UUID, it could be generated > by the UPS.js, and its JS callback would/could return it (so that the > JS app has it handy for later unregister). > > That would mean the JS client would sending down the same JSON as > before, right ? > > deviceToken: client_side_generated_UUID, > pushEndpoint: someURL > > > Did I get it ? > > > >> >> > >> > >> >> Would UUID work? >> >> EndpointURL can become part of JSON [1]. >> > >> > it was there as "simplePushEndpoint", but for stated reasons it's >> now >> > the deviceToken that has the URL value >> > >> > >> >> >> >> Such change would mean that clients can't use SP server directly >> but >> >> have to go through UPS. This makes more sense then current setup >> to >> >> me. >> > >> > not really >> >> See reason stated above. >> > >> >> >> >> Karel >> >> >> >> [1] >> >> >> https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/jaxrs/src/main/java/org/jboss/aerogear/unifiedpush/rest/registry/installations/InstallationRegistrationEndpoint.java#L74 >> >> >> >> On Fri, Jul 25, 2014 at 1:04 PM, Matthias Wessendorf >> >> wrote: >> >> > >> >> > >> >> > >> >> > On Fri, Jul 25, 2014 at 12:25 PM, Tadeas Kriz >> >> > wrote: >> >> >> >> >> >> ? >> >> >> Tadeas Kriz >> >> >> >> >> >> On 25 Jul 2014, at 11:04 am, Daniel Bevenius >> >> >> wrote: >> >> >> >> >> >>> >5. don?t use the url as a deviceToken (might not comply >> with >> >> >>> Mozzila?s SimplePush specs) >> >> >>> The deviceToken is an UPS concept and there is nothing in the >> >> >>> SimplePush spec which is violated in this case. >> >> >>> >> >> >> I thought that deviceTokens were changed from a generated >> value to >> >> >> the URL just to comply with Mozzila?s SimplePush specs. >> >> > >> >> > Nope >> >> > >> >> >> Matzew, why was the generated token removed then? >> >> > >> >> > It was the channelID before - but that should not be exposed. >> >> > In GCM devices are identified via registrationID >> >> > In APNs devices are identified va deviceToken >> >> > (both are somewhat the same - but different names) >> >> > >> >> > In SimplePush devices are identifeid v/ the URL of the >> pushEndpoint >> >> > (a backend uses that endpoint to notify _THAT_ client, >> regardless >> >> of >> >> > how many channels it has subscribed) >> >> > >> >> > So, that lead us to make the change (see history of this threa) >> >> > >> >> > -M >> >> > >> >> > >> >> > >> >> >> >> >> >>> I'm not sure about what the best option is for UPS thought. >> >> Would a >> >> >>> regex in for the @Path annotation work perhaps, something >> like: >> >> >>> >> >> >>> @DELETE >> >> >>> @Path("{token, .+}") >> >> >>> public Response unregisterInstallations( >> >> >>> >> >> >> >> >> >> What do you mean by that regex? The problem is simply the >> >> ?%2F? >> >> >> in the token (which is an URLencoded simplepush url) and it?s >> >> >> being revoked long before it hits the RestEasy (which does the >> >> >> routing according to what?s in the @Path). >> >> >> >> >> >>> >> >> >>> On 25 July 2014 10:32, Tadeas Kriz wrote: >> >> >>>> >> >> >>>> ? >> >> >>>> Tadeas Kriz >> >> >>>> >> >> >>>> On 24 Jul 2014, at 05:44 pm, Karel Piwko >> >> wrote: >> >> >>>> >> >> >>>> > On Thu, Jul 24, 2014 at 3:28 PM, Tadeas Kriz >> >> >> >> >>>> wrote: >> >> >>>> >> >> >> >>>> >> It should not. For hibernate, it?s just a string like >> any >> >> >>>> other. >> >> >>>> >> The problem might be in the configuration of >> >> JAX.RS/RestEasy. If >> >> >>>> >> I?ll have some time today evening, I?ll try to fix >> it, it >> >> >>>> should >> >> >>>> >> be an easy fix. >> >> >>>> > >> >> >>>> > Last famous words? ;-) >> >> >>>> > >> >> >>>> >> >> >>>> I shall never say ?an easy fix? again. >> >> >>>> >> >> >>>> > But I agree. Everything is string and URL encode should >> >> happen on >> >> >>>> > client while server should automatically decode and work >> >> always >> >> >>>> with >> >> >>>> > just decoded string. If we need to encode twice, something >> is >> >> >>>> wrong. >> >> >>>> > >> >> >>>> >> >> >>>> Anyway, the 400 Bad request response is made by the tomcat >> >> itself, >> >> >>>> disallowing the use of %2F as a path parameter. This will >> >> probably >> >> >>>> apply on other web containers. >> >> >>>> >> >> >>>> Possible solutions with their disadvantages: >> >> >>>> >> >> >>>> 1. well-documented double-encoding of the URL (might be >> >> confusing) >> >> >>>> 2. use @QueryParam instead of @PathParam (breaks the api >> >> >>>> consistence, as every other call would still use @PathParam) >> >> >>>> 3. allow @QueryParam (again, breaks the api consistence, but >> >> only >> >> >>>> for the SimplePush) >> >> >>>> 4. find another encoding (Base64 for URL = URLEncode then >> Base64 >> >> >>>> encode) >> >> >>>> 5. don?t use the url as a deviceToken (might not comply >> with >> >> >>>> Mozzila?s SimplePush specs) >> >> >>>> >> >> >>>> What do you think guys? >> >> >>>> >> >> >>>> >> >> >> >>>> >> >> >> >>>> > >> >> >>>> > >> >> >>>> > _______________________________________________ >> >> >>>> > aerogear-dev mailing list >> >> >>>> > aerogear-dev at lists.jboss.org >> >> >>>> > https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >>>> >> >> >>>> >> >> >>>> _______________________________________________ >> >> >>>> aerogear-dev mailing list >> >> >>>> aerogear-dev at lists.jboss.org >> >> >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >>> >> >> >>> _______________________________________________ >> >> >>> aerogear-dev mailing list >> >> >>> aerogear-dev at lists.jboss.org >> >> >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> >> >> >> >> >> >> _______________________________________________ >> >> >> aerogear-dev mailing list >> >> >> aerogear-dev at lists.jboss.org >> >> >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> > >> >> > >> >> > >> >> > -- >> >> > Matthias Wessendorf >> >> > >> >> > blog: http://matthiaswessendorf.wordpress.com/ >> >> > sessions: http://www.slideshare.net/mwessendorf >> >> > twitter: http://twitter.com/mwessendorf >> >> >> >> >> >> _______________________________________________ >> >> aerogear-dev mailing list >> >> aerogear-dev at lists.jboss.org >> >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > >> > >> > >> > -- >> > Matthias Wessendorf >> > >> > blog: http://matthiaswessendorf.wordpress.com/ >> > sessions: http://www.slideshare.net/mwessendorf >> > twitter: http://twitter.com/mwessendorf >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf From lukas.fryc at gmail.com Mon Jul 28 03:44:25 2014 From: lukas.fryc at gmail.com (=?UTF-8?B?THVrw6HFoSBGcnnEjQ==?=) Date: Mon, 28 Jul 2014 09:44:25 +0200 Subject: [aerogear-dev] Github releases In-Reply-To: <40EEC57B-3CE7-40C8-B361-9A613DD1DB8C@redhat.com> References: <40EEC57B-3CE7-40C8-B361-9A613DD1DB8C@redhat.com> Message-ID: +1 sounds good https://github.com/blog/1547-release-your-software On Fri, Jul 25, 2014 at 9:13 PM, Lucas Holmquist wrote: > Hi all, > > yup, sending this on a Friday, at 3pm EST. > > while going over some of the JS push tutorial docs, i found that the links > to the AG JS lib were point to somewhat older releases. While we could try > to remember to update these docs after every release, i propose we use > githubs really neat ?release? button. > > Basically, we would still tag our releases normally, and after we push > those up, we can press the ?Draft a New Release? button. > > This allows us to choose an existing tag, but some release notes in, and > also mark as a pre-release > > but the best part, is that we can now link to the ?latest? release in our > docs > > This is the link created: > https://github.com/aerogear/aerogear-js-dist/releases/latest > > > this will link to: > https://github.com/aerogear/aerogear-js/releases/tag/1.5.1 > > > > wdyt? > > > -Luke > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140728/8dd55e80/attachment.html From matzew at apache.org Mon Jul 28 08:47:43 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Mon, 28 Jul 2014 14:47:43 +0200 Subject: [aerogear-dev] [UnifiedPush] From JBoss AS 7.1.1 to WildFly 8.x Message-ID: Hi, currently we are working on getting support for WildFly8.x in. Our offering currently is focused on an outdated version of the JBoss AS 7.1.1 (including on OpenShift). I'd like to propose dropping JBoss AS 7.1.1 and have it working on latest EAP (6.3.x) and WildFly 8.x instead. This would also allow us to finally merge the PR for [1] Any thoughts ? -Matthias [1] https://issues.jboss.org/browse/AGPUSH-673 -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140728/94454524/attachment.html From scm.blanc at gmail.com Mon Jul 28 08:49:12 2014 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Mon, 28 Jul 2014 14:49:12 +0200 Subject: [aerogear-dev] [UnifiedPush] From JBoss AS 7.1.1 to WildFly 8.x In-Reply-To: References: Message-ID: Does "dropping" means it won't work anymore on AS7 ? On Mon, Jul 28, 2014 at 2:47 PM, Matthias Wessendorf wrote: > Hi, > > currently we are working on getting support for WildFly8.x in. Our > offering currently is focused on an outdated version of the JBoss AS 7.1.1 > (including on OpenShift). > > I'd like to propose dropping JBoss AS 7.1.1 and have it working on latest > EAP (6.3.x) and WildFly 8.x instead. This would also allow us to finally > merge the PR for [1] > > Any thoughts ? > > -Matthias > > [1] https://issues.jboss.org/browse/AGPUSH-673 > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140728/895b4754/attachment-0001.html From daniel.bevenius at gmail.com Mon Jul 28 08:49:32 2014 From: daniel.bevenius at gmail.com (Daniel Bevenius) Date: Mon, 28 Jul 2014 14:49:32 +0200 Subject: [aerogear-dev] [UnifiedPush] From JBoss AS 7.1.1 to WildFly 8.x In-Reply-To: References: Message-ID: +1 sound good. On 28 July 2014 14:47, Matthias Wessendorf wrote: > Hi, > > currently we are working on getting support for WildFly8.x in. Our > offering currently is focused on an outdated version of the JBoss AS 7.1.1 > (including on OpenShift). > > I'd like to propose dropping JBoss AS 7.1.1 and have it working on latest > EAP (6.3.x) and WildFly 8.x instead. This would also allow us to finally > merge the PR for [1] > > Any thoughts ? > > -Matthias > > [1] https://issues.jboss.org/browse/AGPUSH-673 > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140728/ec6da890/attachment-0001.html From matzew at apache.org Mon Jul 28 08:57:19 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Mon, 28 Jul 2014 14:57:19 +0200 Subject: [aerogear-dev] [UnifiedPush] From JBoss AS 7.1.1 to WildFly 8.x In-Reply-To: References: Message-ID: On Mon, Jul 28, 2014 at 2:49 PM, Sebastien Blanc wrote: > Does "dropping" means it won't work anymore on AS7 ? > yeah, and supporting than only EAP6.3 and WildFly8 E.g. the referenced JIRA is something we can not do today, simply because it's broken on JBoss AS 7.1.1. > > > > On Mon, Jul 28, 2014 at 2:47 PM, Matthias Wessendorf > wrote: > >> Hi, >> >> currently we are working on getting support for WildFly8.x in. Our >> offering currently is focused on an outdated version of the JBoss AS 7.1.1 >> (including on OpenShift). >> >> I'd like to propose dropping JBoss AS 7.1.1 and have it working on latest >> EAP (6.3.x) and WildFly 8.x instead. This would also allow us to finally >> merge the PR for [1] >> >> Any thoughts ? >> >> -Matthias >> >> [1] https://issues.jboss.org/browse/AGPUSH-673 >> >> -- >> Matthias Wessendorf >> >> blog: http://matthiaswessendorf.wordpress.com/ >> sessions: http://www.slideshare.net/mwessendorf >> twitter: http://twitter.com/mwessendorf >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140728/5aa7b967/attachment.html From bruno at abstractj.org Mon Jul 28 09:28:06 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Mon, 28 Jul 2014 10:28:06 -0300 Subject: [aerogear-dev] [UnifiedPush] From JBoss AS 7.1.1 to WildFly 8.x In-Reply-To: References: Message-ID: <20140728132806.GA43110@abstractj.org> +1 as long as we get it fully tested on Wildfly before. I would wait for Keycloak beta4 be released, because it contains fixes for Wildfly. On 2014-07-28, Matthias Wessendorf wrote: > Hi, > > currently we are working on getting support for WildFly8.x in. Our offering > currently is focused on an outdated version of the JBoss AS 7.1.1 > (including on OpenShift). > > I'd like to propose dropping JBoss AS 7.1.1 and have it working on latest > EAP (6.3.x) and WildFly 8.x instead. This would also allow us to finally > merge the PR for [1] > > Any thoughts ? > > -Matthias > > [1] https://issues.jboss.org/browse/AGPUSH-673 > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -- abstractj PGP: 0x84DC9914 From supittma at redhat.com Mon Jul 28 09:42:42 2014 From: supittma at redhat.com (Summers Pittman) Date: Mon, 28 Jul 2014 09:42:42 -0400 Subject: [aerogear-dev] Modularizing the Android Library In-Reply-To: <20140725190100.GA1461@abstractj.org> References: <20140508192800.GB69433@abstractj.org> <4CD71A7A-EDE1-4648-AB3E-E4DDB383D824@gmail.com> <20140722150611.GA58163@abstractj.org> <53D280B2.4070100@redhat.com> <20140725171611.GC26186@abstractj.org> <20140725172551.GD26186@abstractj.org> <20140725190100.GA1461@abstractj.org> Message-ID: <53D65352.3040203@redhat.com> On 07/25/2014 03:01 PM, Bruno Oliveira wrote: > On 2014-07-25, Lucas Holmquist wrote: >> On Jul 25, 2014, at 1:25 PM, Bruno Oliveira wrote: >> >>> On 2014-07-25, Lucas Holmquist wrote: >>>> On Jul 25, 2014, at 1:16 PM, Bruno Oliveira wrote: >>>> >>>>> On 2014-07-25, Summers Pittman wrote: >>>>>> On 07/22/2014 11:06 AM, Bruno Oliveira wrote: >>>>>>> Passos, what does aerogear-android-security stands for? Do we really >>>>>>> need the authz module? My question is due to the fact that mostly it >>>>>>> will be together with auth module, but I could be wrong. >>>>>> You are wrong :) >>>>> Do you have authorization without authentication? Or authentication with >>>>> no authorization? >>>> We have this in our JS lib, the Authenitcation module, just does the login/logout/enroll >>>> >>>> and the Authz module doesn?t rely on it, but connects to 3rd party OAuth2( the current adapter ) providers >>> If it connects using a Token from a 3rd party service, is because it's based on some credential. So, >>> I assume that you have authentication AND authorization, there's no magic ;) >>> >>> Either way, name it to whatever you guys think is the best. >> yea, the names can be confusing here :). we should rename to ?CoolSuperAwesomeThing? and ?bob? :) > As long as you do at your own repository, I'm ok. Meanwhile let's not > mix the concept of OAuth2 with authorization only. OAuth2 is an implementation of Authorization. We have Jira's for OAuth1a, alternate work flows etc. A better way to think about it would be the auth module is user visible credential authentication and authorization. The authz module is third party authentication and authorization. A while ago we did discuss revisiting authz/auth and see if they can be meaningfully merged. This may be something for a different thread. As it stands they don't make sense to be in the same module because they work differently for different use cases. > >>>> >>>>>> In general >>>>>> >>>>>> Auth module consumes a username and password and manages a session. >>>>>> Authz fetches and consumers tokens and manages them through a >>>>>> android.app.Service service. >>>>>>> On 2014-07-22, Daniel Passos wrote: >>>>>>>> Hey Guys, >>>>>>>> >>>>>>>> Summers and I started working on agdroid modules and remove some cyclic >>>>>>>> dependencies. So we plan to split the agdroid on these modules: >>>>>>>> >>>>>>>> - aerogear-android-core >>>>>>>> - aerogear-android-pipe >>>>>>>> - aerogear-android-auth >>>>>>>> - aerogear-android-autz >>>>>>>> - aerogear-android-store (with option security dependecy to use >>>>>>>> EncryptedStores) >>>>>>>> - aerogear-android-security >>>>>>>> - aerogear-android-push >>>>>>>> - aerogear-android-push-ups >>>>>>>> - aerogear-android-offline >>>>>>>> >>>>>>>> -- Passos >>>>>>>> ? >>>>>>>> >>>>>>>> >>>>>>>> On Fri, May 9, 2014 at 3:55 AM, Corinne Krych >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Oops >>>>>>>>> [2] https://issues.jboss.org/browse/AGIOS-187 >>>>>>>>> >>>>>>>>> On 09 May 2014, at 08:52, Corinne Krych wrote: >>>>>>>>> >>>>>>>>>> [2] https://issues.jboss.org/browse/AGIOS-192 >>>>>>>>> _______________________________________________ >>>>>>>>> aerogear-dev mailing list >>>>>>>>> aerogear-dev at lists.jboss.org >>>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> aerogear-dev mailing list >>>>>>>> aerogear-dev at lists.jboss.org >>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>> -- >>>>>>> >>>>>>> abstractj >>>>>>> PGP: 0x84DC9914 >>>>>>> _______________________________________________ >>>>>>> aerogear-dev mailing list >>>>>>> aerogear-dev at lists.jboss.org >>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>> >>>>>> -- >>>>>> Summers Pittman >>>>>>>> Phone:404 941 4698 >>>>>>>> Java is my crack. >>>>>> _______________________________________________ >>>>>> aerogear-dev mailing list >>>>>> aerogear-dev at lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>> -- >>>>> >>>>> abstractj >>>>> PGP: 0x84DC9914 >>>>> _______________________________________________ >>>>> aerogear-dev mailing list >>>>> aerogear-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >>> -- >>> >>> abstractj >>> PGP: 0x84DC9914 >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > -- > > abstractj > PGP: 0x84DC9914 > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -- Summers Pittman >>Phone:404 941 4698 >>Java is my crack. From matzew at apache.org Mon Jul 28 09:45:57 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Mon, 28 Jul 2014 15:45:57 +0200 Subject: [aerogear-dev] [UnifiedPush] From JBoss AS 7.1.1 to WildFly 8.x In-Reply-To: <20140728132806.GA43110@abstractj.org> References: <20140728132806.GA43110@abstractj.org> Message-ID: On Mon, Jul 28, 2014 at 3:28 PM, Bruno Oliveira wrote: > +1 as long as we get it fully tested on Wildfly before. I would wait for > Keycloak beta4 be released, because it contains fixes for Wildfly. > good point on the KC beta4! -M > > On 2014-07-28, Matthias Wessendorf wrote: > > Hi, > > > > currently we are working on getting support for WildFly8.x in. Our > offering > > currently is focused on an outdated version of the JBoss AS 7.1.1 > > (including on OpenShift). > > > > I'd like to propose dropping JBoss AS 7.1.1 and have it working on latest > > EAP (6.3.x) and WildFly 8.x instead. This would also allow us to finally > > merge the PR for [1] > > > > Any thoughts ? > > > > -Matthias > > > > [1] https://issues.jboss.org/browse/AGPUSH-673 > > > > -- > > Matthias Wessendorf > > > > blog: http://matthiaswessendorf.wordpress.com/ > > sessions: http://www.slideshare.net/mwessendorf > > twitter: http://twitter.com/mwessendorf > > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > -- > > abstractj > PGP: 0x84DC9914 > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140728/09a29446/attachment.html From bruno at abstractj.org Mon Jul 28 10:09:55 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Mon, 28 Jul 2014 11:09:55 -0300 Subject: [aerogear-dev] Modularizing the Android Library In-Reply-To: <53D65352.3040203@redhat.com> References: <4CD71A7A-EDE1-4648-AB3E-E4DDB383D824@gmail.com> <20140722150611.GA58163@abstractj.org> <53D280B2.4070100@redhat.com> <20140725171611.GC26186@abstractj.org> <20140725172551.GD26186@abstractj.org> <20140725190100.GA1461@abstractj.org> <53D65352.3040203@redhat.com> Message-ID: <20140728140955.GB43110@abstractj.org> Answers inline. On 2014-07-28, Summers Pittman wrote: > On 07/25/2014 03:01 PM, Bruno Oliveira wrote: > > On 2014-07-25, Lucas Holmquist wrote: > >> On Jul 25, 2014, at 1:25 PM, Bruno Oliveira wrote: > >> > >>> On 2014-07-25, Lucas Holmquist wrote: > >>>> On Jul 25, 2014, at 1:16 PM, Bruno Oliveira wrote: > >>>> > >>>>> On 2014-07-25, Summers Pittman wrote: > >>>>>> On 07/22/2014 11:06 AM, Bruno Oliveira wrote: > >>>>>>> Passos, what does aerogear-android-security stands for? Do we really > >>>>>>> need the authz module? My question is due to the fact that mostly it > >>>>>>> will be together with auth module, but I could be wrong. > >>>>>> You are wrong :) > >>>>> Do you have authorization without authentication? Or authentication with > >>>>> no authorization? > >>>> We have this in our JS lib, the Authenitcation module, just does the login/logout/enroll > >>>> > >>>> and the Authz module doesn?t rely on it, but connects to 3rd party OAuth2( the current adapter ) providers > >>> If it connects using a Token from a 3rd party service, is because it's based on some credential. So, > >>> I assume that you have authentication AND authorization, there's no magic ;) > >>> > >>> Either way, name it to whatever you guys think is the best. > >> yea, the names can be confusing here :). we should rename to ?CoolSuperAwesomeThing? and ?bob? :) > > As long as you do at your own repository, I'm ok. Meanwhile let's not > > mix the concept of OAuth2 with authorization only. > OAuth2 is an implementation of Authorization. We have Jira's for > OAuth1a, alternate work flows etc. Summers, there's no authorization without authentication before. Even with OAuth2 the client make use of the Bearer authentication scheme for example. If you assume that OAuth2 is authorization only, would be the same of assume that once my application is authorized on Twitter, I should be able to access many profiles as I want. Even if IETF says "The OAuth 2.0 Authorization Framework: Bearer Token Usage". > > A better way to think about it would be the auth module is user visible > credential authentication and authorization. The authz module is third > party authentication and authorization.a authz into any security context stands for "authorization", if you mix both concepts here, people will get confused. > > A while ago we did discuss revisiting authz/auth and see if they can be > meaningfully merged. This may be something for a different thread. As > it stands they don't make sense to be in the same module because they > work differently for different use cases. As I said, I trust in your judgment, but mix concepts will lead to confusion. > > > > >>>> > >>>>>> In general > >>>>>> > >>>>>> Auth module consumes a username and password and manages a session. > >>>>>> Authz fetches and consumers tokens and manages them through a > >>>>>> android.app.Service service. > >>>>>>> On 2014-07-22, Daniel Passos wrote: > >>>>>>>> Hey Guys, > >>>>>>>> > >>>>>>>> Summers and I started working on agdroid modules and remove some cyclic > >>>>>>>> dependencies. So we plan to split the agdroid on these modules: > >>>>>>>> > >>>>>>>> - aerogear-android-core > >>>>>>>> - aerogear-android-pipe > >>>>>>>> - aerogear-android-auth > >>>>>>>> - aerogear-android-autz > >>>>>>>> - aerogear-android-store (with option security dependecy to use > >>>>>>>> EncryptedStores) > >>>>>>>> - aerogear-android-security > >>>>>>>> - aerogear-android-push > >>>>>>>> - aerogear-android-push-ups > >>>>>>>> - aerogear-android-offline > >>>>>>>> > >>>>>>>> -- Passos > >>>>>>>> ? > >>>>>>>> > >>>>>>>> > >>>>>>>> On Fri, May 9, 2014 at 3:55 AM, Corinne Krych > >>>>>>>> wrote: > >>>>>>>> > >>>>>>>>> Oops > >>>>>>>>> [2] https://issues.jboss.org/browse/AGIOS-187 > >>>>>>>>> > >>>>>>>>> On 09 May 2014, at 08:52, Corinne Krych wrote: > >>>>>>>>> > >>>>>>>>>> [2] https://issues.jboss.org/browse/AGIOS-192 > >>>>>>>>> _______________________________________________ > >>>>>>>>> aerogear-dev mailing list > >>>>>>>>> aerogear-dev at lists.jboss.org > >>>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev > >>>>>>>>> > >>>>>>>> _______________________________________________ > >>>>>>>> aerogear-dev mailing list > >>>>>>>> aerogear-dev at lists.jboss.org > >>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev > >>>>>>> -- > >>>>>>> > >>>>>>> abstractj > >>>>>>> PGP: 0x84DC9914 > >>>>>>> _______________________________________________ > >>>>>>> aerogear-dev mailing list > >>>>>>> aerogear-dev at lists.jboss.org > >>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev > >>>>>> > >>>>>> -- > >>>>>> Summers Pittman > >>>>>>>> Phone:404 941 4698 > >>>>>>>> Java is my crack. > >>>>>> _______________________________________________ > >>>>>> aerogear-dev mailing list > >>>>>> aerogear-dev at lists.jboss.org > >>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev > >>>>> -- > >>>>> > >>>>> abstractj > >>>>> PGP: 0x84DC9914 > >>>>> _______________________________________________ > >>>>> aerogear-dev mailing list > >>>>> aerogear-dev at lists.jboss.org > >>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev > >>>> _______________________________________________ > >>>> aerogear-dev mailing list > >>>> aerogear-dev at lists.jboss.org > >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev > >>> > >>> -- > >>> > >>> abstractj > >>> PGP: 0x84DC9914 > >>> _______________________________________________ > >>> aerogear-dev mailing list > >>> aerogear-dev at lists.jboss.org > >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev > >> _______________________________________________ > >> aerogear-dev mailing list > >> aerogear-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > -- > > > > abstractj > > PGP: 0x84DC9914 > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > -- > Summers Pittman > >>Phone:404 941 4698 > >>Java is my crack. > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -- abstractj PGP: 0x84DC9914 From cvasilak at gmail.com Mon Jul 28 10:12:07 2014 From: cvasilak at gmail.com (Christos Vasilakis) Date: Mon, 28 Jul 2014 17:12:07 +0300 Subject: [aerogear-dev] Team meeting In-Reply-To: References: Message-ID: <5CD08B77-B230-4FA3-A72A-D9EA9889BD64@gmail.com> fyi, meeting minutes: Meeting ended Mon Jul 28 14:09:12 2014 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) Minutes: http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2014/aerogear.2014-07-28-14.00.html Minutes (text): http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2014/aerogear.2014-07-28-14.00.txt Log: http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2014/aerogear.2014-07-28-14.00.log.html On Jul 27, 2014, at 6:40 PM, Daniel Bevenius wrote: > Agenda: > http://oksoclap.com/p/aerogear-team-mgt-20140728 > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140728/6f59bc5a/attachment.html From corinnekrych at gmail.com Mon Jul 28 10:23:33 2014 From: corinnekrych at gmail.com (Corinne Krych) Date: Mon, 28 Jul 2014 16:23:33 +0200 Subject: [aerogear-dev] Modularizing the Android Library In-Reply-To: <20140728140955.GB43110@abstractj.org> References: <4CD71A7A-EDE1-4648-AB3E-E4DDB383D824@gmail.com> <20140722150611.GA58163@abstractj.org> <53D280B2.4070100@redhat.com> <20140725171611.GC26186@abstractj.org> <20140725172551.GD26186@abstractj.org> <20140725190100.GA1461@abstractj.org> <53D65352.3040203@redhat.com> <20140728140955.GB43110@abstractj.org> Message-ID: @abstractj @summers what about being more specific and naming ag-android-authz as ag-android-oauth2? This will be without confusion. For now we only implement oauth2. If we need oauth1a impl we can have a separate module. wdyt? This is the way i?d like to go for iOS lib. With Oauth2 you do need authentication but as it?s taken care of by the oauth2 provider, client side lib does not need a ?login? method, this indeed why we need auth module is different to authz one. ++ Corinne On 28 Jul 2014, at 16:09, Bruno Oliveira wrote: > Answers inline. > > On 2014-07-28, Summers Pittman wrote: >> On 07/25/2014 03:01 PM, Bruno Oliveira wrote: >>> On 2014-07-25, Lucas Holmquist wrote: >>>> On Jul 25, 2014, at 1:25 PM, Bruno Oliveira wrote: >>>> >>>>> On 2014-07-25, Lucas Holmquist wrote: >>>>>> On Jul 25, 2014, at 1:16 PM, Bruno Oliveira wrote: >>>>>> >>>>>>> On 2014-07-25, Summers Pittman wrote: >>>>>>>> On 07/22/2014 11:06 AM, Bruno Oliveira wrote: >>>>>>>>> Passos, what does aerogear-android-security stands for? Do we really >>>>>>>>> need the authz module? My question is due to the fact that mostly it >>>>>>>>> will be together with auth module, but I could be wrong. >>>>>>>> You are wrong :) >>>>>>> Do you have authorization without authentication? Or authentication with >>>>>>> no authorization? >>>>>> We have this in our JS lib, the Authenitcation module, just does the login/logout/enroll >>>>>> >>>>>> and the Authz module doesn?t rely on it, but connects to 3rd party OAuth2( the current adapter ) providers >>>>> If it connects using a Token from a 3rd party service, is because it's based on some credential. So, >>>>> I assume that you have authentication AND authorization, there's no magic ;) >>>>> >>>>> Either way, name it to whatever you guys think is the best. >>>> yea, the names can be confusing here :). we should rename to ?CoolSuperAwesomeThing? and ?bob? :) >>> As long as you do at your own repository, I'm ok. Meanwhile let's not >>> mix the concept of OAuth2 with authorization only. >> OAuth2 is an implementation of Authorization. We have Jira's for >> OAuth1a, alternate work flows etc. > > Summers, there's no authorization without authentication before. Even > with OAuth2 the client make use of the Bearer authentication scheme for > example. > > If you assume that OAuth2 is authorization only, would be the same of > assume that once my application is authorized on Twitter, I should be able > to access many profiles as I want. > > Even if IETF says "The OAuth 2.0 Authorization Framework: Bearer Token > Usage". > >> >> A better way to think about it would be the auth module is user visible >> credential authentication and authorization. The authz module is third >> party authentication and authorization.a > > authz into any security context stands for "authorization", if you mix > both concepts here, people will get confused. > >> >> A while ago we did discuss revisiting authz/auth and see if they can be >> meaningfully merged. This may be something for a different thread. As >> it stands they don't make sense to be in the same module because they >> work differently for different use cases. > > As I said, I trust in your judgment, but mix concepts will lead to > confusion. > >> >>> >>>>>> >>>>>>>> In general >>>>>>>> >>>>>>>> Auth module consumes a username and password and manages a session. >>>>>>>> Authz fetches and consumers tokens and manages them through a >>>>>>>> android.app.Service service. >>>>>>>>> On 2014-07-22, Daniel Passos wrote: >>>>>>>>>> Hey Guys, >>>>>>>>>> >>>>>>>>>> Summers and I started working on agdroid modules and remove some cyclic >>>>>>>>>> dependencies. So we plan to split the agdroid on these modules: >>>>>>>>>> >>>>>>>>>> - aerogear-android-core >>>>>>>>>> - aerogear-android-pipe >>>>>>>>>> - aerogear-android-auth >>>>>>>>>> - aerogear-android-autz >>>>>>>>>> - aerogear-android-store (with option security dependecy to use >>>>>>>>>> EncryptedStores) >>>>>>>>>> - aerogear-android-security >>>>>>>>>> - aerogear-android-push >>>>>>>>>> - aerogear-android-push-ups >>>>>>>>>> - aerogear-android-offline >>>>>>>>>> >>>>>>>>>> -- Passos >>>>>>>>>> ? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Fri, May 9, 2014 at 3:55 AM, Corinne Krych >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> Oops >>>>>>>>>>> [2] https://issues.jboss.org/browse/AGIOS-187 >>>>>>>>>>> >>>>>>>>>>> On 09 May 2014, at 08:52, Corinne Krych wrote: >>>>>>>>>>> >>>>>>>>>>>> [2] https://issues.jboss.org/browse/AGIOS-192 >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> aerogear-dev mailing list >>>>>>>>>>> aerogear-dev at lists.jboss.org >>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> aerogear-dev mailing list >>>>>>>>>> aerogear-dev at lists.jboss.org >>>>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>>> -- >>>>>>>>> >>>>>>>>> abstractj >>>>>>>>> PGP: 0x84DC9914 >>>>>>>>> _______________________________________________ >>>>>>>>> aerogear-dev mailing list >>>>>>>>> aerogear-dev at lists.jboss.org >>>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>> >>>>>>>> -- >>>>>>>> Summers Pittman >>>>>>>>>> Phone:404 941 4698 >>>>>>>>>> Java is my crack. >>>>>>>> _______________________________________________ >>>>>>>> aerogear-dev mailing list >>>>>>>> aerogear-dev at lists.jboss.org >>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>> -- >>>>>>> >>>>>>> abstractj >>>>>>> PGP: 0x84DC9914 >>>>>>> _______________________________________________ >>>>>>> aerogear-dev mailing list >>>>>>> aerogear-dev at lists.jboss.org >>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>> _______________________________________________ >>>>>> aerogear-dev mailing list >>>>>> aerogear-dev at lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>> >>>>> -- >>>>> >>>>> abstractj >>>>> PGP: 0x84DC9914 >>>>> _______________________________________________ >>>>> aerogear-dev mailing list >>>>> aerogear-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >>> -- >>> >>> abstractj >>> PGP: 0x84DC9914 >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> -- >> Summers Pittman >>>> Phone:404 941 4698 >>>> Java is my crack. >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > -- > > abstractj > PGP: 0x84DC9914 > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev From lholmqui at redhat.com Mon Jul 28 10:56:36 2014 From: lholmqui at redhat.com (Luke Holmquist) Date: Mon, 28 Jul 2014 10:56:36 -0400 (EDT) Subject: [aerogear-dev] Differences between Firefox OS "native" Push lib and AeroGear's Push adapter In-Reply-To: <1406532921.14163.2@smtp.corp.redhat.com> References: <9B70BDB9-4774-4BF0-9FF7-5213185E4F52@redhat.com> <51C9D854-0730-4B2A-9A92-9DC92649947D@redhat.com> <8AEB32A5-0F61-495B-8EA5-767F48312B9C@redhat.com> <02064329-0F9B-49DC-A5EC-A106001DD51F! @redhat.com> <1406216640.15307.0@smtp.corp.redhat.com> <1E3E76E8-60D7-4BF3-9B95-6C58F4DC9286@redhat.com> <919B56C2-8E6D-4CD8-A620-F9839E013685@redhat.com> <1406292545.14163.0@smtp.corp.redhat.com> <1406293568.14163.1@smtp.corp.redhat.com> <1406532921.14163.2@smtp.corp.redhat.com> Message-ID: <5E92DCB2-42DD-4E6D-8E30-6710C2010DEF@redhat.com> I would rather not have to generate some id and then store that locally. Simple push is not the only thing the uses the UPS client. Sent from my iPhone > On Jul 28, 2014, at 3:36 AM, Karel Piwko wrote: > > Yes, that was it. And you're right, it indeed makes better sense to > generate UUID by client, not by server. > > Karel > > > > On Fri, Jul 25, 2014 at 3:19 PM, Matthias Wessendorf > wrote: >> >> >> >> On Fri, Jul 25, 2014 at 3:06 PM, Karel Piwko >> wrote: >>> On Fri, Jul 25, 2014 at 2:56 PM, Matthias Wessendorf >>> wrote: >>>> >>>>> UPS can translate {deviceToken} to EndpointURL. We just need a way >>>>> how >>>>> to generate unique {deviceToken} on client. >>>> >>>> that would be our own layer on-top, which is a no-go >>> >>> why? it would be there anyway. Imagine that your UPS is running on >>> exposed URL which is a gateway to your internal network. SP URL is >>> valid only in that internal network, not visible from outside world >>> at >>> all. >>> >>> So, using UPS is the only way to send the message to that URL. >> >> Hrm... let's see if I am following you. Let's try: >> >> If the UPS has a mapping between "magic_UUID" and endpointURL, that >> means the client layer (e.g. UPS.js) has to store this UUID >> somewhere, for unregistration. >> >> Instead of having the UPS generating the UUID, it could be generated >> by the UPS.js, and its JS callback would/could return it (so that the >> JS app has it handy for later unregister). >> >> That would mean the JS client would sending down the same JSON as >> before, right ? >> >> deviceToken: client_side_generated_UUID, >> pushEndpoint: someURL >> >> >> Did I get it ? >> >> >> >>> >>>> >>>> >>>>> Would UUID work? >>>>> EndpointURL can become part of JSON [1]. >>>> >>>> it was there as "simplePushEndpoint", but for stated reasons it's >>> now >>>> the deviceToken that has the URL value >>>> >>>> >>>>> >>>>> Such change would mean that clients can't use SP server directly >>> but >>>>> have to go through UPS. This makes more sense then current setup >>> to >>>>> me. >>>> >>>> not really >>> >>> See reason stated above. >>>> >>>>> >>>>> Karel >>>>> >>>>> [1] >>> https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/jaxrs/src/main/java/org/jboss/aerogear/unifiedpush/rest/registry/installations/InstallationRegistrationEndpoint.java#L74 >>>>> >>>>> On Fri, Jul 25, 2014 at 1:04 PM, Matthias Wessendorf >>>>> wrote: >>>>>> >>>>>> >>>>>> >>>>>> On Fri, Jul 25, 2014 at 12:25 PM, Tadeas Kriz >>>>>> wrote: >>>>>>> >>>>>>> ? >>>>>>> Tadeas Kriz >>>>>>> >>>>>>> On 25 Jul 2014, at 11:04 am, Daniel Bevenius >>>>>>> wrote: >>>>>>> >>>>>>>>> 5. don?t use the url as a deviceToken (might not comply >>> with >>>>>>>> Mozzila?s SimplePush specs) >>>>>>>> The deviceToken is an UPS concept and there is nothing in the >>>>>>>> SimplePush spec which is violated in this case. >>>>>>> I thought that deviceTokens were changed from a generated >>> value to >>>>>>> the URL just to comply with Mozzila?s SimplePush specs. >>>>>> >>>>>> Nope >>>>>> >>>>>>> Matzew, why was the generated token removed then? >>>>>> >>>>>> It was the channelID before - but that should not be exposed. >>>>>> In GCM devices are identified via registrationID >>>>>> In APNs devices are identified va deviceToken >>>>>> (both are somewhat the same - but different names) >>>>>> >>>>>> In SimplePush devices are identifeid v/ the URL of the >>> pushEndpoint >>>>>> (a backend uses that endpoint to notify _THAT_ client, >>> regardless >>>>> of >>>>>> how many channels it has subscribed) >>>>>> >>>>>> So, that lead us to make the change (see history of this threa) >>>>>> >>>>>> -M >>>>>> >>>>>> >>>>>> >>>>>>> >>>>>>>> I'm not sure about what the best option is for UPS thought. >>>>> Would a >>>>>>>> regex in for the @Path annotation work perhaps, something >>> like: >>>>>>>> >>>>>>>> @DELETE >>>>>>>> @Path("{token, .+}") >>>>>>>> public Response unregisterInstallations( >>>>>>> >>>>>>> What do you mean by that regex? The problem is simply the >>>>> ?%2F? >>>>>>> in the token (which is an URLencoded simplepush url) and it?s >>>>>>> being revoked long before it hits the RestEasy (which does the >>>>>>> routing according to what?s in the @Path). >>>>>>> >>>>>>>> >>>>>>>>> On 25 July 2014 10:32, Tadeas Kriz wrote: >>>>>>>>> >>>>>>>>> ? >>>>>>>>> Tadeas Kriz >>>>>>>>> >>>>>>>>> On 24 Jul 2014, at 05:44 pm, Karel Piwko >>>>> wrote: >>>>>>>>> >>>>>>>>>> On Thu, Jul 24, 2014 at 3:28 PM, Tadeas Kriz >>>>> >>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> It should not. For hibernate, it?s just a string like >>> any >>>>>>>>> other. >>>>>>>>>>> The problem might be in the configuration of >>>>> JAX.RS/RestEasy. If >>>>>>>>>>> I?ll have some time today evening, I?ll try to fix >>> it, it >>>>>>>>> should >>>>>>>>>>> be an easy fix. >>>>>>>>>> >>>>>>>>>> Last famous words? ;-) >>>>>>>>> >>>>>>>>> I shall never say ?an easy fix? again. >>>>>>>>> >>>>>>>>>> But I agree. Everything is string and URL encode should >>>>> happen on >>>>>>>>>> client while server should automatically decode and work >>>>> always >>>>>>>>> with >>>>>>>>>> just decoded string. If we need to encode twice, something >>> is >>>>>>>>> wrong. >>>>>>>>> >>>>>>>>> Anyway, the 400 Bad request response is made by the tomcat >>>>> itself, >>>>>>>>> disallowing the use of %2F as a path parameter. This will >>>>> probably >>>>>>>>> apply on other web containers. >>>>>>>>> >>>>>>>>> Possible solutions with their disadvantages: >>>>>>>>> >>>>>>>>> 1. well-documented double-encoding of the URL (might be >>>>> confusing) >>>>>>>>> 2. use @QueryParam instead of @PathParam (breaks the api >>>>>>>>> consistence, as every other call would still use @PathParam) >>>>>>>>> 3. allow @QueryParam (again, breaks the api consistence, but >>>>> only >>>>>>>>> for the SimplePush) >>>>>>>>> 4. find another encoding (Base64 for URL = URLEncode then >>> Base64 >>>>>>>>> encode) >>>>>>>>> 5. don?t use the url as a deviceToken (might not comply >>> with >>>>>>>>> Mozzila?s SimplePush specs) >>>>>>>>> >>>>>>>>> What do you think guys? >>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> aerogear-dev mailing list >>>>>>>>>> aerogear-dev at lists.jboss.org >>>>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> aerogear-dev mailing list >>>>>>>>> aerogear-dev at lists.jboss.org >>>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> aerogear-dev mailing list >>>>>>>> aerogear-dev at lists.jboss.org >>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> aerogear-dev mailing list >>>>>>> aerogear-dev at lists.jboss.org >>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Matthias Wessendorf >>>>>> >>>>>> blog: http://matthiaswessendorf.wordpress.com/ >>>>>> sessions: http://www.slideshare.net/mwessendorf >>>>>> twitter: http://twitter.com/mwessendorf >>>>> >>>>> >>>>> _______________________________________________ >>>>> aerogear-dev mailing list >>>>> aerogear-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> >>>> >>>> >>>> -- >>>> Matthias Wessendorf >>>> >>>> blog: http://matthiaswessendorf.wordpress.com/ >>>> sessions: http://www.slideshare.net/mwessendorf >>>> twitter: http://twitter.com/mwessendorf >>> >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> >> -- >> Matthias Wessendorf >> >> blog: http://matthiaswessendorf.wordpress.com/ >> sessions: http://www.slideshare.net/mwessendorf >> twitter: http://twitter.com/mwessendorf > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev From matzew at apache.org Mon Jul 28 11:23:35 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Mon, 28 Jul 2014 17:23:35 +0200 Subject: [aerogear-dev] Differences between Firefox OS "native" Push lib and AeroGear's Push adapter In-Reply-To: <5E92DCB2-42DD-4E6D-8E30-6710C2010DEF@redhat.com> References: <9B70BDB9-4774-4BF0-9FF7-5213185E4F52@redhat.com> <51C9D854-0730-4B2A-9A92-9DC92649947D@redhat.com> <8AEB32A5-0F61-495B-8EA5-767F48312B9C@redhat.com> <1406216640.15307.0@smtp.corp.redhat.com> <1E3E76E8-60D7-4BF3-9B95-6C58F4DC9286@redhat.com> <919B56C2-8E6D-4CD8-A620-F9839E013685@redhat.com> <1406292545.14163.0@smtp.corp.redhat.com> <1406293568.14163.1@smtp.corp.redhat.com> <1406532921.14163.2@smtp.corp.redhat.com> <5E92DCB2-42DD-4E6D-8E30-6710C2010DEF@redhat.com> Message-ID: OK, fair point. Once I am done w/ documentation, I will get back to this - unless some else beats me to it :) On Mon, Jul 28, 2014 at 4:56 PM, Luke Holmquist wrote: > I would rather not have to generate some id and then store that locally. > > Simple push is not the only thing the uses the UPS client. > > Sent from my iPhone > > > On Jul 28, 2014, at 3:36 AM, Karel Piwko wrote: > > > > Yes, that was it. And you're right, it indeed makes better sense to > > generate UUID by client, not by server. > > > > Karel > > > > > > > > On Fri, Jul 25, 2014 at 3:19 PM, Matthias Wessendorf > > wrote: > >> > >> > >> > >> On Fri, Jul 25, 2014 at 3:06 PM, Karel Piwko > >> wrote: > >>> On Fri, Jul 25, 2014 at 2:56 PM, Matthias Wessendorf > >>> wrote: > >>>> > >>>>> UPS can translate {deviceToken} to EndpointURL. We just need a way > >>>>> how > >>>>> to generate unique {deviceToken} on client. > >>>> > >>>> that would be our own layer on-top, which is a no-go > >>> > >>> why? it would be there anyway. Imagine that your UPS is running on > >>> exposed URL which is a gateway to your internal network. SP URL is > >>> valid only in that internal network, not visible from outside world > >>> at > >>> all. > >>> > >>> So, using UPS is the only way to send the message to that URL. > >> > >> Hrm... let's see if I am following you. Let's try: > >> > >> If the UPS has a mapping between "magic_UUID" and endpointURL, that > >> means the client layer (e.g. UPS.js) has to store this UUID > >> somewhere, for unregistration. > >> > >> Instead of having the UPS generating the UUID, it could be generated > >> by the UPS.js, and its JS callback would/could return it (so that the > >> JS app has it handy for later unregister). > >> > >> That would mean the JS client would sending down the same JSON as > >> before, right ? > >> > >> deviceToken: client_side_generated_UUID, > >> pushEndpoint: someURL > >> > >> > >> Did I get it ? > >> > >> > >> > >>> > >>>> > >>>> > >>>>> Would UUID work? > >>>>> EndpointURL can become part of JSON [1]. > >>>> > >>>> it was there as "simplePushEndpoint", but for stated reasons it's > >>> now > >>>> the deviceToken that has the URL value > >>>> > >>>> > >>>>> > >>>>> Such change would mean that clients can't use SP server directly > >>> but > >>>>> have to go through UPS. This makes more sense then current setup > >>> to > >>>>> me. > >>>> > >>>> not really > >>> > >>> See reason stated above. > >>>> > >>>>> > >>>>> Karel > >>>>> > >>>>> [1] > >>> > https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/jaxrs/src/main/java/org/jboss/aerogear/unifiedpush/rest/registry/installations/InstallationRegistrationEndpoint.java#L74 > >>>>> > >>>>> On Fri, Jul 25, 2014 at 1:04 PM, Matthias Wessendorf > >>>>> wrote: > >>>>>> > >>>>>> > >>>>>> > >>>>>> On Fri, Jul 25, 2014 at 12:25 PM, Tadeas Kriz > >>>>>> wrote: > >>>>>>> > >>>>>>> ? > >>>>>>> Tadeas Kriz > >>>>>>> > >>>>>>> On 25 Jul 2014, at 11:04 am, Daniel Bevenius > >>>>>>> wrote: > >>>>>>> > >>>>>>>>> 5. don?t use the url as a deviceToken (might not comply > >>> with > >>>>>>>> Mozzila?s SimplePush specs) > >>>>>>>> The deviceToken is an UPS concept and there is nothing in the > >>>>>>>> SimplePush spec which is violated in this case. > >>>>>>> I thought that deviceTokens were changed from a generated > >>> value to > >>>>>>> the URL just to comply with Mozzila?s SimplePush specs. > >>>>>> > >>>>>> Nope > >>>>>> > >>>>>>> Matzew, why was the generated token removed then? > >>>>>> > >>>>>> It was the channelID before - but that should not be exposed. > >>>>>> In GCM devices are identified via registrationID > >>>>>> In APNs devices are identified va deviceToken > >>>>>> (both are somewhat the same - but different names) > >>>>>> > >>>>>> In SimplePush devices are identifeid v/ the URL of the > >>> pushEndpoint > >>>>>> (a backend uses that endpoint to notify _THAT_ client, > >>> regardless > >>>>> of > >>>>>> how many channels it has subscribed) > >>>>>> > >>>>>> So, that lead us to make the change (see history of this threa) > >>>>>> > >>>>>> -M > >>>>>> > >>>>>> > >>>>>> > >>>>>>> > >>>>>>>> I'm not sure about what the best option is for UPS thought. > >>>>> Would a > >>>>>>>> regex in for the @Path annotation work perhaps, something > >>> like: > >>>>>>>> > >>>>>>>> @DELETE > >>>>>>>> @Path("{token, .+}") > >>>>>>>> public Response unregisterInstallations( > >>>>>>> > >>>>>>> What do you mean by that regex? The problem is simply the > >>>>> ?%2F? > >>>>>>> in the token (which is an URLencoded simplepush url) and it?s > >>>>>>> being revoked long before it hits the RestEasy (which does the > >>>>>>> routing according to what?s in the @Path). > >>>>>>> > >>>>>>>> > >>>>>>>>> On 25 July 2014 10:32, Tadeas Kriz wrote: > >>>>>>>>> > >>>>>>>>> ? > >>>>>>>>> Tadeas Kriz > >>>>>>>>> > >>>>>>>>> On 24 Jul 2014, at 05:44 pm, Karel Piwko > >>>>> wrote: > >>>>>>>>> > >>>>>>>>>> On Thu, Jul 24, 2014 at 3:28 PM, Tadeas Kriz > >>>>> > >>>>>>>>> wrote: > >>>>>>>>>>> > >>>>>>>>>>> It should not. For hibernate, it?s just a string like > >>> any > >>>>>>>>> other. > >>>>>>>>>>> The problem might be in the configuration of > >>>>> JAX.RS/RestEasy. If > >>>>>>>>>>> I?ll have some time today evening, I?ll try to fix > >>> it, it > >>>>>>>>> should > >>>>>>>>>>> be an easy fix. > >>>>>>>>>> > >>>>>>>>>> Last famous words? ;-) > >>>>>>>>> > >>>>>>>>> I shall never say ?an easy fix? again. > >>>>>>>>> > >>>>>>>>>> But I agree. Everything is string and URL encode should > >>>>> happen on > >>>>>>>>>> client while server should automatically decode and work > >>>>> always > >>>>>>>>> with > >>>>>>>>>> just decoded string. If we need to encode twice, something > >>> is > >>>>>>>>> wrong. > >>>>>>>>> > >>>>>>>>> Anyway, the 400 Bad request response is made by the tomcat > >>>>> itself, > >>>>>>>>> disallowing the use of %2F as a path parameter. This will > >>>>> probably > >>>>>>>>> apply on other web containers. > >>>>>>>>> > >>>>>>>>> Possible solutions with their disadvantages: > >>>>>>>>> > >>>>>>>>> 1. well-documented double-encoding of the URL (might be > >>>>> confusing) > >>>>>>>>> 2. use @QueryParam instead of @PathParam (breaks the api > >>>>>>>>> consistence, as every other call would still use @PathParam) > >>>>>>>>> 3. allow @QueryParam (again, breaks the api consistence, but > >>>>> only > >>>>>>>>> for the SimplePush) > >>>>>>>>> 4. find another encoding (Base64 for URL = URLEncode then > >>> Base64 > >>>>>>>>> encode) > >>>>>>>>> 5. don?t use the url as a deviceToken (might not comply > >>> with > >>>>>>>>> Mozzila?s SimplePush specs) > >>>>>>>>> > >>>>>>>>> What do you think guys? > >>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> _______________________________________________ > >>>>>>>>>> aerogear-dev mailing list > >>>>>>>>>> aerogear-dev at lists.jboss.org > >>>>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> _______________________________________________ > >>>>>>>>> aerogear-dev mailing list > >>>>>>>>> aerogear-dev at lists.jboss.org > >>>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev > >>>>>>>> > >>>>>>>> _______________________________________________ > >>>>>>>> aerogear-dev mailing list > >>>>>>>> aerogear-dev at lists.jboss.org > >>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev > >>>>>>> > >>>>>>> > >>>>>>> _______________________________________________ > >>>>>>> aerogear-dev mailing list > >>>>>>> aerogear-dev at lists.jboss.org > >>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev > >>>>>> > >>>>>> > >>>>>> > >>>>>> -- > >>>>>> Matthias Wessendorf > >>>>>> > >>>>>> blog: http://matthiaswessendorf.wordpress.com/ > >>>>>> sessions: http://www.slideshare.net/mwessendorf > >>>>>> twitter: http://twitter.com/mwessendorf > >>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> aerogear-dev mailing list > >>>>> aerogear-dev at lists.jboss.org > >>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev > >>>> > >>>> > >>>> > >>>> -- > >>>> Matthias Wessendorf > >>>> > >>>> blog: http://matthiaswessendorf.wordpress.com/ > >>>> sessions: http://www.slideshare.net/mwessendorf > >>>> twitter: http://twitter.com/mwessendorf > >>> > >>> > >>> _______________________________________________ > >>> aerogear-dev mailing list > >>> aerogear-dev at lists.jboss.org > >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev > >> > >> > >> > >> -- > >> Matthias Wessendorf > >> > >> blog: http://matthiaswessendorf.wordpress.com/ > >> sessions: http://www.slideshare.net/mwessendorf > >> twitter: http://twitter.com/mwessendorf > > > > > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140728/6265612f/attachment-0001.html From rlgarris at outlook.com Mon Jul 28 12:58:07 2014 From: rlgarris at outlook.com (rlgarris) Date: Mon, 28 Jul 2014 09:58:07 -0700 (PDT) Subject: [aerogear-dev] [UnifiedPush] From JBoss AS 7.1.1 to WildFly 8.x In-Reply-To: References: <20140728132806.GA43110@abstractj.org> Message-ID: <1406566687850-8619.post@n5.nabble.com> +1 for Wildfly 8.0 support for UnifiedPush. We have services dependent on Java EE 7 and it would be great if UnifiedPush could support the latest and greatest from JBoss. Cheers RG -- View this message in context: http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-UnifiedPush-From-JBoss-AS-7-1-1-to-WildFly-8-x-tp8607p8619.html Sent from the aerogear-dev mailing list archive at Nabble.com. From matzew at apache.org Tue Jul 29 08:50:17 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Tue, 29 Jul 2014 14:50:17 +0200 Subject: [aerogear-dev] Beta1 of the UnifiedPush Server 1.0.0 released Message-ID: Today we are announcing the first beta release of our 1.0.0 version. After the big overhaul, including a brand new AdminUI with the last release this release contains several enhancements: - iOS8 interactive notification support - increased APNs payload (2k) - Pagination for analytics - improved callback for details on actual push delivery - optimisations and improvements The complete list of included items are avialble on our JIRA instance . iOS8 interactive notifications Besides the work on the server, we have updated our Java and Node.js sender libraries to support the new iOS8 interactive notification message format. If you curious about iOS8 notifications, Corinne Krych has a detailed blog post on it and how to use it with the AeroGear UnifiedPush Server. Swift support for iOS On the iOS client side Corinne Krych and Christos Vasilakis were also busy starting some Swift work: our iOS registration SDK supports swift on this branch . To give you an idea how it looks, here is some code: func application(application: UIApplication!, didRegisterForRemoteNotificationsWithDeviceToken deviceToken: NSData!) { // setup registration let registration = AGDeviceRegistration(serverURL: NSURL(string: "<# URL of the running AeroGear UnifiedPush Server #>")) // attemp to register registration.registerWithClientInfo({ (clientInfo: AGClientDeviceInformation!) in // setup configuration clientInfo.deviceToken = deviceToken clientInfo.variantID = "<# Variant Id #>" clientInfo.variantSecret = "<# Variant Secret #>" // apply the token, to identify THIS device let currentDevice = UIDevice() // --optional config-- // set some 'useful' hardware information params clientInfo.operatingSystem = currentDevice.systemName clientInfo.osVersion = currentDevice.systemVersion clientInfo.deviceType = currentDevice.model }, success: { println("UnifiedPush Server registration succeeded") }, failure: {(error: NSError!) in println("failed to register, error: \(error.description)") })} Demos To get easily started using the UnifiedPush Server we have a bunch of demos, supporting various client platforms: - Android - Apache Cordova (with jQuery and Angular/Ionic) - iOS The simple HelloWorld examples are located here . Some more advanced examples, including a Picketlink secured JAX-RS application, as well as a Fabric8 based Proxy, are available here . For those of you who that are into Swift, there Swift branches for these demos as well: - https://github.com/aerogear/aerogear-push-helloworld/tree/swift/ios-swift - https://github.com/cvasilak/aerogear-push-quickstarts/tree/swift Feedback We hope you enjoy the bits and we do appreciate your feedback! Swing by on our mailing list ! We are looking forward to hear from you! NOTE: the Openshift online offering will be updated w/in the next day or two -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140729/06f855ed/attachment.html From lholmqui at redhat.com Tue Jul 29 10:10:52 2014 From: lholmqui at redhat.com (Lucas Holmquist) Date: Tue, 29 Jul 2014 10:10:52 -0400 Subject: [aerogear-dev] SimplePush sync with MOz Message-ID: so this sort of relates to this thread here: http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-Differences-between-Firefox-OS-quot-native-quot-Push-lib-and-AeroGear-s-Push-adapter-td6195.html from https://developer.mozilla.org/en-US/docs/Web/API/Simple_Push_API#Add_the_push_message_handler Moz example window.navigator.mozSetMessageHandler('push', function(e) { console.log('My endpoint is ' + e.pushEndpoint); console.log('My new version is ' + e.version); //Remember that you can handle here if you have more than //one pushEndpoint if (e.pushEndpoint === emailEndpoint) { emailHandler(e.version); } else if (e.pushEndpoint === imEndpoint) { imHandler(e.version); } }); The notification that they send back includes the pushEndpoint and the version Currently, when we do navigator.push.register() the result we send back is an object that includes the pushEndpoint, this is actually changing to be more in line with Mozilla. Instead of the object being sent back, we will send back the pushEndpoint as a String. <--- is a super easy change that sebi already did, just need to re-merge it back in but in our message handler, our notification that is sent back includes the channelId and version I believe the server should now be sending the pushEndpoint in the notification instead. I'd do it myself, but you know, it's java -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140729/4e8bde56/attachment-0001.html From daniel.bevenius at gmail.com Tue Jul 29 10:29:46 2014 From: daniel.bevenius at gmail.com (Daniel Bevenius) Date: Tue, 29 Jul 2014 16:29:46 +0200 Subject: [aerogear-dev] SimplePush sync with MOz In-Reply-To: References: Message-ID: > but in our message handler, our notification that is sent back includes the channelId and version The 'Notification' section SimplePush Protocol [1] it specifies what should be returned. I'm not sure if Mozilla's server does something different of if it is the client side that does something different. I'm not against changing things, but I think it makes sense for us to follow their protocol. I'll read up on the protocol and see if there is any new information that I'm not aware of. I'll take a look at their server too. [1] https://wiki.mozilla.org/WebAPI/SimplePush/Protocol#PushServer_-.3E_UserAgent_5 On 29 July 2014 16:10, Lucas Holmquist wrote: > so this sort of relates to this thread here: > http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-Differences-between-Firefox-OS-quot-native-quot-Push-lib-and-AeroGear-s-Push-adapter-td6195.html > > from > https://developer.mozilla.org/en-US/docs/Web/API/Simple_Push_API#Add_the_push_message_handler > Moz example > > window.navigator.mozSetMessageHandler('push', function(e) { > console.log('My endpoint is ' + e.pushEndpoint); > console.log('My new version is ' + e.version); > //Remember that you can handle here if you have more than > //one pushEndpoint > if (e.pushEndpoint === emailEndpoint) { > emailHandler(e.version); > } else if (e.pushEndpoint === imEndpoint) { > imHandler(e.version); > } > }); > > The notification that they send back includes the pushEndpoint and the > version > > Currently, when we do navigator.push.register() the result we send back > is an object that includes the pushEndpoint, this is actually changing to > be more in line with Mozilla. Instead of the object being sent back, we > will send back the pushEndpoint as a String. <--- is a super easy change > that sebi already did, just need to re-merge it back in > > but in our message handler, our notification that is sent back includes > the channelId and version > > I believe the server should now be sending the pushEndpoint in the > notification instead. > > I'd do it myself, but you know, it's java > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140729/44dac52b/attachment.html From lholmqui at redhat.com Tue Jul 29 10:37:36 2014 From: lholmqui at redhat.com (Lucas Holmquist) Date: Tue, 29 Jul 2014 10:37:36 -0400 Subject: [aerogear-dev] SimplePush sync with MOz In-Reply-To: References: Message-ID: On Jul 29, 2014, at 10:29 AM, Daniel Bevenius wrote: > > but in our message handler, our notification that is sent back includes the channelId and version > The 'Notification' section SimplePush Protocol [1] it specifies what should be returned. I'm not sure if Mozilla's server does something different of if it is the client side that does something different. most likely it's the client side code that should be saving the pushEndpoint along with the channelID and then looking up by the channel ID, and then giving it to the user this is probably what happens in the native browser code that we are trying to polyfill > I'm not against changing things, but I think it makes sense for us to follow their protocol. I'll read up on the protocol and see if there is any new information that I'm not aware of. I'll take a look at their server too. > > [1] https://wiki.mozilla.org/WebAPI/SimplePush/Protocol#PushServer_-.3E_UserAgent_5 > > > > > On 29 July 2014 16:10, Lucas Holmquist wrote: > so this sort of relates to this thread here: > > http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-Differences-between-Firefox-OS-quot-native-quot-Push-lib-and-AeroGear-s-Push-adapter-td6195.html > > > > > from https://developer.mozilla.org/en-US/docs/Web/API/Simple_Push_API#Add_the_push_message_handler > Moz example > > window.navigator.mozSetMessageHandler('push', function(e) { > console.log('My endpoint is ' + e.pushEndpoint); > console.log('My new version is ' + e.version); > //Remember that you can handle here if you have more than > //one pushEndpoint > if (e.pushEndpoint === emailEndpoint) { > emailHandler(e.version); > } else if (e.pushEndpoint === imEndpoint) { > imHandler(e.version); > } > }); > The notification that they send back includes the pushEndpoint and the version > > Currently, when we do navigator.push.register() the result we send back is an object that includes the pushEndpoint, this is actually changing to be more in line with Mozilla. Instead of the object being sent back, we will send back the pushEndpoint as a String. <--- is a super easy change that sebi already did, just need to re-merge it back in > > but in our message handler, our notification that is sent back includes the channelId and version > > I believe the server should now be sending the pushEndpoint in the notification instead. > > I'd do it myself, but you know, it's java > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140729/21696e42/attachment.html From daniel.bevenius at gmail.com Tue Jul 29 10:46:21 2014 From: daniel.bevenius at gmail.com (Daniel Bevenius) Date: Tue, 29 Jul 2014 16:46:21 +0200 Subject: [aerogear-dev] SimplePush sync with MOz In-Reply-To: References: Message-ID: Yeah, it looks like this is what's happening (at least looking at the server side of it that is) On 29 July 2014 16:37, Lucas Holmquist wrote: > > On Jul 29, 2014, at 10:29 AM, Daniel Bevenius > wrote: > > > but in our message handler, our notification that is sent back includes > the channelId and version > The 'Notification' section SimplePush Protocol [1] it specifies what > should be returned. I'm not sure if Mozilla's server does something > different of if it is the client side that does something different. > > > most likely it's the client side code that should be saving the > pushEndpoint along with the channelID and then looking up by the channel > ID, and then giving it to the user > > this is probably what happens in the native browser code that we are > trying to polyfill > > I'm not against changing things, but I think it makes sense for us to > follow their protocol. I'll read up on the protocol and see if there is any > new information that I'm not aware of. I'll take a look at their server > too. > > [1] > https://wiki.mozilla.org/WebAPI/SimplePush/Protocol#PushServer_-.3E_UserAgent_5 > > > > > On 29 July 2014 16:10, Lucas Holmquist wrote: > >> so this sort of relates to this thread here: >> http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-Differences-between-Firefox-OS-quot-native-quot-Push-lib-and-AeroGear-s-Push-adapter-td6195.html >> >> from >> https://developer.mozilla.org/en-US/docs/Web/API/Simple_Push_API#Add_the_push_message_handler >> Moz example >> >> window.navigator.mozSetMessageHandler('push', function(e) { >> console.log('My endpoint is ' + e.pushEndpoint); >> console.log('My new version is ' + e.version); >> //Remember that you can handle here if you have more than >> //one pushEndpoint >> if (e.pushEndpoint === emailEndpoint) { >> emailHandler(e.version); >> } else if (e.pushEndpoint === imEndpoint) { >> imHandler(e.version); >> } >> }); >> >> The notification that they send back includes the pushEndpoint and the >> version >> >> Currently, when we do navigator.push.register() the result we send back >> is an object that includes the pushEndpoint, this is actually changing to >> be more in line with Mozilla. Instead of the object being sent back, we >> will send back the pushEndpoint as a String. <--- is a super easy change >> that sebi already did, just need to re-merge it back in >> >> but in our message handler, our notification that is sent back includes >> the channelId and version >> >> I believe the server should now be sending the pushEndpoint in the >> notification instead. >> >> I'd do it myself, but you know, it's java >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140729/2481bc99/attachment-0001.html From lholmqui at redhat.com Tue Jul 29 11:59:46 2014 From: lholmqui at redhat.com (Lucas Holmquist) Date: Tue, 29 Jul 2014 11:59:46 -0400 Subject: [aerogear-dev] SimplePush sync with MOz In-Reply-To: References: Message-ID: <4C74DDCA-4125-479B-AFC6-24D860B6461F@redhat.com> created a JIRA for it https://issues.jboss.org/browse/AGJS-203 PR coming soon for the client code On Jul 29, 2014, at 10:46 AM, Daniel Bevenius wrote: > Yeah, it looks like this is what's happening (at least looking at the server side of it that is) > > > On 29 July 2014 16:37, Lucas Holmquist wrote: > > On Jul 29, 2014, at 10:29 AM, Daniel Bevenius wrote: > >> > but in our message handler, our notification that is sent back includes the channelId and version >> The 'Notification' section SimplePush Protocol [1] it specifies what should be returned. I'm not sure if Mozilla's server does something different of if it is the client side that does something different. > > most likely it's the client side code that should be saving the pushEndpoint along with the channelID and then looking up by the channel ID, and then giving it to the user > > this is probably what happens in the native browser code that we are trying to polyfill >> I'm not against changing things, but I think it makes sense for us to follow their protocol. I'll read up on the protocol and see if there is any new information that I'm not aware of. I'll take a look at their server too. >> >> [1] https://wiki.mozilla.org/WebAPI/SimplePush/Protocol#PushServer_-.3E_UserAgent_5 >> >> >> >> >> On 29 July 2014 16:10, Lucas Holmquist wrote: >> so this sort of relates to this thread here: >> >> http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-Differences-between-Firefox-OS-quot-native-quot-Push-lib-and-AeroGear-s-Push-adapter-td6195.html >> >> >> >> >> from https://developer.mozilla.org/en-US/docs/Web/API/Simple_Push_API#Add_the_push_message_handler >> Moz example >> >> window.navigator.mozSetMessageHandler('push', function(e) { >> console.log('My endpoint is ' + e.pushEndpoint); >> console.log('My new version is ' + e.version); >> //Remember that you can handle here if you have more than >> //one pushEndpoint >> if (e.pushEndpoint === emailEndpoint) { >> emailHandler(e.version); >> } else if (e.pushEndpoint === imEndpoint) { >> imHandler(e.version); >> } >> }); >> The notification that they send back includes the pushEndpoint and the version >> >> Currently, when we do navigator.push.register() the result we send back is an object that includes the pushEndpoint, this is actually changing to be more in line with Mozilla. Instead of the object being sent back, we will send back the pushEndpoint as a String. <--- is a super easy change that sebi already did, just need to re-merge it back in >> >> but in our message handler, our notification that is sent back includes the channelId and version >> >> I believe the server should now be sending the pushEndpoint in the notification instead. >> >> I'd do it myself, but you know, it's java >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140729/d4c13298/attachment.html From matzew at apache.org Tue Jul 29 12:48:40 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Tue, 29 Jul 2014 18:48:40 +0200 Subject: [aerogear-dev] Docs: update on the UPS docs In-Reply-To: References: Message-ID: Here is a first PR for it: https://github.com/aerogear/aerogear.org/pull/333 as noted, still WIP - but it is getting there On Thu, Jul 24, 2014 at 3:25 PM, Matthias Wessendorf wrote: > Thanks Dan! > > > FYI - the draft of the TOC (and soon content) lives in this branch: > > > https://github.com/aerogear/aerogear.org/blob/NewUPS_Guide/docs/unifiedpush/ups_userguide/index.markdown > > -M > > > On Thu, Jul 24, 2014 at 2:14 PM, Daniel Bevenius < > daniel.bevenius at gmail.com> wrote: > >> Looks good! >> perhaps change: Configuring and Managing Applications that use the >> UnifiedPush Server -> Configuring and managing applications that use the >> UnifiedPush Server >> >> >> >> On 24 July 2014 13:32, Matthias Wessendorf wrote: >> >>> update: >>> >>> >>> UnifiedPush Server User Guide >>> >>> - Overview >>> - About the UnifiedPush Server >>> - Use-cases and scenarios >>> - Useful Terminology >>> - How the UnifiedPush Server Works >>> - Installation and configuration >>> - The WAR file distribution >>> - setup and configure a database >>> - deploy the WAR files >>> - Running on OpenShift >>> - create an instance using OpenShift's Web UI >>> - create an instance using OpenShift's command line interface >>> - Using the Admin UI >>> - Administering the UnifiedPush Server Console >>> - Configuring and Managing Applications that use the UnifiedPush >>> Server >>> - Preparing mobile devices to be connected with the UnifiedPush >>> Server >>> - Sending Push Notifications >>> - Preparing backends to send Push Notifications >>> - Next steps >>> - TBD: Links to tutorials and specs (some specs might go away) >>> >>> >>> >>> >>> >>> >>> >>> On Thu, Jul 24, 2014 at 1:29 PM, Matthias Wessendorf >>> wrote: >>> >>>> Here is the TOC that I have in mind (and started to work on): >>>> >>>> UnifiedPush Server User Guide >>>> >>>> - Overview >>>> - About the UnifiedPush Server >>>> - Use-cases and scenarios >>>> - Useful Terminology >>>> - How the UnifiedPush Server Works >>>> - Installation and configuration >>>> - The WAR file distribution >>>> - setup and configure a database >>>> - deploy the WAR files >>>> - Running on OpenShift >>>> - create an instance using OpenShift's Web UI >>>> - create an instance using OpenShift's command line interface >>>> - Using the Admin UI >>>> - Administering the UnifiedPush Server Console >>>> - Configuring and Managing Applications that use the UnifiedPush >>>> Server >>>> - Preparing mobile devices to be connected with the UnifiedPush >>>> Server >>>> - Sending Push Notifications >>>> - Next steps >>>> - TBD: Links to tutorials and specs (some specs might go away) >>>> >>>> >>>> >>>> >>>> >>>> On Thu, Jul 24, 2014 at 11:26 AM, Matthias Wessendorf < >>>> matzew at apache.org> wrote: >>>> >>>>> Before actually starting with the (initial) rewrite of the UPS guide >>>>> (as I outlined), I did the re-org of the UPS content. >>>>> >>>>> Please review: >>>>> https://github.com/aerogear/aerogear.org/pull/327 >>>>> >>>>> >>>>> >>>>> >>>>> On Mon, Jul 21, 2014 at 5:59 PM, Matthias Wessendorf < >>>>> matzew at apache.org> wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> right now we have a lot of different 'documentation files', like the >>>>>> README, some specs, and guides and tutorials. >>>>>> >>>>>> I'd like to restructure that a bit and centralize the documentation a >>>>>> bit. >>>>>> >>>>>> On the "push" landing page ([1]), I'd like to change the "Lean More" >>>>>> link to a new page that has all the UPS centric documentations >>>>>> >>>>>> - AeroGear UnifiedPush Server User/Reference Guide >>>>>> - Tutorials >>>>>> >>>>>> >>>>>> AeroGear >>>>>> UnifiedPush Server User/Reference Guide >>>>>> >>>>>> - Overview >>>>>> - some generic information >>>>>> - Installation and configuration >>>>>> - what's needed (e.g. JBoss and a database) >>>>>> - Running on OpenShift >>>>>> - using the UI on OpenShift >>>>>> - using the rhc command line >>>>>> - Using the Admin UI >>>>>> - doing an overhaul of our existing Admin UI guide (e.g. >>>>>> taking new screenshots and updating based on new UI features) >>>>>> >>>>>> The format of the *reference guide* would be similar to the one from >>>>>> Keycloak ([2]). But... I will continue using asciidoc ;-) >>>>>> >>>>>> The README will be extremely quick and simply link to the homepage >>>>>> ;-) After this *new* reference guide, I think some of the current >>>>>> specs can be removed, as the *reference guide* hopefully covers all >>>>>> of their content :-) >>>>>> >>>>>> For the RESTful APIs, I have to look what Keycloak did to get >>>>>> something like: >>>>>> http://docs.jboss.org/keycloak/docs/1.0-beta-3/rest-api/overview-index.html >>>>>> >>>>>> After the work as been completed, I will be revisiting the specs and >>>>>> evaluate their need ;-) >>>>>> >>>>>> Tutorials >>>>>> >>>>>> This section will contain links to all the different tutorials we >>>>>> have: >>>>>> >>>>>> - http://aerogear.org/docs/guides/aerogear-push-ios/ >>>>>> - http://aerogear.org/docs/guides/aerogear-push-js/ >>>>>> - http://aerogear.org/docs/guides/aerogear-push-android/ >>>>>> - http://aerogear.org/docs/guides/aerogear-push-chrome/ >>>>>> - http://aerogear.org/docs/guides/GetStartedwithJavaSender/ >>>>>> >>>>>> For Cordova we will have one single document, instead of three: >>>>>> >>>>>> - http://aerogear.org/docs/guides/aerogear-push-cordova-android/ >>>>>> - http://aerogear.org/docs/guides/aerogear-push-cordova-ios/ >>>>>> - >>>>>> http://aerogear.org/docs/guides/aerogear-cordova/AerogearCordovaPush/ >>>>>> >>>>>> There is already a JIRA for that ([4]). >>>>>> >>>>>> To make it more clear (or clean?), I will remove the UPS/Push related >>>>>> docs from our guides ([3]) and replace all those links by a single link to >>>>>> the above mentioned new page (also referenced from [1]). >>>>>> >>>>>> Greetings, >>>>>> Matthias >>>>>> >>>>>> >>>>>> >>>>>> - [1] http://aerogear.org/push/ >>>>>> - [2] >>>>>> http://docs.jboss.org/keycloak/docs/1.0-beta-3/userguide/html/index.html >>>>>> - [3] http://aerogear.org/docs/guides/ >>>>>> - [4] https://issues.jboss.org/browse/AGPUSH-805 >>>>>> >>>>>> >>>>>> -- >>>>>> Matthias Wessendorf >>>>>> >>>>>> blog: http://matthiaswessendorf.wordpress.com/ >>>>>> sessions: http://www.slideshare.net/mwessendorf >>>>>> twitter: http://twitter.com/mwessendorf >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Matthias Wessendorf >>>>> >>>>> blog: http://matthiaswessendorf.wordpress.com/ >>>>> sessions: http://www.slideshare.net/mwessendorf >>>>> twitter: http://twitter.com/mwessendorf >>>>> >>>> >>>> >>>> >>>> -- >>>> Matthias Wessendorf >>>> >>>> blog: http://matthiaswessendorf.wordpress.com/ >>>> sessions: http://www.slideshare.net/mwessendorf >>>> twitter: http://twitter.com/mwessendorf >>>> >>> >>> >>> >>> -- >>> Matthias Wessendorf >>> >>> blog: http://matthiaswessendorf.wordpress.com/ >>> sessions: http://www.slideshare.net/mwessendorf >>> twitter: http://twitter.com/mwessendorf >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140729/344896e2/attachment-0001.html From matzew at apache.org Tue Jul 29 15:32:35 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Tue, 29 Jul 2014 21:32:35 +0200 Subject: [aerogear-dev] [UnifiedPush Server] Openshift update (of Beta1) Message-ID: Good evening folks! Now that we got the 1.0.0.Beta1 release out, I used its tag and ran the 'openshift' profile. The generated WARs (and a new version label) are made available in this PR: https://github.com/aerogear/openshift-origin-cartridge-aerogear-push/pull/19 If you want to test it, you simple need to run the following command on your shell (assuming 'rhc' is installed) rhc app create --no-git LATESTUPS https://cartreflect-claytondev.rhcloud.com/reflect\?github\=matzew/openshift-origin-cartridge-aerogear-push Feedback welcome! Thanks -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140729/3c55711b/attachment.html From matzew at apache.org Tue Jul 29 17:55:22 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Tue, 29 Jul 2014 23:55:22 +0200 Subject: [aerogear-dev] New release of Cordova Push Plugin ? Message-ID: Hi, looked at the change log of the Cordova Plugin and there were some fixes since the last 0.6.0 release. Before we run the Beta2 of UPS (around 6th of August, depends a bit on Keycloak's beta4) I'd like to get a 0.7.0 release out. Any thoughts? Thanks, Matthias -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140729/22da1e41/attachment.html From matzew at apache.org Wed Jul 30 02:57:11 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Wed, 30 Jul 2014 08:57:11 +0200 Subject: [aerogear-dev] AG parent release Message-ID: Hi, I have staged version 0.2.4 to: https://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-3641/ mostly updates and important Hibernate upgrade to 4.2.15.Final Please test -M -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140730/3bcf2796/attachment.html From matzew at apache.org Wed Jul 30 04:16:48 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Wed, 30 Jul 2014 10:16:48 +0200 Subject: [aerogear-dev] SimplePush sync with MOz In-Reply-To: References: Message-ID: On Tue, Jul 29, 2014 at 4:10 PM, Lucas Holmquist wrote: > so this sort of relates to this thread here: > http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-Differences-between-Firefox-OS-quot-native-quot-Push-lib-and-AeroGear-s-Push-adapter-td6195.html > > from > https://developer.mozilla.org/en-US/docs/Web/API/Simple_Push_API#Add_the_push_message_handler > Moz example > > window.navigator.mozSetMessageHandler('push', function(e) { > console.log('My endpoint is ' + e.pushEndpoint); > console.log('My new version is ' + e.version); > //Remember that you can handle here if you have more than > //one pushEndpoint > if (e.pushEndpoint === emailEndpoint) { > emailHandler(e.version); > } else if (e.pushEndpoint === imEndpoint) { > imHandler(e.version); > } > }); > > The notification that they send back includes the pushEndpoint and the > version > Using the little hack, I am not seeing the pushEndpoint being returned by their server: https://gist.github.com/matzew/cbda360d72eaaef75971 > Currently, when we do navigator.push.register() the result we send back > is an object that includes the pushEndpoint, this is actually changing to > be more in line with Mozilla. Instead of the object being sent back, we > will send back the pushEndpoint as a String. <--- is a super easy change > that sebi already did, just need to re-merge it back in > > but in our message handler, our notification that is sent back includes > the channelId and version > here is, the JSON I receive w/ the above hack: {"messageType":"notification","updates":[{"channelID":"d9b74644-4f97-46aa-b8fa-9393985cd6cd","version":3}]} > I believe the server should now be sending the pushEndpoint in the > notification instead. > > I'd do it myself, but you know, it's java > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140730/ec630ea3/attachment.html From matzew at apache.org Wed Jul 30 04:17:38 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Wed, 30 Jul 2014 10:17:38 +0200 Subject: [aerogear-dev] SimplePush sync with MOz In-Reply-To: References: Message-ID: On Tue, Jul 29, 2014 at 4:29 PM, Daniel Bevenius wrote: > > but in our message handler, our notification that is sent back includes > the channelId and version > The 'Notification' section SimplePush Protocol [1] it specifies what > should be returned. I'm not sure if Mozilla's server does something > different of if it is the client side that does something different. > their live server returns exactly what has been spec'd in [1] -Matthias > I'm not against changing things, but I think it makes sense for us to > follow their protocol. I'll read up on the protocol and see if there is any > new information that I'm not aware of. I'll take a look at their server > too. > > [1] > https://wiki.mozilla.org/WebAPI/SimplePush/Protocol#PushServer_-.3E_UserAgent_5 > > > > > On 29 July 2014 16:10, Lucas Holmquist wrote: > >> so this sort of relates to this thread here: >> http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-Differences-between-Firefox-OS-quot-native-quot-Push-lib-and-AeroGear-s-Push-adapter-td6195.html >> >> from >> https://developer.mozilla.org/en-US/docs/Web/API/Simple_Push_API#Add_the_push_message_handler >> Moz example >> >> window.navigator.mozSetMessageHandler('push', function(e) { >> console.log('My endpoint is ' + e.pushEndpoint); >> console.log('My new version is ' + e.version); >> //Remember that you can handle here if you have more than >> //one pushEndpoint >> if (e.pushEndpoint === emailEndpoint) { >> emailHandler(e.version); >> } else if (e.pushEndpoint === imEndpoint) { >> imHandler(e.version); >> } >> }); >> >> The notification that they send back includes the pushEndpoint and the >> version >> >> Currently, when we do navigator.push.register() the result we send back >> is an object that includes the pushEndpoint, this is actually changing to >> be more in line with Mozilla. Instead of the object being sent back, we >> will send back the pushEndpoint as a String. <--- is a super easy change >> that sebi already did, just need to re-merge it back in >> >> but in our message handler, our notification that is sent back includes >> the channelId and version >> >> I believe the server should now be sending the pushEndpoint in the >> notification instead. >> >> I'd do it myself, but you know, it's java >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140730/8a4aae9a/attachment-0001.html From avibelli at redhat.com Wed Jul 30 08:07:17 2014 From: avibelli at redhat.com (Andrea Vibelli) Date: Wed, 30 Jul 2014 05:07:17 -0700 (PDT) Subject: [aerogear-dev] AG parent release In-Reply-To: References: Message-ID: <1406722037476-8632.post@n5.nabble.com> Go for it!! Thanks Andrea Matthias Wessendorf wrote > Hi, > > I have staged version 0.2.4 to: > https://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-3641/ > > mostly updates and important Hibernate upgrade to 4.2.15.Final > > Please test > > -M > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at .jboss > https://lists.jboss.org/mailman/listinfo/aerogear-dev -- View this message in context: http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-AG-parent-release-tp8629p8632.html Sent from the aerogear-dev mailing list archive at Nabble.com. From matzew at apache.org Wed Jul 30 09:40:07 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Wed, 30 Jul 2014 15:40:07 +0200 Subject: [aerogear-dev] Modularizing the Android Library In-Reply-To: References: <4CD71A7A-EDE1-4648-AB3E-E4DDB383D824@gmail.com> <20140722150611.GA58163@abstractj.org> <53D280B2.4070100@redhat.com> <20140725171611.GC26186@abstractj.org> <20140725172551.GD26186@abstractj.org> <20140725190100.GA1461@abstractj.org> <53D65352.3040203@redhat.com> <20140728140955.GB43110@abstractj.org> Message-ID: FYI, here is a JIRA that passos created for those repos: https://issues.jboss.org/browse/AEROGEAR-1479 -M On Mon, Jul 28, 2014 at 4:23 PM, Corinne Krych wrote: > @abstractj @summers what about being more specific and naming > ag-android-authz as ag-android-oauth2? This will be without confusion. > For now we only implement oauth2. If we need oauth1a impl we can have a > separate module. wdyt? > This is the way i?d like to go for iOS lib. > > With Oauth2 you do need authentication but as it?s taken care of by the > oauth2 provider, client side lib does not need a ?login? method, this > indeed why we need auth module is different to authz one. > > ++ > Corinne > > On 28 Jul 2014, at 16:09, Bruno Oliveira wrote: > > > Answers inline. > > > > On 2014-07-28, Summers Pittman wrote: > >> On 07/25/2014 03:01 PM, Bruno Oliveira wrote: > >>> On 2014-07-25, Lucas Holmquist wrote: > >>>> On Jul 25, 2014, at 1:25 PM, Bruno Oliveira > wrote: > >>>> > >>>>> On 2014-07-25, Lucas Holmquist wrote: > >>>>>> On Jul 25, 2014, at 1:16 PM, Bruno Oliveira > wrote: > >>>>>> > >>>>>>> On 2014-07-25, Summers Pittman wrote: > >>>>>>>> On 07/22/2014 11:06 AM, Bruno Oliveira wrote: > >>>>>>>>> Passos, what does aerogear-android-security stands for? Do we > really > >>>>>>>>> need the authz module? My question is due to the fact that > mostly it > >>>>>>>>> will be together with auth module, but I could be wrong. > >>>>>>>> You are wrong :) > >>>>>>> Do you have authorization without authentication? Or > authentication with > >>>>>>> no authorization? > >>>>>> We have this in our JS lib, the Authenitcation module, just does > the login/logout/enroll > >>>>>> > >>>>>> and the Authz module doesn?t rely on it, but connects to 3rd party > OAuth2( the current adapter ) providers > >>>>> If it connects using a Token from a 3rd party service, is because > it's based on some credential. So, > >>>>> I assume that you have authentication AND authorization, there's no > magic ;) > >>>>> > >>>>> Either way, name it to whatever you guys think is the best. > >>>> yea, the names can be confusing here :). we should rename to > ?CoolSuperAwesomeThing? and ?bob? :) > >>> As long as you do at your own repository, I'm ok. Meanwhile let's not > >>> mix the concept of OAuth2 with authorization only. > >> OAuth2 is an implementation of Authorization. We have Jira's for > >> OAuth1a, alternate work flows etc. > > > > Summers, there's no authorization without authentication before. Even > > with OAuth2 the client make use of the Bearer authentication scheme for > > example. > > > > If you assume that OAuth2 is authorization only, would be the same of > > assume that once my application is authorized on Twitter, I should be > able > > to access many profiles as I want. > > > > Even if IETF says "The OAuth 2.0 Authorization Framework: Bearer Token > > Usage". > > > >> > >> A better way to think about it would be the auth module is user visible > >> credential authentication and authorization. The authz module is third > >> party authentication and authorization.a > > > > authz into any security context stands for "authorization", if you mix > > both concepts here, people will get confused. > > > >> > >> A while ago we did discuss revisiting authz/auth and see if they can be > >> meaningfully merged. This may be something for a different thread. As > >> it stands they don't make sense to be in the same module because they > >> work differently for different use cases. > > > > As I said, I trust in your judgment, but mix concepts will lead to > > confusion. > > > >> > >>> > >>>>>> > >>>>>>>> In general > >>>>>>>> > >>>>>>>> Auth module consumes a username and password and manages a > session. > >>>>>>>> Authz fetches and consumers tokens and manages them through a > >>>>>>>> android.app.Service service. > >>>>>>>>> On 2014-07-22, Daniel Passos wrote: > >>>>>>>>>> Hey Guys, > >>>>>>>>>> > >>>>>>>>>> Summers and I started working on agdroid modules and remove > some cyclic > >>>>>>>>>> dependencies. So we plan to split the agdroid on these modules: > >>>>>>>>>> > >>>>>>>>>> - aerogear-android-core > >>>>>>>>>> - aerogear-android-pipe > >>>>>>>>>> - aerogear-android-auth > >>>>>>>>>> - aerogear-android-autz > >>>>>>>>>> - aerogear-android-store (with option security dependecy to > use > >>>>>>>>>> EncryptedStores) > >>>>>>>>>> - aerogear-android-security > >>>>>>>>>> - aerogear-android-push > >>>>>>>>>> - aerogear-android-push-ups > >>>>>>>>>> - aerogear-android-offline > >>>>>>>>>> > >>>>>>>>>> -- Passos > >>>>>>>>>> ? > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> On Fri, May 9, 2014 at 3:55 AM, Corinne Krych < > corinnekrych at gmail.com> > >>>>>>>>>> wrote: > >>>>>>>>>> > >>>>>>>>>>> Oops > >>>>>>>>>>> [2] https://issues.jboss.org/browse/AGIOS-187 > >>>>>>>>>>> > >>>>>>>>>>> On 09 May 2014, at 08:52, Corinne Krych < > corinnekrych at gmail.com> wrote: > >>>>>>>>>>> > >>>>>>>>>>>> [2] https://issues.jboss.org/browse/AGIOS-192 > >>>>>>>>>>> _______________________________________________ > >>>>>>>>>>> aerogear-dev mailing list > >>>>>>>>>>> aerogear-dev at lists.jboss.org > >>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev > >>>>>>>>>>> > >>>>>>>>>> _______________________________________________ > >>>>>>>>>> aerogear-dev mailing list > >>>>>>>>>> aerogear-dev at lists.jboss.org > >>>>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev > >>>>>>>>> -- > >>>>>>>>> > >>>>>>>>> abstractj > >>>>>>>>> PGP: 0x84DC9914 > >>>>>>>>> _______________________________________________ > >>>>>>>>> aerogear-dev mailing list > >>>>>>>>> aerogear-dev at lists.jboss.org > >>>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev > >>>>>>>> > >>>>>>>> -- > >>>>>>>> Summers Pittman > >>>>>>>>>> Phone:404 941 4698 > >>>>>>>>>> Java is my crack. > >>>>>>>> _______________________________________________ > >>>>>>>> aerogear-dev mailing list > >>>>>>>> aerogear-dev at lists.jboss.org > >>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev > >>>>>>> -- > >>>>>>> > >>>>>>> abstractj > >>>>>>> PGP: 0x84DC9914 > >>>>>>> _______________________________________________ > >>>>>>> aerogear-dev mailing list > >>>>>>> aerogear-dev at lists.jboss.org > >>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev > >>>>>> _______________________________________________ > >>>>>> aerogear-dev mailing list > >>>>>> aerogear-dev at lists.jboss.org > >>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev > >>>>> > >>>>> -- > >>>>> > >>>>> abstractj > >>>>> PGP: 0x84DC9914 > >>>>> _______________________________________________ > >>>>> aerogear-dev mailing list > >>>>> aerogear-dev at lists.jboss.org > >>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev > >>>> _______________________________________________ > >>>> aerogear-dev mailing list > >>>> aerogear-dev at lists.jboss.org > >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev > >>> > >>> -- > >>> > >>> abstractj > >>> PGP: 0x84DC9914 > >>> _______________________________________________ > >>> aerogear-dev mailing list > >>> aerogear-dev at lists.jboss.org > >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev > >> > >> > >> -- > >> Summers Pittman > >>>> Phone:404 941 4698 > >>>> Java is my crack. > >> > >> _______________________________________________ > >> aerogear-dev mailing list > >> aerogear-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > -- > > > > abstractj > > PGP: 0x84DC9914 > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140730/b571dfaf/attachment.html From lholmqui at redhat.com Wed Jul 30 09:58:48 2014 From: lholmqui at redhat.com (Lucas Holmquist) Date: Wed, 30 Jul 2014 09:58:48 -0400 Subject: [aerogear-dev] SimplePush sync with MOz In-Reply-To: References: Message-ID: On Jul 30, 2014, at 4:17 AM, Matthias Wessendorf wrote: > > > > On Tue, Jul 29, 2014 at 4:29 PM, Daniel Bevenius wrote: > > but in our message handler, our notification that is sent back includes the channelId and version > The 'Notification' section SimplePush Protocol [1] it specifies what should be returned. I'm not sure if Mozilla's server does something different of if it is the client side that does something different. > > their live server returns exactly what has been spec'd in [1] yea, we realized it is probably coming from the native browser code, so i?ve update the client side to deal with this https://github.com/aerogear/aerogear-js/pull/135 > > -Matthias > > > I'm not against changing things, but I think it makes sense for us to follow their protocol. I'll read up on the protocol and see if there is any new information that I'm not aware of. I'll take a look at their server too. > > [1] https://wiki.mozilla.org/WebAPI/SimplePush/Protocol#PushServer_-.3E_UserAgent_5 > > > > > On 29 July 2014 16:10, Lucas Holmquist wrote: > so this sort of relates to this thread here: > > http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-Differences-between-Firefox-OS-quot-native-quot-Push-lib-and-AeroGear-s-Push-adapter-td6195.html > > > > > from https://developer.mozilla.org/en-US/docs/Web/API/Simple_Push_API#Add_the_push_message_handler > Moz example > > window.navigator.mozSetMessageHandler('push', function(e) { > console.log('My endpoint is ' + e.pushEndpoint); > console.log('My new version is ' + e.version); > //Remember that you can handle here if you have more than > //one pushEndpoint > if (e.pushEndpoint === emailEndpoint) { > emailHandler(e.version); > } else if (e.pushEndpoint === imEndpoint) { > imHandler(e.version); > } > }); > The notification that they send back includes the pushEndpoint and the version > > Currently, when we do navigator.push.register() the result we send back is an object that includes the pushEndpoint, this is actually changing to be more in line with Mozilla. Instead of the object being sent back, we will send back the pushEndpoint as a String. <--- is a super easy change that sebi already did, just need to re-merge it back in > > but in our message handler, our notification that is sent back includes the channelId and version > > I believe the server should now be sending the pushEndpoint in the notification instead. > > I'd do it myself, but you know, it's java > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140730/d665eab4/attachment-0001.html From matzew at apache.org Wed Jul 30 10:34:03 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Wed, 30 Jul 2014 16:34:03 +0200 Subject: [aerogear-dev] [UnifiedPush Server] Openshift update (of Beta1) In-Reply-To: References: Message-ID: I have done some updates to the PR, based on review feedback. Please test the given 'rhc' script, to check if this can be released, or not. -M On Tue, Jul 29, 2014 at 9:32 PM, Matthias Wessendorf wrote: > Good evening folks! > > > Now that we got the 1.0.0.Beta1 release out, I used its tag and ran the > 'openshift' profile. > > The generated WARs (and a new version label) are made available in this PR: > > https://github.com/aerogear/openshift-origin-cartridge-aerogear-push/pull/19 > > > If you want to test it, you simple need to run the following command on > your shell (assuming 'rhc' is installed) > > rhc app create --no-git LATESTUPS > https://cartreflect-claytondev.rhcloud.com/reflect\?github\=matzew/openshift-origin-cartridge-aerogear-push > > > Feedback welcome! > > Thanks > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140730/8b767a01/attachment.html From matzew at apache.org Wed Jul 30 10:39:28 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Wed, 30 Jul 2014 16:39:28 +0200 Subject: [aerogear-dev] Docs: update on the UPS docs In-Reply-To: References: Message-ID: A lot of more content. Please review, and comment on the PR if this can be merged or not .... On Tue, Jul 29, 2014 at 6:48 PM, Matthias Wessendorf wrote: > Here is a first PR for it: > > https://github.com/aerogear/aerogear.org/pull/333 > > as noted, still WIP - but it is getting there > > > On Thu, Jul 24, 2014 at 3:25 PM, Matthias Wessendorf > wrote: > >> Thanks Dan! >> >> >> FYI - the draft of the TOC (and soon content) lives in this branch: >> >> >> https://github.com/aerogear/aerogear.org/blob/NewUPS_Guide/docs/unifiedpush/ups_userguide/index.markdown >> >> -M >> >> >> On Thu, Jul 24, 2014 at 2:14 PM, Daniel Bevenius < >> daniel.bevenius at gmail.com> wrote: >> >>> Looks good! >>> perhaps change: Configuring and Managing Applications that use the >>> UnifiedPush Server -> Configuring and managing applications that use >>> the UnifiedPush Server >>> >>> >>> >>> On 24 July 2014 13:32, Matthias Wessendorf wrote: >>> >>>> update: >>>> >>>> >>>> UnifiedPush Server User Guide >>>> >>>> - Overview >>>> - About the UnifiedPush Server >>>> - Use-cases and scenarios >>>> - Useful Terminology >>>> - How the UnifiedPush Server Works >>>> - Installation and configuration >>>> - The WAR file distribution >>>> - setup and configure a database >>>> - deploy the WAR files >>>> - Running on OpenShift >>>> - create an instance using OpenShift's Web UI >>>> - create an instance using OpenShift's command line interface >>>> - Using the Admin UI >>>> - Administering the UnifiedPush Server Console >>>> - Configuring and Managing Applications that use the UnifiedPush >>>> Server >>>> - Preparing mobile devices to be connected with the UnifiedPush >>>> Server >>>> - Sending Push Notifications >>>> - Preparing backends to send Push Notifications >>>> - Next steps >>>> - TBD: Links to tutorials and specs (some specs might go away) >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> On Thu, Jul 24, 2014 at 1:29 PM, Matthias Wessendorf >>> > wrote: >>>> >>>>> Here is the TOC that I have in mind (and started to work on): >>>>> >>>>> UnifiedPush Server User Guide >>>>> >>>>> - Overview >>>>> - About the UnifiedPush Server >>>>> - Use-cases and scenarios >>>>> - Useful Terminology >>>>> - How the UnifiedPush Server Works >>>>> - Installation and configuration >>>>> - The WAR file distribution >>>>> - setup and configure a database >>>>> - deploy the WAR files >>>>> - Running on OpenShift >>>>> - create an instance using OpenShift's Web UI >>>>> - create an instance using OpenShift's command line interface >>>>> - Using the Admin UI >>>>> - Administering the UnifiedPush Server Console >>>>> - Configuring and Managing Applications that use the >>>>> UnifiedPush Server >>>>> - Preparing mobile devices to be connected with the UnifiedPush >>>>> Server >>>>> - Sending Push Notifications >>>>> - Next steps >>>>> - TBD: Links to tutorials and specs (some specs might go away) >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Thu, Jul 24, 2014 at 11:26 AM, Matthias Wessendorf < >>>>> matzew at apache.org> wrote: >>>>> >>>>>> Before actually starting with the (initial) rewrite of the UPS guide >>>>>> (as I outlined), I did the re-org of the UPS content. >>>>>> >>>>>> Please review: >>>>>> https://github.com/aerogear/aerogear.org/pull/327 >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Mon, Jul 21, 2014 at 5:59 PM, Matthias Wessendorf < >>>>>> matzew at apache.org> wrote: >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> right now we have a lot of different 'documentation files', like the >>>>>>> README, some specs, and guides and tutorials. >>>>>>> >>>>>>> I'd like to restructure that a bit and centralize the documentation >>>>>>> a bit. >>>>>>> >>>>>>> On the "push" landing page ([1]), I'd like to change the "Lean More" >>>>>>> link to a new page that has all the UPS centric documentations >>>>>>> >>>>>>> - AeroGear UnifiedPush Server User/Reference Guide >>>>>>> - Tutorials >>>>>>> >>>>>>> >>>>>>> AeroGear >>>>>>> UnifiedPush Server User/Reference Guide >>>>>>> >>>>>>> - Overview >>>>>>> - some generic information >>>>>>> - Installation and configuration >>>>>>> - what's needed (e.g. JBoss and a database) >>>>>>> - Running on OpenShift >>>>>>> - using the UI on OpenShift >>>>>>> - using the rhc command line >>>>>>> - Using the Admin UI >>>>>>> - doing an overhaul of our existing Admin UI guide (e.g. >>>>>>> taking new screenshots and updating based on new UI features) >>>>>>> >>>>>>> The format of the *reference guide* would be similar to the one >>>>>>> from Keycloak ([2]). But... I will continue using asciidoc ;-) >>>>>>> >>>>>>> The README will be extremely quick and simply link to the homepage >>>>>>> ;-) After this *new* reference guide, I think some of the current >>>>>>> specs can be removed, as the *reference guide* hopefully covers all >>>>>>> of their content :-) >>>>>>> >>>>>>> For the RESTful APIs, I have to look what Keycloak did to get >>>>>>> something like: >>>>>>> http://docs.jboss.org/keycloak/docs/1.0-beta-3/rest-api/overview-index.html >>>>>>> >>>>>>> After the work as been completed, I will be revisiting the specs and >>>>>>> evaluate their need ;-) >>>>>>> >>>>>>> Tutorials >>>>>>> >>>>>>> This section will contain links to all the different tutorials we >>>>>>> have: >>>>>>> >>>>>>> - http://aerogear.org/docs/guides/aerogear-push-ios/ >>>>>>> - http://aerogear.org/docs/guides/aerogear-push-js/ >>>>>>> - http://aerogear.org/docs/guides/aerogear-push-android/ >>>>>>> - http://aerogear.org/docs/guides/aerogear-push-chrome/ >>>>>>> - http://aerogear.org/docs/guides/GetStartedwithJavaSender/ >>>>>>> >>>>>>> For Cordova we will have one single document, instead of three: >>>>>>> >>>>>>> - http://aerogear.org/docs/guides/aerogear-push-cordova-android/ >>>>>>> - http://aerogear.org/docs/guides/aerogear-push-cordova-ios/ >>>>>>> - >>>>>>> http://aerogear.org/docs/guides/aerogear-cordova/AerogearCordovaPush/ >>>>>>> >>>>>>> There is already a JIRA for that ([4]). >>>>>>> >>>>>>> To make it more clear (or clean?), I will remove the UPS/Push >>>>>>> related docs from our guides ([3]) and replace all those links by a single >>>>>>> link to the above mentioned new page (also referenced from [1]). >>>>>>> >>>>>>> Greetings, >>>>>>> Matthias >>>>>>> >>>>>>> >>>>>>> >>>>>>> - [1] http://aerogear.org/push/ >>>>>>> - [2] >>>>>>> http://docs.jboss.org/keycloak/docs/1.0-beta-3/userguide/html/index.html >>>>>>> - [3] http://aerogear.org/docs/guides/ >>>>>>> - [4] https://issues.jboss.org/browse/AGPUSH-805 >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Matthias Wessendorf >>>>>>> >>>>>>> blog: http://matthiaswessendorf.wordpress.com/ >>>>>>> sessions: http://www.slideshare.net/mwessendorf >>>>>>> twitter: http://twitter.com/mwessendorf >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Matthias Wessendorf >>>>>> >>>>>> blog: http://matthiaswessendorf.wordpress.com/ >>>>>> sessions: http://www.slideshare.net/mwessendorf >>>>>> twitter: http://twitter.com/mwessendorf >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Matthias Wessendorf >>>>> >>>>> blog: http://matthiaswessendorf.wordpress.com/ >>>>> sessions: http://www.slideshare.net/mwessendorf >>>>> twitter: http://twitter.com/mwessendorf >>>>> >>>> >>>> >>>> >>>> -- >>>> Matthias Wessendorf >>>> >>>> blog: http://matthiaswessendorf.wordpress.com/ >>>> sessions: http://www.slideshare.net/mwessendorf >>>> twitter: http://twitter.com/mwessendorf >>>> >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> >>> >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >> >> >> >> -- >> Matthias Wessendorf >> >> blog: http://matthiaswessendorf.wordpress.com/ >> sessions: http://www.slideshare.net/mwessendorf >> twitter: http://twitter.com/mwessendorf >> > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140730/ad56c4ac/attachment-0001.html From lholmqui at redhat.com Wed Jul 30 11:34:53 2014 From: lholmqui at redhat.com (Lucas Holmquist) Date: Wed, 30 Jul 2014 11:34:53 -0400 Subject: [aerogear-dev] SimplePush sync with MOz In-Reply-To: <4C74DDCA-4125-479B-AFC6-24D860B6461F@redhat.com> References: <4C74DDCA-4125-479B-AFC6-24D860B6461F@redhat.com> Message-ID: <0B3BBB15-5287-4584-91D1-24EA15A311A2@redhat.com> PR for this client update is now here: https://github.com/aerogear/aerogear-js/pull/135 if peeps have time, a review would be welcome. looking to get this in before i update the push docs and examples for simplePush and UPS/SimplePush -Thanks dudes On Jul 29, 2014, at 11:59 AM, Lucas Holmquist wrote: > created a JIRA for it > > https://issues.jboss.org/browse/AGJS-203 > > > PR coming soon for the client code > On Jul 29, 2014, at 10:46 AM, Daniel Bevenius wrote: > >> Yeah, it looks like this is what's happening (at least looking at the server side of it that is) >> >> >> On 29 July 2014 16:37, Lucas Holmquist wrote: >> >> On Jul 29, 2014, at 10:29 AM, Daniel Bevenius wrote: >> >>> > but in our message handler, our notification that is sent back includes the channelId and version >>> The 'Notification' section SimplePush Protocol [1] it specifies what should be returned. I'm not sure if Mozilla's server does something different of if it is the client side that does something different. >> >> most likely it's the client side code that should be saving the pushEndpoint along with the channelID and then looking up by the channel ID, and then giving it to the user >> >> this is probably what happens in the native browser code that we are trying to polyfill >>> I'm not against changing things, but I think it makes sense for us to follow their protocol. I'll read up on the protocol and see if there is any new information that I'm not aware of. I'll take a look at their server too. >>> >>> [1] https://wiki.mozilla.org/WebAPI/SimplePush/Protocol#PushServer_-.3E_UserAgent_5 >>> >>> >>> >>> >>> On 29 July 2014 16:10, Lucas Holmquist wrote: >>> so this sort of relates to this thread here: >>> >>> http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-Differences-between-Firefox-OS-quot-native-quot-Push-lib-and-AeroGear-s-Push-adapter-td6195.html >>> >>> >>> >>> >>> from https://developer.mozilla.org/en-US/docs/Web/API/Simple_Push_API#Add_the_push_message_handler >>> Moz example >>> >>> window.navigator.mozSetMessageHandler('push', function(e) { >>> console.log('My endpoint is ' + e.pushEndpoint); >>> console.log('My new version is ' + e.version); >>> //Remember that you can handle here if you have more than >>> //one pushEndpoint >>> if (e.pushEndpoint === emailEndpoint) { >>> emailHandler(e.version); >>> } else if (e.pushEndpoint === imEndpoint) { >>> imHandler(e.version); >>> } >>> }); >>> The notification that they send back includes the pushEndpoint and the version >>> >>> Currently, when we do navigator.push.register() the result we send back is an object that includes the pushEndpoint, this is actually changing to be more in line with Mozilla. Instead of the object being sent back, we will send back the pushEndpoint as a String. <--- is a super easy change that sebi already did, just need to re-merge it back in >>> >>> but in our message handler, our notification that is sent back includes the channelId and version >>> >>> I believe the server should now be sending the pushEndpoint in the notification instead. >>> >>> I'd do it myself, but you know, it's java >>> >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140730/d8c93954/attachment.html From jrconlin at gmail.com Wed Jul 30 12:14:57 2014 From: jrconlin at gmail.com (JR Conlin) Date: Wed, 30 Jul 2014 09:14:57 -0700 Subject: [aerogear-dev] SimplePush sync with MOz In-Reply-To: References: Message-ID: <53D91A01.7080109@gmail.com> On 2014/7/30 1:16 AM, Matthias Wessendorf wrote: > Using the little hack, I am not seeing the pushEndpoint being returned > by their server: > https://gist.github.com/matzew/cbda360d72eaaef75971 > Registration messages carry the pushEndpoint, which is supposed to go to the App. Actual Push Notifications don't have the pushEndpoint. The Client (the bit of SimplePush that the Apps talk to), maps the ChannelID to the App that requested it and fires the event when it gets an update. > > Currently, when we do |navigator.push.register()| the result we > send back is an object that includes the pushEndpoint, this is > actually changing to be more in line with Mozilla. Instead of the > object being sent back, we will send back the pushEndpoint as a > String. <--- is a super easy change that sebi already did, just > need to re-merge it back in > > but in our message handler, our notification that is sent back > includes the channelId and version > > > here is, the JSON I receive w/ the above hack: > {"messageType":"notification","updates":[{"channelID":"d9b74644-4f97-46aa-b8fa-9393985cd6cd","version":3}]} > > > > > I believe the server should now be sending the pushEndpoint in the > notification instead. > > I'd do it myself, but you know, it's java > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140730/570d7151/attachment.html From lholmqui at redhat.com Wed Jul 30 12:47:31 2014 From: lholmqui at redhat.com (Lucas Holmquist) Date: Wed, 30 Jul 2014 12:47:31 -0400 Subject: [aerogear-dev] SimplePush sync with MOz In-Reply-To: <53D91A01.7080109@gmail.com> References: <53D91A01.7080109@gmail.com> Message-ID: <5BB617A0-94C7-4B74-96F2-E5D49874F883@redhat.com> On Jul 30, 2014, at 12:14 PM, JR Conlin wrote: > On 2014/7/30 1:16 AM, Matthias Wessendorf wrote: >> Using the little hack, I am not seeing the pushEndpoint being returned by their server: >> https://gist.github.com/matzew/cbda360d72eaaef75971 >> > Registration messages carry the pushEndpoint, which is supposed to go to the App. > Actual Push Notifications don't have the pushEndpoint. The Client (the bit of SimplePush that the Apps talk to), maps the ChannelID to the App that requested it and fires the event when it gets an update. ok, cool, thanks for the info, that?s what i?ve now updated our client polyfill to do >> Currently, when we do navigator.push.register() the result we send back is an object that includes the pushEndpoint, this is actually changing to be more in line with Mozilla. Instead of the object being sent back, we will send back the pushEndpoint as a String. <--- is a super easy change that sebi already did, just need to re-merge it back in >> >> but in our message handler, our notification that is sent back includes the channelId and version >> >> >> here is, the JSON I receive w/ the above hack: >> {"messageType":"notification","updates":[{"channelID":"d9b74644-4f97-46aa-b8fa-9393985cd6cd","version":3}]} >> >> >> >> I believe the server should now be sending the pushEndpoint in the notification instead. >> >> I'd do it myself, but you know, it's java >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> >> -- >> Matthias Wessendorf >> >> blog: http://matthiaswessendorf.wordpress.com/ >> sessions: http://www.slideshare.net/mwessendorf >> twitter: http://twitter.com/mwessendorf >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140730/1e001665/attachment-0001.html From bruno at abstractj.org Wed Jul 30 14:58:38 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Wed, 30 Jul 2014 15:58:38 -0300 Subject: [aerogear-dev] AG Site and new section Message-ID: <20140730185838.GA9505@abstractj.org> Good morning peeps, as you know, AG Security was deprecated, but we still have references on AeroGear site http://staging.aerogear.org/docs/guides/aerogear-security/. Probably a bad rebase, once it was already removed here: https://github.com/aerogear/aerogear.org/pull/287/files ? Atm I'm looking for volunteers to replace this section at the main page or suggestions about how to improve it. Please see: http://staging.aerogear.org. "Mobility and security, both Integrate with your existing enterprise environment. AeroGear provides Two-Factor Authentication and One-Time-Password features to improve your application's security. Learn about AeroGear Security" Suggestions are welcome. -- abstractj PGP: 0x84DC9914 From bruno at abstractj.org Wed Jul 30 16:14:57 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Wed, 30 Jul 2014 17:14:57 -0300 Subject: [aerogear-dev] AG parent release In-Reply-To: <1406722037476-8632.post@n5.nabble.com> References: <1406722037476-8632.post@n5.nabble.com> Message-ID: <20140730201457.GB49268@abstractj.org> Ship it! On 2014-07-30, Andrea Vibelli wrote: > Go for it!! > Thanks > Andrea > > > Matthias Wessendorf wrote > > Hi, > > > > I have staged version 0.2.4 to: > > https://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-3641/ > > > > mostly updates and important Hibernate upgrade to 4.2.15.Final > > > > Please test > > > > -M > > > > -- > > Matthias Wessendorf > > > > blog: http://matthiaswessendorf.wordpress.com/ > > sessions: http://www.slideshare.net/mwessendorf > > twitter: http://twitter.com/mwessendorf > > > > _______________________________________________ > > aerogear-dev mailing list > > > aerogear-dev at .jboss > > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > > -- > View this message in context: http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-AG-parent-release-tp8629p8632.html > Sent from the aerogear-dev mailing list archive at Nabble.com. > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -- abstractj PGP: 0x84DC9914 From qmx at qmx.me Wed Jul 30 19:12:08 2014 From: qmx at qmx.me (Douglas Campos) Date: Wed, 30 Jul 2014 20:12:08 -0300 Subject: [aerogear-dev] AG Site and new section In-Reply-To: <20140730185838.GA9505@abstractj.org> References: <20140730185838.GA9505@abstractj.org> Message-ID: <20140730231208.GI88071@darkstar.local> On Wed, Jul 30, 2014 at 03:58:38PM -0300, Bruno Oliveira wrote: > Good morning peeps, as you know, AG Security was deprecated, but we > still have references on AeroGear site > http://staging.aerogear.org/docs/guides/aerogear-security/. Probably a > bad rebase, once it was already removed here: > https://github.com/aerogear/aerogear.org/pull/287/files ? > > Atm I'm looking for volunteers to replace this section at the main page > or suggestions about how to improve it. Please see: http://staging.aerogear.org. > > "Mobility and security, both > > Integrate with your existing enterprise environment. AeroGear provides > Two-Factor Authentication and One-Time-Password features to improve your > application's security. > > Learn about AeroGear Security" What message are we trying to convey here? Do we want to fill the void left by AeroGear Security with educational material (like "use keycloak for this") or are we going to just yank all references? > > Suggestions are welcome. > > -- > > abstractj > PGP: 0x84DC9914 > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -- qmx From scm.blanc at gmail.com Thu Jul 31 03:20:04 2014 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Thu, 31 Jul 2014 09:20:04 +0200 Subject: [aerogear-dev] Help needed on AGPUSH-848 Message-ID: Morning Peeps, I'm currently trying to fix AGPUSH-848[1]. Basically, the number of receivers shown in the top3 list is not always accurate. I suspect that something is wrong with this query : https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/model/jpa/src/main/java/org/jboss/aerogear/unifiedpush/jpa/dao/impl/JPAPushMessageInformationDao.java#L99-L104 I have change this test case : https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/model%2Fjpa%2Fsrc%2Ftest%2Fjava%2Forg%2Fjboss%2Faerogear%2Funifiedpush%2Fjpa%2FPushMessageInformationDaoTest.java#L251 By adding just one VariantInformation[2] and now the test is failing and I have no idea why, so I would aprreciate a second eye on this. I'm probably missing something obvious but I can not see it right now :) Sebi [1]https://issues.jboss.org/browse/AGPUSH-848 [2] https://gist.github.com/sebastienblanc/ea34e7f9fdafbc0785f2#file-gistfile1-java-L30-L35 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140731/df9cd2d3/attachment.html From daniel.bevenius at gmail.com Thu Jul 31 03:34:42 2014 From: daniel.bevenius at gmail.com (Daniel Bevenius) Date: Thu, 31 Jul 2014 09:34:42 +0200 Subject: [aerogear-dev] Help needed on AGPUSH-848 In-Reply-To: References: Message-ID: Is this because variantFour and variantFive have the same variantId (231543432434)? When added to the map only one will exist later in findTopThreeBusyVariantIDs. On 31 July 2014 09:20, Sebastien Blanc wrote: > Morning Peeps, > > I'm currently trying to fix AGPUSH-848[1]. > Basically, the number of receivers shown in the top3 list is not always > accurate. > > I suspect that something is wrong with this query : > > > https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/model/jpa/src/main/java/org/jboss/aerogear/unifiedpush/jpa/dao/impl/JPAPushMessageInformationDao.java#L99-L104 > > I have change this test case : > > https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/model%2Fjpa%2Fsrc%2Ftest%2Fjava%2Forg%2Fjboss%2Faerogear%2Funifiedpush%2Fjpa%2FPushMessageInformationDaoTest.java#L251 > > By adding just one VariantInformation[2] and now the test is failing and I > have no idea why, so I would aprreciate a second eye on this. > > I'm probably missing something obvious but I can not see it right now :) > > Sebi > > > [1]https://issues.jboss.org/browse/AGPUSH-848 > [2] > https://gist.github.com/sebastienblanc/ea34e7f9fdafbc0785f2#file-gistfile1-java-L30-L35 > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140731/fadafec4/attachment.html From scm.blanc at gmail.com Thu Jul 31 03:39:24 2014 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Thu, 31 Jul 2014 09:39:24 +0200 Subject: [aerogear-dev] Help needed on AGPUSH-848 In-Reply-To: References: Message-ID: Well, several VariantMetricInformation instances can have the same VariantID, at each send , one is created : https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/push%2Fsrc%2Fmain%2Fjava%2Forg%2Fjboss%2Faerogear%2Funifiedpush%2Fmessage%2FSenderServiceImpl.java#L133 On Thu, Jul 31, 2014 at 9:34 AM, Daniel Bevenius wrote: > Is this because variantFour and variantFive have the same variantId > (231543432434)? When added to the map only one will exist later > in findTopThreeBusyVariantIDs. > > > > > > On 31 July 2014 09:20, Sebastien Blanc wrote: > >> Morning Peeps, >> >> I'm currently trying to fix AGPUSH-848[1]. >> Basically, the number of receivers shown in the top3 list is not always >> accurate. >> >> I suspect that something is wrong with this query : >> >> >> https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/model/jpa/src/main/java/org/jboss/aerogear/unifiedpush/jpa/dao/impl/JPAPushMessageInformationDao.java#L99-L104 >> >> I have change this test case : >> >> https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/model%2Fjpa%2Fsrc%2Ftest%2Fjava%2Forg%2Fjboss%2Faerogear%2Funifiedpush%2Fjpa%2FPushMessageInformationDaoTest.java#L251 >> >> By adding just one VariantInformation[2] and now the test is failing and >> I have no idea why, so I would aprreciate a second eye on this. >> >> I'm probably missing something obvious but I can not see it right now :) >> >> Sebi >> >> >> [1]https://issues.jboss.org/browse/AGPUSH-848 >> [2] >> https://gist.github.com/sebastienblanc/ea34e7f9fdafbc0785f2#file-gistfile1-java-L30-L35 >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140731/814e1299/attachment.html From bruno at abstractj.org Thu Jul 31 03:49:04 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Thu, 31 Jul 2014 04:49:04 -0300 Subject: [aerogear-dev] AG Site and new section In-Reply-To: <20140730231208.GI88071@darkstar.local> References: <20140730185838.GA9505@abstractj.org> <20140730231208.GI88071@darkstar.local> Message-ID: <20140731074904.GA19958@abstractj.org> Good morning qmx, I'm all for suggestions, server side bits made sense in the past, today with Keycloak, not anymore. Also, most of our security bits are covered per platform, for example AG Crypto at iOS, JS, Cordova and Android documentation ? I would like to avoid duplication. I'm all for an education material, not sure if we should name it "AeroGear Security". On 2014-07-30, Douglas Campos wrote: > On Wed, Jul 30, 2014 at 03:58:38PM -0300, Bruno Oliveira wrote: > > Good morning peeps, as you know, AG Security was deprecated, but we > > still have references on AeroGear site > > http://staging.aerogear.org/docs/guides/aerogear-security/. Probably a > > bad rebase, once it was already removed here: > > https://github.com/aerogear/aerogear.org/pull/287/files ? > > > > Atm I'm looking for volunteers to replace this section at the main page > > or suggestions about how to improve it. Please see: http://staging.aerogear.org. > > > > "Mobility and security, both > > > > Integrate with your existing enterprise environment. AeroGear provides > > Two-Factor Authentication and One-Time-Password features to improve your > > application's security. > > > > Learn about AeroGear Security" > What message are we trying to convey here? Do we want to fill the void > left by AeroGear Security with educational material (like "use keycloak > for this") or are we going to just yank all references? > > > > > Suggestions are welcome. > > > > -- > > > > abstractj > > PGP: 0x84DC9914 > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > -- > qmx > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -- abstractj PGP: 0x84DC9914 From matzew at apache.org Thu Jul 31 03:50:52 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Thu, 31 Jul 2014 09:50:52 +0200 Subject: [aerogear-dev] New docs got merged (was: Re: Docs: update on the UPS docs) Message-ID: Hi, the new "push" landing page and restructuring went into our master branch. * http://staging.aerogear.org/push - the 'Learn More' now redirects to: ** http://staging.aerogear.org/docs/unifiedpush/ That contains all UPS/Push related docs on a more centralized page. It also contains the new 'User/Reference Guide' on the UnifiedPush Server: http://staging.aerogear.org/docs/unifiedpush/ups_userguide/ feel free to review and sent PRs/JIRAs for 'bugs' or improvements! Thanks! -Matthias On Wed, Jul 30, 2014 at 4:39 PM, Matthias Wessendorf wrote: > A lot of more content. > > Please review, and comment on the PR if this can be merged or not .... > > > On Tue, Jul 29, 2014 at 6:48 PM, Matthias Wessendorf > wrote: > >> Here is a first PR for it: >> >> https://github.com/aerogear/aerogear.org/pull/333 >> >> as noted, still WIP - but it is getting there >> >> >> On Thu, Jul 24, 2014 at 3:25 PM, Matthias Wessendorf >> wrote: >> >>> Thanks Dan! >>> >>> >>> FYI - the draft of the TOC (and soon content) lives in this branch: >>> >>> >>> https://github.com/aerogear/aerogear.org/blob/NewUPS_Guide/docs/unifiedpush/ups_userguide/index.markdown >>> >>> -M >>> >>> >>> On Thu, Jul 24, 2014 at 2:14 PM, Daniel Bevenius < >>> daniel.bevenius at gmail.com> wrote: >>> >>>> Looks good! >>>> perhaps change: Configuring and Managing Applications that use the >>>> UnifiedPush Server -> Configuring and managing applications that use >>>> the UnifiedPush Server >>>> >>>> >>>> >>>> On 24 July 2014 13:32, Matthias Wessendorf wrote: >>>> >>>>> update: >>>>> >>>>> >>>>> UnifiedPush Server User Guide >>>>> >>>>> - Overview >>>>> - About the UnifiedPush Server >>>>> - Use-cases and scenarios >>>>> - Useful Terminology >>>>> - How the UnifiedPush Server Works >>>>> - Installation and configuration >>>>> - The WAR file distribution >>>>> - setup and configure a database >>>>> - deploy the WAR files >>>>> - Running on OpenShift >>>>> - create an instance using OpenShift's Web UI >>>>> - create an instance using OpenShift's command line interface >>>>> - Using the Admin UI >>>>> - Administering the UnifiedPush Server Console >>>>> - Configuring and Managing Applications that use the >>>>> UnifiedPush Server >>>>> - Preparing mobile devices to be connected with the UnifiedPush >>>>> Server >>>>> - Sending Push Notifications >>>>> - Preparing backends to send Push Notifications >>>>> - Next steps >>>>> - TBD: Links to tutorials and specs (some specs might go away) >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Thu, Jul 24, 2014 at 1:29 PM, Matthias Wessendorf < >>>>> matzew at apache.org> wrote: >>>>> >>>>>> Here is the TOC that I have in mind (and started to work on): >>>>>> >>>>>> UnifiedPush Server User Guide >>>>>> >>>>>> - Overview >>>>>> - About the UnifiedPush Server >>>>>> - Use-cases and scenarios >>>>>> - Useful Terminology >>>>>> - How the UnifiedPush Server Works >>>>>> - Installation and configuration >>>>>> - The WAR file distribution >>>>>> - setup and configure a database >>>>>> - deploy the WAR files >>>>>> - Running on OpenShift >>>>>> - create an instance using OpenShift's Web UI >>>>>> - create an instance using OpenShift's command line interface >>>>>> - Using the Admin UI >>>>>> - Administering the UnifiedPush Server Console >>>>>> - Configuring and Managing Applications that use the >>>>>> UnifiedPush Server >>>>>> - Preparing mobile devices to be connected with the >>>>>> UnifiedPush Server >>>>>> - Sending Push Notifications >>>>>> - Next steps >>>>>> - TBD: Links to tutorials and specs (some specs might go away) >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Thu, Jul 24, 2014 at 11:26 AM, Matthias Wessendorf < >>>>>> matzew at apache.org> wrote: >>>>>> >>>>>>> Before actually starting with the (initial) rewrite of the UPS guide >>>>>>> (as I outlined), I did the re-org of the UPS content. >>>>>>> >>>>>>> Please review: >>>>>>> https://github.com/aerogear/aerogear.org/pull/327 >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Mon, Jul 21, 2014 at 5:59 PM, Matthias Wessendorf < >>>>>>> matzew at apache.org> wrote: >>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> right now we have a lot of different 'documentation files', like >>>>>>>> the README, some specs, and guides and tutorials. >>>>>>>> >>>>>>>> I'd like to restructure that a bit and centralize the documentation >>>>>>>> a bit. >>>>>>>> >>>>>>>> On the "push" landing page ([1]), I'd like to change the "Lean >>>>>>>> More" link to a new page that has all the UPS centric documentations >>>>>>>> >>>>>>>> - AeroGear UnifiedPush Server User/Reference Guide >>>>>>>> - Tutorials >>>>>>>> >>>>>>>> >>>>>>>> AeroGear >>>>>>>> UnifiedPush Server User/Reference Guide >>>>>>>> >>>>>>>> - Overview >>>>>>>> - some generic information >>>>>>>> - Installation and configuration >>>>>>>> - what's needed (e.g. JBoss and a database) >>>>>>>> - Running on OpenShift >>>>>>>> - using the UI on OpenShift >>>>>>>> - using the rhc command line >>>>>>>> - Using the Admin UI >>>>>>>> - doing an overhaul of our existing Admin UI guide (e.g. >>>>>>>> taking new screenshots and updating based on new UI features) >>>>>>>> >>>>>>>> The format of the *reference guide* would be similar to the one >>>>>>>> from Keycloak ([2]). But... I will continue using asciidoc ;-) >>>>>>>> >>>>>>>> The README will be extremely quick and simply link to the homepage >>>>>>>> ;-) After this *new* reference guide, I think some of the current >>>>>>>> specs can be removed, as the *reference guide* hopefully covers >>>>>>>> all of their content :-) >>>>>>>> >>>>>>>> For the RESTful APIs, I have to look what Keycloak did to get >>>>>>>> something like: >>>>>>>> http://docs.jboss.org/keycloak/docs/1.0-beta-3/rest-api/overview-index.html >>>>>>>> >>>>>>>> After the work as been completed, I will be revisiting the specs >>>>>>>> and evaluate their need ;-) >>>>>>>> >>>>>>>> Tutorials >>>>>>>> >>>>>>>> This section will contain links to all the different tutorials we >>>>>>>> have: >>>>>>>> >>>>>>>> - http://aerogear.org/docs/guides/aerogear-push-ios/ >>>>>>>> - http://aerogear.org/docs/guides/aerogear-push-js/ >>>>>>>> - http://aerogear.org/docs/guides/aerogear-push-android/ >>>>>>>> - http://aerogear.org/docs/guides/aerogear-push-chrome/ >>>>>>>> - http://aerogear.org/docs/guides/GetStartedwithJavaSender/ >>>>>>>> >>>>>>>> For Cordova we will have one single document, instead of three: >>>>>>>> >>>>>>>> - http://aerogear.org/docs/guides/aerogear-push-cordova-android/ >>>>>>>> - http://aerogear.org/docs/guides/aerogear-push-cordova-ios/ >>>>>>>> - >>>>>>>> http://aerogear.org/docs/guides/aerogear-cordova/AerogearCordovaPush/ >>>>>>>> >>>>>>>> There is already a JIRA for that ([4]). >>>>>>>> >>>>>>>> To make it more clear (or clean?), I will remove the UPS/Push >>>>>>>> related docs from our guides ([3]) and replace all those links by a single >>>>>>>> link to the above mentioned new page (also referenced from [1]). >>>>>>>> >>>>>>>> Greetings, >>>>>>>> Matthias >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> - [1] http://aerogear.org/push/ >>>>>>>> - [2] >>>>>>>> http://docs.jboss.org/keycloak/docs/1.0-beta-3/userguide/html/index.html >>>>>>>> - [3] http://aerogear.org/docs/guides/ >>>>>>>> - [4] https://issues.jboss.org/browse/AGPUSH-805 >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Matthias Wessendorf >>>>>>>> >>>>>>>> blog: http://matthiaswessendorf.wordpress.com/ >>>>>>>> sessions: http://www.slideshare.net/mwessendorf >>>>>>>> twitter: http://twitter.com/mwessendorf >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Matthias Wessendorf >>>>>>> >>>>>>> blog: http://matthiaswessendorf.wordpress.com/ >>>>>>> sessions: http://www.slideshare.net/mwessendorf >>>>>>> twitter: http://twitter.com/mwessendorf >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Matthias Wessendorf >>>>>> >>>>>> blog: http://matthiaswessendorf.wordpress.com/ >>>>>> sessions: http://www.slideshare.net/mwessendorf >>>>>> twitter: http://twitter.com/mwessendorf >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Matthias Wessendorf >>>>> >>>>> blog: http://matthiaswessendorf.wordpress.com/ >>>>> sessions: http://www.slideshare.net/mwessendorf >>>>> twitter: http://twitter.com/mwessendorf >>>>> >>>>> _______________________________________________ >>>>> aerogear-dev mailing list >>>>> aerogear-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>> >>>> >>>> >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> >>> >>> >>> >>> -- >>> Matthias Wessendorf >>> >>> blog: http://matthiaswessendorf.wordpress.com/ >>> sessions: http://www.slideshare.net/mwessendorf >>> twitter: http://twitter.com/mwessendorf >>> >> >> >> >> -- >> Matthias Wessendorf >> >> blog: http://matthiaswessendorf.wordpress.com/ >> sessions: http://www.slideshare.net/mwessendorf >> twitter: http://twitter.com/mwessendorf >> > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140731/9d69e917/attachment-0001.html From daniel.bevenius at gmail.com Thu Jul 31 04:08:42 2014 From: daniel.bevenius at gmail.com (Daniel Bevenius) Date: Thu, 31 Jul 2014 10:08:42 +0200 Subject: [aerogear-dev] Help needed on AGPUSH-848 In-Reply-To: References: Message-ID: Oh I see. Then I'd say you'll need to change the return type to either use a custom object for the key in the map, or perhaps return a list with that came custom object. What ever makes the most sense in this use case. Makes sense? On 31 July 2014 09:39, Sebastien Blanc wrote: > Well, several VariantMetricInformation instances can have the same > VariantID, at each send , one is created : > https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/push%2Fsrc%2Fmain%2Fjava%2Forg%2Fjboss%2Faerogear%2Funifiedpush%2Fmessage%2FSenderServiceImpl.java#L133 > > > > On Thu, Jul 31, 2014 at 9:34 AM, Daniel Bevenius < > daniel.bevenius at gmail.com> wrote: > >> Is this because variantFour and variantFive have the same variantId >> (231543432434)? When added to the map only one will exist later >> in findTopThreeBusyVariantIDs. >> >> >> >> >> >> On 31 July 2014 09:20, Sebastien Blanc wrote: >> >>> Morning Peeps, >>> >>> I'm currently trying to fix AGPUSH-848[1]. >>> Basically, the number of receivers shown in the top3 list is not always >>> accurate. >>> >>> I suspect that something is wrong with this query : >>> >>> >>> https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/model/jpa/src/main/java/org/jboss/aerogear/unifiedpush/jpa/dao/impl/JPAPushMessageInformationDao.java#L99-L104 >>> >>> I have change this test case : >>> >>> https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/model%2Fjpa%2Fsrc%2Ftest%2Fjava%2Forg%2Fjboss%2Faerogear%2Funifiedpush%2Fjpa%2FPushMessageInformationDaoTest.java#L251 >>> >>> By adding just one VariantInformation[2] and now the test is failing and >>> I have no idea why, so I would aprreciate a second eye on this. >>> >>> I'm probably missing something obvious but I can not see it right now :) >>> >>> Sebi >>> >>> >>> [1]https://issues.jboss.org/browse/AGPUSH-848 >>> [2] >>> https://gist.github.com/sebastienblanc/ea34e7f9fdafbc0785f2#file-gistfile1-java-L30-L35 >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140731/658c62fe/attachment.html From scm.blanc at gmail.com Thu Jul 31 04:39:43 2014 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Thu, 31 Jul 2014 10:39:43 +0200 Subject: [aerogear-dev] Help needed on AGPUSH-848 In-Reply-To: References: Message-ID: Hi Dan, Not sure if I understand exactly what you meant, could do a small snippet ? On Thu, Jul 31, 2014 at 10:08 AM, Daniel Bevenius wrote: > Oh I see. Then I'd say you'll need to change the return type to either use > a custom object for the key in the map, or perhaps return a list with that > came custom object. What ever makes the most sense in this use case. Makes > sense? > > > On 31 July 2014 09:39, Sebastien Blanc wrote: > >> Well, several VariantMetricInformation instances can have the same >> VariantID, at each send , one is created : >> https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/push%2Fsrc%2Fmain%2Fjava%2Forg%2Fjboss%2Faerogear%2Funifiedpush%2Fmessage%2FSenderServiceImpl.java#L133 >> >> >> >> On Thu, Jul 31, 2014 at 9:34 AM, Daniel Bevenius < >> daniel.bevenius at gmail.com> wrote: >> >>> Is this because variantFour and variantFive have the same variantId >>> (231543432434)? When added to the map only one will exist later >>> in findTopThreeBusyVariantIDs. >>> >>> >>> >>> >>> >>> On 31 July 2014 09:20, Sebastien Blanc wrote: >>> >>>> Morning Peeps, >>>> >>>> I'm currently trying to fix AGPUSH-848[1]. >>>> Basically, the number of receivers shown in the top3 list is not always >>>> accurate. >>>> >>>> I suspect that something is wrong with this query : >>>> >>>> >>>> https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/model/jpa/src/main/java/org/jboss/aerogear/unifiedpush/jpa/dao/impl/JPAPushMessageInformationDao.java#L99-L104 >>>> >>>> I have change this test case : >>>> >>>> https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/model%2Fjpa%2Fsrc%2Ftest%2Fjava%2Forg%2Fjboss%2Faerogear%2Funifiedpush%2Fjpa%2FPushMessageInformationDaoTest.java#L251 >>>> >>>> By adding just one VariantInformation[2] and now the test is failing >>>> and I have no idea why, so I would aprreciate a second eye on this. >>>> >>>> I'm probably missing something obvious but I can not see it right now :) >>>> >>>> Sebi >>>> >>>> >>>> [1]https://issues.jboss.org/browse/AGPUSH-848 >>>> [2] >>>> https://gist.github.com/sebastienblanc/ea34e7f9fdafbc0785f2#file-gistfile1-java-L30-L35 >>>> >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> >>> >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140731/550e2147/attachment.html From daniel.bevenius at gmail.com Thu Jul 31 04:47:34 2014 From: daniel.bevenius at gmail.com (Daniel Bevenius) Date: Thu, 31 Jul 2014 10:47:34 +0200 Subject: [aerogear-dev] Help needed on AGPUSH-848 In-Reply-To: References: Message-ID: Hey Seb, sure let me take a closer look at this. I'm getting the feeling that it might not be as simple as that. Let me push something and we can discuss it. On 31 July 2014 10:39, Sebastien Blanc wrote: > Hi Dan, > Not sure if I understand exactly what you meant, could do a small snippet > ? > > > > On Thu, Jul 31, 2014 at 10:08 AM, Daniel Bevenius < > daniel.bevenius at gmail.com> wrote: > >> Oh I see. Then I'd say you'll need to change the return type to either >> use a custom object for the key in the map, or perhaps return a list with >> that came custom object. What ever makes the most sense in this use case. >> Makes sense? >> >> >> On 31 July 2014 09:39, Sebastien Blanc wrote: >> >>> Well, several VariantMetricInformation instances can have the same >>> VariantID, at each send , one is created : >>> https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/push%2Fsrc%2Fmain%2Fjava%2Forg%2Fjboss%2Faerogear%2Funifiedpush%2Fmessage%2FSenderServiceImpl.java#L133 >>> >>> >>> >>> On Thu, Jul 31, 2014 at 9:34 AM, Daniel Bevenius < >>> daniel.bevenius at gmail.com> wrote: >>> >>>> Is this because variantFour and variantFive have the same variantId >>>> (231543432434)? When added to the map only one will exist later >>>> in findTopThreeBusyVariantIDs. >>>> >>>> >>>> >>>> >>>> >>>> On 31 July 2014 09:20, Sebastien Blanc wrote: >>>> >>>>> Morning Peeps, >>>>> >>>>> I'm currently trying to fix AGPUSH-848[1]. >>>>> Basically, the number of receivers shown in the top3 list is not >>>>> always accurate. >>>>> >>>>> I suspect that something is wrong with this query : >>>>> >>>>> >>>>> https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/model/jpa/src/main/java/org/jboss/aerogear/unifiedpush/jpa/dao/impl/JPAPushMessageInformationDao.java#L99-L104 >>>>> >>>>> I have change this test case : >>>>> >>>>> https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/model%2Fjpa%2Fsrc%2Ftest%2Fjava%2Forg%2Fjboss%2Faerogear%2Funifiedpush%2Fjpa%2FPushMessageInformationDaoTest.java#L251 >>>>> >>>>> By adding just one VariantInformation[2] and now the test is failing >>>>> and I have no idea why, so I would aprreciate a second eye on this. >>>>> >>>>> I'm probably missing something obvious but I can not see it right now >>>>> :) >>>>> >>>>> Sebi >>>>> >>>>> >>>>> [1]https://issues.jboss.org/browse/AGPUSH-848 >>>>> [2] >>>>> https://gist.github.com/sebastienblanc/ea34e7f9fdafbc0785f2#file-gistfile1-java-L30-L35 >>>>> >>>>> _______________________________________________ >>>>> aerogear-dev mailing list >>>>> aerogear-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>> >>>> >>>> >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> >>> >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140731/200ac01d/attachment-0001.html From matzew at apache.org Thu Jul 31 05:11:25 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Thu, 31 Jul 2014 11:11:25 +0200 Subject: [aerogear-dev] Modularizing the Android Library In-Reply-To: References: <4CD71A7A-EDE1-4648-AB3E-E4DDB383D824@gmail.com> <20140722150611.GA58163@abstractj.org> <53D280B2.4070100@redhat.com> <20140725171611.GC26186@abstractj.org> <20140725172551.GD26186@abstractj.org> <20140725190100.GA1461@abstractj.org> <53D65352.3040203@redhat.com> <20140728140955.GB43110@abstractj.org> Message-ID: Done! I created these repos, added the required team for us to push and enabled the webhooks. However, no Travis atm, since there is no code, yet... On Wed, Jul 30, 2014 at 3:40 PM, Matthias Wessendorf wrote: > FYI, > here is a JIRA that passos created for those repos: > > https://issues.jboss.org/browse/AEROGEAR-1479 > > > -M > > > > > > On Mon, Jul 28, 2014 at 4:23 PM, Corinne Krych > wrote: > >> @abstractj @summers what about being more specific and naming >> ag-android-authz as ag-android-oauth2? This will be without confusion. >> For now we only implement oauth2. If we need oauth1a impl we can have a >> separate module. wdyt? >> This is the way i?d like to go for iOS lib. >> >> With Oauth2 you do need authentication but as it?s taken care of by the >> oauth2 provider, client side lib does not need a ?login? method, this >> indeed why we need auth module is different to authz one. >> >> ++ >> Corinne >> >> On 28 Jul 2014, at 16:09, Bruno Oliveira wrote: >> >> > Answers inline. >> > >> > On 2014-07-28, Summers Pittman wrote: >> >> On 07/25/2014 03:01 PM, Bruno Oliveira wrote: >> >>> On 2014-07-25, Lucas Holmquist wrote: >> >>>> On Jul 25, 2014, at 1:25 PM, Bruno Oliveira >> wrote: >> >>>> >> >>>>> On 2014-07-25, Lucas Holmquist wrote: >> >>>>>> On Jul 25, 2014, at 1:16 PM, Bruno Oliveira >> wrote: >> >>>>>> >> >>>>>>> On 2014-07-25, Summers Pittman wrote: >> >>>>>>>> On 07/22/2014 11:06 AM, Bruno Oliveira wrote: >> >>>>>>>>> Passos, what does aerogear-android-security stands for? Do we >> really >> >>>>>>>>> need the authz module? My question is due to the fact that >> mostly it >> >>>>>>>>> will be together with auth module, but I could be wrong. >> >>>>>>>> You are wrong :) >> >>>>>>> Do you have authorization without authentication? Or >> authentication with >> >>>>>>> no authorization? >> >>>>>> We have this in our JS lib, the Authenitcation module, just does >> the login/logout/enroll >> >>>>>> >> >>>>>> and the Authz module doesn?t rely on it, but connects to 3rd party >> OAuth2( the current adapter ) providers >> >>>>> If it connects using a Token from a 3rd party service, is because >> it's based on some credential. So, >> >>>>> I assume that you have authentication AND authorization, there's no >> magic ;) >> >>>>> >> >>>>> Either way, name it to whatever you guys think is the best. >> >>>> yea, the names can be confusing here :). we should rename to >> ?CoolSuperAwesomeThing? and ?bob? :) >> >>> As long as you do at your own repository, I'm ok. Meanwhile let's not >> >>> mix the concept of OAuth2 with authorization only. >> >> OAuth2 is an implementation of Authorization. We have Jira's for >> >> OAuth1a, alternate work flows etc. >> > >> > Summers, there's no authorization without authentication before. Even >> > with OAuth2 the client make use of the Bearer authentication scheme for >> > example. >> > >> > If you assume that OAuth2 is authorization only, would be the same of >> > assume that once my application is authorized on Twitter, I should be >> able >> > to access many profiles as I want. >> > >> > Even if IETF says "The OAuth 2.0 Authorization Framework: Bearer Token >> > Usage". >> > >> >> >> >> A better way to think about it would be the auth module is user visible >> >> credential authentication and authorization. The authz module is third >> >> party authentication and authorization.a >> > >> > authz into any security context stands for "authorization", if you mix >> > both concepts here, people will get confused. >> > >> >> >> >> A while ago we did discuss revisiting authz/auth and see if they can be >> >> meaningfully merged. This may be something for a different thread. As >> >> it stands they don't make sense to be in the same module because they >> >> work differently for different use cases. >> > >> > As I said, I trust in your judgment, but mix concepts will lead to >> > confusion. >> > >> >> >> >>> >> >>>>>> >> >>>>>>>> In general >> >>>>>>>> >> >>>>>>>> Auth module consumes a username and password and manages a >> session. >> >>>>>>>> Authz fetches and consumers tokens and manages them through a >> >>>>>>>> android.app.Service service. >> >>>>>>>>> On 2014-07-22, Daniel Passos wrote: >> >>>>>>>>>> Hey Guys, >> >>>>>>>>>> >> >>>>>>>>>> Summers and I started working on agdroid modules and remove >> some cyclic >> >>>>>>>>>> dependencies. So we plan to split the agdroid on these modules: >> >>>>>>>>>> >> >>>>>>>>>> - aerogear-android-core >> >>>>>>>>>> - aerogear-android-pipe >> >>>>>>>>>> - aerogear-android-auth >> >>>>>>>>>> - aerogear-android-autz >> >>>>>>>>>> - aerogear-android-store (with option security dependecy to >> use >> >>>>>>>>>> EncryptedStores) >> >>>>>>>>>> - aerogear-android-security >> >>>>>>>>>> - aerogear-android-push >> >>>>>>>>>> - aerogear-android-push-ups >> >>>>>>>>>> - aerogear-android-offline >> >>>>>>>>>> >> >>>>>>>>>> -- Passos >> >>>>>>>>>> ? >> >>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>>> On Fri, May 9, 2014 at 3:55 AM, Corinne Krych < >> corinnekrych at gmail.com> >> >>>>>>>>>> wrote: >> >>>>>>>>>> >> >>>>>>>>>>> Oops >> >>>>>>>>>>> [2] https://issues.jboss.org/browse/AGIOS-187 >> >>>>>>>>>>> >> >>>>>>>>>>> On 09 May 2014, at 08:52, Corinne Krych < >> corinnekrych at gmail.com> wrote: >> >>>>>>>>>>> >> >>>>>>>>>>>> [2] https://issues.jboss.org/browse/AGIOS-192 >> >>>>>>>>>>> _______________________________________________ >> >>>>>>>>>>> aerogear-dev mailing list >> >>>>>>>>>>> aerogear-dev at lists.jboss.org >> >>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >>>>>>>>>>> >> >>>>>>>>>> _______________________________________________ >> >>>>>>>>>> aerogear-dev mailing list >> >>>>>>>>>> aerogear-dev at lists.jboss.org >> >>>>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >>>>>>>>> -- >> >>>>>>>>> >> >>>>>>>>> abstractj >> >>>>>>>>> PGP: 0x84DC9914 >> >>>>>>>>> _______________________________________________ >> >>>>>>>>> aerogear-dev mailing list >> >>>>>>>>> aerogear-dev at lists.jboss.org >> >>>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >>>>>>>> >> >>>>>>>> -- >> >>>>>>>> Summers Pittman >> >>>>>>>>>> Phone:404 941 4698 >> >>>>>>>>>> Java is my crack. >> >>>>>>>> _______________________________________________ >> >>>>>>>> aerogear-dev mailing list >> >>>>>>>> aerogear-dev at lists.jboss.org >> >>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >>>>>>> -- >> >>>>>>> >> >>>>>>> abstractj >> >>>>>>> PGP: 0x84DC9914 >> >>>>>>> _______________________________________________ >> >>>>>>> aerogear-dev mailing list >> >>>>>>> aerogear-dev at lists.jboss.org >> >>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >>>>>> _______________________________________________ >> >>>>>> aerogear-dev mailing list >> >>>>>> aerogear-dev at lists.jboss.org >> >>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >>>>> >> >>>>> -- >> >>>>> >> >>>>> abstractj >> >>>>> PGP: 0x84DC9914 >> >>>>> _______________________________________________ >> >>>>> aerogear-dev mailing list >> >>>>> aerogear-dev at lists.jboss.org >> >>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >>>> _______________________________________________ >> >>>> aerogear-dev mailing list >> >>>> aerogear-dev at lists.jboss.org >> >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >>> >> >>> -- >> >>> >> >>> abstractj >> >>> PGP: 0x84DC9914 >> >>> _______________________________________________ >> >>> aerogear-dev mailing list >> >>> aerogear-dev at lists.jboss.org >> >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> >> >> >> -- >> >> Summers Pittman >> >>>> Phone:404 941 4698 >> >>>> Java is my crack. >> >> >> >> _______________________________________________ >> >> aerogear-dev mailing list >> >> aerogear-dev at lists.jboss.org >> >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > >> > -- >> > >> > abstractj >> > PGP: 0x84DC9914 >> > _______________________________________________ >> > aerogear-dev mailing list >> > aerogear-dev at lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140731/9a079cb2/attachment.html From daniel.bevenius at gmail.com Thu Jul 31 05:31:43 2014 From: daniel.bevenius at gmail.com (Daniel Bevenius) Date: Thu, 31 Jul 2014 11:31:43 +0200 Subject: [aerogear-dev] Help needed on AGPUSH-848 In-Reply-To: References: Message-ID: Sorry, looking into this and I can't see any easy fix. The problem as I see it is that the for the same variantId there can be multiple receivers. But we currently don't know which ApplicationVariant the receivers belong to. So we cannot match them up in DashBoardService. This my first time looking at the code so I might be missing something. So I'd say your first post about the query being wrong is correct, and we have to take the match the VariantMetricInformation and match it with a pushApplicationId. Again, I could be way off here :) On 31 July 2014 10:47, Daniel Bevenius wrote: > Hey Seb, > > sure let me take a closer look at this. I'm getting the feeling that it > might not be as simple as that. Let me push something and we can discuss it. > > > > > On 31 July 2014 10:39, Sebastien Blanc wrote: > >> Hi Dan, >> Not sure if I understand exactly what you meant, could do a small snippet >> ? >> >> >> >> On Thu, Jul 31, 2014 at 10:08 AM, Daniel Bevenius < >> daniel.bevenius at gmail.com> wrote: >> >>> Oh I see. Then I'd say you'll need to change the return type to either >>> use a custom object for the key in the map, or perhaps return a list with >>> that came custom object. What ever makes the most sense in this use case. >>> Makes sense? >>> >>> >>> On 31 July 2014 09:39, Sebastien Blanc wrote: >>> >>>> Well, several VariantMetricInformation instances can have the same >>>> VariantID, at each send , one is created : >>>> https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/push%2Fsrc%2Fmain%2Fjava%2Forg%2Fjboss%2Faerogear%2Funifiedpush%2Fmessage%2FSenderServiceImpl.java#L133 >>>> >>>> >>>> >>>> On Thu, Jul 31, 2014 at 9:34 AM, Daniel Bevenius < >>>> daniel.bevenius at gmail.com> wrote: >>>> >>>>> Is this because variantFour and variantFive have the same variantId >>>>> (231543432434)? When added to the map only one will exist later >>>>> in findTopThreeBusyVariantIDs. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On 31 July 2014 09:20, Sebastien Blanc wrote: >>>>> >>>>>> Morning Peeps, >>>>>> >>>>>> I'm currently trying to fix AGPUSH-848[1]. >>>>>> Basically, the number of receivers shown in the top3 list is not >>>>>> always accurate. >>>>>> >>>>>> I suspect that something is wrong with this query : >>>>>> >>>>>> >>>>>> https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/model/jpa/src/main/java/org/jboss/aerogear/unifiedpush/jpa/dao/impl/JPAPushMessageInformationDao.java#L99-L104 >>>>>> >>>>>> I have change this test case : >>>>>> >>>>>> https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/model%2Fjpa%2Fsrc%2Ftest%2Fjava%2Forg%2Fjboss%2Faerogear%2Funifiedpush%2Fjpa%2FPushMessageInformationDaoTest.java#L251 >>>>>> >>>>>> By adding just one VariantInformation[2] and now the test is failing >>>>>> and I have no idea why, so I would aprreciate a second eye on this. >>>>>> >>>>>> I'm probably missing something obvious but I can not see it right now >>>>>> :) >>>>>> >>>>>> Sebi >>>>>> >>>>>> >>>>>> [1]https://issues.jboss.org/browse/AGPUSH-848 >>>>>> [2] >>>>>> https://gist.github.com/sebastienblanc/ea34e7f9fdafbc0785f2#file-gistfile1-java-L30-L35 >>>>>> >>>>>> _______________________________________________ >>>>>> aerogear-dev mailing list >>>>>> aerogear-dev at lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> aerogear-dev mailing list >>>>> aerogear-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>> >>>> >>>> >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> >>> >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140731/b2930370/attachment-0001.html From matzew at apache.org Thu Jul 31 05:35:52 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Thu, 31 Jul 2014 11:35:52 +0200 Subject: [aerogear-dev] AG Site and new section In-Reply-To: <20140731074904.GA19958@abstractj.org> References: <20140730185838.GA9505@abstractj.org> <20140730231208.GI88071@darkstar.local> <20140731074904.GA19958@abstractj.org> Message-ID: *thinking* On Thu, Jul 31, 2014 at 9:49 AM, Bruno Oliveira wrote: > Good morning qmx, > > I'm all for suggestions, server side bits made sense in the past, today > with Keycloak, not anymore. > > Also, most of our security bits are covered per platform, for example AG > Crypto at iOS, JS, Cordova and Android documentation ? I would like to > avoid duplication. > > I'm all for an education material, not sure if we should name it > "AeroGear Security". > Learn about AeroGear's mobile security (vision?) --> LINK TO 'SOME PAGE' 'SOME PAGE' could be a langing page, that lists the different approaches = Mobile Client Security AeroGear Crypto supports X,Y,Z on different platforms: * Android (Link to the Android AG-Crypto usage page/doc) * Apache Cordova (Link to the Cordova AG-Crypto usage page/doc) * iOS (Link to the iOS AG-Crypto usage page/doc) = Server Security (for Mobile Clients?) * LINK to Keycloak (+ a refernece to the UPS?) * Link to PicketLink? (could also include a link to the 'mobile-contacts' quickstart ) Now I wnder if we could/should also include the current OAth2 efforts of our team on such "Mobile Security" page -Matthias > > On 2014-07-30, Douglas Campos wrote: > > On Wed, Jul 30, 2014 at 03:58:38PM -0300, Bruno Oliveira wrote: > > > Good morning peeps, as you know, AG Security was deprecated, but we > > > still have references on AeroGear site > > > http://staging.aerogear.org/docs/guides/aerogear-security/. Probably a > > > bad rebase, once it was already removed here: > > > https://github.com/aerogear/aerogear.org/pull/287/files ? > > > > > > Atm I'm looking for volunteers to replace this section at the main page > > > or suggestions about how to improve it. Please see: > http://staging.aerogear.org. > > > > > > "Mobility and security, both > > > > > > Integrate with your existing enterprise environment. AeroGear provides > > > Two-Factor Authentication and One-Time-Password features to improve > your > > > application's security. > > > > > > Learn about AeroGear Security" > > What message are we trying to convey here? Do we want to fill the void > > left by AeroGear Security with educational material (like "use keycloak > > for this") or are we going to just yank all references? > > > > > > > > Suggestions are welcome. > > > > > > -- > > > > > > abstractj > > > PGP: 0x84DC9914 > > > _______________________________________________ > > > aerogear-dev mailing list > > > aerogear-dev at lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > -- > > qmx > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > -- > > abstractj > PGP: 0x84DC9914 > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140731/999e81ef/attachment.html From scm.blanc at gmail.com Thu Jul 31 05:42:46 2014 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Thu, 31 Jul 2014 11:42:46 +0200 Subject: [aerogear-dev] Help needed on AGPUSH-848 In-Reply-To: References: Message-ID: BTW, I wonder how we had in mind the computing of the 3 busiest variants, what does it mean exactly ? Should we not sum up all the receiver for each VariantMetricInformation and from there get the top 3 ? Not sure this is happening right now, maybe @matzew or @edewit could give more info. On Thu, Jul 31, 2014 at 11:31 AM, Daniel Bevenius wrote: > Sorry, looking into this and I can't see any easy fix. > The problem as I see it is that the for the same variantId there can be > multiple receivers. But we currently don't know which ApplicationVariant > the receivers belong to. So we cannot match them up in DashBoardService. > This my first time looking at the code so I might be missing something. So > I'd say your first post about the query being wrong is correct, and we have > to take the match the VariantMetricInformation and match it with a > pushApplicationId. Again, I could be way off here :) > > > > > On 31 July 2014 10:47, Daniel Bevenius wrote: > >> Hey Seb, >> >> sure let me take a closer look at this. I'm getting the feeling that it >> might not be as simple as that. Let me push something and we can discuss it. >> >> >> >> >> On 31 July 2014 10:39, Sebastien Blanc wrote: >> >>> Hi Dan, >>> Not sure if I understand exactly what you meant, could do a small >>> snippet ? >>> >>> >>> >>> On Thu, Jul 31, 2014 at 10:08 AM, Daniel Bevenius < >>> daniel.bevenius at gmail.com> wrote: >>> >>>> Oh I see. Then I'd say you'll need to change the return type to either >>>> use a custom object for the key in the map, or perhaps return a list with >>>> that came custom object. What ever makes the most sense in this use case. >>>> Makes sense? >>>> >>>> >>>> On 31 July 2014 09:39, Sebastien Blanc wrote: >>>> >>>>> Well, several VariantMetricInformation instances can have the same >>>>> VariantID, at each send , one is created : >>>>> https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/push%2Fsrc%2Fmain%2Fjava%2Forg%2Fjboss%2Faerogear%2Funifiedpush%2Fmessage%2FSenderServiceImpl.java#L133 >>>>> >>>>> >>>>> >>>>> On Thu, Jul 31, 2014 at 9:34 AM, Daniel Bevenius < >>>>> daniel.bevenius at gmail.com> wrote: >>>>> >>>>>> Is this because variantFour and variantFive have the same variantId >>>>>> (231543432434)? When added to the map only one will exist later >>>>>> in findTopThreeBusyVariantIDs. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On 31 July 2014 09:20, Sebastien Blanc wrote: >>>>>> >>>>>>> Morning Peeps, >>>>>>> >>>>>>> I'm currently trying to fix AGPUSH-848[1]. >>>>>>> Basically, the number of receivers shown in the top3 list is not >>>>>>> always accurate. >>>>>>> >>>>>>> I suspect that something is wrong with this query : >>>>>>> >>>>>>> >>>>>>> https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/model/jpa/src/main/java/org/jboss/aerogear/unifiedpush/jpa/dao/impl/JPAPushMessageInformationDao.java#L99-L104 >>>>>>> >>>>>>> I have change this test case : >>>>>>> >>>>>>> https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/model%2Fjpa%2Fsrc%2Ftest%2Fjava%2Forg%2Fjboss%2Faerogear%2Funifiedpush%2Fjpa%2FPushMessageInformationDaoTest.java#L251 >>>>>>> >>>>>>> By adding just one VariantInformation[2] and now the test is failing >>>>>>> and I have no idea why, so I would aprreciate a second eye on this. >>>>>>> >>>>>>> I'm probably missing something obvious but I can not see it right >>>>>>> now :) >>>>>>> >>>>>>> Sebi >>>>>>> >>>>>>> >>>>>>> [1]https://issues.jboss.org/browse/AGPUSH-848 >>>>>>> [2] >>>>>>> https://gist.github.com/sebastienblanc/ea34e7f9fdafbc0785f2#file-gistfile1-java-L30-L35 >>>>>>> >>>>>>> _______________________________________________ >>>>>>> aerogear-dev mailing list >>>>>>> aerogear-dev at lists.jboss.org >>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> aerogear-dev mailing list >>>>>> aerogear-dev at lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> aerogear-dev mailing list >>>>> aerogear-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>> >>>> >>>> >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> >>> >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >> >> > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140731/fae562ce/attachment.html From bruno at abstractj.org Thu Jul 31 06:05:39 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Thu, 31 Jul 2014 07:05:39 -0300 Subject: [aerogear-dev] New release of Cordova Push Plugin ? In-Reply-To: References: Message-ID: <20140731100539.GA24892@abstractj.org> Do we have a roadmap and the release date for 0.7.0? The roadmap[1] is not totally clear to me. [1] - http://staging.aerogear.org/docs/planning/roadmaps/AeroGearCordova/ On 2014-07-29, Matthias Wessendorf wrote: > Hi, > > looked at the change log of the Cordova Plugin and there were some fixes > since the last 0.6.0 release. > > Before we run the Beta2 of UPS (around 6th of August, depends a bit on > Keycloak's beta4) I'd like to get a 0.7.0 release out. > > Any thoughts? > > Thanks, > Matthias > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -- abstractj PGP: 0x84DC9914 From matzew at apache.org Thu Jul 31 06:11:00 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Thu, 31 Jul 2014 12:11:00 +0200 Subject: [aerogear-dev] New release of Cordova Push Plugin ? In-Reply-To: <20140731100539.GA24892@abstractj.org> References: <20140731100539.GA24892@abstractj.org> Message-ID: On Thu, Jul 31, 2014 at 12:05 PM, Bruno Oliveira wrote: > Do we have a roadmap and the release date for 0.7.0? I was hoping to get a 0.7.0 release by the time of our UPS-1.0.0.Beta2. > The roadmap[1] is > not totally clear to me. > the 1.0.0 of the lib, should be aligned w/ the UPS 1.0.0.Final ( http://staging.aerogear.org/docs/planning/roadmaps/UnifiedPush/#_1_0_0_final_mid_august_2014 ) > > > [1] - > http://staging.aerogear.org/docs/planning/roadmaps/AeroGearCordova/ > > On 2014-07-29, Matthias Wessendorf wrote: > > Hi, > > > > looked at the change log of the Cordova Plugin and there were some fixes > > since the last 0.6.0 release. > > > > Before we run the Beta2 of UPS (around 6th of August, depends a bit on > > Keycloak's beta4) I'd like to get a 0.7.0 release out. > > > > Any thoughts? > > > > Thanks, > > Matthias > > > > -- > > Matthias Wessendorf > > > > blog: http://matthiaswessendorf.wordpress.com/ > > sessions: http://www.slideshare.net/mwessendorf > > twitter: http://twitter.com/mwessendorf > > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > -- > > abstractj > PGP: 0x84DC9914 > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140731/e8adaf38/attachment.html From matzew at apache.org Thu Jul 31 06:12:08 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Thu, 31 Jul 2014 12:12:08 +0200 Subject: [aerogear-dev] Help needed on AGPUSH-848 In-Reply-To: References: Message-ID: I think original idea was to show the three most busy (in number of receives, not installations) On Thu, Jul 31, 2014 at 11:42 AM, Sebastien Blanc wrote: > BTW, > I wonder how we had in mind the computing of the 3 busiest variants, what > does it mean exactly ? > Should we not sum up all the receiver for each VariantMetricInformation > and from there get the top 3 ? Not sure this is happening right now, maybe > @matzew or @edewit could give more info. > > > > On Thu, Jul 31, 2014 at 11:31 AM, Daniel Bevenius < > daniel.bevenius at gmail.com> wrote: > >> Sorry, looking into this and I can't see any easy fix. >> The problem as I see it is that the for the same variantId there can be >> multiple receivers. But we currently don't know which ApplicationVariant >> the receivers belong to. So we cannot match them up in DashBoardService. >> This my first time looking at the code so I might be missing something. >> So I'd say your first post about the query being wrong is correct, and we >> have to take the match the VariantMetricInformation and match it with a >> pushApplicationId. Again, I could be way off here :) >> >> >> >> >> On 31 July 2014 10:47, Daniel Bevenius wrote: >> >>> Hey Seb, >>> >>> sure let me take a closer look at this. I'm getting the feeling that it >>> might not be as simple as that. Let me push something and we can discuss it. >>> >>> >>> >>> >>> On 31 July 2014 10:39, Sebastien Blanc wrote: >>> >>>> Hi Dan, >>>> Not sure if I understand exactly what you meant, could do a small >>>> snippet ? >>>> >>>> >>>> >>>> On Thu, Jul 31, 2014 at 10:08 AM, Daniel Bevenius < >>>> daniel.bevenius at gmail.com> wrote: >>>> >>>>> Oh I see. Then I'd say you'll need to change the return type to either >>>>> use a custom object for the key in the map, or perhaps return a list with >>>>> that came custom object. What ever makes the most sense in this use case. >>>>> Makes sense? >>>>> >>>>> >>>>> On 31 July 2014 09:39, Sebastien Blanc wrote: >>>>> >>>>>> Well, several VariantMetricInformation instances can have the same >>>>>> VariantID, at each send , one is created : >>>>>> https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/push%2Fsrc%2Fmain%2Fjava%2Forg%2Fjboss%2Faerogear%2Funifiedpush%2Fmessage%2FSenderServiceImpl.java#L133 >>>>>> >>>>>> >>>>>> >>>>>> On Thu, Jul 31, 2014 at 9:34 AM, Daniel Bevenius < >>>>>> daniel.bevenius at gmail.com> wrote: >>>>>> >>>>>>> Is this because variantFour and variantFive have the same variantId >>>>>>> (231543432434)? When added to the map only one will exist later >>>>>>> in findTopThreeBusyVariantIDs. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 31 July 2014 09:20, Sebastien Blanc wrote: >>>>>>> >>>>>>>> Morning Peeps, >>>>>>>> >>>>>>>> I'm currently trying to fix AGPUSH-848[1]. >>>>>>>> Basically, the number of receivers shown in the top3 list is not >>>>>>>> always accurate. >>>>>>>> >>>>>>>> I suspect that something is wrong with this query : >>>>>>>> >>>>>>>> >>>>>>>> https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/model/jpa/src/main/java/org/jboss/aerogear/unifiedpush/jpa/dao/impl/JPAPushMessageInformationDao.java#L99-L104 >>>>>>>> >>>>>>>> I have change this test case : >>>>>>>> >>>>>>>> https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/model%2Fjpa%2Fsrc%2Ftest%2Fjava%2Forg%2Fjboss%2Faerogear%2Funifiedpush%2Fjpa%2FPushMessageInformationDaoTest.java#L251 >>>>>>>> >>>>>>>> By adding just one VariantInformation[2] and now the test is >>>>>>>> failing and I have no idea why, so I would aprreciate a second eye on this. >>>>>>>> >>>>>>>> I'm probably missing something obvious but I can not see it right >>>>>>>> now :) >>>>>>>> >>>>>>>> Sebi >>>>>>>> >>>>>>>> >>>>>>>> [1]https://issues.jboss.org/browse/AGPUSH-848 >>>>>>>> [2] >>>>>>>> https://gist.github.com/sebastienblanc/ea34e7f9fdafbc0785f2#file-gistfile1-java-L30-L35 >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> aerogear-dev mailing list >>>>>>>> aerogear-dev at lists.jboss.org >>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> aerogear-dev mailing list >>>>>>> aerogear-dev at lists.jboss.org >>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> aerogear-dev mailing list >>>>>> aerogear-dev at lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> aerogear-dev mailing list >>>>> aerogear-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>> >>>> >>>> >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> >>> >>> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140731/a8879732/attachment.html From daniel.bevenius at gmail.com Thu Jul 31 07:24:34 2014 From: daniel.bevenius at gmail.com (Daniel Bevenius) Date: Thu, 31 Jul 2014 13:24:34 +0200 Subject: [aerogear-dev] Help needed on AGPUSH-848 In-Reply-To: References: Message-ID: @Seb I've pushed a suggestion for working around this [1] which might be something to build upon. I've not tested this using the admin-ui though. [1] https://github.com/danbev/aerogear-unified-push-server/commit/0cc53784e422ee751495655f63a9fa98d14c7c3c On 31 July 2014 12:12, Matthias Wessendorf wrote: > I think original idea was to show the three most busy (in number of > receives, not installations) > > > > > On Thu, Jul 31, 2014 at 11:42 AM, Sebastien Blanc > wrote: > >> BTW, >> I wonder how we had in mind the computing of the 3 busiest variants, what >> does it mean exactly ? >> Should we not sum up all the receiver for each VariantMetricInformation >> and from there get the top 3 ? Not sure this is happening right now, maybe >> @matzew or @edewit could give more info. >> >> >> >> On Thu, Jul 31, 2014 at 11:31 AM, Daniel Bevenius < >> daniel.bevenius at gmail.com> wrote: >> >>> Sorry, looking into this and I can't see any easy fix. >>> The problem as I see it is that the for the same variantId there can be >>> multiple receivers. But we currently don't know which ApplicationVariant >>> the receivers belong to. So we cannot match them up in DashBoardService. >>> This my first time looking at the code so I might be missing something. >>> So I'd say your first post about the query being wrong is correct, and we >>> have to take the match the VariantMetricInformation and match it with a >>> pushApplicationId. Again, I could be way off here :) >>> >>> >>> >>> >>> On 31 July 2014 10:47, Daniel Bevenius >>> wrote: >>> >>>> Hey Seb, >>>> >>>> sure let me take a closer look at this. I'm getting the feeling that it >>>> might not be as simple as that. Let me push something and we can discuss it. >>>> >>>> >>>> >>>> >>>> On 31 July 2014 10:39, Sebastien Blanc wrote: >>>> >>>>> Hi Dan, >>>>> Not sure if I understand exactly what you meant, could do a small >>>>> snippet ? >>>>> >>>>> >>>>> >>>>> On Thu, Jul 31, 2014 at 10:08 AM, Daniel Bevenius < >>>>> daniel.bevenius at gmail.com> wrote: >>>>> >>>>>> Oh I see. Then I'd say you'll need to change the return type to >>>>>> either use a custom object for the key in the map, or perhaps return a list >>>>>> with that came custom object. What ever makes the most sense in this use >>>>>> case. Makes sense? >>>>>> >>>>>> >>>>>> On 31 July 2014 09:39, Sebastien Blanc wrote: >>>>>> >>>>>>> Well, several VariantMetricInformation instances can have the same >>>>>>> VariantID, at each send , one is created : >>>>>>> https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/push%2Fsrc%2Fmain%2Fjava%2Forg%2Fjboss%2Faerogear%2Funifiedpush%2Fmessage%2FSenderServiceImpl.java#L133 >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Thu, Jul 31, 2014 at 9:34 AM, Daniel Bevenius < >>>>>>> daniel.bevenius at gmail.com> wrote: >>>>>>> >>>>>>>> Is this because variantFour and variantFive have the same variantId >>>>>>>> (231543432434)? When added to the map only one will exist later >>>>>>>> in findTopThreeBusyVariantIDs. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 31 July 2014 09:20, Sebastien Blanc wrote: >>>>>>>> >>>>>>>>> Morning Peeps, >>>>>>>>> >>>>>>>>> I'm currently trying to fix AGPUSH-848[1]. >>>>>>>>> Basically, the number of receivers shown in the top3 list is not >>>>>>>>> always accurate. >>>>>>>>> >>>>>>>>> I suspect that something is wrong with this query : >>>>>>>>> >>>>>>>>> >>>>>>>>> https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/model/jpa/src/main/java/org/jboss/aerogear/unifiedpush/jpa/dao/impl/JPAPushMessageInformationDao.java#L99-L104 >>>>>>>>> >>>>>>>>> I have change this test case : >>>>>>>>> >>>>>>>>> https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/model%2Fjpa%2Fsrc%2Ftest%2Fjava%2Forg%2Fjboss%2Faerogear%2Funifiedpush%2Fjpa%2FPushMessageInformationDaoTest.java#L251 >>>>>>>>> >>>>>>>>> By adding just one VariantInformation[2] and now the test is >>>>>>>>> failing and I have no idea why, so I would aprreciate a second eye on this. >>>>>>>>> >>>>>>>>> I'm probably missing something obvious but I can not see it right >>>>>>>>> now :) >>>>>>>>> >>>>>>>>> Sebi >>>>>>>>> >>>>>>>>> >>>>>>>>> [1]https://issues.jboss.org/browse/AGPUSH-848 >>>>>>>>> [2] >>>>>>>>> https://gist.github.com/sebastienblanc/ea34e7f9fdafbc0785f2#file-gistfile1-java-L30-L35 >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> aerogear-dev mailing list >>>>>>>>> aerogear-dev at lists.jboss.org >>>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> aerogear-dev mailing list >>>>>>>> aerogear-dev at lists.jboss.org >>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> aerogear-dev mailing list >>>>>>> aerogear-dev at lists.jboss.org >>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> aerogear-dev mailing list >>>>>> aerogear-dev at lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> aerogear-dev mailing list >>>>> aerogear-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>> >>>> >>>> >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140731/6f2012dc/attachment-0001.html From scm.blanc at gmail.com Thu Jul 31 07:28:31 2014 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Thu, 31 Jul 2014 13:28:31 +0200 Subject: [aerogear-dev] Help needed on AGPUSH-848 In-Reply-To: References: Message-ID: Awesome , let me give this a try ! On Thu, Jul 31, 2014 at 1:24 PM, Daniel Bevenius wrote: > @Seb I've pushed a suggestion for working around this [1] which might be > something to build upon. I've not tested this using the admin-ui though. > > > [1] > https://github.com/danbev/aerogear-unified-push-server/commit/0cc53784e422ee751495655f63a9fa98d14c7c3c > > > On 31 July 2014 12:12, Matthias Wessendorf wrote: > >> I think original idea was to show the three most busy (in number of >> receives, not installations) >> >> >> >> >> On Thu, Jul 31, 2014 at 11:42 AM, Sebastien Blanc >> wrote: >> >>> BTW, >>> I wonder how we had in mind the computing of the 3 busiest variants, >>> what does it mean exactly ? >>> Should we not sum up all the receiver for each VariantMetricInformation >>> and from there get the top 3 ? Not sure this is happening right now, maybe >>> @matzew or @edewit could give more info. >>> >>> >>> >>> On Thu, Jul 31, 2014 at 11:31 AM, Daniel Bevenius < >>> daniel.bevenius at gmail.com> wrote: >>> >>>> Sorry, looking into this and I can't see any easy fix. >>>> The problem as I see it is that the for the same variantId there can be >>>> multiple receivers. But we currently don't know which ApplicationVariant >>>> the receivers belong to. So we cannot match them up in DashBoardService. >>>> This my first time looking at the code so I might be missing something. >>>> So I'd say your first post about the query being wrong is correct, and we >>>> have to take the match the VariantMetricInformation and match it with a >>>> pushApplicationId. Again, I could be way off here :) >>>> >>>> >>>> >>>> >>>> On 31 July 2014 10:47, Daniel Bevenius >>>> wrote: >>>> >>>>> Hey Seb, >>>>> >>>>> sure let me take a closer look at this. I'm getting the feeling that >>>>> it might not be as simple as that. Let me push something and we can discuss >>>>> it. >>>>> >>>>> >>>>> >>>>> >>>>> On 31 July 2014 10:39, Sebastien Blanc wrote: >>>>> >>>>>> Hi Dan, >>>>>> Not sure if I understand exactly what you meant, could do a small >>>>>> snippet ? >>>>>> >>>>>> >>>>>> >>>>>> On Thu, Jul 31, 2014 at 10:08 AM, Daniel Bevenius < >>>>>> daniel.bevenius at gmail.com> wrote: >>>>>> >>>>>>> Oh I see. Then I'd say you'll need to change the return type to >>>>>>> either use a custom object for the key in the map, or perhaps return a list >>>>>>> with that came custom object. What ever makes the most sense in this use >>>>>>> case. Makes sense? >>>>>>> >>>>>>> >>>>>>> On 31 July 2014 09:39, Sebastien Blanc wrote: >>>>>>> >>>>>>>> Well, several VariantMetricInformation instances can have the same >>>>>>>> VariantID, at each send , one is created : >>>>>>>> https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/push%2Fsrc%2Fmain%2Fjava%2Forg%2Fjboss%2Faerogear%2Funifiedpush%2Fmessage%2FSenderServiceImpl.java#L133 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Thu, Jul 31, 2014 at 9:34 AM, Daniel Bevenius < >>>>>>>> daniel.bevenius at gmail.com> wrote: >>>>>>>> >>>>>>>>> Is this because variantFour and variantFive have the same >>>>>>>>> variantId (231543432434)? When added to the map only one will exist later >>>>>>>>> in findTopThreeBusyVariantIDs. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On 31 July 2014 09:20, Sebastien Blanc >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> Morning Peeps, >>>>>>>>>> >>>>>>>>>> I'm currently trying to fix AGPUSH-848[1]. >>>>>>>>>> Basically, the number of receivers shown in the top3 list is not >>>>>>>>>> always accurate. >>>>>>>>>> >>>>>>>>>> I suspect that something is wrong with this query : >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/model/jpa/src/main/java/org/jboss/aerogear/unifiedpush/jpa/dao/impl/JPAPushMessageInformationDao.java#L99-L104 >>>>>>>>>> >>>>>>>>>> I have change this test case : >>>>>>>>>> >>>>>>>>>> https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/model%2Fjpa%2Fsrc%2Ftest%2Fjava%2Forg%2Fjboss%2Faerogear%2Funifiedpush%2Fjpa%2FPushMessageInformationDaoTest.java#L251 >>>>>>>>>> >>>>>>>>>> By adding just one VariantInformation[2] and now the test is >>>>>>>>>> failing and I have no idea why, so I would aprreciate a second eye on this. >>>>>>>>>> >>>>>>>>>> I'm probably missing something obvious but I can not see it right >>>>>>>>>> now :) >>>>>>>>>> >>>>>>>>>> Sebi >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> [1]https://issues.jboss.org/browse/AGPUSH-848 >>>>>>>>>> [2] >>>>>>>>>> https://gist.github.com/sebastienblanc/ea34e7f9fdafbc0785f2#file-gistfile1-java-L30-L35 >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> aerogear-dev mailing list >>>>>>>>>> aerogear-dev at lists.jboss.org >>>>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> aerogear-dev mailing list >>>>>>>>> aerogear-dev at lists.jboss.org >>>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> aerogear-dev mailing list >>>>>>>> aerogear-dev at lists.jboss.org >>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> aerogear-dev mailing list >>>>>>> aerogear-dev at lists.jboss.org >>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> aerogear-dev mailing list >>>>>> aerogear-dev at lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>> >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> >>> >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >> >> >> >> -- >> Matthias Wessendorf >> >> blog: http://matthiaswessendorf.wordpress.com/ >> sessions: http://www.slideshare.net/mwessendorf >> twitter: http://twitter.com/mwessendorf >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140731/6a2b0a11/attachment.html From daniel.bevenius at gmail.com Thu Jul 31 07:28:52 2014 From: daniel.bevenius at gmail.com (Daniel Bevenius) Date: Thu, 31 Jul 2014 13:28:52 +0200 Subject: [aerogear-dev] New docs got merged (was: Re: Docs: update on the UPS docs) In-Reply-To: References: Message-ID: I really like the table of content on the pages. Nice work guys! On 31 July 2014 09:50, Matthias Wessendorf wrote: > Hi, > > the new "push" landing page and restructuring went into our master branch. > * http://staging.aerogear.org/push - the 'Learn More' now redirects to: > ** http://staging.aerogear.org/docs/unifiedpush/ > > That contains all UPS/Push related docs on a more centralized page. > > It also contains the new 'User/Reference Guide' on the UnifiedPush Server: > http://staging.aerogear.org/docs/unifiedpush/ups_userguide/ > > feel free to review and sent PRs/JIRAs for 'bugs' or improvements! > > > Thanks! > -Matthias > > > > > On Wed, Jul 30, 2014 at 4:39 PM, Matthias Wessendorf > wrote: > >> A lot of more content. >> >> Please review, and comment on the PR if this can be merged or not .... >> >> >> On Tue, Jul 29, 2014 at 6:48 PM, Matthias Wessendorf >> wrote: >> >>> Here is a first PR for it: >>> >>> https://github.com/aerogear/aerogear.org/pull/333 >>> >>> as noted, still WIP - but it is getting there >>> >>> >>> On Thu, Jul 24, 2014 at 3:25 PM, Matthias Wessendorf >>> wrote: >>> >>>> Thanks Dan! >>>> >>>> >>>> FYI - the draft of the TOC (and soon content) lives in this branch: >>>> >>>> >>>> https://github.com/aerogear/aerogear.org/blob/NewUPS_Guide/docs/unifiedpush/ups_userguide/index.markdown >>>> >>>> -M >>>> >>>> >>>> On Thu, Jul 24, 2014 at 2:14 PM, Daniel Bevenius < >>>> daniel.bevenius at gmail.com> wrote: >>>> >>>>> Looks good! >>>>> perhaps change: Configuring and Managing Applications that use the >>>>> UnifiedPush Server -> Configuring and managing applications that use >>>>> the UnifiedPush Server >>>>> >>>>> >>>>> >>>>> On 24 July 2014 13:32, Matthias Wessendorf wrote: >>>>> >>>>>> update: >>>>>> >>>>>> >>>>>> UnifiedPush Server User Guide >>>>>> >>>>>> - Overview >>>>>> - About the UnifiedPush Server >>>>>> - Use-cases and scenarios >>>>>> - Useful Terminology >>>>>> - How the UnifiedPush Server Works >>>>>> - Installation and configuration >>>>>> - The WAR file distribution >>>>>> - setup and configure a database >>>>>> - deploy the WAR files >>>>>> - Running on OpenShift >>>>>> - create an instance using OpenShift's Web UI >>>>>> - create an instance using OpenShift's command line interface >>>>>> - Using the Admin UI >>>>>> - Administering the UnifiedPush Server Console >>>>>> - Configuring and Managing Applications that use the >>>>>> UnifiedPush Server >>>>>> - Preparing mobile devices to be connected with the >>>>>> UnifiedPush Server >>>>>> - Sending Push Notifications >>>>>> - Preparing backends to send Push Notifications >>>>>> - Next steps >>>>>> - TBD: Links to tutorials and specs (some specs might go away) >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Thu, Jul 24, 2014 at 1:29 PM, Matthias Wessendorf < >>>>>> matzew at apache.org> wrote: >>>>>> >>>>>>> Here is the TOC that I have in mind (and started to work on): >>>>>>> >>>>>>> UnifiedPush Server User Guide >>>>>>> >>>>>>> - Overview >>>>>>> - About the UnifiedPush Server >>>>>>> - Use-cases and scenarios >>>>>>> - Useful Terminology >>>>>>> - How the UnifiedPush Server Works >>>>>>> - Installation and configuration >>>>>>> - The WAR file distribution >>>>>>> - setup and configure a database >>>>>>> - deploy the WAR files >>>>>>> - Running on OpenShift >>>>>>> - create an instance using OpenShift's Web UI >>>>>>> - create an instance using OpenShift's command line interface >>>>>>> - Using the Admin UI >>>>>>> - Administering the UnifiedPush Server Console >>>>>>> - Configuring and Managing Applications that use the >>>>>>> UnifiedPush Server >>>>>>> - Preparing mobile devices to be connected with the >>>>>>> UnifiedPush Server >>>>>>> - Sending Push Notifications >>>>>>> - Next steps >>>>>>> - TBD: Links to tutorials and specs (some specs might go away) >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Thu, Jul 24, 2014 at 11:26 AM, Matthias Wessendorf < >>>>>>> matzew at apache.org> wrote: >>>>>>> >>>>>>>> Before actually starting with the (initial) rewrite of the UPS >>>>>>>> guide (as I outlined), I did the re-org of the UPS content. >>>>>>>> >>>>>>>> Please review: >>>>>>>> https://github.com/aerogear/aerogear.org/pull/327 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Mon, Jul 21, 2014 at 5:59 PM, Matthias Wessendorf < >>>>>>>> matzew at apache.org> wrote: >>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> right now we have a lot of different 'documentation files', like >>>>>>>>> the README, some specs, and guides and tutorials. >>>>>>>>> >>>>>>>>> I'd like to restructure that a bit and centralize the >>>>>>>>> documentation a bit. >>>>>>>>> >>>>>>>>> On the "push" landing page ([1]), I'd like to change the "Lean >>>>>>>>> More" link to a new page that has all the UPS centric documentations >>>>>>>>> >>>>>>>>> - AeroGear UnifiedPush Server User/Reference Guide >>>>>>>>> - Tutorials >>>>>>>>> >>>>>>>>> >>>>>>>>> AeroGear >>>>>>>>> UnifiedPush Server User/Reference Guide >>>>>>>>> >>>>>>>>> - Overview >>>>>>>>> - some generic information >>>>>>>>> - Installation and configuration >>>>>>>>> - what's needed (e.g. JBoss and a database) >>>>>>>>> - Running on OpenShift >>>>>>>>> - using the UI on OpenShift >>>>>>>>> - using the rhc command line >>>>>>>>> - Using the Admin UI >>>>>>>>> - doing an overhaul of our existing Admin UI guide (e.g. >>>>>>>>> taking new screenshots and updating based on new UI features) >>>>>>>>> >>>>>>>>> The format of the *reference guide* would be similar to the one >>>>>>>>> from Keycloak ([2]). But... I will continue using asciidoc ;-) >>>>>>>>> >>>>>>>>> The README will be extremely quick and simply link to the homepage >>>>>>>>> ;-) After this *new* reference guide, I think some of the current >>>>>>>>> specs can be removed, as the *reference guide* hopefully covers >>>>>>>>> all of their content :-) >>>>>>>>> >>>>>>>>> For the RESTful APIs, I have to look what Keycloak did to get >>>>>>>>> something like: >>>>>>>>> http://docs.jboss.org/keycloak/docs/1.0-beta-3/rest-api/overview-index.html >>>>>>>>> >>>>>>>>> After the work as been completed, I will be revisiting the specs >>>>>>>>> and evaluate their need ;-) >>>>>>>>> >>>>>>>>> Tutorials >>>>>>>>> >>>>>>>>> This section will contain links to all the different tutorials we >>>>>>>>> have: >>>>>>>>> >>>>>>>>> - http://aerogear.org/docs/guides/aerogear-push-ios/ >>>>>>>>> - http://aerogear.org/docs/guides/aerogear-push-js/ >>>>>>>>> - http://aerogear.org/docs/guides/aerogear-push-android/ >>>>>>>>> - http://aerogear.org/docs/guides/aerogear-push-chrome/ >>>>>>>>> - http://aerogear.org/docs/guides/GetStartedwithJavaSender/ >>>>>>>>> >>>>>>>>> For Cordova we will have one single document, instead of three: >>>>>>>>> >>>>>>>>> - >>>>>>>>> http://aerogear.org/docs/guides/aerogear-push-cordova-android/ >>>>>>>>> - http://aerogear.org/docs/guides/aerogear-push-cordova-ios/ >>>>>>>>> - >>>>>>>>> http://aerogear.org/docs/guides/aerogear-cordova/AerogearCordovaPush/ >>>>>>>>> >>>>>>>>> There is already a JIRA for that ([4]). >>>>>>>>> >>>>>>>>> To make it more clear (or clean?), I will remove the UPS/Push >>>>>>>>> related docs from our guides ([3]) and replace all those links by a single >>>>>>>>> link to the above mentioned new page (also referenced from [1]). >>>>>>>>> >>>>>>>>> Greetings, >>>>>>>>> Matthias >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> - [1] http://aerogear.org/push/ >>>>>>>>> - [2] >>>>>>>>> http://docs.jboss.org/keycloak/docs/1.0-beta-3/userguide/html/index.html >>>>>>>>> - [3] http://aerogear.org/docs/guides/ >>>>>>>>> - [4] https://issues.jboss.org/browse/AGPUSH-805 >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Matthias Wessendorf >>>>>>>>> >>>>>>>>> blog: http://matthiaswessendorf.wordpress.com/ >>>>>>>>> sessions: http://www.slideshare.net/mwessendorf >>>>>>>>> twitter: http://twitter.com/mwessendorf >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Matthias Wessendorf >>>>>>>> >>>>>>>> blog: http://matthiaswessendorf.wordpress.com/ >>>>>>>> sessions: http://www.slideshare.net/mwessendorf >>>>>>>> twitter: http://twitter.com/mwessendorf >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Matthias Wessendorf >>>>>>> >>>>>>> blog: http://matthiaswessendorf.wordpress.com/ >>>>>>> sessions: http://www.slideshare.net/mwessendorf >>>>>>> twitter: http://twitter.com/mwessendorf >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Matthias Wessendorf >>>>>> >>>>>> blog: http://matthiaswessendorf.wordpress.com/ >>>>>> sessions: http://www.slideshare.net/mwessendorf >>>>>> twitter: http://twitter.com/mwessendorf >>>>>> >>>>>> _______________________________________________ >>>>>> aerogear-dev mailing list >>>>>> aerogear-dev at lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> aerogear-dev mailing list >>>>> aerogear-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>> >>>> >>>> >>>> >>>> -- >>>> Matthias Wessendorf >>>> >>>> blog: http://matthiaswessendorf.wordpress.com/ >>>> sessions: http://www.slideshare.net/mwessendorf >>>> twitter: http://twitter.com/mwessendorf >>>> >>> >>> >>> >>> -- >>> Matthias Wessendorf >>> >>> blog: http://matthiaswessendorf.wordpress.com/ >>> sessions: http://www.slideshare.net/mwessendorf >>> twitter: http://twitter.com/mwessendorf >>> >> >> >> >> -- >> Matthias Wessendorf >> >> blog: http://matthiaswessendorf.wordpress.com/ >> sessions: http://www.slideshare.net/mwessendorf >> twitter: http://twitter.com/mwessendorf >> > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140731/6b4cd095/attachment-0001.html From matzew at apache.org Thu Jul 31 07:46:51 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Thu, 31 Jul 2014 13:46:51 +0200 Subject: [aerogear-dev] New docs got merged (was: Re: Docs: update on the UPS docs) In-Reply-To: References: Message-ID: Yeah, Erik added the CSS for that - I like it as well :-) On Thu, Jul 31, 2014 at 1:28 PM, Daniel Bevenius wrote: > I really like the table of content on the pages. Nice work guys! > > > > > On 31 July 2014 09:50, Matthias Wessendorf wrote: > >> Hi, >> >> the new "push" landing page and restructuring went into our master branch. >> * http://staging.aerogear.org/push - the 'Learn More' now redirects to: >> ** http://staging.aerogear.org/docs/unifiedpush/ >> >> That contains all UPS/Push related docs on a more centralized page. >> >> It also contains the new 'User/Reference Guide' on the UnifiedPush Server: >> http://staging.aerogear.org/docs/unifiedpush/ups_userguide/ >> >> feel free to review and sent PRs/JIRAs for 'bugs' or improvements! >> >> >> Thanks! >> -Matthias >> >> >> >> >> On Wed, Jul 30, 2014 at 4:39 PM, Matthias Wessendorf >> wrote: >> >>> A lot of more content. >>> >>> Please review, and comment on the PR if this can be merged or not .... >>> >>> >>> On Tue, Jul 29, 2014 at 6:48 PM, Matthias Wessendorf >>> wrote: >>> >>>> Here is a first PR for it: >>>> >>>> https://github.com/aerogear/aerogear.org/pull/333 >>>> >>>> as noted, still WIP - but it is getting there >>>> >>>> >>>> On Thu, Jul 24, 2014 at 3:25 PM, Matthias Wessendorf >>> > wrote: >>>> >>>>> Thanks Dan! >>>>> >>>>> >>>>> FYI - the draft of the TOC (and soon content) lives in this branch: >>>>> >>>>> >>>>> https://github.com/aerogear/aerogear.org/blob/NewUPS_Guide/docs/unifiedpush/ups_userguide/index.markdown >>>>> >>>>> -M >>>>> >>>>> >>>>> On Thu, Jul 24, 2014 at 2:14 PM, Daniel Bevenius < >>>>> daniel.bevenius at gmail.com> wrote: >>>>> >>>>>> Looks good! >>>>>> perhaps change: Configuring and Managing Applications that use the >>>>>> UnifiedPush Server -> Configuring and managing applications that use >>>>>> the UnifiedPush Server >>>>>> >>>>>> >>>>>> >>>>>> On 24 July 2014 13:32, Matthias Wessendorf wrote: >>>>>> >>>>>>> update: >>>>>>> >>>>>>> >>>>>>> UnifiedPush Server User Guide >>>>>>> >>>>>>> - Overview >>>>>>> - About the UnifiedPush Server >>>>>>> - Use-cases and scenarios >>>>>>> - Useful Terminology >>>>>>> - How the UnifiedPush Server Works >>>>>>> - Installation and configuration >>>>>>> - The WAR file distribution >>>>>>> - setup and configure a database >>>>>>> - deploy the WAR files >>>>>>> - Running on OpenShift >>>>>>> - create an instance using OpenShift's Web UI >>>>>>> - create an instance using OpenShift's command line interface >>>>>>> - Using the Admin UI >>>>>>> - Administering the UnifiedPush Server Console >>>>>>> - Configuring and Managing Applications that use the >>>>>>> UnifiedPush Server >>>>>>> - Preparing mobile devices to be connected with the >>>>>>> UnifiedPush Server >>>>>>> - Sending Push Notifications >>>>>>> - Preparing backends to send Push Notifications >>>>>>> - Next steps >>>>>>> - TBD: Links to tutorials and specs (some specs might go away) >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Thu, Jul 24, 2014 at 1:29 PM, Matthias Wessendorf < >>>>>>> matzew at apache.org> wrote: >>>>>>> >>>>>>>> Here is the TOC that I have in mind (and started to work on): >>>>>>>> >>>>>>>> UnifiedPush Server User Guide >>>>>>>> >>>>>>>> - Overview >>>>>>>> - About the UnifiedPush Server >>>>>>>> - Use-cases and scenarios >>>>>>>> - Useful Terminology >>>>>>>> - How the UnifiedPush Server Works >>>>>>>> - Installation and configuration >>>>>>>> - The WAR file distribution >>>>>>>> - setup and configure a database >>>>>>>> - deploy the WAR files >>>>>>>> - Running on OpenShift >>>>>>>> - create an instance using OpenShift's Web UI >>>>>>>> - create an instance using OpenShift's command line interface >>>>>>>> - Using the Admin UI >>>>>>>> - Administering the UnifiedPush Server Console >>>>>>>> - Configuring and Managing Applications that use the >>>>>>>> UnifiedPush Server >>>>>>>> - Preparing mobile devices to be connected with the >>>>>>>> UnifiedPush Server >>>>>>>> - Sending Push Notifications >>>>>>>> - Next steps >>>>>>>> - TBD: Links to tutorials and specs (some specs might go >>>>>>>> away) >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Thu, Jul 24, 2014 at 11:26 AM, Matthias Wessendorf < >>>>>>>> matzew at apache.org> wrote: >>>>>>>> >>>>>>>>> Before actually starting with the (initial) rewrite of the UPS >>>>>>>>> guide (as I outlined), I did the re-org of the UPS content. >>>>>>>>> >>>>>>>>> Please review: >>>>>>>>> https://github.com/aerogear/aerogear.org/pull/327 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Mon, Jul 21, 2014 at 5:59 PM, Matthias Wessendorf < >>>>>>>>> matzew at apache.org> wrote: >>>>>>>>> >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> right now we have a lot of different 'documentation files', like >>>>>>>>>> the README, some specs, and guides and tutorials. >>>>>>>>>> >>>>>>>>>> I'd like to restructure that a bit and centralize the >>>>>>>>>> documentation a bit. >>>>>>>>>> >>>>>>>>>> On the "push" landing page ([1]), I'd like to change the "Lean >>>>>>>>>> More" link to a new page that has all the UPS centric documentations >>>>>>>>>> >>>>>>>>>> - AeroGear UnifiedPush Server User/Reference Guide >>>>>>>>>> - Tutorials >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> AeroGear >>>>>>>>>> UnifiedPush Server User/Reference Guide >>>>>>>>>> >>>>>>>>>> - Overview >>>>>>>>>> - some generic information >>>>>>>>>> - Installation and configuration >>>>>>>>>> - what's needed (e.g. JBoss and a database) >>>>>>>>>> - Running on OpenShift >>>>>>>>>> - using the UI on OpenShift >>>>>>>>>> - using the rhc command line >>>>>>>>>> - Using the Admin UI >>>>>>>>>> - doing an overhaul of our existing Admin UI guide (e.g. >>>>>>>>>> taking new screenshots and updating based on new UI features) >>>>>>>>>> >>>>>>>>>> The format of the *reference guide* would be similar to the one >>>>>>>>>> from Keycloak ([2]). But... I will continue using asciidoc ;-) >>>>>>>>>> >>>>>>>>>> The README will be extremely quick and simply link to the >>>>>>>>>> homepage ;-) After this *new* reference guide, I think some of >>>>>>>>>> the current specs can be removed, as the *reference guide* hopefully >>>>>>>>>> covers all of their content :-) >>>>>>>>>> >>>>>>>>>> For the RESTful APIs, I have to look what Keycloak did to get >>>>>>>>>> something like: >>>>>>>>>> http://docs.jboss.org/keycloak/docs/1.0-beta-3/rest-api/overview-index.html >>>>>>>>>> >>>>>>>>>> After the work as been completed, I will be revisiting the specs >>>>>>>>>> and evaluate their need ;-) >>>>>>>>>> >>>>>>>>>> Tutorials >>>>>>>>>> >>>>>>>>>> This section will contain links to all the different tutorials we >>>>>>>>>> have: >>>>>>>>>> >>>>>>>>>> - http://aerogear.org/docs/guides/aerogear-push-ios/ >>>>>>>>>> - http://aerogear.org/docs/guides/aerogear-push-js/ >>>>>>>>>> - http://aerogear.org/docs/guides/aerogear-push-android/ >>>>>>>>>> - http://aerogear.org/docs/guides/aerogear-push-chrome/ >>>>>>>>>> - http://aerogear.org/docs/guides/GetStartedwithJavaSender/ >>>>>>>>>> >>>>>>>>>> For Cordova we will have one single document, instead of three: >>>>>>>>>> >>>>>>>>>> - >>>>>>>>>> http://aerogear.org/docs/guides/aerogear-push-cordova-android/ >>>>>>>>>> - http://aerogear.org/docs/guides/aerogear-push-cordova-ios/ >>>>>>>>>> - >>>>>>>>>> http://aerogear.org/docs/guides/aerogear-cordova/AerogearCordovaPush/ >>>>>>>>>> >>>>>>>>>> There is already a JIRA for that ([4]). >>>>>>>>>> >>>>>>>>>> To make it more clear (or clean?), I will remove the UPS/Push >>>>>>>>>> related docs from our guides ([3]) and replace all those links by a single >>>>>>>>>> link to the above mentioned new page (also referenced from [1]). >>>>>>>>>> >>>>>>>>>> Greetings, >>>>>>>>>> Matthias >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> - [1] http://aerogear.org/push/ >>>>>>>>>> - [2] >>>>>>>>>> http://docs.jboss.org/keycloak/docs/1.0-beta-3/userguide/html/index.html >>>>>>>>>> - [3] http://aerogear.org/docs/guides/ >>>>>>>>>> - [4] https://issues.jboss.org/browse/AGPUSH-805 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Matthias Wessendorf >>>>>>>>>> >>>>>>>>>> blog: http://matthiaswessendorf.wordpress.com/ >>>>>>>>>> sessions: http://www.slideshare.net/mwessendorf >>>>>>>>>> twitter: http://twitter.com/mwessendorf >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Matthias Wessendorf >>>>>>>>> >>>>>>>>> blog: http://matthiaswessendorf.wordpress.com/ >>>>>>>>> sessions: http://www.slideshare.net/mwessendorf >>>>>>>>> twitter: http://twitter.com/mwessendorf >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Matthias Wessendorf >>>>>>>> >>>>>>>> blog: http://matthiaswessendorf.wordpress.com/ >>>>>>>> sessions: http://www.slideshare.net/mwessendorf >>>>>>>> twitter: http://twitter.com/mwessendorf >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Matthias Wessendorf >>>>>>> >>>>>>> blog: http://matthiaswessendorf.wordpress.com/ >>>>>>> sessions: http://www.slideshare.net/mwessendorf >>>>>>> twitter: http://twitter.com/mwessendorf >>>>>>> >>>>>>> _______________________________________________ >>>>>>> aerogear-dev mailing list >>>>>>> aerogear-dev at lists.jboss.org >>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> aerogear-dev mailing list >>>>>> aerogear-dev at lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Matthias Wessendorf >>>>> >>>>> blog: http://matthiaswessendorf.wordpress.com/ >>>>> sessions: http://www.slideshare.net/mwessendorf >>>>> twitter: http://twitter.com/mwessendorf >>>>> >>>> >>>> >>>> >>>> -- >>>> Matthias Wessendorf >>>> >>>> blog: http://matthiaswessendorf.wordpress.com/ >>>> sessions: http://www.slideshare.net/mwessendorf >>>> twitter: http://twitter.com/mwessendorf >>>> >>> >>> >>> >>> -- >>> Matthias Wessendorf >>> >>> blog: http://matthiaswessendorf.wordpress.com/ >>> sessions: http://www.slideshare.net/mwessendorf >>> twitter: http://twitter.com/mwessendorf >>> >> >> >> >> -- >> Matthias Wessendorf >> >> blog: http://matthiaswessendorf.wordpress.com/ >> sessions: http://www.slideshare.net/mwessendorf >> twitter: http://twitter.com/mwessendorf >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140731/53995ae6/attachment-0001.html From edewit at redhat.com Thu Jul 31 08:18:32 2014 From: edewit at redhat.com (Erik Jan de Wit) Date: Thu, 31 Jul 2014 14:18:32 +0200 Subject: [aerogear-dev] Differences between Firefox OS "native" Push lib and AeroGear's Push adapter In-Reply-To: References: <1406216640.15307.0@smtp.corp.redhat.com> <1E3E76E8-60D7-4BF3-9B95-6C58F4DC9286@redhat.com> <919B56C2-8E6D-4CD8-A620-F9839E013685@redhat.com> <20140725133326.GA14148@abstractj.org> Message-ID: BTW, Also the ?deviceID? for Microsoft Push will be an URL so we really need a way to fix this. Adding double url encoding is already a form of encoding so why not go for base64 it?s ?just? another kind of encoding. I also don?t like the idea of a mapping having it stateless is much nicer IMO, I would rather have some form of encoding. From scm.blanc at gmail.com Thu Jul 31 08:18:58 2014 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Thu, 31 Jul 2014 14:18:58 +0200 Subject: [aerogear-dev] Help needed on AGPUSH-848 In-Reply-To: References: Message-ID: On Thu, Jul 31, 2014 at 12:12 PM, Matthias Wessendorf wrote: > I think original idea was to show the three most busy (in number of > receives, not installations) > The total number or receives for one Variant , right ? So, if variant A "sended" a first time to 20 receivers and after that did a selective send 5 : the number that must showned is 25 And we want the top 3 of this total ? > > > > > On Thu, Jul 31, 2014 at 11:42 AM, Sebastien Blanc > wrote: > >> BTW, >> I wonder how we had in mind the computing of the 3 busiest variants, what >> does it mean exactly ? >> Should we not sum up all the receiver for each VariantMetricInformation >> and from there get the top 3 ? Not sure this is happening right now, maybe >> @matzew or @edewit could give more info. >> >> >> >> On Thu, Jul 31, 2014 at 11:31 AM, Daniel Bevenius < >> daniel.bevenius at gmail.com> wrote: >> >>> Sorry, looking into this and I can't see any easy fix. >>> The problem as I see it is that the for the same variantId there can be >>> multiple receivers. But we currently don't know which ApplicationVariant >>> the receivers belong to. So we cannot match them up in DashBoardService. >>> This my first time looking at the code so I might be missing something. >>> So I'd say your first post about the query being wrong is correct, and we >>> have to take the match the VariantMetricInformation and match it with a >>> pushApplicationId. Again, I could be way off here :) >>> >>> >>> >>> >>> On 31 July 2014 10:47, Daniel Bevenius >>> wrote: >>> >>>> Hey Seb, >>>> >>>> sure let me take a closer look at this. I'm getting the feeling that it >>>> might not be as simple as that. Let me push something and we can discuss it. >>>> >>>> >>>> >>>> >>>> On 31 July 2014 10:39, Sebastien Blanc wrote: >>>> >>>>> Hi Dan, >>>>> Not sure if I understand exactly what you meant, could do a small >>>>> snippet ? >>>>> >>>>> >>>>> >>>>> On Thu, Jul 31, 2014 at 10:08 AM, Daniel Bevenius < >>>>> daniel.bevenius at gmail.com> wrote: >>>>> >>>>>> Oh I see. Then I'd say you'll need to change the return type to >>>>>> either use a custom object for the key in the map, or perhaps return a list >>>>>> with that came custom object. What ever makes the most sense in this use >>>>>> case. Makes sense? >>>>>> >>>>>> >>>>>> On 31 July 2014 09:39, Sebastien Blanc wrote: >>>>>> >>>>>>> Well, several VariantMetricInformation instances can have the same >>>>>>> VariantID, at each send , one is created : >>>>>>> https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/push%2Fsrc%2Fmain%2Fjava%2Forg%2Fjboss%2Faerogear%2Funifiedpush%2Fmessage%2FSenderServiceImpl.java#L133 >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Thu, Jul 31, 2014 at 9:34 AM, Daniel Bevenius < >>>>>>> daniel.bevenius at gmail.com> wrote: >>>>>>> >>>>>>>> Is this because variantFour and variantFive have the same variantId >>>>>>>> (231543432434)? When added to the map only one will exist later >>>>>>>> in findTopThreeBusyVariantIDs. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 31 July 2014 09:20, Sebastien Blanc wrote: >>>>>>>> >>>>>>>>> Morning Peeps, >>>>>>>>> >>>>>>>>> I'm currently trying to fix AGPUSH-848[1]. >>>>>>>>> Basically, the number of receivers shown in the top3 list is not >>>>>>>>> always accurate. >>>>>>>>> >>>>>>>>> I suspect that something is wrong with this query : >>>>>>>>> >>>>>>>>> >>>>>>>>> https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/model/jpa/src/main/java/org/jboss/aerogear/unifiedpush/jpa/dao/impl/JPAPushMessageInformationDao.java#L99-L104 >>>>>>>>> >>>>>>>>> I have change this test case : >>>>>>>>> >>>>>>>>> https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/model%2Fjpa%2Fsrc%2Ftest%2Fjava%2Forg%2Fjboss%2Faerogear%2Funifiedpush%2Fjpa%2FPushMessageInformationDaoTest.java#L251 >>>>>>>>> >>>>>>>>> By adding just one VariantInformation[2] and now the test is >>>>>>>>> failing and I have no idea why, so I would aprreciate a second eye on this. >>>>>>>>> >>>>>>>>> I'm probably missing something obvious but I can not see it right >>>>>>>>> now :) >>>>>>>>> >>>>>>>>> Sebi >>>>>>>>> >>>>>>>>> >>>>>>>>> [1]https://issues.jboss.org/browse/AGPUSH-848 >>>>>>>>> [2] >>>>>>>>> https://gist.github.com/sebastienblanc/ea34e7f9fdafbc0785f2#file-gistfile1-java-L30-L35 >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> aerogear-dev mailing list >>>>>>>>> aerogear-dev at lists.jboss.org >>>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> aerogear-dev mailing list >>>>>>>> aerogear-dev at lists.jboss.org >>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> aerogear-dev mailing list >>>>>>> aerogear-dev at lists.jboss.org >>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> aerogear-dev mailing list >>>>>> aerogear-dev at lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> aerogear-dev mailing list >>>>> aerogear-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>> >>>> >>>> >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140731/092389f9/attachment.html From matzew at apache.org Thu Jul 31 08:30:49 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Thu, 31 Jul 2014 14:30:49 +0200 Subject: [aerogear-dev] Differences between Firefox OS "native" Push lib and AeroGear's Push adapter In-Reply-To: References: <1406216640.15307.0@smtp.corp.redhat.com> <1E3E76E8-60D7-4BF3-9B95-6C58F4DC9286@redhat.com> <919B56C2-8E6D-4CD8-A620-F9839E013685@redhat.com> <20140725133326.GA14148@abstractj.org> Message-ID: On Thu, Jul 31, 2014 at 2:18 PM, Erik Jan de Wit wrote: > BTW, > > Also the ?deviceID? for Microsoft Push will be an URL so we really need a > way to fix this. Adding double url encoding is already a form of encoding > so why not go for base64 it?s ?just? another kind of encoding. I also don?t > like the idea of a mapping having it stateless is much nicer IMO, I would > rather have some form of encoding. > Sounds good. Would you be interested in doing the encoding, as proposed and also work on https://issues.jboss.org/browse/AGPUSH-833 (for the unregister issue) ? -Matthias > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140731/25bdd497/attachment.html From edewit at redhat.com Thu Jul 31 08:42:05 2014 From: edewit at redhat.com (Erik Jan de Wit) Date: Thu, 31 Jul 2014 14:42:05 +0200 Subject: [aerogear-dev] Differences between Firefox OS "native" Push lib and AeroGear's Push adapter In-Reply-To: References: <1406216640.15307.0@smtp.corp.redhat.com> <1E3E76E8-60D7-4BF3-9B95-6C58F4DC9286@redhat.com> <919B56C2-8E6D-4CD8-A620-F9839E013685@redhat.com> <20140725133326.GA14148@abstractj.org> Message-ID: <8FE8FB89-A7FF-4CE1-828E-07FE4EE5BEAB@redhat.com> On 31 Jul,2014, at 14:30 , Matthias Wessendorf wrote: > > > > On Thu, Jul 31, 2014 at 2:18 PM, Erik Jan de Wit wrote: > BTW, > > Also the ?deviceID? for Microsoft Push will be an URL so we really need a way to fix this. Adding double url encoding is already a form of encoding so why not go for base64 it?s ?just? another kind of encoding. I also don?t like the idea of a mapping having it stateless is much nicer IMO, I would rather have some form of encoding. > > Sounds good. Would you be interested in doing the encoding, as proposed and also work on https://issues.jboss.org/browse/AGPUSH-833 (for the unregister issue) ? > I?m on it -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140731/1d9a2904/attachment-0001.html From matzew at apache.org Thu Jul 31 08:45:21 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Thu, 31 Jul 2014 14:45:21 +0200 Subject: [aerogear-dev] Help needed on AGPUSH-848 In-Reply-To: References: Message-ID: On Thu, Jul 31, 2014 at 2:18 PM, Sebastien Blanc wrote: > > > > On Thu, Jul 31, 2014 at 12:12 PM, Matthias Wessendorf > wrote: > >> I think original idea was to show the three most busy (in number of >> receives, not installations) >> > The total number or receives for one Variant , right ? > So, if variant A "sended" a first time to 20 receivers and after that did > a selective send 5 : the number that must showned is 25 > And we want the top 3 of this total ? > uhm, there was a thread in the past. Burr added something, and Hylke.... and we were somewhat talked into this (I guess we did not think too much about it :-( ) So... I think..... we perhaps could: * show the most (three) recent variants (and their # of receivers) But IMO not doing a count. Perhaps that means some code needs to be rewritten... Also... "Most active" could mean something else: * TOTAL number of receivers (per variant/app) -> like a count * TOTAL number of messages (per vairant/app) -> like a count on the actual message I think I do (now) like the first (show the most (three) recent variants (and their # of receivers) ) the best :-) > > >> >> >> >> >> On Thu, Jul 31, 2014 at 11:42 AM, Sebastien Blanc >> wrote: >> >>> BTW, >>> I wonder how we had in mind the computing of the 3 busiest variants, >>> what does it mean exactly ? >>> Should we not sum up all the receiver for each VariantMetricInformation >>> and from there get the top 3 ? Not sure this is happening right now, maybe >>> @matzew or @edewit could give more info. >>> >>> >>> >>> On Thu, Jul 31, 2014 at 11:31 AM, Daniel Bevenius < >>> daniel.bevenius at gmail.com> wrote: >>> >>>> Sorry, looking into this and I can't see any easy fix. >>>> The problem as I see it is that the for the same variantId there can be >>>> multiple receivers. But we currently don't know which ApplicationVariant >>>> the receivers belong to. So we cannot match them up in DashBoardService. >>>> This my first time looking at the code so I might be missing something. >>>> So I'd say your first post about the query being wrong is correct, and we >>>> have to take the match the VariantMetricInformation and match it with a >>>> pushApplicationId. Again, I could be way off here :) >>>> >>>> >>>> >>>> >>>> On 31 July 2014 10:47, Daniel Bevenius >>>> wrote: >>>> >>>>> Hey Seb, >>>>> >>>>> sure let me take a closer look at this. I'm getting the feeling that >>>>> it might not be as simple as that. Let me push something and we can discuss >>>>> it. >>>>> >>>>> >>>>> >>>>> >>>>> On 31 July 2014 10:39, Sebastien Blanc wrote: >>>>> >>>>>> Hi Dan, >>>>>> Not sure if I understand exactly what you meant, could do a small >>>>>> snippet ? >>>>>> >>>>>> >>>>>> >>>>>> On Thu, Jul 31, 2014 at 10:08 AM, Daniel Bevenius < >>>>>> daniel.bevenius at gmail.com> wrote: >>>>>> >>>>>>> Oh I see. Then I'd say you'll need to change the return type to >>>>>>> either use a custom object for the key in the map, or perhaps return a list >>>>>>> with that came custom object. What ever makes the most sense in this use >>>>>>> case. Makes sense? >>>>>>> >>>>>>> >>>>>>> On 31 July 2014 09:39, Sebastien Blanc wrote: >>>>>>> >>>>>>>> Well, several VariantMetricInformation instances can have the same >>>>>>>> VariantID, at each send , one is created : >>>>>>>> https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/push%2Fsrc%2Fmain%2Fjava%2Forg%2Fjboss%2Faerogear%2Funifiedpush%2Fmessage%2FSenderServiceImpl.java#L133 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Thu, Jul 31, 2014 at 9:34 AM, Daniel Bevenius < >>>>>>>> daniel.bevenius at gmail.com> wrote: >>>>>>>> >>>>>>>>> Is this because variantFour and variantFive have the same >>>>>>>>> variantId (231543432434)? When added to the map only one will exist later >>>>>>>>> in findTopThreeBusyVariantIDs. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On 31 July 2014 09:20, Sebastien Blanc >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> Morning Peeps, >>>>>>>>>> >>>>>>>>>> I'm currently trying to fix AGPUSH-848[1]. >>>>>>>>>> Basically, the number of receivers shown in the top3 list is not >>>>>>>>>> always accurate. >>>>>>>>>> >>>>>>>>>> I suspect that something is wrong with this query : >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/model/jpa/src/main/java/org/jboss/aerogear/unifiedpush/jpa/dao/impl/JPAPushMessageInformationDao.java#L99-L104 >>>>>>>>>> >>>>>>>>>> I have change this test case : >>>>>>>>>> >>>>>>>>>> https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/model%2Fjpa%2Fsrc%2Ftest%2Fjava%2Forg%2Fjboss%2Faerogear%2Funifiedpush%2Fjpa%2FPushMessageInformationDaoTest.java#L251 >>>>>>>>>> >>>>>>>>>> By adding just one VariantInformation[2] and now the test is >>>>>>>>>> failing and I have no idea why, so I would aprreciate a second eye on this. >>>>>>>>>> >>>>>>>>>> I'm probably missing something obvious but I can not see it right >>>>>>>>>> now :) >>>>>>>>>> >>>>>>>>>> Sebi >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> [1]https://issues.jboss.org/browse/AGPUSH-848 >>>>>>>>>> [2] >>>>>>>>>> https://gist.github.com/sebastienblanc/ea34e7f9fdafbc0785f2#file-gistfile1-java-L30-L35 >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> aerogear-dev mailing list >>>>>>>>>> aerogear-dev at lists.jboss.org >>>>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> aerogear-dev mailing list >>>>>>>>> aerogear-dev at lists.jboss.org >>>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> aerogear-dev mailing list >>>>>>>> aerogear-dev at lists.jboss.org >>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> aerogear-dev mailing list >>>>>>> aerogear-dev at lists.jboss.org >>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> aerogear-dev mailing list >>>>>> aerogear-dev at lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>> >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> >>> >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >> >> >> >> -- >> Matthias Wessendorf >> >> blog: http://matthiaswessendorf.wordpress.com/ >> sessions: http://www.slideshare.net/mwessendorf >> twitter: http://twitter.com/mwessendorf >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140731/25e87dcc/attachment.html From matzew at apache.org Thu Jul 31 08:45:52 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Thu, 31 Jul 2014 14:45:52 +0200 Subject: [aerogear-dev] Differences between Firefox OS "native" Push lib and AeroGear's Push adapter In-Reply-To: <8FE8FB89-A7FF-4CE1-828E-07FE4EE5BEAB@redhat.com> References: <1406216640.15307.0@smtp.corp.redhat.com> <1E3E76E8-60D7-4BF3-9B95-6C58F4DC9286@redhat.com> <919B56C2-8E6D-4CD8-A620-F9839E013685@redhat.com> <20140725133326.GA14148@abstractj.org> <8FE8FB89-A7FF-4CE1-828E-07FE4EE5BEAB@redhat.com> Message-ID: On Thu, Jul 31, 2014 at 2:42 PM, Erik Jan de Wit wrote: > > On 31 Jul,2014, at 14:30 , Matthias Wessendorf wrote: > > > > > On Thu, Jul 31, 2014 at 2:18 PM, Erik Jan de Wit > wrote: > >> BTW, >> >> Also the ?deviceID? for Microsoft Push will be an URL so we really need a >> way to fix this. Adding double url encoding is already a form of encoding >> so why not go for base64 it?s ?just? another kind of encoding. I also don?t >> like the idea of a mapping having it stateless is much nicer IMO, I would >> rather have some form of encoding. >> > > Sounds good. Would you be interested in doing the encoding, as proposed > and also work on https://issues.jboss.org/browse/AGPUSH-833 (for the > unregister issue) ? > > I?m on it > cool ! :-) > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140731/58ed2082/attachment-0001.html From scm.blanc at gmail.com Thu Jul 31 08:52:36 2014 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Thu, 31 Jul 2014 14:52:36 +0200 Subject: [aerogear-dev] Help needed on AGPUSH-848 In-Reply-To: References: Message-ID: On Thu, Jul 31, 2014 at 2:45 PM, Matthias Wessendorf wrote: > > > > On Thu, Jul 31, 2014 at 2:18 PM, Sebastien Blanc > wrote: > >> >> >> >> On Thu, Jul 31, 2014 at 12:12 PM, Matthias Wessendorf >> wrote: >> >>> I think original idea was to show the three most busy (in number of >>> receives, not installations) >>> >> The total number or receives for one Variant , right ? >> So, if variant A "sended" a first time to 20 receivers and after that did >> a selective send 5 : the number that must showned is 25 >> And we want the top 3 of this total ? >> > > uhm, there was a thread in the past. Burr added something, and Hylke.... > and we were somewhat talked into this (I guess we did not think too much > about it :-( ) > > So... I think..... > > we perhaps could: > * show the most (three) recent variants (and their # of receivers) > We could do that but then we will need to change the naming > > But IMO not doing a count. Perhaps that means some code needs to be > rewritten... > Well, I just managed to modify the query to really get the 3 variants having send to the most receivers : createQuery("select distinct vmi.variantID, SUM(vmi.receivers), vmi.pushApplicationID from VariantMetricInformation vmi" + " where vmi.variantID IN (select t.variantID from Variant t where t.developer = :developer)" + " GROUP BY vmi.variantID ORDER BY SUM(vmi.receivers) " + DESC) .setMaxResults(3) .setParameter("developer", loginName) .getResultList(); And the code don't need to be rewitten (just changing the label on the dashboard that is now a bit confusing) > > > Also... "Most active" could mean something else: > * TOTAL number of receivers (per variant/app) -> like a count > Yeah that is what my query above does now > * TOTAL number of messages (per vairant/app) -> like a count on the actual > message > > > > I think I do (now) like the first (show the most (three) recent variants > (and their # of receivers) ) the best :-) > > > > > > > >> >> >>> >>> >>> >>> >>> On Thu, Jul 31, 2014 at 11:42 AM, Sebastien Blanc >>> wrote: >>> >>>> BTW, >>>> I wonder how we had in mind the computing of the 3 busiest variants, >>>> what does it mean exactly ? >>>> Should we not sum up all the receiver for each VariantMetricInformation >>>> and from there get the top 3 ? Not sure this is happening right now, maybe >>>> @matzew or @edewit could give more info. >>>> >>>> >>>> >>>> On Thu, Jul 31, 2014 at 11:31 AM, Daniel Bevenius < >>>> daniel.bevenius at gmail.com> wrote: >>>> >>>>> Sorry, looking into this and I can't see any easy fix. >>>>> The problem as I see it is that the for the same variantId there can >>>>> be multiple receivers. But we currently don't know which ApplicationVariant >>>>> the receivers belong to. So we cannot match them up in DashBoardService. >>>>> This my first time looking at the code so I might be missing >>>>> something. So I'd say your first post about the query being wrong is >>>>> correct, and we have to take the match the VariantMetricInformation and >>>>> match it with a pushApplicationId. Again, I could be way off here :) >>>>> >>>>> >>>>> >>>>> >>>>> On 31 July 2014 10:47, Daniel Bevenius >>>>> wrote: >>>>> >>>>>> Hey Seb, >>>>>> >>>>>> sure let me take a closer look at this. I'm getting the feeling that >>>>>> it might not be as simple as that. Let me push something and we can discuss >>>>>> it. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On 31 July 2014 10:39, Sebastien Blanc wrote: >>>>>> >>>>>>> Hi Dan, >>>>>>> Not sure if I understand exactly what you meant, could do a small >>>>>>> snippet ? >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Thu, Jul 31, 2014 at 10:08 AM, Daniel Bevenius < >>>>>>> daniel.bevenius at gmail.com> wrote: >>>>>>> >>>>>>>> Oh I see. Then I'd say you'll need to change the return type to >>>>>>>> either use a custom object for the key in the map, or perhaps return a list >>>>>>>> with that came custom object. What ever makes the most sense in this use >>>>>>>> case. Makes sense? >>>>>>>> >>>>>>>> >>>>>>>> On 31 July 2014 09:39, Sebastien Blanc wrote: >>>>>>>> >>>>>>>>> Well, several VariantMetricInformation instances can have the same >>>>>>>>> VariantID, at each send , one is created : >>>>>>>>> https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/push%2Fsrc%2Fmain%2Fjava%2Forg%2Fjboss%2Faerogear%2Funifiedpush%2Fmessage%2FSenderServiceImpl.java#L133 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Thu, Jul 31, 2014 at 9:34 AM, Daniel Bevenius < >>>>>>>>> daniel.bevenius at gmail.com> wrote: >>>>>>>>> >>>>>>>>>> Is this because variantFour and variantFive have the same >>>>>>>>>> variantId (231543432434)? When added to the map only one will exist later >>>>>>>>>> in findTopThreeBusyVariantIDs. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 31 July 2014 09:20, Sebastien Blanc >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> Morning Peeps, >>>>>>>>>>> >>>>>>>>>>> I'm currently trying to fix AGPUSH-848[1]. >>>>>>>>>>> Basically, the number of receivers shown in the top3 list is not >>>>>>>>>>> always accurate. >>>>>>>>>>> >>>>>>>>>>> I suspect that something is wrong with this query : >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/model/jpa/src/main/java/org/jboss/aerogear/unifiedpush/jpa/dao/impl/JPAPushMessageInformationDao.java#L99-L104 >>>>>>>>>>> >>>>>>>>>>> I have change this test case : >>>>>>>>>>> >>>>>>>>>>> https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/model%2Fjpa%2Fsrc%2Ftest%2Fjava%2Forg%2Fjboss%2Faerogear%2Funifiedpush%2Fjpa%2FPushMessageInformationDaoTest.java#L251 >>>>>>>>>>> >>>>>>>>>>> By adding just one VariantInformation[2] and now the test is >>>>>>>>>>> failing and I have no idea why, so I would aprreciate a second eye on this. >>>>>>>>>>> >>>>>>>>>>> I'm probably missing something obvious but I can not see it >>>>>>>>>>> right now :) >>>>>>>>>>> >>>>>>>>>>> Sebi >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> [1]https://issues.jboss.org/browse/AGPUSH-848 >>>>>>>>>>> [2] >>>>>>>>>>> https://gist.github.com/sebastienblanc/ea34e7f9fdafbc0785f2#file-gistfile1-java-L30-L35 >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> aerogear-dev mailing list >>>>>>>>>>> aerogear-dev at lists.jboss.org >>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> aerogear-dev mailing list >>>>>>>>>> aerogear-dev at lists.jboss.org >>>>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> aerogear-dev mailing list >>>>>>>>> aerogear-dev at lists.jboss.org >>>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> aerogear-dev mailing list >>>>>>>> aerogear-dev at lists.jboss.org >>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> aerogear-dev mailing list >>>>>>> aerogear-dev at lists.jboss.org >>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>> >>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> aerogear-dev mailing list >>>>> aerogear-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>> >>>> >>>> >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> >>> >>> >>> >>> -- >>> Matthias Wessendorf >>> >>> blog: http://matthiaswessendorf.wordpress.com/ >>> sessions: http://www.slideshare.net/mwessendorf >>> twitter: http://twitter.com/mwessendorf >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140731/a7ab7ba9/attachment.html From matzew at apache.org Thu Jul 31 09:17:28 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Thu, 31 Jul 2014 15:17:28 +0200 Subject: [aerogear-dev] Help needed on AGPUSH-848 In-Reply-To: References: Message-ID: On Thu, Jul 31, 2014 at 2:52 PM, Sebastien Blanc wrote: > > > > On Thu, Jul 31, 2014 at 2:45 PM, Matthias Wessendorf > wrote: > >> >> >> >> On Thu, Jul 31, 2014 at 2:18 PM, Sebastien Blanc >> wrote: >> >>> >>> >>> >>> On Thu, Jul 31, 2014 at 12:12 PM, Matthias Wessendorf >> > wrote: >>> >>>> I think original idea was to show the three most busy (in number of >>>> receives, not installations) >>>> >>> The total number or receives for one Variant , right ? >>> So, if variant A "sended" a first time to 20 receivers and after that >>> did a selective send 5 : the number that must showned is 25 >>> And we want the top 3 of this total ? >>> >> >> uhm, there was a thread in the past. Burr added something, and Hylke.... >> and we were somewhat talked into this (I guess we did not think too much >> about it :-( ) >> >> So... I think..... >> >> we perhaps could: >> * show the most (three) recent variants (and their # of receivers) >> > We could do that but then we will need to change the naming > I don't mind renaming ! > >> But IMO not doing a count. Perhaps that means some code needs to be >> rewritten... >> > > Well, I just managed to modify the query to really get the 3 variants > having send to the most receivers : > > createQuery("select distinct vmi.variantID, SUM(vmi.receivers), > vmi.pushApplicationID from VariantMetricInformation vmi" + > " where vmi.variantID IN (select t.variantID from Variant > t where t.developer = :developer)" + > " GROUP BY vmi.variantID ORDER BY SUM(vmi.receivers) " + > DESC) > .setMaxResults(3) > .setParameter("developer", loginName) > .getResultList(); > > And the code don't need to be rewitten (just changing the label on the > dashboard that is now a bit confusing) > ah, cool; Yeah - I've zero concerns in chaning the label :-) > >> >> Also... "Most active" could mean something else: >> * TOTAL number of receivers (per variant/app) -> like a count >> > Yeah that is what my query above does now > Ok. So you don't like the "show the most (three) recent variants (and their # of receivers) " ? :-) > * TOTAL number of messages (per vairant/app) -> like a count on the >> actual message >> >> >> >> I think I do (now) like the first (show the most (three) recent variants >> (and their # of receivers) ) the best :-) >> >> >> >> >> >> >> >>> >>> >>>> >>>> >>>> >>>> >>>> On Thu, Jul 31, 2014 at 11:42 AM, Sebastien Blanc >>>> wrote: >>>> >>>>> BTW, >>>>> I wonder how we had in mind the computing of the 3 busiest variants, >>>>> what does it mean exactly ? >>>>> Should we not sum up all the receiver for each >>>>> VariantMetricInformation and from there get the top 3 ? Not sure this is >>>>> happening right now, maybe @matzew or @edewit could give more info. >>>>> >>>>> >>>>> >>>>> On Thu, Jul 31, 2014 at 11:31 AM, Daniel Bevenius < >>>>> daniel.bevenius at gmail.com> wrote: >>>>> >>>>>> Sorry, looking into this and I can't see any easy fix. >>>>>> The problem as I see it is that the for the same variantId there can >>>>>> be multiple receivers. But we currently don't know which ApplicationVariant >>>>>> the receivers belong to. So we cannot match them up in DashBoardService. >>>>>> This my first time looking at the code so I might be missing >>>>>> something. So I'd say your first post about the query being wrong is >>>>>> correct, and we have to take the match the VariantMetricInformation and >>>>>> match it with a pushApplicationId. Again, I could be way off here :) >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On 31 July 2014 10:47, Daniel Bevenius >>>>>> wrote: >>>>>> >>>>>>> Hey Seb, >>>>>>> >>>>>>> sure let me take a closer look at this. I'm getting the feeling that >>>>>>> it might not be as simple as that. Let me push something and we can discuss >>>>>>> it. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 31 July 2014 10:39, Sebastien Blanc wrote: >>>>>>> >>>>>>>> Hi Dan, >>>>>>>> Not sure if I understand exactly what you meant, could do a small >>>>>>>> snippet ? >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Thu, Jul 31, 2014 at 10:08 AM, Daniel Bevenius < >>>>>>>> daniel.bevenius at gmail.com> wrote: >>>>>>>> >>>>>>>>> Oh I see. Then I'd say you'll need to change the return type to >>>>>>>>> either use a custom object for the key in the map, or perhaps return a list >>>>>>>>> with that came custom object. What ever makes the most sense in this use >>>>>>>>> case. Makes sense? >>>>>>>>> >>>>>>>>> >>>>>>>>> On 31 July 2014 09:39, Sebastien Blanc >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> Well, several VariantMetricInformation instances can have the >>>>>>>>>> same VariantID, at each send , one is created : >>>>>>>>>> https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/push%2Fsrc%2Fmain%2Fjava%2Forg%2Fjboss%2Faerogear%2Funifiedpush%2Fmessage%2FSenderServiceImpl.java#L133 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Thu, Jul 31, 2014 at 9:34 AM, Daniel Bevenius < >>>>>>>>>> daniel.bevenius at gmail.com> wrote: >>>>>>>>>> >>>>>>>>>>> Is this because variantFour and variantFive have the same >>>>>>>>>>> variantId (231543432434)? When added to the map only one will exist later >>>>>>>>>>> in findTopThreeBusyVariantIDs. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 31 July 2014 09:20, Sebastien Blanc >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>>> Morning Peeps, >>>>>>>>>>>> >>>>>>>>>>>> I'm currently trying to fix AGPUSH-848[1]. >>>>>>>>>>>> Basically, the number of receivers shown in the top3 list is >>>>>>>>>>>> not always accurate. >>>>>>>>>>>> >>>>>>>>>>>> I suspect that something is wrong with this query : >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/model/jpa/src/main/java/org/jboss/aerogear/unifiedpush/jpa/dao/impl/JPAPushMessageInformationDao.java#L99-L104 >>>>>>>>>>>> >>>>>>>>>>>> I have change this test case : >>>>>>>>>>>> >>>>>>>>>>>> https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/model%2Fjpa%2Fsrc%2Ftest%2Fjava%2Forg%2Fjboss%2Faerogear%2Funifiedpush%2Fjpa%2FPushMessageInformationDaoTest.java#L251 >>>>>>>>>>>> >>>>>>>>>>>> By adding just one VariantInformation[2] and now the test is >>>>>>>>>>>> failing and I have no idea why, so I would aprreciate a second eye on this. >>>>>>>>>>>> >>>>>>>>>>>> I'm probably missing something obvious but I can not see it >>>>>>>>>>>> right now :) >>>>>>>>>>>> >>>>>>>>>>>> Sebi >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> [1]https://issues.jboss.org/browse/AGPUSH-848 >>>>>>>>>>>> [2] >>>>>>>>>>>> https://gist.github.com/sebastienblanc/ea34e7f9fdafbc0785f2#file-gistfile1-java-L30-L35 >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> aerogear-dev mailing list >>>>>>>>>>>> aerogear-dev at lists.jboss.org >>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> aerogear-dev mailing list >>>>>>>>>>> aerogear-dev at lists.jboss.org >>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> aerogear-dev mailing list >>>>>>>>>> aerogear-dev at lists.jboss.org >>>>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> aerogear-dev mailing list >>>>>>>>> aerogear-dev at lists.jboss.org >>>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> aerogear-dev mailing list >>>>>>>> aerogear-dev at lists.jboss.org >>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> aerogear-dev mailing list >>>>>> aerogear-dev at lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> aerogear-dev mailing list >>>>> aerogear-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>> >>>> >>>> >>>> >>>> -- >>>> Matthias Wessendorf >>>> >>>> blog: http://matthiaswessendorf.wordpress.com/ >>>> sessions: http://www.slideshare.net/mwessendorf >>>> twitter: http://twitter.com/mwessendorf >>>> >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> >>> >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >> >> >> >> -- >> Matthias Wessendorf >> >> blog: http://matthiaswessendorf.wordpress.com/ >> sessions: http://www.slideshare.net/mwessendorf >> twitter: http://twitter.com/mwessendorf >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140731/746437c5/attachment-0001.html From scm.blanc at gmail.com Thu Jul 31 09:44:59 2014 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Thu, 31 Jul 2014 15:44:59 +0200 Subject: [aerogear-dev] Help needed on AGPUSH-848 In-Reply-To: References: Message-ID: On Thu, Jul 31, 2014 at 3:17 PM, Matthias Wessendorf wrote: > > > > On Thu, Jul 31, 2014 at 2:52 PM, Sebastien Blanc > wrote: > >> >> >> >> On Thu, Jul 31, 2014 at 2:45 PM, Matthias Wessendorf >> wrote: >> >>> >>> >>> >>> On Thu, Jul 31, 2014 at 2:18 PM, Sebastien Blanc >>> wrote: >>> >>>> >>>> >>>> >>>> On Thu, Jul 31, 2014 at 12:12 PM, Matthias Wessendorf < >>>> matzew at apache.org> wrote: >>>> >>>>> I think original idea was to show the three most busy (in number of >>>>> receives, not installations) >>>>> >>>> The total number or receives for one Variant , right ? >>>> So, if variant A "sended" a first time to 20 receivers and after that >>>> did a selective send 5 : the number that must showned is 25 >>>> And we want the top 3 of this total ? >>>> >>> >>> uhm, there was a thread in the past. Burr added something, and Hylke.... >>> and we were somewhat talked into this (I guess we did not think too much >>> about it :-( ) >>> >>> So... I think..... >>> >>> we perhaps could: >>> * show the most (three) recent variants (and their # of receivers) >>> >> We could do that but then we will need to change the naming >> > > I don't mind renaming ! > > > > > >> >>> But IMO not doing a count. Perhaps that means some code needs to be >>> rewritten... >>> >> >> Well, I just managed to modify the query to really get the 3 variants >> having send to the most receivers : >> >> createQuery("select distinct vmi.variantID, SUM(vmi.receivers), >> vmi.pushApplicationID from VariantMetricInformation vmi" + >> " where vmi.variantID IN (select t.variantID from Variant >> t where t.developer = :developer)" + >> " GROUP BY vmi.variantID ORDER BY SUM(vmi.receivers) " + >> DESC) >> .setMaxResults(3) >> .setParameter("developer", loginName) >> .getResultList(); >> >> And the code don't need to be rewitten (just changing the label on the >> dashboard that is now a bit confusing) >> > > ah, cool; Yeah - I've zero concerns in chaning the label :-) > > > >> >>> >>> Also... "Most active" could mean something else: >>> * TOTAL number of receivers (per variant/app) -> like a count >>> >> Yeah that is what my query above does now >> > > Ok. So you don't like the "show the most (three) recent variants (and > their # of receivers) " ? :-) > Yeah why not :) , we just have to choose something that will be a real useful information, I would like from the rest of the team. Then, if we go for this I need some clarification : - most recent variants, you mean most recent "active" variant, meaning the most recent that sent out a Push Message ? Because if you meant on Variant creation date, we don't have this info :) - Number of receivers, sorry to ask again, I know you make the distinction with installations, but you mean the number of active tokens (i.e : we have 20 "active" (not toggled off) tokens, or the total of receivers for all the sent messages (i.e : Message A was sent to 10 receivers, Message B was sent to 5 receivers, we show 15 ) ? > > > > >> * TOTAL number of messages (per vairant/app) -> like a count on the >>> actual message >>> >>> >>> >>> I think I do (now) like the first (show the most (three) recent variants >>> (and their # of receivers) ) the best :-) >>> >>> >>> >>> >>> >>> >>> >>>> >>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Thu, Jul 31, 2014 at 11:42 AM, Sebastien Blanc >>>> > wrote: >>>>> >>>>>> BTW, >>>>>> I wonder how we had in mind the computing of the 3 busiest variants, >>>>>> what does it mean exactly ? >>>>>> Should we not sum up all the receiver for each >>>>>> VariantMetricInformation and from there get the top 3 ? Not sure this is >>>>>> happening right now, maybe @matzew or @edewit could give more info. >>>>>> >>>>>> >>>>>> >>>>>> On Thu, Jul 31, 2014 at 11:31 AM, Daniel Bevenius < >>>>>> daniel.bevenius at gmail.com> wrote: >>>>>> >>>>>>> Sorry, looking into this and I can't see any easy fix. >>>>>>> The problem as I see it is that the for the same variantId there can >>>>>>> be multiple receivers. But we currently don't know which ApplicationVariant >>>>>>> the receivers belong to. So we cannot match them up in DashBoardService. >>>>>>> This my first time looking at the code so I might be missing >>>>>>> something. So I'd say your first post about the query being wrong is >>>>>>> correct, and we have to take the match the VariantMetricInformation and >>>>>>> match it with a pushApplicationId. Again, I could be way off here :) >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 31 July 2014 10:47, Daniel Bevenius >>>>>>> wrote: >>>>>>> >>>>>>>> Hey Seb, >>>>>>>> >>>>>>>> sure let me take a closer look at this. I'm getting the feeling >>>>>>>> that it might not be as simple as that. Let me push something and we can >>>>>>>> discuss it. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 31 July 2014 10:39, Sebastien Blanc wrote: >>>>>>>> >>>>>>>>> Hi Dan, >>>>>>>>> Not sure if I understand exactly what you meant, could do a small >>>>>>>>> snippet ? >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Thu, Jul 31, 2014 at 10:08 AM, Daniel Bevenius < >>>>>>>>> daniel.bevenius at gmail.com> wrote: >>>>>>>>> >>>>>>>>>> Oh I see. Then I'd say you'll need to change the return type to >>>>>>>>>> either use a custom object for the key in the map, or perhaps return a list >>>>>>>>>> with that came custom object. What ever makes the most sense in this use >>>>>>>>>> case. Makes sense? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 31 July 2014 09:39, Sebastien Blanc >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> Well, several VariantMetricInformation instances can have the >>>>>>>>>>> same VariantID, at each send , one is created : >>>>>>>>>>> https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/push%2Fsrc%2Fmain%2Fjava%2Forg%2Fjboss%2Faerogear%2Funifiedpush%2Fmessage%2FSenderServiceImpl.java#L133 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Thu, Jul 31, 2014 at 9:34 AM, Daniel Bevenius < >>>>>>>>>>> daniel.bevenius at gmail.com> wrote: >>>>>>>>>>> >>>>>>>>>>>> Is this because variantFour and variantFive have the same >>>>>>>>>>>> variantId (231543432434)? When added to the map only one will exist later >>>>>>>>>>>> in findTopThreeBusyVariantIDs. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 31 July 2014 09:20, Sebastien Blanc >>>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Morning Peeps, >>>>>>>>>>>>> >>>>>>>>>>>>> I'm currently trying to fix AGPUSH-848[1]. >>>>>>>>>>>>> Basically, the number of receivers shown in the top3 list is >>>>>>>>>>>>> not always accurate. >>>>>>>>>>>>> >>>>>>>>>>>>> I suspect that something is wrong with this query : >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/model/jpa/src/main/java/org/jboss/aerogear/unifiedpush/jpa/dao/impl/JPAPushMessageInformationDao.java#L99-L104 >>>>>>>>>>>>> >>>>>>>>>>>>> I have change this test case : >>>>>>>>>>>>> >>>>>>>>>>>>> https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/model%2Fjpa%2Fsrc%2Ftest%2Fjava%2Forg%2Fjboss%2Faerogear%2Funifiedpush%2Fjpa%2FPushMessageInformationDaoTest.java#L251 >>>>>>>>>>>>> >>>>>>>>>>>>> By adding just one VariantInformation[2] and now the test is >>>>>>>>>>>>> failing and I have no idea why, so I would aprreciate a second eye on this. >>>>>>>>>>>>> >>>>>>>>>>>>> I'm probably missing something obvious but I can not see it >>>>>>>>>>>>> right now :) >>>>>>>>>>>>> >>>>>>>>>>>>> Sebi >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> [1]https://issues.jboss.org/browse/AGPUSH-848 >>>>>>>>>>>>> [2] >>>>>>>>>>>>> https://gist.github.com/sebastienblanc/ea34e7f9fdafbc0785f2#file-gistfile1-java-L30-L35 >>>>>>>>>>>>> >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> aerogear-dev mailing list >>>>>>>>>>>>> aerogear-dev at lists.jboss.org >>>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> aerogear-dev mailing list >>>>>>>>>>>> aerogear-dev at lists.jboss.org >>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> aerogear-dev mailing list >>>>>>>>>>> aerogear-dev at lists.jboss.org >>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> aerogear-dev mailing list >>>>>>>>>> aerogear-dev at lists.jboss.org >>>>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> aerogear-dev mailing list >>>>>>>>> aerogear-dev at lists.jboss.org >>>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> aerogear-dev mailing list >>>>>>> aerogear-dev at lists.jboss.org >>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> aerogear-dev mailing list >>>>>> aerogear-dev at lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Matthias Wessendorf >>>>> >>>>> blog: http://matthiaswessendorf.wordpress.com/ >>>>> sessions: http://www.slideshare.net/mwessendorf >>>>> twitter: http://twitter.com/mwessendorf >>>>> >>>>> _______________________________________________ >>>>> aerogear-dev mailing list >>>>> aerogear-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>> >>>> >>>> >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> >>> >>> >>> >>> -- >>> Matthias Wessendorf >>> >>> blog: http://matthiaswessendorf.wordpress.com/ >>> sessions: http://www.slideshare.net/mwessendorf >>> twitter: http://twitter.com/mwessendorf >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140731/4916ea44/attachment-0001.html From matzew at apache.org Thu Jul 31 09:54:18 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Thu, 31 Jul 2014 15:54:18 +0200 Subject: [aerogear-dev] Help needed on AGPUSH-848 In-Reply-To: References: Message-ID: On Thu, Jul 31, 2014 at 3:44 PM, Sebastien Blanc wrote: > > > > On Thu, Jul 31, 2014 at 3:17 PM, Matthias Wessendorf > wrote: > >> >> >> >> On Thu, Jul 31, 2014 at 2:52 PM, Sebastien Blanc >> wrote: >> >>> >>> >>> >>> On Thu, Jul 31, 2014 at 2:45 PM, Matthias Wessendorf >>> wrote: >>> >>>> >>>> >>>> >>>> On Thu, Jul 31, 2014 at 2:18 PM, Sebastien Blanc >>>> wrote: >>>> >>>>> >>>>> >>>>> >>>>> On Thu, Jul 31, 2014 at 12:12 PM, Matthias Wessendorf < >>>>> matzew at apache.org> wrote: >>>>> >>>>>> I think original idea was to show the three most busy (in number of >>>>>> receives, not installations) >>>>>> >>>>> The total number or receives for one Variant , right ? >>>>> So, if variant A "sended" a first time to 20 receivers and after that >>>>> did a selective send 5 : the number that must showned is 25 >>>>> And we want the top 3 of this total ? >>>>> >>>> >>>> uhm, there was a thread in the past. Burr added something, and >>>> Hylke.... and we were somewhat talked into this (I guess we did not think >>>> too much about it :-( ) >>>> >>>> So... I think..... >>>> >>>> we perhaps could: >>>> * show the most (three) recent variants (and their # of receivers) >>>> >>> We could do that but then we will need to change the naming >>> >> >> I don't mind renaming ! >> >> >> >> >> >>> >>>> But IMO not doing a count. Perhaps that means some code needs to be >>>> rewritten... >>>> >>> >>> Well, I just managed to modify the query to really get the 3 variants >>> having send to the most receivers : >>> >>> createQuery("select distinct vmi.variantID, SUM(vmi.receivers), >>> vmi.pushApplicationID from VariantMetricInformation vmi" + >>> " where vmi.variantID IN (select t.variantID from >>> Variant t where t.developer = :developer)" + >>> " GROUP BY vmi.variantID ORDER BY SUM(vmi.receivers) " + >>> DESC) >>> .setMaxResults(3) >>> .setParameter("developer", loginName) >>> .getResultList(); >>> >>> And the code don't need to be rewitten (just changing the label on the >>> dashboard that is now a bit confusing) >>> >> >> ah, cool; Yeah - I've zero concerns in chaning the label :-) >> >> >> >>> >>>> >>>> Also... "Most active" could mean something else: >>>> * TOTAL number of receivers (per variant/app) -> like a count >>>> >>> Yeah that is what my query above does now >>> >> >> Ok. So you don't like the "show the most (three) recent variants (and >> their # of receivers) " ? :-) >> > Yeah why not :) , we just have to choose something that will be a real > useful information, I would like from the rest of the team. > yes, I'd be interested in hearing from others as well > Then, if we go for this I need some clarification : > - most recent variants, you mean most recent "active" variant, meaning the > most recent that sent out a Push Message ? > yep > Because if you meant on Variant creation date, we don't have this info :) > - Number of receivers, sorry to ask again, I know you make the distinction > with installations, but you mean the number of active tokens (i.e : we have > 20 "active" (not toggled off) tokens, or the total of receivers for all > the sent messages (i.e : Message A was sent to 10 receivers, Message B was > sent to 5 receivers, we show 15 ) ? > I'd expect a 5 here (or a 15) :) - not sure -M > > >> >> >> >> >>> * TOTAL number of messages (per vairant/app) -> like a count on the >>>> actual message >>>> >>>> >>>> >>>> I think I do (now) like the first (show the most (three) recent >>>> variants (and their # of receivers) ) the best :-) >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>> >>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Thu, Jul 31, 2014 at 11:42 AM, Sebastien Blanc < >>>>>> scm.blanc at gmail.com> wrote: >>>>>> >>>>>>> BTW, >>>>>>> I wonder how we had in mind the computing of the 3 busiest variants, >>>>>>> what does it mean exactly ? >>>>>>> Should we not sum up all the receiver for each >>>>>>> VariantMetricInformation and from there get the top 3 ? Not sure this is >>>>>>> happening right now, maybe @matzew or @edewit could give more info. >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Thu, Jul 31, 2014 at 11:31 AM, Daniel Bevenius < >>>>>>> daniel.bevenius at gmail.com> wrote: >>>>>>> >>>>>>>> Sorry, looking into this and I can't see any easy fix. >>>>>>>> The problem as I see it is that the for the same variantId there >>>>>>>> can be multiple receivers. But we currently don't know which >>>>>>>> ApplicationVariant the receivers belong to. So we cannot match them up in >>>>>>>> DashBoardService. >>>>>>>> This my first time looking at the code so I might be missing >>>>>>>> something. So I'd say your first post about the query being wrong is >>>>>>>> correct, and we have to take the match the VariantMetricInformation and >>>>>>>> match it with a pushApplicationId. Again, I could be way off here :) >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 31 July 2014 10:47, Daniel Bevenius >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Hey Seb, >>>>>>>>> >>>>>>>>> sure let me take a closer look at this. I'm getting the feeling >>>>>>>>> that it might not be as simple as that. Let me push something and we can >>>>>>>>> discuss it. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On 31 July 2014 10:39, Sebastien Blanc >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> Hi Dan, >>>>>>>>>> Not sure if I understand exactly what you meant, could do a small >>>>>>>>>> snippet ? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Thu, Jul 31, 2014 at 10:08 AM, Daniel Bevenius < >>>>>>>>>> daniel.bevenius at gmail.com> wrote: >>>>>>>>>> >>>>>>>>>>> Oh I see. Then I'd say you'll need to change the return type to >>>>>>>>>>> either use a custom object for the key in the map, or perhaps return a list >>>>>>>>>>> with that came custom object. What ever makes the most sense in this use >>>>>>>>>>> case. Makes sense? >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 31 July 2014 09:39, Sebastien Blanc >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>>> Well, several VariantMetricInformation instances can have the >>>>>>>>>>>> same VariantID, at each send , one is created : >>>>>>>>>>>> https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/push%2Fsrc%2Fmain%2Fjava%2Forg%2Fjboss%2Faerogear%2Funifiedpush%2Fmessage%2FSenderServiceImpl.java#L133 >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Thu, Jul 31, 2014 at 9:34 AM, Daniel Bevenius < >>>>>>>>>>>> daniel.bevenius at gmail.com> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Is this because variantFour and variantFive have the same >>>>>>>>>>>>> variantId (231543432434)? When added to the map only one will exist later >>>>>>>>>>>>> in findTopThreeBusyVariantIDs. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On 31 July 2014 09:20, Sebastien Blanc >>>>>>>>>>>>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> Morning Peeps, >>>>>>>>>>>>>> >>>>>>>>>>>>>> I'm currently trying to fix AGPUSH-848[1]. >>>>>>>>>>>>>> Basically, the number of receivers shown in the top3 list is >>>>>>>>>>>>>> not always accurate. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I suspect that something is wrong with this query : >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/model/jpa/src/main/java/org/jboss/aerogear/unifiedpush/jpa/dao/impl/JPAPushMessageInformationDao.java#L99-L104 >>>>>>>>>>>>>> >>>>>>>>>>>>>> I have change this test case : >>>>>>>>>>>>>> >>>>>>>>>>>>>> https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/model%2Fjpa%2Fsrc%2Ftest%2Fjava%2Forg%2Fjboss%2Faerogear%2Funifiedpush%2Fjpa%2FPushMessageInformationDaoTest.java#L251 >>>>>>>>>>>>>> >>>>>>>>>>>>>> By adding just one VariantInformation[2] and now the test is >>>>>>>>>>>>>> failing and I have no idea why, so I would aprreciate a second eye on this. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I'm probably missing something obvious but I can not see it >>>>>>>>>>>>>> right now :) >>>>>>>>>>>>>> >>>>>>>>>>>>>> Sebi >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> [1]https://issues.jboss.org/browse/AGPUSH-848 >>>>>>>>>>>>>> [2] >>>>>>>>>>>>>> https://gist.github.com/sebastienblanc/ea34e7f9fdafbc0785f2#file-gistfile1-java-L30-L35 >>>>>>>>>>>>>> >>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>> aerogear-dev mailing list >>>>>>>>>>>>>> aerogear-dev at lists.jboss.org >>>>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> aerogear-dev mailing list >>>>>>>>>>>>> aerogear-dev at lists.jboss.org >>>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> aerogear-dev mailing list >>>>>>>>>>>> aerogear-dev at lists.jboss.org >>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> aerogear-dev mailing list >>>>>>>>>>> aerogear-dev at lists.jboss.org >>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> aerogear-dev mailing list >>>>>>>>>> aerogear-dev at lists.jboss.org >>>>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> aerogear-dev mailing list >>>>>>>> aerogear-dev at lists.jboss.org >>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> aerogear-dev mailing list >>>>>>> aerogear-dev at lists.jboss.org >>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Matthias Wessendorf >>>>>> >>>>>> blog: http://matthiaswessendorf.wordpress.com/ >>>>>> sessions: http://www.slideshare.net/mwessendorf >>>>>> twitter: http://twitter.com/mwessendorf >>>>>> >>>>>> _______________________________________________ >>>>>> aerogear-dev mailing list >>>>>> aerogear-dev at lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> aerogear-dev mailing list >>>>> aerogear-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>> >>>> >>>> >>>> >>>> -- >>>> Matthias Wessendorf >>>> >>>> blog: http://matthiaswessendorf.wordpress.com/ >>>> sessions: http://www.slideshare.net/mwessendorf >>>> twitter: http://twitter.com/mwessendorf >>>> >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> >>> >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >> >> >> >> -- >> Matthias Wessendorf >> >> blog: http://matthiaswessendorf.wordpress.com/ >> sessions: http://www.slideshare.net/mwessendorf >> twitter: http://twitter.com/mwessendorf >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140731/f2b72db7/attachment-0001.html From matzew at apache.org Thu Jul 31 10:23:13 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Thu, 31 Jul 2014 16:23:13 +0200 Subject: [aerogear-dev] [UnifiedPush Server] Openshift update (of Beta1) In-Reply-To: References: Message-ID: Thanks Bruno for merging it! It's now live! -Matthias On Wed, Jul 30, 2014 at 4:34 PM, Matthias Wessendorf wrote: > I have done some updates to the PR, based on review feedback. > > Please test the given 'rhc' script, to check if this can be released, or > not. > > -M > > > On Tue, Jul 29, 2014 at 9:32 PM, Matthias Wessendorf > wrote: > >> Good evening folks! >> >> >> Now that we got the 1.0.0.Beta1 release out, I used its tag and ran the >> 'openshift' profile. >> >> The generated WARs (and a new version label) are made available in this >> PR: >> >> https://github.com/aerogear/openshift-origin-cartridge-aerogear-push/pull/19 >> >> >> If you want to test it, you simple need to run the following command on >> your shell (assuming 'rhc' is installed) >> >> rhc app create --no-git LATESTUPS >> https://cartreflect-claytondev.rhcloud.com/reflect\?github\=matzew/openshift-origin-cartridge-aerogear-push >> >> >> Feedback welcome! >> >> Thanks >> >> -- >> Matthias Wessendorf >> >> blog: http://matthiaswessendorf.wordpress.com/ >> sessions: http://www.slideshare.net/mwessendorf >> twitter: http://twitter.com/mwessendorf >> > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140731/4d2da5f8/attachment.html From scm.blanc at gmail.com Thu Jul 31 12:37:02 2014 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Thu, 31 Jul 2014 18:37:02 +0200 Subject: [aerogear-dev] [UPS] What should the Top 3 Most Active Variants shows ? Message-ID: Hi, I decided to start a new thread after some discussions we had on a previous thread[1] Basically, we are talking about this part of the dashboard : [image: screenshot-1.png - Latest 25/Jul/14 8:20 AM - Sebastien Blanc] It appeared that is not really clear what we want to show there, as a side note, the current query behind this is not correct and should change whatever we decide. So, what can we show here : 1. Show the most (three) recent active variants (and their # of receivers) Active means here, the 3 latest variants that sent a Push Message. The term "receivers" can also be confusing , do we want to show : 1.a : The number of receivers/active tokens that received the last Push message (i.e : Push Message A sent to 10 people and Push Message B to 5 people, we show 5) ? 1.b : The total number of receivers/actives tokens of this variant (i.e : Push Message A sent to 10 people and Push Message B to 5 people, we show 15) ? 1.c : The total number of Push Messages sent (i.e : Push Message A sent to 10 people and Push Message B to 5 people, we show 2). ? 2. Show the most active variants (and their # of receivers) Almost same than 1. but here we look at all the variants even those without an recent activity. Here again 1.a/1.b or 1.c applies. The core question, IMO, is what would be an useful information for the user ? Sebi [1]http://lists.jboss.org/pipermail/aerogear-dev/2014-July/008548.html -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140731/c401c16e/attachment.html